Understanding CAPI Concepts and Terms

Some important CAPI terms and concepts you need for planning and preparing for your major version upgrade

To get the most from this major version upgrade, there are a few CAPI concepts to be familiar with, starting with a few important terms and their relationships to each other. You can find a deeper discussion of the architecture in the ClusterAPI Book.

CAPI makes use of a bootstrap cluster for provisioning and starting clusters. A bootstrap cluster handles the following:

  1. Generating the cluster certificates, if they are not otherwise specified.

  2. Initializing the control plane, and managing the creation of other nodes until it is complete.

  3. Joining control plane and worker nodes to the cluster.

  4. Installing and configuring networking plugin (Calico CNI), CSI volume provisioners, cluster-autoscaler and other core Kubernetes components.

BootstrapData is machine or node role-specific data, such as cloud initialization data, used to bootstrap a “machine” onto a node.

For customers using Kommander for multi-cluster management, a management cluster that manages the lifecycle of workload clusters. As the management cluster, DKP Kommander works with bootstrap providers, infrastructure providers, and maintains cluster resources such as bootstrap configurations and templates. If you are working with only one cluster, Kommander will provide you with addon (platform application) management for that cluster, but not others.

A workload cluster is a Kubernetes cluster whose lifecycle is managed by a management cluster, and provides the platform on which you deploy and execute your workloads.

As part of a collection of Custom Resource Definitions or CRDs that extend the Kubernetes API, these additional concepts are important for understanding the upgrade.

A ClusterResourceSet Kubernetes cluster created by CAPI is functionally minimal in nature. Crucial components like CSI and CNI are not a part of the default cluster spec. A ClusterResourceSet is a CRD that can be used to group and deploy core cluster components post-Kubernetes cluster install.

When you create a bootstrap cluster. You can find all the components in the default namespace and we move them to the workload cluster during the process of making the cluster self-managed.

A machine is a declarative spec for a platform or infrastructure component that hosts a Kubernetes node such as a bare metal server or a VM. CAPI uses provider-specific controllers to provision and install new hosts which then register as nodes. When you update a machine spec other than for certain values, such as annotations, status, and labels, the controller deletes the host and creates a new one that conforms to the new spec. This is called machine immutability. If you delete a machine, the controller deletes both the infrastructure and the node. Provider-specific information is not portable between providers.

Within CAPI, you use declarative MachineDeployments to handle changes to machines by replacing them in much the same way that a core Kubernetes Deployment replaces Pods. MachineDeployments reconcile changes to machine specs by rolling out changes to two MachineSets (similar to a ReplicaSet), both the old and the newly-updated.

A MachineHealthCheck identifies unhealthy node conditions, and initiates remediation for nodes owned by a MachineSet.