Kubernetes is not a platform: it is a toolkit

Kubernetes is a toolkit, not a platform, according to a team that claims to have "built a platform" because it runs Kubernetes. However, developers still need to assemble various components such as Deployments, Services, and HorizontalPodAutoscalers by hand. The Kubernetes project itself emphasizes this distinction in its overview documentation, stating that it is "not a traditional, all-inclusive PaaS" and provides "the building blocks for building developer platforms."

In other words, Kubernetes offers a robust control plane and programmable foundation, but the actual platform still needs to be constructed by the teams using it. This realization often leads to the categorization error where teams mistakenly consider Kubernetes as their platform, when in reality, it is merely the substrate upon which a platform should be built.

The core components that make Kubernetes valuable include strong primitives, a programmable control plane, declarative desired state reconciliation loops, service discovery, rollout machinery, and extensibility through Custom Resource Definitions (CRDs) and controllers. These elements form a solid foundation for building a platform, but they are not the entire platform itself.

The confusion between a toolkit and a platform arises when teams assume that simply running Kubernetes equates to providing a full-fledged platform. However, the actual platform is the opinionated layer built on top of Kubernetes, providing self-service interfaces, paved roads, policies, defaults, documentation, and support boundaries.

This layer should simplify the process of creating and managing applications, rather than requiring developers to possess extensive Kubernetes knowledge. The key takeaway is that the complexity of Kubernetes remains unchanged; it is simply shifted from the cluster infrastructure team to the consuming teams, who now need to learn and manage more aspects of the platform.

This misunderstanding of Kubernetes as a platform can lead to a situation where developers still require a deep understanding of various Kubernetes concepts, such as request and limit interactions with scheduling, HPA behavior, PodDisruptionBudget requirements, NetworkPolicy defaults, and standard ingress or certificate paths. The solution lies in creating a thin, viable platform that provides a clear, safe, and repeatable way for developers to develop and deploy applications.

This platform can start as simple as a single golden path for a standard web service, a starter template with pre-wired defaults, a single CI path, documented service exposure methods, and a centralized place to request databases or secrets with built-in guardrails. Even a minimal platform can significantly reduce cognitive load and improve developer productivity, demonstrating that the value of Kubernetes as a platform lies in the clarity, safety, and repetition it offers to developers, not in the complexity of the underlying technology.