Cluster API gives control plane changes a controller
Cluster API v1alpha3 adds declarative kubeadm control plane management and bounded worker health remediation. Its APIs distinguish control plane sequencing from infrastructure-managed worker groups.
Scaling a Kubernetes control plane includes work that a machine count cannot describe. When etcd runs on those machines, removing a replica also changes a stateful cluster's membership. Earlier Cluster API users had to create specially prepared Machine resources to grow the control plane and manually remove etcd members when shrinking it. The v1alpha3 generation gives that sequence a dedicated controller.
Daniel Lipovetsky's April 21 account of Cluster API v1alpha3 describes the Kubeadm-based Control Plane, or KCP. Its declarative API handles deployment, scaling, and upgrades, including etcd management. The release also adds failure domains and automated replacement of unhealthy worker nodes. These mechanisms bring cluster infrastructure into the same style of management that Kubernetes applies to application resources.
I consider that a strong use of the Kubernetes API model. The useful abstraction is a controller that knows the sequence required to reach the declared state. Giving a replica count to an API is only part of the work. Control plane management has to account for the stateful system whose replicas it changes.
KubeadmControlPlane owns the sequence
The announcement illustrates a KubeadmControlPlane with a desired replica count and Kubernetes version. Its infrastructure template identifies the provider-specific machine configuration. The example uses Docker infrastructure maintained for testing and development, and it omits other required resources for brevity. It is an illustration of the relationship between objects, not a complete production cluster manifest.
The central desired-state fields are straightforward. This fragment follows the announcement's example and belongs inside a complete KubeadmControlPlane resource.
spec:
replicas: 3
version: 1.16.3
The controller supplies the operational meaning behind changes to those fields. KCP manages etcd by default and requires an odd replica count in that configuration. With externally managed etcd, the announcement recommends an odd count but does not require one. The distinction matters because the control plane replica count and the etcd membership are no longer necessarily the same management operation.
KCP works with a v1alpha3-compatible infrastructure provider that supplies a fixed control plane endpoint. That endpoint can be a load balancer or virtual IP, and it lets clients reach multiple control plane replicas. Replicating machines does not by itself give clients a stable endpoint. The provider integration must supply that part of the arrangement.
The announcement also distinguishes control plane availability from the survival of already running workloads. Some workloads can continue during a control plane outage, but operators and service meshes can depend on its APIs. Declarative infrastructure management therefore has to preserve the availability of a system on which other controllers themselves rely.
Failure domains describe correlated loss
A failure domain groups resources that a particular failure can make unavailable together. The release's examples include cloud availability zones and on-premises boundaries such as racks or power distribution units. Infrastructure providers map those boundaries into the API. Support is optional for providers whose infrastructure does not need it.
KCP tries to spread its machines evenly across suitable domains. It creates a new node in the domain with the fewest existing nodes and removes one from the domain with the most. Providers can mark whether a domain is suitable for control plane nodes. The controller only uses domains marked suitable for that purpose.
Worker placement has a different implementation in this release. MachineDeployments and MachineSets do not automatically distribute nodes across failure domains. The documented approach creates one MachineDeployment or MachineSet for each domain. Treating the control plane's distribution behavior as a guarantee for every worker controller would therefore misread the release.
This difference is useful to state directly because failure-domain support can sound like a property of the whole cluster. Its practical effect depends on the controller consuming the information. A declared domain only influences placement when the responsible controller implements that behavior.
Health remediation stops at a threshold
The new MachineHealthCheck resource lets a controller monitor node health and remove unhealthy nodes. Another Cluster API controller detects the removal and creates replacement capacity. The health controller can wait before acting, which allows a short interruption to recover without replacing the machine.
It can also stop removing nodes when an unhealthy threshold is reached. That bounds remediation during a broad failure. A machine replacement may help when one node is broken, but the same response applied to many nodes can be an inappropriate reaction to a shared outage. The threshold gives the operator a way to express that distinction.
The release limits this remediation to nodes managed by a Cluster API MachineSet. It does not remove control plane nodes, including those managed by KCP. The presence of a control plane controller and a health controller in the same release does not imply that their responsibilities overlap. Their documented limits are part of understanding the recovery behavior.
I prefer this explicit threshold to an assumption that replacing every unhealthy machine is always safe. Reconciliation needs a policy for when to stop acting as well as a target state. Here the wait interval and unhealthy threshold make that policy configurable.
MachinePool delegates group management
MachinePool addresses another boundary, the infrastructure provider's own group API. The MachinePool proposal linked by the announcement explains that MachineDeployment uses MachineSets to manage individual Machines. MachinePool instead delegates group management to a provider-specific resource, such as an AWS Auto Scaling Group or an Azure Virtual Machine Scale Set.
That can use capabilities the infrastructure provider already implements for managing groups. The proposal also recognizes differences between those providers as a source of inconsistent behavior. It keeps MachinePool optional and excludes control plane management from its goals. In v1alpha3 the feature is experimental and disabled by default.
The redesigned clusterctl makes the object workflow easier to start. It installs provider components, generates workload cluster manifests, and supports moving Cluster API resources between management clusters. Once generated, the workload cluster description is a collection of Kubernetes objects. The release leaves the actual convergence work with controllers whose responsibilities differ according to whether they manage a stateful control plane, individual worker machines, or a provider-managed group.