Kubernetes

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.

Younes Hairej profile picture
Younes Hairej3 min read
multi-cluster-evolution

From Single Clusters to Multi-Cluster Reality

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:

  • Geographic distribution for latency and data gravity
  • Isolation requirements for security and compliance
  • Cost optimization across cloud providers
  • Risk mitigation through redundancy

The core challenge: Kubernetes clusters know nothing about themselves or other clusters. No native "cluster name" or "cluster ID" exists.

The Problem with "Lists of Lists"

As Fields demonstrated, we've ended up with a proliferation of cluster management solutions:

Open source cluster managers:

  • KubeFleet, Open Cluster Management (OCM), Clusternet
  • Karmada, Kubestellar, KubeAdmiral

Tools with multi-cluster modes:

  • ArgoCD, KubeVela, Istio, Kueue

Cloud provider solutions:

  • GKE Fleet, Azure Kubernetes Fleet Manager

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.

The Standardization Breakthrough

Kubernetes's next decade timeline

Kubernetes SIG Multicluster is solving this with two foundational APIs:

1. ClusterProfiles API (KEP-4322)

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

2. Multi-Cluster Services API (KEP-1645)

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.

Centralized Management: The Apple Approach

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

What's Coming: The Technical Foundation

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

The Aokumo Perspective: Platform Engineering at Scale

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:

  • Crossplane for unified cloud resource management
  • Karpenter for intelligent node provisioning across clusters
  • ArgoCD for GitOps-based multi-cluster deployments
  • Kyverno for consistent policy enforcement

This isn't just about tools—it's about adopting the centralized management philosophy that will define Kubernetes's second decade.

Looking Ahead: Kubernetes for Managing Kubernetes

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.

Key Takeaways for Platform Teams

Immediate actions:

  1. Embrace GitOps: Multi-cluster GitOps with ArgoCD is becoming standard
  2. Think centrally: Design platforms with "hub cluster" approach for management

Strategic preparations:

  1. Standardize early: Adopt ClusterProfiles API patterns before building custom solutions
  2. Prepare for AI workloads: DRA and enhanced resource management will be critical
  3. Build on standards: Use Gateway API, avoid vendor lock-in with proprietary networking

We're evaluating the ClusterProfiles controller prototype for Q3 implementation.

Conclusion

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!