4. 证书管理基础：TLS/SSL 证书的作用、证书过期风险、Kubernetes 中证书的存储方式（Secret）
在 Kubernetes 集群中，TLS/SSL 证书是保障通信安全的核心组件。无论是集群内部组件之间的通信（如 kube-apiserver 与 kubelet），还是外部流量通过 Ingress 进入集群，都依赖证书来建立加密通道并验证身份。本章将系统梳理证书的核心作用、过期风险以及 Kubernetes 中原生的证书存储方案——Secret。
4.1 TLS/SSL 证书的核心作用
TLS/SSL 证书本质上是一个数字身份凭证，它通过非对称加密技术解决了三个关键问题：
- 身份验证（Authentication）：客户端通过验证服务端证书的签名链，确认通信对方是预期的合法实体，防止中间人攻击。
- 数据加密（Encryption）：通过握手阶段协商出的对称密钥，对传输数据进行加密，确保即使数据被截获也无法被解读。
- 数据完整性（Integrity）：通过消息认证码（MAC）机制，确保数据在传输过程中未被篡改。
关键概念：证书由权威证书颁发机构（CA）签发，包含公钥、主体信息、有效期、签发者信息等。Kubernetes 中通常使用自建 CA 或 cert-manager 管理的 CA 来签发内部证书。
4.2 证书过期风险：从“小问题”到“大故障”
证书具有固定的有效期（通常为 1 年或更短）。一旦证书过期，其加密和验证能力将立即失效，导致以下严重后果：
| 风险等级 | 影响范围 | 典型表现 | 恢复难度 |
|---|---|---|---|
| 致命 | 集群控制面 | kube-apiserver 证书过期 → 所有 kubectl 命令失败，集群完全不可用 | 极高（需进入节点手动恢复） |
| 严重 | Ingress / 外部访问 | HTTPS 证书过期 → 浏览器显示“不安全”，用户无法访问服务 | 中等（重新签发并更新 Secret） |
| 中等 | 组件间通信 | kubelet 证书过期 → Node 状态异常，Pod 调度失败 | 较高（需重启 kubelet 并重新认证） |
| 轻微 | 内部 mTLS | Service Mesh 证书过期 → 服务间调用中断，出现 503 错误 | 中等（自动轮换机制可缓解） |
⚠️ 生产教训：证书过期是 Kubernetes 生产环境中排名前三的故障原因。许多团队在证书到期前 30 天、7 天、1 天未设置监控告警，导致在非工作时间突发集群级故障。证书轮换必须作为常规运维操作纳入自动化流程。
4.3 Kubernetes 中证书的存储方式：Secret
Kubernetes 使用 Secret 对象来存储敏感数据，包括 TLS 证书和私钥。Secret 以 Base64 编码形式存储，并通过 Volume 挂载或环境变量的方式提供给 Pod。
4.3.1 TLS Secret 的结构
Kubernetes 原生支持 kubernetes.io/tls 类型的 Secret，专门用于存储 TLS 证书。其结构如下：
apiVersion: v1
kind: Secret
metadata:
name: example-tls-secret
namespace: default
type: kubernetes.io/tls
data:
tls.crt: <Base64 编码的证书文件>
tls.key: <Base64 编码的私钥文件>当使用 Ingress 时，只需在 spec.tls.secretName 中引用该 Secret 名称，Ingress Controller 会自动加载证书并配置 HTTPS。
4.3.2 创建 TLS Secret 的常用方式
| 方式 | 命令 / 工具 | 适用场景 |
|---|---|---|
| kubectl 命令行 | kubectl create secret tls my-tls --cert=cert.pem --key=key.pem |
快速创建，适合手动操作 |
| YAML 文件 | 编写 Secret YAML 并通过 kubectl apply -f 部署 |
GitOps 流程，版本控制 |
| cert-manager | 自动签发证书并生成 Secret | 生产环境自动化轮换 |
| 外部 Secret 管理工具 | External Secrets Operator / Vault | 企业级密钥集中管理 |
4.3.3 Secret 的生命周期与轮换挑战
Secret 本身是一个静态资源，证书过期后需要手动或自动更新 Secret 中的数据。在 Deployment 中，即使 Secret 被更新，正在运行的 Pod 也不会自动重新加载证书，因为 Volume 挂载是 Pod 启动时确定的。这就引出了本课程的核心问题：如何在不重启 Pod 或造成停机的情况下，让运行中的服务加载新证书？