Skip to navigation

Control Plane

View as Markdown

NVKE manages each cluster’s control plane through a dedicated control-plane controller. You declare the control plane once, in controlPlaneConfig, and NVKE provisions, upgrades and replaces control-plane nodes to match it. Node pools always contain worker nodes.

  • Size. controlPlaneConfig.desiredCount sets the number of control-plane nodes. It is required when you create a cluster.
  • Rollouts. When the control-plane configuration changes (release or Kubernetes version), NVKE compares each control-plane node with the desired configuration and replaces drifted nodes. maxSurge (0 or 1) controls whether a replacement node is added before the old one is removed. Progress is reported in ControlPlaneStatus.rollout and, per node, in Node.controlPlaneRollout.
  • Recycling gate. When enableCPNodeRecycling is false, drifted nodes are detected and reported as pending but are not replaced until an operator acts.
  • Deletes. Control-plane node deletes are serialized. A delete request is recorded first (deleteRequested) and NVKE starts teardowns one at a time. A delete is rejected if it would leave fewer than 3 healthy, joined control-plane nodes.

The control plane is read at GET /clusters/{clusterID}/control-plane and changed through PATCH /clusters/{clusterID}. Its configuration history is an ordered list of snapshots of control-plane configuration changes.

Releases (release). The OS and first-boot configuration for every node come from a release the Operator supplies to the management plane. Control-plane and node pool requests select them by name in nico.release. Changing release on a node pool or on the control plane triggers a rollout of the affected nodes to the new release.