Two-node kubeadm operations

What this exercise adds to kind

kind supplied a node image with much of the setup already done. kubeadm bootstraps Kubernetes on Linux machines you prepare. You now own the operating system, runtime, node addresses, and the network plugin. A CNI plugin provides Pod networking; without a working network setup, node and DNS readiness can remain incomplete. kubeadm does not create your VMs or make one control plane highly available.

Read through this bite before provisioning anything. The small worked maintenance case below can be reasoned through on paper; its VM implementation is a separate profile. Keep a table for node name, private address, CPU/memory allocation, runtime version, Kubernetes version, and network ranges. Two identical copied VMs still need distinct names and machine identities. When a check fails, fix that prerequisite before asking Kubernetes to hide it.

Use independent Linux VMs for this track

Pause kind and the optional telemetry stack first. Prepare two full Linux VMs: one control plane and one worker. A starting allocation to evaluate is 2 vCPU/2 GB for the control plane and 2 vCPU/3 GB for the worker, with expandable disks and host headroom. This is a cluster-administration exercise; measure the worker’s capacity before adding MicroBank or controllers.

OrbStack Linux machines share its Linux kernel. Keep using them for the earlier userspace exercises, but choose independently booted VMs for node kernel, runtime, reboot, and kubeadm practice. One control plane is a single point of failure.

Create a reproducible node checklist

Follow the versioned kubeadm installation guide for your VM distribution. Record the Kubernetes minor, kubeadm/kubelet versions, supported container runtime, systemd cgroup configuration, swap configuration, unique hostnames, private addresses, time synchronization, and required ports between the VMs. Do not paste an old package-repository command into a newer release.

1. Prepare both nodes; verify the container runtime works before initializing Kubernetes.
2. Choose a CNI and a Pod CIDR that does not overlap host, VM, VPN, or Service networks. Match the CNI's installation requirements.
3. On the control plane, run kubeadm init with your reviewed settings. Install its kubeconfig for the lab administrator only.
4. Apply the selected CNI. Join the worker using the generated token and CA hash; do not publish the join command.
5. Wait for both nodes and CoreDNS to become ready. Keep the control-plane scheduling taint.

Predict maintenance before trying it

Cordon marks a node unavailable for new ordinary scheduling. Existing Pods stay. Drain attempts to evict eligible workloads so the node can be maintained; controllers may create replacements elsewhere. Uncordon allows new scheduling again. A taint can repel Pods unless they have a matching toleration. Tolerating a taint permits placement; it does not guarantee placement.

Suppose this cluster has one worker with two web replicas, and a control plane that retains its default workload taint. Cordoning the worker leaves those replicas running. Draining can remove them, but their replacements have no eligible node and remain Pending. Two replicas on the same worker did not provide a second failure location. A PodDisruptionBudget declaring minAvailable: 1 can block a supported voluntary eviction when it would violate that minimum; it cannot create spare capacity or prevent every failure.

For the practice, identify your two exact node names with get nodes -o wide, deploy a disposable stateless page, and verify its initial request. In the version-matched drain guide below, inspect the treatment of DaemonSets, unmanaged Pods, and local temporary data before selecting flags. Do not add force or deletion flags merely to make a blocked drain finish. Record whether the block is protecting data or expressing an unavailable-replica constraint.

Practise a maintenance window

Deploy a small stateless workload on the worker. Drain that worker using the kubeadm node-maintenance guidance, observe Pending replacement Pods, perform the planned maintenance, then uncordon it. With only one worker and a tainted control plane, workload downtime is expected. If a PodDisruptionBudget blocks the drain, explain the constraint and review the maintenance plan before proceeding.

Keep this kubeconfig distinct from kind. Do not run the MicroBank fault scripts against it. Record why a Pod cannot move and the downtime you actually observe.

Maintenance answer: with only one eligible worker, a Pending replacement is an expected capacity/placement outcome. Uncordoning can allow it to return after maintenance; a permanently lost worker needs repair or replacement. A successful drain is not proof of user availability. Stop this VM profile before resuming kind, verify the explicit kind context, and continue with Scheduling and troubleshooting.

Sources

Install kubeadm↗, create the cluster↗, and safely drain a node↗.