Node Management
This document explains how to manage worker nodes using Cluster API Machine resources.
TOC
Prerequisites
Important Prerequisites
- The control plane must be deployed before performing node operations. See Create Cluster for setup instructions.
- Ensure you have proper access to the DCS platform and required permissions.
Configuration Guidelines When working with the configurations in this document:
- Only modify values enclosed in
<>brackets - Replace placeholder values with your environment-specific settings
- Preserve all other default configurations unless explicitly required
Overview
Worker nodes are managed through Cluster API Machine resources, providing declarative and automated node lifecycle management. The deployment process involves:
- IP-Hostname Pool Configuration - Network settings for worker nodes
- Machine Template Setup - VM specifications
- Bootstrap Configuration - Node initialization and join settings
- Machine Deployment - Orchestration of node creation and management
Worker Node Deployment
Step 1: Configure IP-Hostname Pool
The IP-Hostname Pool defines the network configuration for worker node virtual machines. You must plan and configure the IP addresses, hostnames, DNS servers, and other network parameters before deployment.
Pool Size Requirement The pool must include at least as many entries as the number of worker nodes you plan to deploy. Insufficient entries will prevent node deployment.
Example:
Create a DCSIpHostnamePool named <worker-iphostname-pool-name>:
Key parameters:
Step 2: Configure Machine Template
The DCSMachineTemplate defines the specifications for worker node virtual machines, including VM templates, compute resources, storage configuration, and network settings.
Required Disk Configurations The following disk mount points are mandatory. Do not remove them:
- System volume (
systemVolume: true) /var/lib/kubelet- Kubelet data directory/var/lib/containerd- Container runtime data/var/cpaas- Platform-specific data
You may add additional disks, but these essential configurations must be preserved.
Example:
Create a DCSMachineTemplate named <worker-dcs-machine-template-name>:
Key parameters:
*Required when parent object is specified
Step 3: Configure Bootstrap Template
The KubeadmConfigTemplate defines the bootstrap configuration for worker nodes, including user accounts, SSH keys, system files, and kubeadm join settings.
Template Optimization The template includes pre-optimized configurations for security and performance. Modify only the parameters that require customization for your environment.
Example:
Step 4: Configure Machine Deployment
The MachineDeployment orchestrates the creation and management of worker nodes by referencing the previously configured DCSMachineTemplate and KubeadmConfigTemplate resources. It manages the desired number of nodes and handles rolling updates.
Example:
Key parameters:
Node Management Operations
This section covers common operational tasks for managing worker nodes, including updates, upgrades, and template modifications.
Cluster API Framework Node management operations are based on the Cluster API framework. For detailed information, refer to the official Cluster API documentation.
Upgrading Machine Infrastructure
To upgrade worker machine specifications (CPU, memory, disk, VM template), follow these steps:
-
Create New Machine Template
- Copy the existing
DCSMachineTemplatereferenced by yourMachineDeployment - Modify the required values (CPU, memory, disk, VM template, etc.)
- Give the new template a unique name
- Apply the new
DCSMachineTemplateto the cluster
- Copy the existing
-
Update Machine Deployment
- Modify the
MachineDeploymentresource - Update the
spec.template.spec.infrastructureRef.namefield to reference the new template - Apply the changes
- Modify the
-
Rolling Update
- The system will automatically trigger a rolling update
- Worker nodes will be replaced with the new specifications
- Monitor the update progress through the MachineDeployment status
Updating Bootstrap Templates
Bootstrap templates (KubeadmConfigTemplate) are used by MachineDeployment and MachineSet resources. Changes to existing templates do not automatically trigger rollouts of existing machines; only new machines use the updated template.
Update Process:
-
Export Existing Template
-
Modify Configuration
- Update the desired fields in the exported YAML
- Change the
metadata.nameto a new unique name - Remove extraneous metadata fields (
resourceVersion,uid,creationTimestamp, etc.)
-
Create New Template
-
Update MachineDeployment
- Modify the MachineDeployment resource
- Update
spec.template.spec.bootstrap.configRef.nameto reference the new template - Apply the changes to trigger a rolling update
Template Rollout Behavior Existing machines continue using the old bootstrap configuration. Only newly created machines (during scaling or rolling updates) will use the updated template.
Upgrading Kubernetes Version
Kubernetes version upgrades require coordinated updates to both the MachineDeployment and the underlying VM template to ensure compatibility.
Upgrade Process:
-
Update Machine Template
- Create a new
DCSMachineTemplatewith an updatedvmTemplateNamethat supports the target Kubernetes version - Ensure the VM template includes the correct Kubernetes binaries and dependencies
- Create a new
-
Update MachineDeployment
- Modify the
MachineDeploymentresource with the following changes:- Update
spec.template.spec.versionto the target Kubernetes version - Update
spec.template.spec.infrastructureRef.nameto reference the new machine template - Optionally update
spec.template.spec.bootstrap.configRef.nameif bootstrap configuration changes are needed
- Update
- Modify the
-
Monitor Upgrade
- The system will perform a rolling upgrade of worker nodes
- Verify that new nodes join the cluster with the correct Kubernetes version
- Monitor cluster health throughout the upgrade process
Version Compatibility Ensure the VM template's Kubernetes version matches the version specified in the MachineDeployment. Mismatched versions will cause node join failures.