Kubernetes集群高可用搭建 | 团队必备 证书管理

▌ 技术引导
Kubernetes高可用集群搭建必须绕过三个核心陷阱：主控节点负载不均、证书过期导致服务中断、网络策略未预设导致组件通信故障。我见过太多团队因为证书管理不当，在生产环境中频繁遭遇无法访问API服务器或节点认证失败的问题，最终只能半夜跪着修复。真实场景中，很多企业误以为使用默认证书就能奏效，结果在升级或重置时彻底翻车。

高可用证书管理必须采用自动化与冗余机制，人工干预会带来不可控风险。比如在etcd集群中，每个节点的SSL证书必须独立配置，并且在部署时预置CA证书，避免因证书更新而触发全量重启。我曾经在部署的时候，漏掉了一个节点的证书配置，结果整个集群通信中断，导致业务降级。

证书生命周期管理必须结合Vault等工具，确保每次更新都能同步到所有节点。证书轮换时要同步更新kubelet、apiserver、controller-manager、scheduler等组件，否则会出现部分节点认证失败的问题。我用过Kubernetes的内置证书管理，但发现其对多节点环境支持极差，必须手动干预，效率极低。

推荐使用独立的CA服务器来生成证书，并在集群部署阶段通过脚本自动注入。这可以避免证书分散管理带来的麻烦，同时提高安全性和可追溯性。实际部署中，每个组件的证书都需要包含特定的SAN字段，特别是apiserver的证书必须包含所有主控节点的IP和域名，否则会触发连接异常。

最后，证书存储路径和权限设置必须严格按照Kubernetes文档规范，否则会引发权限不足或无法读取证书的问题。命令行工具比如kubeadm、kops、kubefed等都支持证书自动生成，但依赖其内置的证书管理模块，一旦出现异常，排查起来会非常困难。

▌ 技术参考

etcd集群证书配置必须独立于kubeadm生成的证书，在每个etcd节点部署前，先用cfssl生成CA和节点证书。生成证书时，注意指定CN为"etcd"，并添加所有节点的IP地址到SAN字段中。命令类似：

```bash
cfssl genkey -init-ca -profile=etcd -config=cfssl.json
cfssl sign -ca=ca.pem -ca-key=ca-key.pem -config=cfssl.json -profile=etcd node-csr.json
```

证书必须存储在/etc/kubernetes/ssl/目录下，并设置正确的权限，比如chmod 644和chown root:root。在集群部署完成后，通过kubectl get secrets命令确认证书是否已正确注入到每个节点。如果不同步，需要手动复制证书文件并重新加载kubelet配置。

apiserver证书需要包含所有主控节点的IP和域名，否则在访问时会提示"X509: certificate is not trusted"。使用kops工具部署时，可以配置--apiserver-cert-extra-sans参数添加额外的SAN字段。比如：

```bash
kops create cluster --name=example.com --state=s3 --master-size=3 --node-size=2 --node-count=3 --apiserver-cert-extra-sans="10.0.0.1,10.0.0.2,10.0.0.3"
```

证书轮换必须提前布局，不能等到过期才处理。建议使用Vault或Consul作为证书管理中心，配置证书自动下发和轮换策略。例如，使用Vault的KV v2存储证书，并通过kubectl secret命令将证书注入到各个组件中。这样可以避免手动更新并减少人为错误。

在多个master节点的集群中，证书需要统一管理。比如使用kubeadm部署时，每个master节点都会自动生成证书，但这些证书的CA是同一个，所以必须在所有master节点中同步。如果某个节点证书丢失，可以通过kubeadm upgrade命令重新生成，但注意要保留现有的CA证书，否则会导致整个集群信任链断裂。

证书过期时，必须同时更新apiserver、controller-manager、scheduler、kubelet、coredns等组件的证书。建议在证书即将过期前，通过kops或kubeadm的证书轮换功能进行统一替换。如果手动替换，需要停用对应的组件，更新证书后重新启动，但这种做法容易引发服务中断。

证书应该使用TLSv1.2或更高版本，避免兼容性问题。使用openssl生成证书时，指定-cipher参数为ECDHE-RSA-AES256-SHA384，确保加密强度。在生成证书时，注意指定正确的有效期，比如设置--valid-for参数为8760h（一年），避免频繁更换。

在多数据中心部署时，证书需要跨区域同步。比如使用etcd集群时，每个节点的证书必须被所有节点信任。可以使用etcd的--cert-file和--key-file参数指定证书路径，并确保所有节点的CA证书一致。如果某个节点的证书与CA不匹配，etcd会直接拒绝通信，导致集群状态异常。

证书管理是高可用集群中最容易被忽视的地方，但又是最关键的一环。比如在部署时，如果忘记添加某个master节点的IP到apiserver证书的SAN字段，会导致kubectl命令在访问该节点时失败。这种问题往往需要深入检查证书内容才能发现，排查耗时较长。

使用kops工具部署时，可以通过--apiserver-cert-extra-sans参数添加额外域名或IP地址，避免证书不匹配的问题。同时，每个节点的证书需要包含自己的IP和主机名，否则在通信时会触发证书验证错误。比如，在生成证书时，必须确保所有节点的IP地址都包含在SAN中。

在证书更新过程中，必须同步更新所有相关的组件配置文件，比如/etc/kubernetes/manifests/controller-manager.yaml、/etc/kubernetes/manifests/scheduler.yaml等。如果某个组件的证书未及时更新，会导致集群无法正常运行。例如，当kubelet证书过期后，节点会失联，导致Pod无法调度。

证书生命周期管理需要结合监控系统，比如Prometheus和Grafana，实时跟踪证书剩余有效期。当证书剩余不足30天时，触发自动轮换流程。使用Ansible或Terraform可以实现证书自动同步，避免手动操作带来的风险。

在实际部署中，我曾遇到过证书泄露的问题，为避免这种情况，建议将证书存储在加密的secret中，并设置合理的访问权限。使用kops创建集群时，默认会将证书存储在S3桶中，但需要配置访问策略，确保只有指定的节点可以读取。如果权限设置不当，会导致证书无法访问，进而影响整个集群的可用性。

对于大规模集群，建议采用独立的证书管理系统，比如Vault。Vault可以实现动态证书下发，确保每个节点在启动时自动获取最新证书。同时，Vault的审计日志可以记录所有证书的使用情况，方便后期排查问题。

在多集群场景中，证书管理需要跨集群同步，建议使用kubefed进行证书自动同步。kubefed会将主集群的证书信息同步到各个子集群中，避免证书不一致的问题。如果某个子集群的证书未能成功同步，可能导致跨集群通信失败。

在某些情况下，使用自签名证书会导致后续运维困难。因此，建议在生产环境统一使用由CA签发的证书，确保所有组件的证书具有统一的信任链。同时，CA证书需要进行备份，防止因误操作导致整个集群无法信任任何证书。

在证书替换过程中，必须确保所有组件的重启顺序合理，避免服务中断。例如，先更新apiserver的证书，再重启controller-manager，最后重启kubelet。如果顺序颠倒，可能会导致某些组件在证书未更新时仍试图使用旧证书，引发连接异常。

在跨区域部署时，证书需要考虑网络延迟因素。例如，etcd集群分布在多个AWS可用区时，延迟可能会影响证书同步效率，进而导致节点间的通信异常。此时，建议在部署时使用私有网络和加密通信，避免因网络问题引发证书验证失败。

在证书管理过程中，切忌忽视每个组件的配置文件，特别是kubelet的--tls-cert-file和--tls-private-key-file参数。如果这两个参数未正确指向新证书，会导致节点无法认证，进而被apiserver踢出集群。

对于某些特殊场景，比如混合云部署，可以采用多CA证书策略，确保每个区域的证书都能被其他区域的组件信任。这需要在集群配置中指定多个CA证书，并在每个节点的证书中添加对应的CA信息。

在证书更新之前，必须确保所有组件的版本兼容性。比如，使用kops 1.22版本部署的集群，如果升级到kops 1.26，可能需要重新生成证书，否则会导致组件无法识别旧证书格式。这种兼容性问题在实际部署中非常常见，需要提前规划。