Certificate renewal — kubeadm certs renew and the rotation sequence

kubeadm certs renew is the operational command for extending cert validity without rotating keys. The renewal is online, contained to a single control-plane host, and reversible. This lesson walks the command, the multi-host sequence, and the verification steps.

The renew subcommand

sudo kubeadm certs renew --help

Usage:
  kubeadm certs renew [flags]

Available Commands:
  admin.conf               Renew the certificate embedded in the admin.conf client configuration file
  all                      Renew all available certificates
  apiserver                Renew the certificate for the API server
  apiserver-kubelet-client Renew the certificate for the API server to connect to the kubelet
  controller-manager.conf  Renew the certificate embedded in the controller-manager.conf client configuration file
  etcd-ca                  Renew the certificate authority for etcd
  etcd-healthcheck-client  Renew the certificate for liveness probes to healthcheck etcd
  etcd-peer                Renew the certificate for etcd nodes to communicate with each other
  etcd-server              Renew the certificate for serving etcd
  front-proxy-ca           Renew the certificate authority for the front proxy
  front-proxy-client       Renew the certificate for the front proxy client
  scheduler.conf           Renew the certificate embedded in the scheduler.conf client configuration file

Each subcommand targets a specific cert. The all subcommand targets every cert in the cluster.

The renewal of all certs

sudo kubeadm certs renew all

The command:

1. Reads the current PKI from /etc/kubernetes/pki/.
2. Generates a new cert for each entry, retaining the existing key (default behavior).
3. Writes the new cert to the same file path.
4. Updates the kubeconfigs in /etc/kubernetes/ that reference the certs.
5. Restarts the affected static pods (API server, controller-manager, scheduler, etcd) so the new cert is loaded.

The command is silent on success. Verify:

sudo kubeadm certs check-expiration

CERTIFICATE                          EXPIRES                  RESIDUAL TIME
apiserver                           Aug 16 10:00:00 2028 UTC  364d

The expiry has advanced by 1 year.

The multi-host sequence

On a multi-control-plane cluster, the renewal must run on each host. The order matters:

sequenceDiagram
    participant O as Operator
    participant CP2 as cp-2 (follower)
    participant CP3 as cp-3 (follower)
    participant CP1 as cp-1 (leader)
    O->>CP2: kubeadm certs renew all
    CP2-->>O: cp-2 at 1y
    O->>CP3: kubeadm certs renew all
    CP3-->>O: cp-3 at 1y
    O->>CP1: kubeadm certs renew all
    CP1-->>O: cp-1 at 1y (brief API server unavailability)

Run on a follower first, then the second follower, then the leader. The leader’s renewal causes the API server’s static pod to restart briefly; the LB routes around, and clients see a 503 and retry.

The static pod restart

After kubeadm certs renew all, the affected static pods are restarted by kubelet. The restart is brief:

kubectl get pods -n kube-system -w

NAME                       READY   STATUS    RESTARTS   AGE
kube-apiserver-cp-1        1/1     Running   0          24h
kube-apiserver-cp-2        1/1     Running   0          24h
kube-apiserver-cp-3        1/1     Running   0          24h
...
# after renewal on cp-1:
kube-apiserver-cp-1        1/1     Running   1          24h  # restart!
kube-apiserver-cp-2        1/1     Running   0          24h
kube-apiserver-cp-3        1/1     Running   0          24h

The RESTARTS column increments on the host where the renewal ran. The other hosts are unaffected.

Renewing a single cert

For a single cert, the syntax is:

sudo kubeadm certs renew apiserver
sudo kubeadm certs renew etcd-server
sudo kubeadm certs renew front-proxy-client

Each renews the named cert only. The static pod restart is limited to the host where the renewal ran.

The etcd renewal

The etcd certs live in /etc/kubernetes/pki/etcd/. Renewal:

sudo kubeadm certs renew etcd-server
sudo kubeadm certs renew etcd-peer
sudo kubeadm certs renew etcd-healthcheck-client

Each causes the etcd static pod to restart on the local host. etcd’s static pod restart is brief; the cluster quorum is maintained as long as the other etcd members are healthy.

The CA renewal

The cluster CA (ca.crt) and the etcd CA (etcd/ca.crt) are renew:

sudo kubeadm certs renew ca
sudo kubeadm certs renew etcd-ca

CA renewal is rare. It does not change the CA’s key by default; it just extends the cert’s validity. The CA’s serial number may change, which affects the chain of trust.

The verification

After renewal:

# 1. Verify cert expiry
sudo kubeadm certs check-expiration

# 2. Verify cluster health
kubectl get nodes
kubectl get pods -n kube-system

# 3. Verify API server endpoints
kubectl get endpointslices -n default

# 4. Verify etcd quorum
sudo etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
  --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
  --endpoints=https://127.0.0.1:2379 \
  endpoint health

The cluster is healthy if all components are Running and etcd’s quorum is intact.

Cross-course references

• The Linux course covers systemd service restart semantics.
• The Observability course covers cert expiry alerting via Prometheus.
• The VyOS course covers CA chain validation when integrating external services.

Quiz

Production discipline

• Snapshot before renewal. The etcd snapshot is the safety net.
• Followers first, leader last. Contain the static pod restart to the leader.
• Verify at each step. kubeadm certs check-expiration on each host.
• Document the renewal. Add to the runbook; update the calendar.
• Test on staging. Catch misconfiguration before production.
• Avoid CA rotation without planning. It cascades to every chained cert.

The renewal is a planned, ordered, validated sequence. Operating it well is following the order and verifying at each step.