抹茶柚子冰1. 为什么Kubernetes需要cert-manager？
在传统IT架构中，SSL/TLS证书管理是个令人头疼的问题。想象一下，你管理着上百个微服务，每个都需要配置HTTPS，手动操作不仅耗时还容易出错。这正是cert-manager诞生的背景——它让Kubernetes集群中的证书管理变得像声明式配置一样简单。
我曾在生产环境中手动维护过证书，那种半夜被证书过期告警吵醒的经历实在难忘。cert-manager通过自动化解决了三大痛点：
- 自动签发：对接Let's Encrypt等CA机构
- 自动续期：在证书到期前完成更新
- 自动部署：将证书注入Ingress或Secret
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. ACME协议工作机制解析
ACME（Automated Certificate Management Environment）是Let's Encrypt提出的协议规范。它的精妙之处在于用HTTP-01或DNS-01挑战验证域名所有权。以HTTP-01为例：
- cert-manager在/.well-known/acme-challenge/路径创建特定文件
- Let's Encrypt服务器尝试访问该文件
- 验证通过后颁发证书
重要提示：生产环境建议使用DNS-01验证方式，它不需要开放HTTP端口，安全性更高。但需要配置云厂商的API密钥。
我曾在AWS Route53上配置时踩过坑：API密钥权限过大存在风险，过小又无法完成验证。最佳实践是：
yaml复制apiVersion: v1
kind: Secret
metadata:
name: route53-credentials
type: Opaque
data:
secret-access-key: BASE64_ENCODED_KEY
3. cert-manager核心组件详解
安装cert-manager后会出现三个关键组件：
-
Issuer/ClusterIssuer：证书签发者定义
- ClusterIssuer是集群级别的（适合多命名空间）
- Issuer限定在单个命名空间
-
Certificate：证书申请资源
yaml复制apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: example-com spec: secretName: example-com-tls issuerRef: name: letsencrypt-prod kind: ClusterIssuer dnsNames: - "example.com" - "www.example.com" -
Challenge：ACME验证过程的临时资源
组件交互流程：
mermaid复制graph TD
A[Certificate] -->|创建| B[Order]
B -->|触发| C[Challenge]
C -->|完成| D[Certificate Issued]
4. 生产环境部署方案
经过多个项目实践，我总结出高可用部署方案：
架构设计：
- 独立命名空间：
kube-system之外单独创建cert-manager - 资源限制：
yaml复制resources: limits: cpu: 500m memory: 512Mi requests: cpu: 100m memory: 128Mi - 副本数：至少2个controller Pod
关键配置：
yaml复制apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: admin@example.com
privateKeySecretRef:
name: letsencrypt-prod-account-key
solvers:
- dns01:
route53:
region: us-west-2
accessKeyID: AKIAxxxxxxxxxxxx
secretAccessKeySecretRef:
name: route53-credentials
key: secret-access-key
5. 常见故障排查指南
问题1：证书卡在Pending状态
- 检查Issuer状态：
kubectl describe clusterissuer - 查看Order事件：
kubectl describe order <name> - 常见原因：ACME账号密钥配置错误
问题2：DNS验证超时
- 测试DNS解析：
dig TXT _acme-challenge.example.com - 检查权限：确保DNS API密钥有修改记录的权限
- 我遇到过的坑：AWS Route53的API调用有速率限制
问题3：证书续期失败
- 检查cert-manager日志：
bash复制
kubectl logs -n cert-manager deploy/cert-manager - 验证Secret是否更新：
kubectl get secret example-com-tls -o jsonpath='{.data.tls\.crt}'
6. 高级配置技巧
证书轮换策略
yaml复制spec:
renewBefore: 720h # 30天前开始续期
revisionHistoryLimit: 3
多CA备用方案
yaml复制apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: fallback-cert
spec:
issuerRef:
name: backup-issuer
kind: ClusterIssuer
usages:
- server auth
- client auth
证书监控方案
bash复制# 检查证书过期时间
kubectl get secret example-com-tls -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -enddate -noout
在实际运维中，我发现结合Prometheus监控证书过期时间非常有用。可以配置类似这样的告警规则：
yaml复制- alert: CertificateExpiringSoon
expr: (certmanager_certificate_expiration_timestamp_seconds - time()) / 86400 < 30
for: 5m
labels:
severity: warning
annotations:
summary: "证书即将过期 (实例 {{ $labels.instance }})"
description: "证书 {{ $labels.name }} 将在30天内过期"
经过多个生产集群的验证，这套方案能有效降低证书管理的人力成本。最后分享一个实用技巧：对于开发环境，可以使用Let's Encrypt的staging环境避免触发速率限制：
yaml复制spec:
acme:
server: https://acme-staging-v02.api.letsencrypt.org/directory