给K8s证书上个闹钟：利用kubeadm和crontab实现证书过期自动巡检与续期（附脚本）
给K8s证书上个闹钟：利用kubeadm和crontab实现证书过期自动巡检与续期（附脚本）
凌晨三点，手机铃声突然响起——又是证书过期导致的集群故障。这种场景对于运维团队来说再熟悉不过。Kubernetes集群中各类证书的有效期管理，往往成为最容易被忽视却又最具破坏性的运维盲点。本文将分享如何通过自动化手段，将证书管理从被动应急转变为主动预防，让运维团队告别深夜报警的困扰。
1. Kubernetes证书生命周期管理基础
在Kubernetes集群中，证书是安全通信的基石。通过kubeadm部署的集群默认会生成以下几类关键证书：
- API Server证书：用于集群控制平面的安全通信
- etcd证书：保障分布式键值存储的加密传输
- kubelet客户端证书：节点与控制平面间的身份验证
- front-proxy证书：用于API聚合层通信
这些证书默认有效期为1年，过期后将导致集群组件间通信中断。传统的手动检查方式存在明显缺陷：
# 传统手动检查方式示例 kubeadm certs check-expiration openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates证书管理面临的三大挑战：
- 检查频率难以保证（人工检查易遗漏）
- 过期时间分散（不同证书过期时间不一致）
- 续期操作复杂（涉及多组件重启和协调）
2. 自动化检查方案设计与实现
2.1 基于kubeadm的证书检查脚本
核心检查逻辑可以通过封装kubeadm命令实现：
#!/bin/bash # cert-checker.sh EXPIRY_THRESHOLD=30 # 过期阈值(天) # 检查kubeadm管理的证书 kubeadm certs check-expiration --config /etc/kubernetes/kubeadm-config.yaml | \ awk -v threshold=$EXPIRY_THRESHOLD ' /^CERTIFICATE/ {cert=$2; sub(/.*\//, "", cert)} /^Expires/ { split($3, d, "-") expiry=mktime(d[1]" "d[2]" "d[3]" 00 00 00") diff=(expiry-systime())/86400 if (diff < threshold) { printf "[WARN] 证书 %s 将在 %.1f 天后过期\n", cert, diff exit 1 } }'2.2 OpenSSL深度检查方案
对于kubelet等动态证书，需要更精细的检查逻辑：
# kubelet证书检查函数 check_kubelet_cert() { local cert_file="/var/lib/kubelet/pki/kubelet-client-current.pem" local expiry_date=$(openssl x509 -enddate -noout -in "$cert_file" | cut -d= -f2) local expiry_epoch=$(date -d "$expiry_date" +%s) local now_epoch=$(date +%s) local days_left=$(( (expiry_epoch - now_epoch) / 86400 )) [ $days_left -lt $EXPIRY_THRESHOLD ] && \ echo "Kubelet证书将在$days_left天后过期" && return 1 return 0 }2.3 检查结果分级处理
建议对检查结果进行分级告警：
| 剩余天数 | 告警级别 | 处理建议 |
|---|---|---|
| <7天 | CRITICAL | 立即处理 |
| 7-15天 | WARNING | 本周计划内处理 |
| 15-30天 | NOTICE | 下个维护窗口处理 |
| >30天 | OK | 定期监控即可 |
3. 自动化巡检系统集成
3.1 基于Crontab的定时检查
将检查脚本配置为定期任务：
# 每天凌晨2点执行检查 0 2 * * * /opt/k8s-scripts/cert-checker.sh >> /var/log/k8s-cert-monitor.log 2>&13.2 Prometheus监控集成
通过Node Exporter的textfile收集器暴露指标：
# 生成Prometheus格式的指标文件 cert_checker.sh | awk ' /\[WARN\]/ { print "k8s_cert_expiry_alert{component=\""$3"\"} 1" print "k8s_cert_expiry_days{component=\""$3"\"} "$6 }' > /var/lib/node_exporter/textfile_collector/k8s_cert.prom对应的告警规则配置示例：
groups: - name: k8s-cert-alerts rules: - alert: K8sCertNearExpiry expr: k8s_cert_expiry_days < 15 for: 1h labels: severity: warning annotations: summary: "K8s证书即将过期 ({{ $labels.component }})" description: "证书 {{ $labels.component }} 将在{{ $value }}天后过期"4. 安全自动化续期方案
4.1 半自动续期流程设计
建议采用"人工审批+自动执行"的混合模式：
- 检测到证书即将过期时触发审批流程
- 审批通过后执行续期操作
- 验证续期结果并通知
# 续期执行脚本示例 renew_certs() { # 备份现有证书 local backup_dir="/etc/kubernetes/pki/backup_$(date +%Y%m%d)" mkdir -p "$backup_dir" cp -a /etc/kubernetes/pki/*.crt /etc/kubernetes/pki/*.key "$backup_dir" # 执行续期 kubeadm certs renew all # 重启控制平面组件 docker ps -f 'name=k8s_kube-apiserver|k8s_kube-controller-manager|k8s_kube-scheduler' -q | xargs docker restart # 更新kubeconfig cp /etc/kubernetes/admin.conf ${HOME}/.kube/config }4.2 kubelet证书的特殊处理
kubelet证书需要额外步骤：
# 续期后处理kubelet证书 systemctl restart kubelet kubectl get csr | grep Pending | awk '{print $1}' | xargs kubectl certificate approve4.3 安全审计与合规考量
建议记录所有证书操作：
| 操作类型 | 记录内容 | 存储位置 |
|---|---|---|
| 自动检查 | 检查时间、结果、触发条件 | ELK/Splunk |
| 证书续期 | 操作人、时间、变更前哈希 | 区块链/数据库 |
| 审批流程 | 审批人、意见、时间戳 | 工作流系统数据库 |
5. 进阶：证书管理的长期解决方案
5.1 使用外部CA集成
对于生产环境，建议考虑：
- Hashicorp Vault：提供动态证书签发能力
- Cert-manager：Kubernetes原生的证书管理Operator
- 企业级PKI：与现有CA系统集成
# 使用cert-manager的ClusterIssuer示例 apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: vault-issuer spec: vault: server: https://vault.example.com path: pki/sign/k8s-cluster auth: tokenSecretRef: name: vault-token key: token5.2 证书轮换策略优化
推荐的最佳实践组合：
分级有效期：
- 根CA：5-10年
- 中间CA：2-3年
- 终端实体证书：3-6个月
滚动更新机制：
- 提前30天开始告警
- 设置15天的强制更新窗口
- 保留7天的重叠期确保平滑过渡
自动化测试验证：
# 证书变更后验证脚本 verify_cert_chain() { kubectl get --raw /healthz kubectl get nodes crictl pods }
在实际生产环境中，我们团队通过这套自动化系统将证书相关事件减少了90%。最关键的改进点是建立了分级预警机制，使得证书更新可以合理安排在正常工作时段进行，而非等到最后一刻紧急处理。