在运维Kubernetes集群时，证书管理是个让人头疼的问题。就像食品有保质期一样，Kubernetes的各种证书也有有效期，一旦过期，整个集群就可能"罢工"。今天咱们就来聊聊如何用自动化方案解决这个痛点。

一、为什么需要证书自动轮换

Kubernetes集群中有多种证书，包括API Server证书、etcd证书、kubelet证书等。这些证书默认有效期通常是一年。想象一下，凌晨三点突然收到报警说集群不可用，排查半天发现是证书过期了，这种经历绝对让人崩溃。

手动更新证书不仅麻烦，还容易出错。我们需要连接每个节点，备份旧证书，生成新证书，然后重启服务。对于大型集群来说，这简直就是噩梦。自动化轮换方案能让我们高枕无忧，再也不用担心半夜被报警吵醒。

二、证书轮换方案设计思路

要实现自动化轮换，我们需要考虑几个关键点。首先是监控证书有效期，这就像定期检查食品保质期一样重要。其次是安全地生成新证书，就像换锁不能影响家门安全。最后是无缝切换，就像给行驶中的汽车换轮胎，不能影响正常行驶。

这里我们选择使用cert-manager这个Kubernetes原生工具来实现自动化证书管理。它就像个智能管家，能帮我们打理所有证书相关事务。

三、具体实现步骤

1. 安装cert-manager

首先我们需要在集群中部署cert-manager。这里使用Helm来安装，就像用应用商店安装APP一样简单：

# 添加cert-manager的helm仓库
helm repo add jetstack https://charts.jetstack.io
helm repo update

# 安装cert-manager
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.11.0 \
  --set installCRDs=true

2. 配置CA Issuer

cert-manager需要知道从哪里获取证书。我们配置一个CA Issuer，就像告诉管家去哪里拿新锁：

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: ca-issuer
  namespace: default
spec:
  ca:
    secretName: ca-key-pair  # 引用包含CA证书和私钥的Secret

3. 创建证书自动轮换策略

现在我们来定义证书资源，设置自动轮换规则：

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: kube-apiserver-cert
  namespace: default
spec:
  secretName: kube-apiserver-tls  # 新证书存储的Secret名称
  duration: 2160h  # 90天有效期
  renewBefore: 720h  # 到期前30天开始轮换
  issuerRef:
    name: ca-issuer
    kind: Issuer
  commonName: kube-apiserver
  dnsNames:
  - kubernetes
  - kubernetes.default
  - kubernetes.default.svc
  - kubernetes.default.svc.cluster.local
  - kube-apiserver

4. 自动更新服务证书

为了让服务使用新证书，我们需要监控Secret变化并重启服务。这里使用Reloader来实现：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kube-apiserver
  annotations:
    reloader.stakater.com/auto: "true"  # 启用自动重载
spec:
  template:
    spec:
      containers:
      - name: kube-apiserver
        volumeMounts:
        - name: cert-volume
          mountPath: /etc/kubernetes/pki
      volumes:
      - name: cert-volume
        secret:
          secretName: kube-apiserver-tls  # 挂载证书Secret

四、方案优化与注意事项

1. 多级证书策略

对于生产环境，建议采用多级CA架构，就像大公司的门禁系统有主卡和子卡：

# 根CA
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: root-ca
spec:
  ca:
    secretName: root-ca-key-pair

# 中间CA
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: intermediate-ca
spec:
  secretName: intermediate-ca-key-pair
  issuerRef:
    name: root-ca
    kind: ClusterIssuer
  commonName: intermediate-ca
  isCA: true

2. 监控与告警

虽然实现了自动化，但我们还是要监控证书状态，就像汽车有自动驾驶也需要仪表盘：

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: cert-expiry-alerts
spec:
  groups:
  - name: cert-manager
    rules:
    - alert: CertificateExpirySoon
      expr: certmanager_certificate_expiration_timestamp_seconds - time() < 86400 * 30  # 30天过期
      labels:
        severity: warning
      annotations:
        summary: "Certificate will expire soon (instance {{ $labels.instance }})"
        description: "Certificate {{ $labels.name }} expires in 30 days"

3. 灾备方案

任何时候都要有Plan B。建议保留手动更新证书的能力，就像自动门也要保留手动开关：

# 手动更新证书的应急命令
kubeadm alpha certs renew all --config /etc/kubernetes/kubeadm-config.yaml
systemctl restart kubelet

五、技术方案对比

1. 与手动更新对比

手动更新就像手动挡汽车，需要频繁操作且容易出错。我们的方案就像自动挡，省心省力。具体来说：

  • 手动更新：耗时费力，平均每个集群需要2-3小时
  • 自动轮换：一次配置，永久生效，更新过程只需几分钟

2. 与其他工具对比

除了cert-manager，还有Vault等方案。cert-manager的优势在于：

  • 原生Kubernetes支持，无需额外基础设施
  • 简单的声明式配置
  • 丰富的监控指标

六、实际应用案例

某电商平台使用这套方案后，证书相关故障降为零。他们的集群有200多个节点，过去每年都要组织专门的"证书更新日"，现在完全自动化了。运维团队可以专注于更有价值的工作，而不是重复性的证书更新。

七、经验总结

实施证书自动轮换就像给运维工作买了保险。虽然初期需要一些投入，但长远来看绝对是值得的。关键收获：

  1. 自动化程度越高，人为错误越少
  2. 监控告警必不可少，不能完全依赖自动化
  3. 灾备方案一定要有，自动化不是万能的

通过这个方案，我们实现了：

  • 证书过期前自动更新
  • 服务无感知切换
  • 完善的监控告警
  • 灵活的灾备方案

现在，终于可以安心睡觉，不用担心半夜被证书过期的报警吵醒了。