Kubernetes Node Registration
Kubernetes Node Registration is the process of adding and authenticating worker nodes to a cluster, enabling them to participate in scheduling and workload execution.
Kubernetes Node Registration is the precise sequence by which a machine running a kubelet establishes trust with a cluster's control plane and causes a corresponding Node object to be created, covering the bootstrap credential exchange, certificate issuance, and initial status reporting that together transform an unaffiliated machine into a schedulable member of the cluster.
Bootstrap Credentials
The Bootstrap Token
A new node's kubelet formally authenticates its very first contact with the API server using a bootstrap token, a short-lived, narrowly scoped credential created specifically to allow an as-yet-untrusted machine to request its own long-term identity, rather than being pre-provisioned with a full client certificate before it ever joins the cluster.
kubeadm token create --print-join-command
apiVersion: v1
kind: Secret
metadata:
name: bootstrap-token-abcdef
namespace: kube-system
type: bootstrap.kubernetes.io/token
data:
token-id: YWJjZGVm
token-secret: MDEyMzQ1Njc4OWFiY2RlZg==
TLS Bootstrapping
Certificate Signing Request Submission
Using its bootstrap token identity, the kubelet formally submits a CertificateSigningRequest (CSR) to the API server, requesting a client certificate that will become its permanent, node-specific identity for all future communication.
kubectl get csr
kubectl certificate approve node-csr-abc123
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
name: node-csr-abc123
spec:
request: <base64-encoded CSR>
signerName: kubernetes.io/kube-apiserver-client-kubelet
usages: ["client auth"]
Automatic Approval via RBAC
In most cluster setups, a CSR approving controller, granted permission through the system:bootstrappers group's bound RBAC role, formally auto-approves CSRs matching the expected pattern for new node registrations, allowing the process to complete without manual intervention while still requiring the underlying request to be properly signed and formatted.
Node Object Creation
Self-Registration by the kubelet
With its permanent client certificate obtained, the kubelet formally creates the Node object representing itself, populated with its own reported capacity, operating system, architecture, and kubelet version, a self-registration behavior enabled by default and controlled by the --register-node flag.
cat /etc/kubernetes/kubelet.conf | grep client-certificate
kubectl get node worker-node-3 -o yaml
kind: Node
metadata:
name: worker-node-3
status:
nodeInfo:
kubeletVersion: v1.29.2
architecture: amd64
operatingSystem: linux
capacity:
cpu: "8"
memory: "32Gi"
Manual Node Object Pre-Creation
In some setups, a Node object is instead created in advance by an administrator or external provisioning system, with --register-node=false configured on the kubelet, requiring the object to already exist and match before the kubelet's own reported status is accepted against it.
Initial Readiness
From Registered to Schedulable
Immediately after registration, a node's Ready condition formally begins as False or Unknown until the kubelet completes its own startup checks, network plugin initialization among them, and reports a successful first status update; only once Ready transitions to True does the scheduler consider the node a feasible target for new Pods.
kubectl get node worker-node-3 -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'
Ongoing Re-Registration Behavior
Restart Does Not Require Re-Bootstrapping
Once a node's kubelet has obtained its permanent client certificate, restarting the kubelet process formally reuses that existing credential rather than repeating the bootstrap token exchange; the bootstrap process described above is required only once, at a node's initial join, not on every subsequent kubelet restart.
systemctl restart kubelet
kubectl get node worker-node-3 -w
Why Registration Is Structured as a Bootstrap-Then-Escalate Process
Separating a short-lived, narrowly scoped bootstrap credential from the permanent client certificate ultimately issued is what formally allows new nodes to join a cluster without requiring administrators to pre-generate and securely distribute long-term credentials to every machine in advance, while still ensuring that the permanent identity a node ultimately holds is issued only through a controlled, auditable certificate-signing process rather than being self-asserted from the outset.