The Stack Observer
Cloud Native / Kubernetes

Kubernetes Weekly: Dashboard Archived, EKS Auto Mode + Istio Ambient, and etcd at 60-Cluster Scale

•Stackxx•Cloud Native, Kubernetes

Kubernetes Dashboard Archived: Headlamp Takes the Helm

The Kubernetes Dashboard project, the visual interface that introduced countless developers to Kubernetes, has been officially archived. The upstream Kubernetes blog published a comprehensive migration guide on June 1, 2026, explaining how Headlamp has stepped in as the recommended replacement.

Headlamp, originally developed by Kinvolk and now maintained within the Kubernetes ecosystem, builds on Dashboard’s legacy while addressing modern operational needs. Where Dashboard was limited to single-cluster views, Headlamp natively supports multi-cluster visibility from a single interface — a critical capability as organizations scale beyond one production environment.

The transition guide highlights several key improvements Headlamp brings:

  • Multi-cluster workflows: Manage development, staging, and production clusters side by side without context switching
  • Projects: An application-centric view that groups related workloads, services, and configurations into logical units
  • Plugin ecosystem: Extensible architecture with community plugins including Flux for GitOps and an AI Assistant for troubleshooting
  • Flexible deployment: Run in-cluster for shared environments or as a desktop application for local development

Importantly, Headlamp preserves the workflows Kubernetes Dashboard users already know. Viewing workloads, editing manifests, and understanding resource relationships all work in familiar ways, with RBAC permissions respected exactly as before. For teams running legacy Dashboard installations, the message is clear: the deprecation is real, but the migration path is well-documented and the successor offers genuinely useful upgrades.

AWS EKS Auto Mode Integrates with Istio Ambient Mesh

On June 9, 2026, AWS published a technical deep dive showing how Amazon EKS Auto Mode and Istio Ambient Mesh can be combined to address two of the hardest operational challenges in Kubernetes: infrastructure lifecycle management and zero-trust service-to-service security.

EKS Auto Mode, which AWS launched to extend its managed service beyond the control plane to the compute layer itself, automates node provisioning, scaling, patching, and updates. It runs workloads on hardened Bottlerocket instances with AWS-managed system components like VPC CNI, kube-proxy, EBS CSI driver, CoreDNS, and the AWS Load Balancer Controller — all maintained by AWS rather than deployed as user-managed add-ons.

Istio Ambient Mesh, the sidecar-less evolution of the Istio service mesh, provides automatic mutual TLS encryption and traffic policies without requiring application code changes or traditional sidecar proxies. The combination means teams get fully automated compute infrastructure and automatic service-to-service encryption and authorization.

The AWS blog post includes a hands-on walkthrough covering cluster creation, mTLS encryption setup, authorization policies, and Layer 7 traffic controls. For teams running hundreds of microservices, this integration addresses the exact pain point the post describes: “keeping compute infrastructure running smoothly and securing communication between services.”

At Scale: How Garanti BBVA Optimized etcd for 60 OpenShift Clusters

At KubeCon + CloudNativeCon Europe 2026’s Day Zero event in Amsterdam, Red Hat and Garanti BBVA — one of Turkey’s largest private banks — shared an unusually candid look at etcd optimization at massive scale. The bank operates 60 Red Hat OpenShift clusters serving 30 million customers and processing up to 2 billion transactions daily during peak periods.

The challenge was uncontrolled etcd database growth. In non-production environments with 40,000 pods and 10,000 microservices, etcd performance degradation created system-wide API latency that bottlenecked pod scheduling and reconciliation loops.

The team identified three root causes:

  • Unrestricted revision history: Deployment objects lacked revision limits, causing historical data accumulation. The fix: keep only one previous revision
  • Secret proliferation: Over 20,000 unnecessary secrets were stored in etcd, including legacy service account tokens no longer required since OpenShift 4.11
  • Duplicated ConfigMaps: CI/CD pipelines created redundant configurations across namespaces, which were consolidated into shared ConfigMaps

When existing open source tools like K8sPurger proved too resource-intensive, the bank built a custom cleanup tool using the OpenShift REST API directly — reducing scan time from 30 minutes to 4 minutes. The tool includes a unique space reclamation estimator that decodes etcd data to predict cleanup impact before any deletion occurs.

The results: 1.5 to 2 GB of etcd space reclaimed in non-production environments, with the cleanup now fully automated. As Garanti BBVA’s Emirhan Bilge Bulut noted, “In large systems, problems are not always solved by adding more resources. They are solved by understanding the system deeply.”

containerd 2.1.8 and Helm v4.2.0: Runtime and Packaging Updates

Two foundational Kubernetes ecosystem components shipped notable releases in recent weeks.

containerd 2.1.8 arrived on June 2, 2026, as the eighth patch release in the 2.1 series. It includes a security fix for CVE-2026-46680 and addresses runtime issues including out-of-range USER value handling in OCI specs, sandbox service configuration forwarding, and conditional AppArmor ABI support for versions below 3.0. The snapshotter also gained support for both “volatile” and “fsync=volatile” mount options.

Helm v4.2.0 shipped on May 14, 2026, as a feature release updating Kubernetes client libraries to v1.36 — keeping the package manager current with upstream API evolution. Notable changes include a switch to goreleaser for builds, a new mustToToml template function, and the long-requested fix making --dry-run=server respect generateName: fields.

On the etcd front, the project published v3.8.0-alpha.0 on June 5, 2026, across all component packages — the first alpha of what will become the next major etcd release. While release notes were minimal, the coordinated multi-package release signals active development toward the next stable version.

Security: Kubernetes CVE Records Being Corrected

On May 26, 2026, the Kubernetes Security Response Committee announced it would correct CVE records for older, unfixed vulnerabilities. Some records had incorrectly included “fixed version” fields for issues that were never actually patched — a discrepancy that could cause vulnerability scanners to miss real risks.

The corrections took effect on June 1, 2026. The Kubernetes blog specifically called out that this may result in scanners flagging vulnerabilities in places where they previously went undetected. For cluster administrators, this is a reminder that the official Kubernetes CVE Feed is the authoritative source, and that “fixed” claims should always be verified against actual patch availability.

What This Means for Platform Teams

The past two weeks in Kubernetes have delivered meaningful signals for platform engineering teams:

  • UI modernization is non-negotiable — Dashboard’s deprecation means teams need a migration plan to Headlamp or another supported interface
  • Managed Kubernetes + service mesh convergence is maturing — AWS’s EKS Auto Mode + Istio Ambient integration shows the direction: infrastructure automation paired with transparent security
  • etcd hygiene at scale is a real engineering discipline — Garanti BBVA’s work demonstrates that automated cleanup, revision limits, and secret audits are essential for clusters beyond a few thousand pods
  • Runtime security remains active — containerd’s CVE fix and Kubernetes’s CVE record corrections show the ecosystem’s continued investment in accurate, actionable security data

For teams evaluating their Kubernetes stack, the headline is this: the ecosystem is consolidating around managed infrastructure, sidecar-less service meshes, and automated operational hygiene — with better tooling to manage it all visually.

Sources

Next signal