ingress 依赖 ingress controller（如 nginx）实现 tls 终止，证书必须以类型为 kubernetes.io/tls 的 secret 存储，字段名严格为 tls.crt 和 tls.key，且需与 ingress 同命名空间；ingress 资源中须通过 tls 块显式引用该 secret，并确保 hosts 与证书 san 一致。
在 Kubernetes 中，Ingress 本身不直接处理 SSL/TLS 加密，而是由背后的 Ingress Controller（如 NGINX Ingress Controller）完成 TLS 终止。证书必须以 Secret 形式提供给控制器，这是云原生场景下安全、可声明、可复用的标准做法。
为什么必须用 Secret 存储证书
Kubernetes 将证书和私钥视为敏感数据，禁止明文写入 Ingress YAML 或挂载为普通文件。Secret 提供了基础的访问控制、命名空间隔离和声明式生命周期管理能力。NGINX Ingress Controller 启动时会监听 Secret 变化，自动热加载新证书，无需重启 Pod。
- Secret 类型必须为 kubernetes.io/tls，否则控制器无法识别
- 字段名必须严格为 tls.crt 和 tls.key（大小写敏感）
- Secret 必须与 Ingress 处于同一命名空间，跨命名空间引用不被支持
创建 TLS Secret 的两种常用方式
无论证书来源是 Let’s Encrypt、腾讯云、阿里云还是自签名，最终都要转为标准 Secret 格式。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
-
命令行快速创建：
kubectl create secret tls my-app-tls --cert=./tls.crt --key=./tls.key -n prod -
YAML 声明式创建（推荐用于 GitOps）：
先 base64 编码证书内容（注意：不要编码换行符），再写入 YAML：apiVersion: v1<br>kind: Secret<br>metadata:<br> name: my-app-tls<br> namespace: prod<br>type: kubernetes.io/tls<br>data:<br> tls.crt: LS0t...<br> tls.key: LS0t...
Ingress 资源中正确引用证书
仅创建 Secret 不够，Ingress 必须显式声明 TLS 配置段，并精确匹配域名与 Secret 名称。
-
hosts 列表必须与证书 SAN（Subject Alternative Name）一致，例如证书支持
app.example.com，则 hosts 中不能只写example.com - secretName 必须与 Secret 的 name 完全相同，拼写或大小写错误会导致 503 或默认证书响应
- 若需多域名共用一张通配符证书（如
*.example.com），可在同一 tls 块中列出多个 host
示例片段：
spec:<br> tls:<br> - hosts:<br> - app.example.com<br> - api.example.com<br> secretName: my-app-tls<br> rules:<br> - host: app.example.com<br> http: ...
生产环境关键注意事项
证书更新不是“替换文件”那么简单，需兼顾滚动生效与零中断。
- 更新证书只需更新 Secret 内容（kubectl apply 或 patch），NGINX Controller 通常在 10 秒内自动重载
- 避免直接编辑私钥文件后重新 create —— 这会触发 Secret 版本变更，可能引发短暂连接中断；建议用
kubectl replace或 patch - 使用 cert-manager 时，Secret 由其全生命周期管理，Ingress 中仍需配置 tls 字段指向该 Secret，但无需手动维护证书内容
- 腾讯云/阿里云等托管 Ingress 若对接 CLB，Secret 中可能需额外字段（如
qcloud_cert_id），此时类型不再是kubernetes.io/tls，而是Opaque，需按云厂商文档构造
