Kubernetes's Second Decade — From Single Clusters to Unified Management
We spent Kubernetes's first decade perfecting single-cluster operations. KubeCon Japan 2025 made it clear: the second decade is about centralized management.

We spent Kubernetes's first decade perfecting single-cluster operations. KubeCon Japan 2025 made it clear: the second decade is about centralized management.
CNCF's 2024 survey shows 49% of enterprises run 4+ clusters in production. Organizations aren't asking if they should adopt multi-cluster anymore—they're asking how to manage them effectively.
Why multi-cluster is inevitable:
The core challenge: Kubernetes clusters know nothing about themselves or other clusters. No native "cluster name" or "cluster ID" exists.
As Fields demonstrated, we've ended up with a proliferation of cluster management solutions:
Open source cluster managers:
Tools with multi-cluster modes:
Cloud provider solutions:
Each solution maintains its own cluster inventory, creating what Fields called "lists of lists"—a management nightmare that forces users to write glue code for any integration.
Kubernetes SIG Multicluster is solving this with two foundational APIs:
Currently in alpha (≥ v1.28), this introduces standardized "Cluster Inventory" through a ClusterProfile CRD:
apiVersion: multicluster.x-k8s.io/v1alpha1
kind: ClusterProfile
metadata:
name: prod-west-cluster
namespace: fleet-system
spec:
displayName: "Production West Coast"
clusterManager:
name: fleet-manager
status:
version:
kubernetes: 1.31.0
properties:
- name: location
value: us-west3
- name: environment
value: production
Beta status with implementations by AWS Cloud Map, Antrea, and others. Makes cross-cluster service access as simple as single-cluster through ServiceExport, ServiceImport, and ClusterSet objects.
Apple's presentation showcased the maturity evolution from manual to unified platform management:
Version | Approach | Key Components |
---|---|---|
V1 | Manual Management | Crossplane claims; Argo CD reconciliation |
V2 | Tenant-centric API | YAML input; preliminary schema validation |
V3 | Schema Validation | Pkl templating; Prow workflows |
V4 | Unified Platform | Generic API server; Kubernetes-native labeling |
Kaslin Fields' overview (KubeCon Japan 2025) revealed the features enabling this centralized future:
Feature | Status | Multi-Cluster Impact |
---|---|---|
Dynamic Resource Allocation (DRA) | Beta in 1.32 | Critical for AI workloads needing precise hardware control across clusters |
Gateway API | v1.3.0 (April 2025) | Standardizes networking across environments—essential for multi-cluster service mesh |
In-Place Pod Resize | Beta in 1.33 | Cuts operational overhead in large multi-cluster deployments |
Enhanced Sidecar Support | Stable in 1.33 | Native sidecar containers streamline service-mesh patterns |
For platform engineering teams like ours at Aokumo, this evolution presents both opportunity and necessity. The move from Ansible to ArgoCD-based deployment that we're planning aligns perfectly with this industry shift.
Our recommended stack for this new era:
This isn't just about tools—it's about adopting the centralized management philosophy that will define Kubernetes's second decade.
The vision is becoming clear: "Kubernetes for managing Kubernetes." Just as Kubernetes revolutionized how we manage applications, we're now seeing it revolutionize how we manage infrastructure and clusters themselves.
The standardization efforts around ClusterProfiles and Multi-Cluster Services APIs, combined with projects like Google's Multi-Cluster Orchestrator (MCO), are creating the foundation for truly unified cluster management.
Immediate actions:
Strategic preparations:
We're evaluating the ClusterProfiles controller prototype for Q3 implementation.
Kubernetes's first decade taught us how to run containers at scale. The second decade is teaching us how to run Kubernetes itself at scale. The shift from individual cluster operations to centralized, unified management isn't just a trend—it's the foundation for the next generation of cloud-native infrastructure.
The tools and standards are maturing rapidly. Organizations that embrace this centralized approach now will have a significant advantage as multi-cluster becomes the default architecture pattern.
The question isn't whether you'll need multi-cluster management—it's whether you'll build it the hard way or leverage the emerging standards that will define Kubernetes's next decade.
What are your thoughts on this evolution? Are you seeing similar multi-cluster challenges in your organization? Let's discuss the best approaches for unified cluster management for your team and organization - Book a Demo Now!