Worker lifecycle is more than kubeadm join. A safe procedure validates versions, protects workload availability with drain, handles DaemonSets and local data explicitly, deletes the Node object, and resets the host.
1. Prepare and execute
Confirm the active kubeconfig context and namespace before applying changes. Save commands and manifests in version control without credentials.
# Control plane: create a fresh, short-lived join command
sudo kubeadm token create --ttl 30m --print-join-command
# Worker: run the printed command with sudo
sudo kubeadm join 10.0.0.10:6443 --token TOKEN
--discovery-token-ca-cert-hash sha256:HASH
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.
# Before draining, make sure replicated workloads have a PodDisruptionBudget.
# emptyDir data is local and is deleted when --delete-emptydir-data is used.
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.
kubectl get nodes -o wide
kubectl describe node worker-1
kubectl get pods -A -o wide --field-selector spec.nodeName=worker-1
kubectl cordon worker-1
kubectl drain worker-1 --ignore-daemonsets --delete-emptydir-data --timeout=10m
kubectl get pods -A -o wide --field-selector spec.nodeName=worker-1
4. Troubleshooting
A drain blocked by a PodDisruptionBudget is a safety signal. Fix capacity or policy rather than immediately forcing deletion. Static Pods, unmanaged Pods, local storage, and finalizers need deliberate handling.
5. Rollback and cleanup
Review the exact target before deleting resources, especially namespaces, claims, Secrets, and cluster-wide add-ons.
kubectl delete node worker-1
# On worker-1:
sudo kubeadm reset -f
sudo rm -rf /etc/cni/net.d
# To return a maintained node to service instead:
kubectl uncordon worker-1
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.
