Kubernetes 1.27 came out in April 2023, and its headline features are incremental. That's fitting for a platform that now handles an estimated 65% of container workloads in production. The real story is what's happening around Kubernetes.
Kubernetes 1.27 made several beta features stable, including better garbage collection for unused images, improved memory manager for NUMA-aware resource allocation, and a new approach to handling pod scheduling on nodes with different hardware. These changes aren't user-visible in most workloads. Kubernetes 1.x releases are now mostly about refining a mature platform rather than adding big new features.
I've seen the new image garbage collector bite back when we ran a 200‑node fleet with containerd 1.6. The default threshold of 10 GB of unused layers caused a cascade of pod restarts during a nightly cleanup because the kubelet was still referencing images that the collector had already pruned. The fix was to tune the --image‑gc‑high‑threshold and low‑threshold flags and add a short delay before the kubelet re‑pulls. On the NUMA side, the memory manager only works when the node reports its topology through the topology manager, which many on‑prem servers still hide behind proprietary firmware. In a 64‑core, 4‑socket workload we had to enable the topology manager in static policy and pin the hugepages manually; otherwise the scheduler kept placing pods on the wrong socket and we lost up to 15 % of expected throughput.
The Kubernetes operator ecosystem has come a long way. Operators, which are controllers that extend Kubernetes to manage stateful applications, have matured significantly. The operator pattern, introduced by CoreOS in 2016, is now standard for running databases, message queues, and monitoring systems on Kubernetes. OperatorHub lists over 250 certified operators. This means running Postgres, Kafka, Elasticsearch, and Prometheus on Kubernetes with production-quality lifecycle management is a solved problem.
The operator story is not all smooth sailing. Our Postgres operator ran fine until we hit a version upgrade that introduced a new init‑container for wal‑level checks. The operator tried to roll out the change across a statefulset of 30 replicas, but the rolling update stalled because the init‑container timed out on a node with high I/O latency. We ended up rolling back the CRD version and adding a custom health check that skips the init‑container on nodes flagged as slow. The lesson is to treat an operator as another piece of application code: you need integration tests that simulate node pressure, and you should monitor the operator's own metrics, not just the managed service.
Cilium, a Kubernetes networking plugin that uses eBPF, has become the default choice for new clusters at most major cloud providers. EKS, AKS, and GKE all offer Cilium as an option. It's faster than older CNI plugins like iptables, provides L7 visibility into HTTP traffic, and can replace kube-proxy entirely. Switching from Flannel or Calico to Cilium takes planning but is worth it for large clusters.
Switching to Cilium is tempting, but the migration can surface hidden limits. The eBPF maps that Cilium uses have a default size of 1 million entries, which is fine for a few hundred services but hits a ceiling in a 5 k service mesh. We ran into map‑full errors during a load test that generated 12 k concurrent connections, and the dataplane started dropping packets. The workaround was to raise the map size in the CiliumConfig and to enable the BPF‑LB mode, which spreads the load across multiple maps. We also had to adjust the kernel parameters sysctl net.core.somaxconn and net.ipv4.ip_local_port_range to avoid socket exhaustion. The debugging workflow involved cilium monitor and bpftool, which added a few extra hours to the rollout but saved us from a production outage.
GitOps deployment tools Argo CD and Flux are now standard. Both have graduated from the CNCF. The question is no longer if you should use GitOps, but which tool to choose: Argo CD with its UI and application set abstractions, or Flux with its composability and closer alignment to Kubernetes' native API patterns. For new platforms, the choice often comes down to team familiarity. For existing platforms, both tools support migration from each other.