如何配置集群组件证书自动轮转机制？

Kubernetes集群中几乎所有控制平面组件和节点组件都依赖证书进行双向TLS认证。证书一旦过期，API Server会拒绝kubelet的请求，控制平面组件之间也会出现连接失败。人工巡检证书有效期虽然可行，但在节点数量多、长期运行的集群里并不现实。自动轮转机制就是把证书续期、签发、重启等操作交给系统定时完成，避免因证书过期造成集群不可用。下面具体分析几种常见的自动轮转配置方式。

一、证书自动轮转的核心机制与适用场景

集群组件证书大致分为三类：CA根证书、服务端证书和客户端证书。API Server使用服务端证书对外提供HTTPS接口，kubelet与API Server通信时使用客户端证书证明自己的身份，同时kubelet也会监听一个本地端口为容器内组件提供带有服务端证书的接口。不同证书的有效期和轮转方式差异很大，CA根证书通常有效期较长但轮转风险极高，服务端和客户端证书则需要频繁更新。

自动轮转的实现路径主要有两条。一是组件内置的自动续期能力，比如kubelet的rotateCertificates参数，它会在证书到期前自动发起续期请求。二是通过外部控制器或定时任务调用kubeadm certs renew命令，集中管理控制平面证书。前者适合节点组件，后者适合API Server、controller-manager、scheduler等控制平面组件。

生产集群、边缘节点以及无人值守环境都需要配置自动轮转。尤其是kubeadm初始化的集群，证书默认有效期为1年，到期后需要手动处理，一旦遗漏就会导致集群组件通信失败。把轮转过程自动化，可以把运维人员从定期巡检中解放出来，同时降低人为操作失误的概率。

二、配置kubelet证书自动轮转

kubelet客户端证书自动轮转的原理并不复杂。kubelet启动后如果检测到客户端证书即将过期，会向API Server提交CertificateSigningRequest（CSR），请求签发新证书。管理员需要批准CSR，或者配置自动批准控制器。kubelet拿到新证书后替换本地文件并重新加载，整个过程中节点上的Pod不会受到影响。

以kubeadm部署的集群为例，首先修改kubelet配置文件/var/lib/kubelet/config.yaml。在该文件中添加rotateCertificates: true，并设置serverTLSBootstrap: true允许kubelet也轮转服务端证书。修改完成后需要重启kubelet服务使配置生效。部分旧版本还需要在kubelet启动参数中显式指定--rotate-certificates，新版本直接在配置文件中启用即可。

接下来配置自动批准CSR。编写一个ClusterRole允许对certificates.k8s.io资源中的certificatesigningrequests执行get、list、watch，以及对certificatesigningrequests/approval执行update。再用ClusterRoleBinding绑定到system:node-bootstrapper或自定义组。这样节点提交的CSR就能自动批准，不需要人工介入。

# kubelet配置片段
rotateCertificates: true
serverTLSBootstrap: true

# 自动批准CSR的ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: auto-approve-node-csr
rules:
- apiGroups: ["certificates.k8s.io"]
  resources: ["certificatesigningrequests"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["certificates.k8s.io"]
  resources: ["certificatesigningrequests/approval"]
  verbs: ["update"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: auto-approve-node-csr-binding
subjects:
- kind: Group
  name: system:node-bootstrapper
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: auto-approve-node-csr
  apiGroup: rbac.authorization.k8s.io

配置完成后，可以手动触发一次轮转来验证。先删除kubelet当前使用的客户端证书文件，然后重启kubelet，它会自动生成新的CSR。此时通过kubectl get csr查看是否出现Pending状态的请求，并确认自动批准后状态变为Approved,Issued。

三、使用kubeadm管理控制平面证书续期

控制平面证书的续期通常使用kubeadm certs renew命令。该命令可以续期全部证书，也可以指定单个组件，例如kubeadm certs renew apiserver或kubeadm certs renew all。续期完成后证书文件会更新，但控制平面组件以静态Pod方式运行，不会自动重新加载新证书，必须重启对应Pod才能生效。

要实现自动化，可以创建一个CronJob定期执行续期操作。CronJob的Pod需要挂载宿主机的/etc/kubernetes/pki目录，并在容器内执行kubeadm certs renew all。续期之后可以直接通过crictl stop停止控制平面静态Pod，kubelet会自动重新创建并加载新证书。注意需要给CronJob对应的ServiceAccount足够的权限，或者直接使用hostPath卷并允许特权访问。

下面给出一个CronJob的示例，每月1号凌晨执行一次续期。续期完成后通过crictl stop停止apiserver、controller-manager和scheduler容器，kubelet检测到静态Pod退出后会立刻重启它们。

apiVersion: batch/v1
kind: CronJob
metadata:
  name: renew-control-plane-certs
  namespace: kube-system
spec:
  schedule: "0 0 1 * *"
  jobTemplate:
    spec:
      template:
        spec:
          hostNetwork: true
          containers:
          - name: renew
            image: bitnami/kubectl:latest
            command:
            - /bin/sh
            - -c
            - |
              kubeadm certs renew all
              crictl stop $(crictl ps --name kube-apiserver -q)
              crictl stop $(crictl ps --name kube-controller-manager -q)
              crictl stop $(crictl ps --name kube-scheduler -q)
            volumeMounts:
            - name: pki
              mountPath: /etc/kubernetes/pki
            - name: kubeadm
              mountPath: /usr/bin/kubeadm
              readOnly: true
            - name: cri-socket
              mountPath: /run/containerd/containerd.sock
          volumes:
          - name: pki
            hostPath:
              path: /etc/kubernetes/pki
              type: Directory
          - name: kubeadm
            hostPath:
              path: /usr/bin/kubeadm
              type: File
          - name: cri-socket
            hostPath:
              path: /run/containerd/containerd.sock
          restartPolicy: OnFailure

这个CronJob需要在控制平面节点上运行，所以通常会加上nodeSelector指定master节点。实际使用时要把/usr/bin/kubeadm的路径替换成环境中真实路径，如果是Docker作为容器运行时，则需要改用docker restart命令。执行续期前最好先备份/etc/kubernetes/pki目录，防止续期过程中出现意外。

四、生产环境实践与监控告警

即使配置了自动轮转，仍然需要监控证书过期时间。可以使用Prometheus的blackbox exporter定期检查API Server证书有效期，或者编写简单的shell脚本通过openssl命令获取剩余天数。下面是一个检查API Server证书有效期的命令示例，返回剩余天数，配合cron任务和告警系统即可实现过期预警。

#!/bin/bash
CERT_FILE=/etc/kubernetes/pki/apiserver.crt
END_DATE=$(openssl x509 -enddate -noout -in "$CERT_FILE" | cut -d= -f2)
END_EPOCH=$(date -d "$END_DATE" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (END_EPOCH - NOW_EPOCH) / 86400 ))
echo "API Server证书剩余天数: $DAYS_LEFT"
if [ "$DAYS_LEFT" -lt 30 ]; then
  echo "警告：证书即将过期"
fi

自动轮转失败的常见原因主要有几个。一是CSR未自动批准，通常是RBAC配置错误或者节点组绑定不正确。二是kubelet配置文件修改后没有重启，导致参数未生效。三是节点与API Server时钟偏差过大，证书校验会直接失败。四是在CA根证书轮转后，新的CA没有同步到所有节点，导致节点无法验证API Server证书。这些问题都需要在变更前做好备份和测试。

总结来说，集群组件证书自动轮转需要分层配置。节点证书交给kubelet自动轮转，控制平面证书用CronJob配合kubeadm定期续期，同时配合监控告警形成闭环。CA根证书的轮转风险很高，一般需要重新生成并逐节点替换，不建议纳入自动轮转流程。合理的证书管理策略可以显著降低集群因证书过期导致不可用的风险。

证书轮转自动续期Kubernetes集群修改时间：2026-09-23 04:19:53