Kubernetes (K8s) is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications across a cluster of machines. Google open-sourced it in 2014, and the Cloud Native Computing Foundation (CNCF) maintains it today.
Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. Google open-sourced Kubernetes in June 2014, and the Cloud Native Computing Foundation (CNCF) has maintained it since 2015. Kubernetes groups containers into Pods, schedules Pods across a cluster of machines, and restarts failed workloads automatically.
Key Takeaways
- Kubernetes schedules containers across a cluster, restarts failed workloads, and scales applications automatically. Google open-sourced it in June 2014, and version 1.0 shipped on July 21, 2015, when the project was donated to the newly formed CNCF.
- A Kubernetes cluster has two parts: a control plane (kube-apiserver, etcd, kube-scheduler, and controller managers) that makes decisions, and worker nodes (kubelet, container runtime, kube-proxy) that run the workloads.
- The project ships three minor releases per year, each supported for roughly 14 months. Kubernetes v1.36, released on April 22, 2026, is the current version.
- Kubernetes Secrets are base64 encoded, not encrypted, by default. Production clusters should enable encryption at rest; the KMS v2 provider has been stable since v1.29.
- The Ingress NGINX controller was retired in March 2026 and receives no further security patches. The Gateway API is its recommended successor.
How Kubernetes Works
Kubernetes works on a declarative model: you describe the state you want in YAML or JSON, and controllers continuously reconcile the cluster toward that state. If you declare that a deployment should run five replicas of a service and one crashes, Kubernetes detects the gap and starts a replacement without human intervention.
Consider a company running an ERP system with separate modules for inventory, HR, and finance. As demand grows, Kubernetes scales the containers behind each module, balances traffic across servers, and restarts failed services. It also runs liveness probes (is the application still running?) and readiness probes (can it accept traffic yet?) so unhealthy containers are restarted or taken out of rotation before users notice. Because CNCF maintains Kubernetes as vendor-neutral open source, the same cluster definition runs on-premises, in any major cloud, or in hybrid environments.
Kubernetes vs Docker Swarm
Docker Swarm is Docker’s built-in clustering mode; it is simpler to set up than Kubernetes but covers a much narrower set of orchestration needs.
| Attribute | Docker Swarm | Kubernetes |
| Setup | Built into Docker; minutes to start | Steeper learning curve; managed services (EKS, AKS, GKE) reduce the burden |
| Scaling | Manual service scaling | Automatic horizontal scaling with the Horizontal Pod Autoscaler (HPA) |
| Self-healing | Restarts failed containers | Restarts, reschedules, and replaces Pods using liveness and readiness probes |
| Rollouts | Rolling updates, limited controls | Rolling updates plus automated rollback on failed health checks |
| Ecosystem | Docker toolchain | CNCF ecosystem: Helm, Prometheus, cert-manager, Gateway API implementations |
| Best for | Small teams, simple workloads | Production systems at scale, microservices, hybrid and multi-cloud |
Key Features of Kubernetes
Kubernetes bundles the operational tasks that teams once scripted by hand into built-in, declarative features.
- Horizontal scaling: The Horizontal Pod Autoscaler adds or removes Pods based on metrics such as CPU and memory. Resource requests and limits let the scheduler bin-pack containers onto nodes without overloading any single machine.
- Self-healing: The kubelet restarts containers that fail liveness probes and withholds traffic from Pods that fail readiness probes.
- Service discovery and load balancing: Every Service gets a DNS name and a stable virtual IP. ClusterIP exposes a Service inside the cluster, NodePort opens a port on each node, and LoadBalancer provisions a cloud load balancer for external traffic.
- Storage orchestration: PersistentVolumes and PersistentVolumeClaims decouple storage from Pods, and the Container Storage Interface (CSI) plugs in backends such as AWS EBS, Google Persistent Disk, or NFS with dynamic provisioning through StorageClasses.
- Secrets and configuration: ConfigMaps hold configuration and Secrets hold sensitive values such as API keys. Secrets are base64 encoded, not encrypted, by default; enable encryption at rest, and use the KMS v2 provider (stable since v1.29) to protect them with keys held in an external key management service.
- Automated rollouts and rollbacks: Deployments update Pods gradually while watching health probes and roll back to the last stable version when an update fails.
- Batch workloads: Jobs run tasks to completion, and CronJobs run them on a schedule, such as nightly backups or analytics runs.
- Dual-stack networking and extensibility: Pods and Services can carry both IPv4 and IPv6 addresses, and Custom Resource Definitions extend the Kubernetes API for tools such as Prometheus operators or cert-manager.
Kubernetes Architecture
A Kubernetes cluster splits responsibilities between a control plane that makes global decisions and worker nodes that run application workloads.
Control Plane Components
- kube-apiserver: The front door of the cluster. Every kubectl command, controller, and node interaction passes through the API server.
- etcd: A consistent key-value store holding all cluster state and configuration. It is the source of truth: if a control plane component restarts, it recovers the current state from etcd.
- kube-scheduler: Assigns newly created Pods to nodes based on resource requests, affinity rules, and constraints.
- kube-controller-manager: Runs the reconciliation loops that keep actual state matching desired state, such as replacing Pods when a node fails.
- cloud-controller-manager: Integrates the cluster with a cloud provider’s APIs for load balancers, routes, and node lifecycle.
Worker Node Components
- kubelet: The agent on each node that ensures the containers described in Pod specs are running and healthy.
- Container runtime: The software that actually runs containers through the Container Runtime Interface (CRI), typically containerd or CRI-O. Kubernetes removed the Docker-specific dockershim in v1.24 (May 2022); images built with Docker still run unchanged.
- kube-proxy: Maintains network rules on each node so Service traffic reaches the right Pods.
Kubernetes Objects
| Object | What it does | Example use case |
| Pod | Smallest deployable unit; one or more containers sharing network and storage | Running one instance of an Nginx web server |
| Service | Stable network endpoint for a set of Pods | Connecting a frontend to a backend API |
| Deployment | Manages ReplicaSets, rolling updates, and rollbacks | Releasing a new microservice version with zero downtime |
| ReplicaSet | Keeps a specified number of identical Pods running | Maintaining five web server replicas for availability |
| ConfigMap / Secret | Hold configuration and sensitive values | Database connection strings; API credentials |
| StatefulSet | Stable identity and storage for stateful apps | Running MongoDB or MySQL with per-instance volumes |
| DaemonSet | Runs a Pod on every node | Deploying a logging or monitoring agent cluster-wide |
| Job / CronJob | Run tasks once or on a schedule | Nightly database backups |
Networking: From Ingress to Gateway API
The way external traffic enters a Kubernetes cluster changed materially in 2026, and any team still standardizing on the Ingress NGINX controller needs to act.
The Ingress API routes external HTTP and HTTPS traffic to Services inside the cluster and can terminate TLS. The API itself remains part of Kubernetes but is feature frozen. Its most popular implementation, the Ingress NGINX controller, was retired by the Kubernetes project on March 24, 2026, after a November 12, 2025 announcement; the repository is read-only and receives no further bug fixes or CVE patches.
In a January 29, 2026 statement, the Kubernetes Steering and Security Response Committees noted that roughly half of cloud native environments run Ingress NGINX and urged immediate migration.
The Gateway API, generally available since v1.0 in October 2023, is the recommended successor. It separates infrastructure concerns (Gateways) from application routing (HTTPRoutes), supports richer traffic controls, and behaves consistently across implementations such as Envoy Gateway, Cilium, and cloud provider gateways.
The ingress2gateway tool, which reached 1.0 in March 2026, converts existing Ingress resources to Gateway API equivalents. Teams that prefer to stay on the Ingress API can move to an actively maintained third-party controller such as Traefik, HAProxy, or the commercial F5 NGINX Ingress Controller.
Kubernetes in DevOps and CI/CD
Kubernetes gives DevOps teams one deployment target and one operational model across every environment, which is why it anchors most modern CI/CD pipelines.
Pipelines built with Jenkins, GitLab CI, or similar tools build a container image, push it to a registry, and apply an updated manifest to the cluster; Kubernetes then performs the rolling update and rolls back automatically if health checks fail.
In GitOps workflows, tools like Argo CD and Flux watch a Git repository and keep the cluster synchronized with it, so every change is version controlled and auditable. Because manifests are declarative, the same definitions run identically in development, staging, and production. For the broader practice this fits into, see what DevOps is and how it works.
PKI and TLS in Kubernetes
Every Kubernetes cluster is a working public key infrastructure: X.509 certificates authenticate and encrypt nearly every connection between components, whether or not the team that runs the cluster thinks about certificates.
Public Key Infrastructure (PKI) is the framework of Certificate Authorities (CAs), certificates, and keys that establishes trust between machines. In Kubernetes, Transport Layer Security (TLS) certificates secure the API server’s endpoint, the kubelet’s connection to the control plane, etcd peer and client traffic, and any Service exposed over HTTPS.
Client certificates also authenticate users and components to the API server. Clusters bootstrapped with kubeadm generate this PKI automatically, and its client certificates expire after one year by default, so renewal has to be tracked or automated before it causes an outage.
For workload certificates, cert-manager automates issuance and renewal inside the cluster and graduated as a CNCF project on November 12, 2024, placing it at the same maturity level as Kubernetes itself. Certificates typically enter the cluster as Kubernetes Secrets referenced by Gateways or Ingress resources; generating the underlying Certificate Signing Request (CSR) correctly is the first step of that chain.
At enterprise scale, cluster and workload certificates should feed the same lifecycle management process as the rest of the estate, especially with public TLS certificate maximum validity dropping to 47 days by March 2029 under the CA/Browser Forum schedule.
Kubernetes Security Risks and Best Practices
Most Kubernetes breaches trace back to a small set of recurring weaknesses, each with a well-understood control.
| Risk | Why it matters | Best practice |
| Misconfigured access control | Weak or default RBAC lets unauthorized users manipulate the cluster | Enforce least-privilege RBAC, audit access regularly, apply network policies |
| Vulnerable container images | Outdated or unverified images carry known CVEs into production | Pull from trusted registries and scan images with tools such as Trivy |
| Unencrypted Secrets | Base64-encoded Secrets are readable by anyone with etcd or API access | Enable encryption at rest with KMS v2; restrict Secret access via RBAC |
| Unpatched ingress layer | Retired controllers such as Ingress NGINX receive no CVE fixes after March 2026 | Migrate to Gateway API or a maintained controller |
| Unsigned supply chain | Tampered images and dependencies enter the cluster undetected | Sign and verify images with Sigstore Cosign; enforce admission policies |
| Expired certificates | kubeadm client certificates expire after one year and break cluster auth | Monitor and automate certificate renewal across clusters |
For a deeper treatment, see EC’s guides on Kubernetes security best practices, securing containers, and machine identities in Kubernetes in a Zero Trust model.
How Encryption Consulting Helps
CertSecure Manager is Encryption Consulting’s certificate lifecycle management platform. It discovers the certificates running across your Kubernetes clusters and the rest of your estate, automates issuance and renewal through integrations including cert-manager, and alerts on expiry before an outage occurs. Encryption Consulting’s PKI services then design and operate the CA hierarchy that anchors trust in your clusters. Backed by ISO/IEC 27001:2022 and SOC 2 certified practices.
Frequently Asked Questions
What is Kubernetes in simple terms?
Kubernetes is software that runs and manages containerized applications across a group of machines called a cluster. You declare the state you want, such as three copies of a web server, and Kubernetes starts the containers, spreads them across machines, replaces any that fail, and adds more when traffic grows.
What is the difference between Kubernetes and Docker?
Docker builds and runs individual containers on a single machine. Kubernetes orchestrates many containers across many machines, handling scheduling, scaling, networking, and recovery. The two work together: container images built with Docker run inside Kubernetes Pods. Since Kubernetes v1.24 removed dockershim in May 2022, clusters run those images through CRI runtimes such as containerd or CRI-O.
How often is Kubernetes released, and which version is current?
The Kubernetes project ships three minor releases per year, and each release receives roughly 14 months of patch support. The project supports the three most recent minor versions at any time. Kubernetes v1.36, released on April 22, 2026, is the current minor version, with v1.37 scheduled for August 26, 2026.
Are Kubernetes Secrets encrypted by default?
No. Kubernetes Secrets are base64 encoded, which is reversible encoding, not encryption. Anyone with access to etcd or sufficient API permissions can read them. Production clusters should enable encryption at rest through an EncryptionConfiguration, ideally with the KMS v2 provider, which became stable in Kubernetes v1.29 and encrypts Secrets with keys held in an external key management service.
What replaced Ingress NGINX in Kubernetes?
The Kubernetes project retired the Ingress NGINX controller in March 2026, and the repository no longer receives bug fixes or security patches. The Ingress API itself still exists but is feature frozen. The Gateway API is the recommended successor for new deployments, and the ingress2gateway tool converts existing Ingress resources during migration.
Why does Kubernetes need PKI and TLS certificates?
Every connection between Kubernetes components, including the API server, etcd, kubelets, and controllers, is authenticated and encrypted with X.509 certificates issued by cluster Certificate Authorities. Without this public key infrastructure, any process could impersonate a cluster component. Certificates issued by kubeadm expire after one year by default, so renewal must be tracked or automated.
Automate Certificate Lifecycles in Your Clusters
Certificate failures take Kubernetes clusters down quietly. Automate certificate lifecycles with CertSecure Manager, or generate your next CSR in seconds with EC’s free CSR Generator.