This guide bootstraps a three-node Kubernetes v1.36 lab with kubeadm: one control-plane node and two workers. It assumes containerd is healthy, unique hostnames are configured, and every node can reach the others on a private network.
1. Prepare and execute
Confirm the active kubeconfig context and namespace before applying changes. Save commands and manifests in version control without credentials.
sudo swapoff -a
sudo sed -ri '/sswaps/s/^#?/#/' /etc/fstab
sudo apt update
sudo apt install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
sudo kubeadm config images pull --kubernetes-version v1.36.0
sudo kubeadm init --kubernetes-version v1.36.0
--apiserver-advertise-address 10.0.0.10
--control-plane-endpoint 10.0.0.10:6443
2. Declarative configuration
Save the following example in a clearly named YAML file, review it, then use server-side dry-run when the API is available.
# Replace 10.0.0.10 with the stable private control-plane address.
# For future HA, use a DNS name or load-balancer address as controlPlaneEndpoint.
3. Verify the result
A successful command is not enough. Inspect resource state, conditions, events, endpoints, logs, and an end-to-end request where applicable.
mkdir -p "$HOME/.kube"
sudo cp /etc/kubernetes/admin.conf "$HOME/.kube/config"
sudo chown "$(id -u):$(id -g)" "$HOME/.kube/config"
kubectl get nodes -o wide
kubectl -n kube-system get pods
sudo kubeadm token create --print-join-command
4. Troubleshooting
A NotReady node before CNI installation is expected. Preflight failures usually identify swap, ports, hostname resolution, CRI, or kernel settings. Never share admin.conf or the join token publicly.
5. Rollback and cleanup
Review the exact target before deleting resources, especially namespaces, claims, Secrets, and cluster-wide add-ons.
kubectl drain WORKER --ignore-daemonsets --delete-emptydir-data
kubectl delete node WORKER
# Run on the removed node:
sudo kubeadm reset -f
Production checklist
- The active context, namespace, and target version were verified.
- Manifests passed client or server-side validation.
- Resource conditions and recent events show no unresolved error.
- Access, network exposure, resource limits, persistence, and rollback were reviewed.
- Commands and expected output were recorded for the operating team.
References: topic documentation and Kubernetes documentation.
