Skip to content

Regional Clusters#

Note

Regional clusters are available starting from version 1.4.0.

Warning

There are some limitations in deploying regional clusters, which will be addressed in upcoming k0rdent releases:

  • Automated credential distribution is not yet supported. You must manually create the corresponding ClusterIdentity objects (e.g., Secrets, AWSClusterIdentity) on each regional cluster.
  • The kubeconfig Secret must exist in the system namespace (default: kcm-system) when registering a new region.

k0rdent can manage thousands of clusters, potentially over multiple clouds and infrastructure domains. It's possible to do all of this within a single k0rdent management cluster. In that case, the management cluster works to manage child clusters across multiple clouds and infrastructures, and serves as the operator's 'single pane of glass'. It collects metrics, provides visibility, and so on. Moreover, k0rdent is designed so that a single manager does not become a single point of failure. The management cluster can be backed up quite simply (see Backups and restored to its prior state quickly without disrupting operations across the IT estate.

However, k0rdent can also work in a distributed arrangement, where each infrastructure domain (for example, a cloud provider, a region within a cloud provider, and so on) is partly controlled by a Regional Cluster. A k0rdent Regional Cluster is not a full-featured k0rdent manager, but a drone cluster containing:

  • CAPI components pertinent to the infrastructure the Regional Cluster is managing. Infrastructure operations (often time-consuming) are distributed by the manager to the Regional Cluster for execution.
  • KOF components including regional metrics and logs aggregation
  • Backup components such as Velero
  • and so on

When using regional clusters, the management cluster remains the single pane of glass, responsible for managing ClusterDeployments, Credentials, Templates, and other k0rdent resources. It then deploys the actual CAPI objects that implement those k0rdent resources on the regional cluster, a plain (non-k0rdent) Kubernetes cluster where provider-related infrastructure (such as CAPI providers) and the objects that implement it (such as Cluster, and Machine objects) are deployed.

Regional clusters provide several benefits:

  • Cluster resources can be distributed across multiple, purpose-specific clusters.
  • Improved fault isolation, because the management cluster only needs to deal with k0rdent objects.
  • Geographic placement of resources.

For more details, see: