Originally inspired by a piece published on ContainerJournal.com. The analysis below represents an independent technical discussion of the same themes.
Kubernetes has become the de facto standard for container orchestration, and for good reason. It offers powerful scheduling, self-healing, service discovery, and a rich ecosystem of extensions. Yet broad adoption does not mean the project is without flaws. If Kubernetes is going to remain the dominant open-source orchestrator, its community needs to honestly address the friction points that slow adoption and frustrate operators.
Below are four areas where Kubernetes could meaningfully improve.
1. The Installation Process
Installing a production-grade Kubernetes cluster from scratch remains one of the most intimidating tasks in modern infrastructure work. The platform is composed of many moving parts — the API server, etcd, the controller manager, the scheduler, the Kubelet, kube-proxy, a CNI plugin, and optionally the Dashboard — and each component must be configured, secured, and validated individually.
Tools like kubeadm have improved the situation considerably, but they still require operators to make decisions about networking, certificate authority management, and add-on configuration before a cluster is truly usable. Managed offerings from cloud providers (EKS, GKE, AKS) solve this problem for teams that are willing to accept a hosted control plane, but they introduce vendor lock-in and cost concerns.
The deeper issue is the lack of a single, universally accepted, community-owned installer. Individual Kubernetes distributions maintain their own tooling — OpenShift has its installer, Rancher has its own approach, and so on. If the broader community pooled those efforts into one well-documented, opinionated installer, operators across organisations of all sizes would benefit from a smoother, more consistent experience.
2. YAML as the Only First-Class Configuration Format
Kubernetes leans heavily on YAML for defining resources — Deployments, Services, ConfigMaps, Ingresses, and everything in between. YAML is human-readable and reasonably expressive, but it has well-known drawbacks: significant whitespace sensitivity, poor support for comments in some toolchains, and limited templating out of the box.
More importantly, Kubernetes essentially mandates YAML. While tools like Helm, Kustomize, and CUE Lang exist to work around the limitations, they are third-party abstractions layered on top of the same underlying format. The Kubernetes API itself does accept JSON (since YAML is a superset of JSON), but the community ecosystem, documentation, and tooling is almost entirely YAML-first.
Greater flexibility here — whether through first-class support for additional formats, better native templating, or a standardised policy language for generating manifests — would make Kubernetes more accessible to operators who come from different configuration management backgrounds.
3. Multi-Cluster Support
Running workloads across multiple Kubernetes clusters is a real-world requirement for many organisations. Common drivers include geographic distribution for latency reduction, environment isolation (production versus staging), compliance requirements that mandate data residency, and blast-radius reduction for failure scenarios.
Kubernetes Federation (originally KubeFed) was the project’s primary answer to this use case, but it never reached the level of maturity or adoption that multi-cluster users needed. The ecosystem has since produced alternatives — tools like Admiralty, Liqo, Karmada, and Cluster API address federation and multi-cluster lifecycle management in various ways — but none of these is a standard, built-in capability of Kubernetes itself.
The standard advice to use a single cluster and divide it with namespaces is sound for many workloads, but it does not provide the level of network, security, or failure isolation that multiple clusters offer. Elevating multi-cluster management to a first-class concern in the Kubernetes project — with stable APIs and clear operational guidance — would address a gap that a significant portion of operators already live with today.
4. Usability at Smaller Scale
Kubernetes was designed to solve the orchestration problems that organisations operating at massive scale — thousands of nodes, tens of thousands of pods — face every day. That origin shows in the architecture. Running a highly available control plane with three etcd nodes, multiple API server replicas, and dedicated node pools is reasonable if you have hundreds of workloads. It is hard to justify for a team deploying three or four microservices.
Lightweight distributions such as K3s (from Rancher/SUSE) and MicroK8s (from Canonical) have done useful work in this space, stripping out cloud-provider integrations and embedding dependencies to reduce the resource footprint. K3s in particular can run on hardware as modest as a Raspberry Pi. However, these distributions sometimes lag behind upstream Kubernetes in feature availability and may not be suitable for all production use cases.
A more intentional investment from the core Kubernetes project in small-scale profiles — perhaps officially supported configuration presets or a tiered architecture that allows non-HA single-node control planes to graduate smoothly to multi-node HA — would lower the barrier for smaller teams and edge computing scenarios without requiring them to choose a community fork.
Conclusion
None of these criticisms diminish Kubernetes’ genuine achievements. It has unified a fragmented ecosystem, enabled enormous operational automation, and created a platform rich enough to support an industry of extensions and tools. But the project’s long-term health depends on continuously lowering friction for new adopters and addressing the real operational pain points of existing users.
A universal, community-owned installer; more flexibility in configuration formats; mature multi-cluster primitives; and better small-scale support would make Kubernetes a stronger tool for a much wider audience — not just the teams deploying at Google-or-Netflix scale.