Kubernetes Is Now a Production Reality

Kubernetes has moved well beyond the proof-of-concept stage. According to the Alcide Kubernetes Security Survey — which polled 200 professionals across development, operations, security, and cloud architecture — 45% of companies were already running Kubernetes in production at the time of publication, with production adoption having risen 120% in the preceding year. Approximately 37% of organisations were running Kubernetes clusters across hybrid or multi-cloud environments.

The top drivers behind this growth were:

• Microservices adoption — cited by 60% of respondents as a primary driver
• Innovation velocity and time-to-market pressure — cited by approximately 53%
• Application scaling requirements — cited by 44%

The data confirms what many in the industry have observed: Kubernetes has effectively won the container orchestration market. All three major cloud providers — Amazon Web Services, Google Cloud, and Microsoft Azure — offer managed Kubernetes services (EKS, GKE, and AKS respectively), further cementing its position as the default choice for teams running containerised workloads at scale.

“As multi-cloud adoption continues to accelerate, it’s been highly correlated with higher Kubernetes adoption. Kubernetes will continue to remain an orchestration tool of choice as it offers broad multi-cloud support and can be leveraged by many organisations to run applications across on-prem and cloud environments.”

— Ben Newton, Sumo Logic

Security Is Not Keeping Pace with Adoption

Rapid adoption has outpaced security maturity across most organisations. The Alcide report included an analysis of 5,000 Kubernetes deployments that revealed stark security gaps:

• 89% of deployments encoded sensitive information — such as passwords and tokens — in plain text, rather than using Kubernetes Secrets as intended.
• Over 75% of scanned deployments used workloads that mounted high-risk host file systems such as /proc, creating potential privilege escalation paths.
• None of the surveyed environments implemented any form of network segmentation using Kubernetes NetworkPolicies.

These findings point to a widespread disconnect between operational velocity and security hygiene. Many teams are deploying Kubernetes clusters quickly but are not applying even baseline hardening practices.

The survey data reflects this uncertainty at the team level: roughly half of respondents said they were not confident their Kubernetes deployments were secure, and 67% anticipated needing to increase their use of Kubernetes-specific security tooling in the near term.

The Complexity Problem: Multi-Cluster Environments

Managing security across a single Kubernetes cluster is already non-trivial. In multi-cluster and multi-cloud environments, complexity grows considerably. SecOps teams must track configuration drift, enforce consistent policies, and stay current with Kubernetes CVEs across environments that may span multiple cloud providers and on-premises infrastructure.

The Alcide report noted that this complexity is compounded by poor integration between security workflows and DevOps pipelines. When security tooling operates in isolation from CI/CD processes, vulnerabilities are often caught too late — or not at all.

Compounding the issue: 44% of Kubernetes users in the survey acknowledged that the platform remains “something of a black box” to them, suggesting that many teams are operating clusters without a full understanding of how control-plane components, RBAC, admission controllers, or network policies actually function.

Policy as Code: Shifting Security Left

One of the most promising trends in Kubernetes security is the formalisation of security policy as code — embedding security rules directly into the deployment pipeline rather than applying them as an afterthought at runtime.

Kubernetes-native primitives such as ConfigMaps and Custom Resource Definitions (CRDs) make it possible to define, version, and enforce configuration and security rules in the same YAML files that describe application workloads. This enables security controls to travel with the application through the CI/CD pipeline, reducing the gap between what is tested and what is deployed.

“Kubernetes ConfigMaps and Custom Resource Definitions (CRDs) are making it possible for configurations and rules to be automated right into the CI/CD and DevOps pipeline. DevOps teams will be much better equipped to analyse application behaviour and set security policies for any and all workload deployments via YAML files.”

— Glen Kosaka, Vice President of Product, NeuVector

Tools in this space — including Open Policy Agent (OPA), Kyverno, and various admission webhook controllers — allow teams to enforce policies such as preventing privileged containers, requiring resource limits, or blocking images from untrusted registries, all before workloads are admitted to the cluster.

Automation Is Essential Given the Skills Gap

The IT security skills shortage is well-documented, and the emergence of Kubernetes and cloud-native architectures has added a new dimension to it. Securing containerised workloads requires familiarity with a distinct threat model: ephemeral workloads, shared kernel namespaces, lateral movement via the API server, supply chain risks in container images, and runtime anomaly detection — all of which differ significantly from traditional VM or bare-metal security.

“The IT skills shortage will continue to plague the market, especially for new technologies such as Kubernetes, and what is by now a chronic shortage in skilled IT security professionals. It will drive organisations to seek solutions that provide a high degree of automation, with ‘zero-configuration’ out-of-the-box capabilities that provide value immediately, and don’t require a lot of integration work or management overhead.”

— Rani Osnat, Vice President of Strategy, Aqua Security

This demand is pushing vendors toward managed security services and automated tooling that can detect misconfigurations, flag anomalous behaviour, and apply remediations without requiring deep Kubernetes expertise from every member of an operations team.

Key Kubernetes Security Practices Teams Should Prioritise

Based on the gaps identified in the survey data, the following practices represent high-value, low-complexity starting points for improving Kubernetes security posture:

1. Use Kubernetes Secrets correctly — Store sensitive data (API keys, passwords, certificates) using the Secrets API, and consider integrating with an external secrets manager such as HashiCorp Vault or AWS Secrets Manager for stronger protection at rest.
2. Define and enforce NetworkPolicies — By default, all pods in a Kubernetes cluster can communicate freely. Implement NetworkPolicies to restrict inter-pod traffic to only what is explicitly required.
3. Avoid mounting sensitive host paths — Restrict workloads from accessing host file systems like /proc, /sys, or the Docker socket, which can be exploited to escape container isolation.
4. Enable RBAC and apply least-privilege principles — Review ClusterRole and RoleBinding configurations regularly. Avoid wildcard permissions and prefer namespace-scoped roles over cluster-wide ones.
5. Integrate image scanning into CI/CD — Scan container images for known CVEs at build time and enforce policies that block deployment of images with critical vulnerabilities.
6. Implement admission control — Use tools like OPA/Gatekeeper or Kyverno to enforce security policies at the point of admission, before workloads reach the scheduler.
7. Enable audit logging — Kubernetes API server audit logs provide visibility into who did what and when. Ensure logs are captured and fed into a SIEM or log management platform.

Looking Forward

Kubernetes has achieved de facto standardisation as the container orchestration platform of record for enterprise workloads. The next phase of maturity will be defined not by adoption rates, but by security posture. Organisations that treat Kubernetes security as a continuous, automated, pipeline-integrated discipline — rather than a periodic audit or point-in-time review — will be best positioned to operate cloud-native infrastructure safely at scale.

The combination of policy as code, automated admission control, runtime anomaly detection, and managed tooling is making it increasingly feasible to close the gap between Kubernetes adoption velocity and security maturity — even in organisations where deep Kubernetes expertise remains scarce.

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.