✦ For everyone, free.

Practical knowledge for real and everyday life

Home

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==
bootstrap token authenticates as system:bootstrappers group

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.

CSR approved certificate issued kubelet's permanent client identity

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.

schedulable Ready condition = True not tainted unschedulable
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.