Kubernetes in Practice: Architecture, Deployment Strategies, and Cluster Management in 2026

• Kubernetes has crossed the mainstream threshold, with over 80% production adoption as of 2026, and the ecosystem is consolidating around containerd, the Gateway API, and first-class sidecar containers.
• The control plane (API server, etcd, scheduler, controller-manager) and worker nodes (kubelet, kube-proxy, containerd) follow a declarative + reconciliation model that every engineer working with K8s needs to internalize.
• Managed Kubernetes (EKS, GKE, AKS) is the right default for most teams; on-premises still makes sense for compliance, data sovereignty, or edge workloads.
• Key breaking changes to know: dockershim removed in v1.24, Ingress NGINX retired March 2026, Gateway API is now the recommended replacement.
• On the tooling side: Lens is now fully commercial under Mirantis; Headlamp has taken the open-source crown as an official Kubernetes SIG-UI project. 

When our team first started shipping containerized workloads at scale, we treated Kubernetes as a complicated curiosity. After many years and a couple of dozen production clusters, it has become the default substrate we build everything on, from Kubernetes architecture decisions to day-two cluster operations. Three things define the 2026 landscape from where we sit: Kubernetes has crossed the maturity threshold (over 80% production adoption); the upstream project is making meaningful breaking changes (dockershim removed in v1.24, Ingress NGINX retired on 24 March 2026, sidecar containers now first-class, Gateway API replacing Ingress); and the tooling layer around it has consolidated, Lens has gone fully closed-source and commercial under Mirantis, while Headlamp has taken the open-source crown as an official Kubernetes SIG-UI sub-project. 

Kubernetes originated from Google’s internal Borg platform, which was used for managing large-scale containerized workloads across the company’s infrastructure.

Google open-sourced Kubernetes in 2014 to bring many of the same operational concepts used internally into the broader engineering ecosystem. Since then, Kubernetes has evolved into the standard platform for deploying and managing containerized applications across cloud and on-premises environments.

Today, Kubernetes is the default container orchestration platform for engineering teams building distributed systems at scale. 

A Kubernetes cluster splits cleanly into a control plane and a set of worker nodes.

The control plane has four moving parts we care about:

• kube-apiserver is the only component that anything else is allowed to talk to. Every kubectl command, every controller, every kubelet on every node hits this REST API. It is the central hub and the only writer of state.
• etcd is a distributed, strongly-consistent key-value store (Raft-based) that holds the entire cluster state: every Deployment, Secret, ConfigMap, Node, and Pod object. If etcd is gone, the cluster is gone, which is why we run it as a 3- or 5-node quorum and back it up obsessively.
• kube-scheduler watches for unscheduled Pods and binds them to a Node based on resource requests, affinities, taints/tolerations, and topology constraints.
• kube-controller-manager is a collection of control loops (Deployment, ReplicaSet, Node, Job, Endpoints…) that drive observed state toward desired state.

Worker nodes run three components: the kubelet (a node agent that talks to the API server and the local runtime), kube-proxy (which programs iptables/IPVS rules for Service networking), and a CRI-compliant container runtime. That runtime is essentially always containerd today; the built-in dockershim adapter that allowed Docker Engine to be used directly was removed in Kubernetes v1.24 (April 2022). EKS, GKE, and AKS all ship containerd as the only runtime on current node images.

Pro-tip: the mental model we drill into every new hire is declarative + reconciliation. You don’t tell Kubernetes to start three Nginx pods; you POST a Deployment object that says, “I want three replicas of this image.” A controller notices that the observed state (zero pods) drifts from the desired state (three pods), creates Pod objects, the scheduler binds them to nodes, kubelets pull the image and start the containers, and the loop closes. Every component reads from the API server, computes a diff, and writes back. This is also why a flaky webhook or a misbehaving controller can melt a cluster; it loops all the way down.

A few additional concepts we lean on constantly:

• Namespaces for soft multi-tenancy and quota boundaries.
• RBAC (Roles/RoleBindings, ClusterRoles/ClusterRoleBindings) for who can do what against the API.
• PersistentVolumeClaims to decouple workloads from the underlying storage, the CSI driver provisions a PV that satisfies the claim.
• Ingress controllers (Traefik, or Gateway-API-native controllers like Envoy Gateway) to terminate HTTP(S) and route to Services. Note: the upstream Ingress NGINX project was officially retired on 24 March 2026; existing installs continue to work but receive no further fixes, so we are migrating new clusters to the Gateway API.
• Sidecar containers (now a first-class Pod feature) for log shippers, service-mesh proxies, and config reloaders.
• HA control planes, three APIservers behind a load balancer, three or five etcd members spread across failure zones. 

For most modern Kubernetes environments, managed services such as AKS, EKS, or GKE significantly reduce operational overhead. The provider manages the control plane, cluster upgrades, and core infrastructure components, while teams primarily focus on running and maintaining their applications.

The most common managed Kubernetes platforms today are:

• Amazon EKS
• Google GKE
• Azure AKS

All three reduce operational overhead significantly by managing the Kubernetes control plane and much of the underlying cluster infrastructure.

In practice, the differences usually come down to ecosystem integration and existing cloud adoption:

• EKS integrates naturally with AWS networking and IAM services
• GKE is known for strong Kubernetes-native tooling and automation
• AKS integrates well with Azure networking, identity, and monitoring services

For most teams, managed Kubernetes reduces much of the operational complexity of maintaining production clusters.

On-premises Kubernetes still makes sense in environments with:

• strict compliance requirements
• data sovereignty constraints
• existing VMware infrastructure
• low-latency edge workloads
• isolated or air-gapped systems

Common on-premises approaches include:

• OpenShift
• VMware Tanzu
• kubeadm-based clusters
• Rancher and RKE2 environments

These setups provide more infrastructure control, but they also require significantly more operational responsibility around upgrades, networking, storage, monitoring, and High Availability.

Hybrid environments are also becoming increasingly common. In these cases, organizations run Kubernetes workloads in both cloud environments and on private infrastructure, depending on latency requirements, compliance needs, or integration with existing systems. 

In on-premises or isolated environments, we typically use kubeadm to manually bootstrap Kubernetes clusters. This gives full control over the cluster configuration, networking, certificates, and control plane setup. 

Example kubeadm initialization: 

Depending on the environment, we also use other Kubernetes distributions and deployment approaches:

• Managed Kubernetes services such as AKS, EKS, or GKE for most production cloud environments
• K3s for lightweight edge deployments, lab environments, or smaller infrastructure setups
• MicroK8s for local Ubuntu-based environments and quick testing scenarios
• Minikube for local development and learning environments
• Kind (Kubernetes in Docker) for CI pipelines and temporary testing clusters

Each approach solves a different operational problem, and the choice between Kubernetes distributions usually depends on infrastructure requirements, operational overhead, and the intended workload. 

These are some of the kubectl commands we use most often during daily Kubernetes operations:

Example Deployment manifest:

Example  Service resource:

For larger environments and reusable deployments, we typically use Helm charts:

Public Helm charts are commonly used for third-party services such as databases, caches, or identity providers. In practice, we also create custom Helm charts for internal applications and platform services. These charts are versioned alongside the application source code and deployed via CI/CD pipelines.

Example Chart.yaml and Deployment template:

Example values.yaml used for deployment:

Typical Helm Operations:  

Pro-tip: treat Helm charts the same way you treat application code. Keep chart versions pinned in Git, avoid deploying unversioned releases, and validate templates in CI before applying changes to the cluster.

In many production environments, Helm is also combined with GitOps tools such as Argo CD or Flux. Instead of manually applying manifests, deployments are managed in Git repositories and automatically synchronized into the cluster. This approach simplifies rollbacks, improves deployment consistency, and provides better visibility into infrastructure changes across environments. 

kubectl remains the primary tool for interacting with Kubernetes clusters, but Kubernetes cluster management becomes more difficult as environments grow in size and complexity.

This is where tools such as Lens can simplify day-to-day cluster operations. Lens provides a graphical interface for inspecting workloads, monitoring cluster resources, reviewing logs, and troubleshooting Kubernetes environments across multiple clusters and namespaces. Note that as of 2026, Lens is a fully commercial product under Mirantis; teams looking for an open-source alternative should consider Headlamp.

Common use cases for Lens include:

• Managing multiple Kubernetes clusters from a single interface
• Inspecting Pods, Deployments, Services, PVCs, Ingress resources, and CRDs
• Accessing container logs and opening terminal sessions inside Pods
• Monitoring CPU, memory, and network usage across clusters and namespaces
• Reviewing Helm releases and deployed charts
• Simplifying troubleshooting during incidents and deployment failures
• Navigating Kubernetes resources without relying entirely on kubectl commands

Besides Lens, other Kubernetes management tools commonly used by engineering teams include k9s for terminal-based operations and Headlamp for graphical cluster management. 

Kubernetes became the industry standard mainly because it solves several operational problems consistently across different environments.

• Scalability: Kubernetes is designed to run large, distributed workloads across thousands of nodes and containers while maintaining automated scheduling, recovery, and scaling capabilities.
• Ecosystem: The Kubernetes ecosystem includes mature tooling for monitoring, GitOps, networking, security, storage, and CI/CD integration. Tools such as Prometheus, Argo CD, cert-manager, and Helm are now standard components in many production environments.
• Portability: Kubernetes workloads can typically be deployed across different cloud providers and on-premises environments with minimal changes, simplifying infrastructure standardization and reducing platform-specific dependencies. 

Kubernetes became the industry standard because it provides a consistent way to deploy, scale, and manage containerized workloads across cloud and on-premises environments.

Its declarative model, large ecosystem, and strong automation capabilities make it suitable for both small development environments and large production platforms.

Some practical Kubernetes best practices and recommendations based on our experience:

1. For New Kubernetes Environments 
   Start with a managed Kubernetes service such as EKS, GKE, or AKS. Use separate clusters or namespaces for staging and production, prefer Gateway API over legacy Ingress NGINX setups, and avoid adopting newly released Kubernetes versions directly in production environments. 
    
2. For Existing On-Premises Infrastructure 
   If the organization already relies heavily on VMware or private datacenters, platforms such as OpenShift, Tanzu, Rancher, or kubeadm-based clusters can offer greater flexibility and integration options. 
    
3. Recommended Operational Tooling 
   Every engineer working with Kubernetes should be comfortable with kubectl and Helm. GUI tools such as Lens or Headlamp significantly simplify troubleshooting, monitoring, and multi-cluster operations. 
    
4. Keep Clusters Regularly Updated 
   Kubernetes upgrades should be planned continuously rather than postponed for years. Staying close to supported versions reduces migration complexity and avoids compatibility issues with APIs, Ingress controllers, and CSI drivers. 
    

If you're evaluating Kubernetes for your infrastructure or need support with cloud and backend engineering, our team at ASSIST Software can help. 

1. What are the main components of the Kubernetes control plane?  

   The Kubernetes control plane consists of four core components: the kube-apiserver (the single entry point for all cluster communication), etcd (the distributed key-value store holding all cluster state), the kube-scheduler (assigns unscheduled pods to nodes), and the kube-controller-manager (a set of control loops that drive the cluster toward its desired state). 
    

2. What replaced dockershim in Kubernetes?  

   dockershim was removed in Kubernetes v1.24 (April 2022). The standard container runtime today is containerd, which is CRI-compliant and ships as the default on current node images for EKS, GKE, and AKS. 
    

3. What is replacing Ingress NGINX in Kubernetes?  

   The upstream Ingress NGINX project was officially retired on 24 March 2026. The recommended replacement is the Gateway API, a more expressive and extensible routing standard. Controllers like Envoy Gateway implement it natively. 
    

4. When should a team choose managed Kubernetes over self-hosted?  

   Managed Kubernetes (EKS, GKE, AKS) is the right default for most teams; the provider handles control plane management, upgrades, and core infrastructure. Self-hosted or on-premises Kubernetes makes sense when strict compliance requirements, data sovereignty constraints, air-gapped environments, or existing VMware/OpenShift infrastructure are involved.