In this blog we will understand how multi Kubernetes clusters can be managed and orchestrated using the Cluster API control plane tool.
It’s a sub-project of Kubernetes which works on declarative API and provides support for CRD (Custom Resource Definition), which manages K8s and VMs based on CRD configuration. Cluster API always checks current K8s clusters on worker nodes status and compares them with desired state which is provided by DevOps team using CRD config files. It provides provisioning of multiple K8s clusters which could be spread to multiple nodes/hosts. It extends the functionality of K8s for multi-node cluster management with Kubeadm API.
Cluster API orchestrates and manages the lifecycle of worker nodes where K8s clusters are provisioned. Also, manages multiple K8s clusters upgrades, failover, rollback etc.
|Tip: Cluster API manages K8s clusters of multi-cloud including on-prem and hybrid.|
Started by the Kubernetes Special Interest Group (SIG) Cluster Lifecycle, the Cluster API project uses Kubernetes style APIs and patterns to automate cluster lifecycle management.
Refer Cluster API docs here: https://cluster-api.sigs.k8s.io/
These are important components of Cluster API:
Basic hardware infrastructure providers such as Vmware, public infra providers such as AWS, GCP, Azure etc.
It’s also called Cluster API bootstrap provider Kubeadm (CABPK). It generates cluster certificates, initialize/bootstrap control planes. It turns the Machine into a K8s Node. It uses the Kubeadm tool.
It manages the lifecycle of K8s clusters on multiple nodes. Kubeadm is a tool built to provide best-practice “fast paths” for creating Kubernetes clusters. It performs the actions necessary to get a minimum viable, secure cluster up and running in a user friendly way.
Control plane is a set of services which manages multiple K8s clusters and scale on production environments. It manages and provisioned dedicated machines/VMs, running static pods for components such as kube-apiserver, kube-controller-manager and kube-scheduler.
The default provider uses kubeadm to bootstrap the control plane.
Custom Resource Definitions (CRDs)
It’s a set of K8s YAML configuration files which maintain desired K8s cluster state. It can be persisted on Git server for platform automation for Cluster API based K8s clusters.
It defines configuration of machines like VM etc. It’s a declarative spec for an infrastructure component hosting a Kubernetes Node. It’s like POD on K8s.
It provides declarative updates for Machines and MachineSets.
It maintains a stable set of Machines running at any given time. It’s like a ReplicaSet of K8s.
It defines the conditions when a Node should be considered unhealthy. If the Node has any unhealthy conditions for a given user-configured time, the MachineHealthCheck initiates remediation of the Node. Remediation of Nodes is performed by deleting the corresponding Machine and creating a new one like ReplicaSet. It always maintains the same set of Machine configuration which has been provided in the CRD file.
It contains the Machine or Node role-specific initialization data (usually cloud-init) used by the Infrastructure Provider to bootstrap a Machine into a Node.