必须引入cert-manager实现证书全生命周期自动化管理，它通过监听Ingress注解自动申请、续订和替换TLS证书，解决手动运维无法应对证书爆炸式增长的问题。
在 Kubernetes 生产环境中，当服务数量增长到数十甚至上百个、每个服务需独立域名和证书时，“手动创建 Secret + 手动配置 Ingress TLS”会迅速失效。核心难点不在单个证书的部署，而在于证书生命周期（申请、分发、轮换、吊销）与服务发布节奏之间的耦合——人无法跟上自动化交付的速度。
证书爆炸式增长带来的三大现实问题
• 命名空间与 Secret 管理失控：不同团队在各自命名空间创建同名 Secret（如 tls-secret），Ingress 引用时因跨命名空间不可见或拼写不一致，导致 503 或 fallback 到 fake certificate。
• 证书过期无人预警：Let’s Encrypt 90 天有效期、DigiCert 13 个月有效期混用，缺乏统一到期看板，常在凌晨告警才发现某关键 API 域名 HTTPS 已中断。
• 通配符与单域名混用引发冲突：例如 *.prod.example.com 和 admin.prod.example.com 同时存在，Ingress Controller 加载顺序不确定，部分请求命中错误证书链，浏览器提示“证书不匹配”而非“已过期”。
必须由 cert-manager 接管全链路
人工运维无法 scale，唯一可落地的方案是引入 cert-manager 作为证书编排中枢。它不是“可选插件”，而是生产级 Ingress TLS 的基础设施层：
• 它监听所有带 cert-manager.io/issuer 或 cert-manager.io/cluster-issuer 注解的 Ingress，自动创建对应 Certificate 资源；
• 自动调用 Let’s Encrypt（HTTP-01 或 DNS-01）、私有 CA 或 HashiCorp Vault 等后端完成签发；
• 在证书剩余 30 天时自动发起续订，并原子性替换 Secret 中的 tls.crt 和 tls.key；
• 支持 duration 和 renewBefore 精确控制生命周期，避免批量续期压垮 ACME 服务器。
关键配置必须收敛到 GitOps 流水线
动态管理 ≠ 放任自流。所有证书策略需声明式固化：
• 每个团队的命名空间内，只允许绑定预定义的 ClusterIssuer（如 letsencrypt-prod），禁止直接操作 Secret；
• Ingress 中 TLS 配置必须使用注解驱动：cert-manager.io/cluster-issuer: letsencrypt-prodcert-manager.io/common-name: app.team-a.example.com
• 通配符证书严格限定为 *.staging.example.com 和 *.prod.example.com 两级，且仅由平台团队通过 ClusterIssuer 统一签发，业务 Ingress 只能引用，不可自行申请；
• 所有 Certificate 资源纳入 Argo CD 或 Flux 同步范围，变更即生效，无需 kubectl apply 人工介入。
监控与故障止血不能只看指标
单纯依赖 nginx_ingress_controller_ssl_certificate_info 易被缓存误导。真实可用性需三层验证：
• 控制器层：检查 cert-manager Pod 日志中是否有 Successfully issued certificate 或 Failed to verify challenge；
• Secret 层：用脚本定期扫描所有命名空间下 kubernetes.io/tls 类型 Secret，比对 tls.crt 的 Not After 字段是否早于当前时间 +7 天；
• 终端层：从集群外真实客户端（如 curl 或浏览器）访问各域名，执行 openssl s_client -connect $HOST:443 -servername $HOST 2>/dev/null | openssl x509 -noout -dates，确认实际返回证书的有效期。
