Kubernetes高可用集群证书体系设计与实践

1. 项目概述在构建Kubernetes高可用集群时证书体系是最关键也是最容易被忽视的部分。作为一位经历过多次K8s集群部署的老兵我深知一个配置不当的证书体系会导致集群出现各种灵异问题。本文将基于三Master节点的生产环境详细解析Kubernetes全链路加密通信的证书体系设计与实现。为什么需要如此复杂的证书体系简单来说Kubernetes的每个组件都需要通过TLS双向认证来建立信任关系。不同于简单的单向HTTPSKubernetes要求组件间必须互相验证身份。这就好比不仅网站要向你证明它是真实的服务器证书你也需要向网站证明你是合法的访问者客户端证书。2. 核心设计思路2.1 证书体系架构设计在Kubernetes集群中我们设计了三级CA体系集群根CA负责签发apiserver、kubelet、controller-manager等核心组件的证书ETCD独立CA专门用于etcd集群内部通信与主集群隔离前端代理CA处理kube-proxy与apiserver之间的通信这种分级设计有三大优势安全隔离etcd作为集群数据库使用独立CA可降低被攻击面职责分离不同场景使用不同CA避免一证多用灵活管理可独立更新某类证书而不影响其他组件2.2 关键通信链路在正式动手前我们需要明确集群中所有需要加密的通信路径通信方向客户端证书服务端证书验证CAkubelet → apiserverkubelet.crtapiserver.crtca.crtapiserver → kubeletapiserver-kubelet-client.crtkubelet.crtca.crtapiserver → etcdapiserver-etcd-client.crtetcd/server.crtetcd/ca.crtetcd peer通信etcd/peer.crtetcd/peer.crtetcd/ca.crt提示这张表建议保存后续部署和排错时非常有用3. 证书生成实操3.1 环境准备首先在所有Master节点安装cfssl工具集# 安装cfssl工具 wget https://github.com/cloudflare/cfssl/releases/download/v1.6.4/cfssl_1.6.4_linux_amd64 -O /usr/local/bin/cfssl wget https://github.com/cloudflare/cfssl/releases/download/v1.6.4/cfssljson_1.6.4_linux_amd64 -O /usr/local/bin/cfssljson chmod x /usr/local/bin/cfssl /usr/local/bin/cfssljson # 验证安装 cfssl version创建统一的证书管理目录mkdir -p /etc/kubernetes/pki/etcd /etc/kubernetes/pki/front-proxy cd /etc/kubernetes/pki3.2 根证书生成集群根CAcat ca-config.json EOF { signing: { default: { expiry: 87600h }, profiles: { kubernetes: { usages: [signing, key encipherment, server auth, client auth], expiry: 87600h }, etcd: { usages: [signing, key encipherment, server auth, client auth], expiry: 87600h } } } } EOF cat ca-csr.json EOF { CN: kubernetes, key: { algo: rsa, size: 2048 }, names: [ { C: CN, ST: Beijing, L: Beijing, O: kubernetes, OU: k8s-cluster } ] } EOF cfssl gencert -initca ca-csr.json | cfssljson -bare caETCD独立CAcat etcd/ca-csr.json EOF { CN: etcd-ca, key: { algo: rsa, size: 2048 }, names: [ { C: CN, ST: Beijing, L: Beijing, O: etcd, OU: k8s-cluster } ] } EOF cfssl gencert -initca etcd/ca-csr.json | cfssljson -bare etcd/ca前端代理CAcat front-proxy/ca-csr.json EOF { CN: front-proxy-ca, key: { algo: rsa, size: 2048 }, names: [ { C: CN, ST: Beijing, L: Beijing, O: kubernetes, OU: k8s-cluster } ] } EOF cfssl gencert -initca front-proxy/ca-csr.json | cfssljson -bare front-proxy/ca重要提示CA私钥.key文件必须严格保密只需在初始Master节点生成不要分发到其他节点3.3 组件证书生成apiserver证书特别注意hosts字段必须包含所有Master节点IP负载均衡VIP服务网段网关IP关键DNS名称cat apiserver-csr.json EOF { CN: kube-apiserver, key: { algo: rsa, size: 2048 }, names: [ { C: CN, ST: Beijing, L: Beijing, O: kubernetes, OU: k8s-cluster } ], hosts: [ 127.0.0.1, 10.10.107.223, 10.10.107.224, 10.10.107.225, 10.10.107.222, booiood.cluster.k8s, kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local, 10.96.0.1 ] } EOF cfssl gencert -caca.crt -ca-keyca.key -configca-config.json -profilekubernetes apiserver-csr.json | cfssljson -bare apiserveretcd相关证书# etcd server证书 cat etcd/server-csr.json EOF { CN: etcd-server, key: { algo: rsa, size: 2048 }, names: [ { C: CN, ST: Beijing, L: Beijing, O: etcd, OU: k8s-cluster } ], hosts: [ 127.0.0.1, 10.10.107.223, 10.10.107.224, 10.10.107.225 ] } EOF cfssl gencert -caetcd/ca.crt -ca-keyetcd/ca.key -configca-config.json -profileetcd etcd/server-csr.json | cfssljson -bare etcd/server # etcd peer证书 cat etcd/peer-csr.json EOF { CN: etcd-peer, key: { algo: rsa, size: 2048 }, names: [ { C: CN, ST: Beijing, L: Beijing, O: etcd, OU: k8s-cluster } ], hosts: [ 127.0.0.1, 10.10.107.223, 10.10.107.224, 10.10.107.225 ] } EOF cfssl gencert -caetcd/ca.crt -ca-keyetcd/ca.key -configca-config.json -profileetcd etcd/peer-csr.json | cfssljson -bare etcd/peerkubelet证书每个节点需要独立的kubelet证书cat kubelet-master-223-csr.json EOF { CN: system:node:master-223, key: { algo: rsa, size: 2048 }, names: [ { C: CN, ST: Beijing, L: Beijing, O: system:nodes, OU: k8s-cluster } ], hosts: [ 127.0.0.1, 10.10.107.223, master-223 ] } EOF cfssl gencert -caca.crt -ca-keyca.key -configca-config.json -profilekubernetes kubelet-master-223-csr.json | cfssljson -bare kubelet-master-223注意CN字段格式必须为system:node:主机名O字段必须为system:nodes这是kubelet在RBAC系统中的身份标识4. 证书分发策略4.1 分发原则CA私钥不分发仅保留在初始Master节点按需分发每个组件只获取它需要的证书权限最小化避免不必要的证书扩散4.2 自动化分发脚本#!/bin/bash # 定义目标节点 NODES(10.10.107.224 10.10.107.225) for node in ${NODES[]}; do echo 分发证书到 $node # 创建目录 ssh root$node mkdir -p /etc/kubernetes/pki/etcd /etc/kubernetes/pki/front-proxy # 集群根CA scp /etc/kubernetes/pki/ca.crt root$node:/etc/kubernetes/pki/ # etcd相关 scp /etc/kubernetes/pki/etcd/ca.crt root$node:/etc/kubernetes/pki/etcd/ scp /etc/kubernetes/pki/etcd/server.{crt,key} root$node:/etc/kubernetes/pki/etcd/ scp /etc/kubernetes/pki/etcd/peer.{crt,key} root$node:/etc/kubernetes/pki/etcd/ # apiserver scp /etc/kubernetes/pki/apiserver.{crt,key} root$node:/etc/kubernetes/pki/ scp /etc/kubernetes/pki/apiserver-etcd-client.{crt,key} root$node:/etc/kubernetes/pki/ # 前端代理 scp /etc/kubernetes/pki/front-proxy/ca.crt root$node:/etc/kubernetes/pki/front-proxy/ scp /etc/kubernetes/pki/front-proxy-client.{crt,key} root$node:/etc/kubernetes/pki/ done5. 证书验证与排错5.1 基础验证# 检查证书有效期 openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates # 验证证书链 openssl verify -CAfile /etc/kubernetes/pki/ca.crt /etc/kubernetes/pki/apiserver.crt # 检查证书包含的SAN openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout | grep -A 1 Subject Alternative Name5.2 常见问题排查问题1x509: certificate relies on legacy Common Name field原因Kubernetes 1.19要求必须使用Subject Alternative Name (SAN)解决确保证书CSR中包含正确的hosts字段问题2x509: certificate signed by unknown authority原因缺少或错误的CA证书解决检查组件是否配置了正确的CA证书路径确认所有节点上的ca.crt内容一致问题3connection refused或TLS handshake timeout原因证书中的IP/DNS与实际的访问地址不匹配解决检查apiserver证书是否包含所有Master IP和VIP检查kubelet证书的CN是否匹配节点主机名6. 证书轮换策略6.1 手动轮换步骤生成新证书逐个节点更新证书重启相关服务# 以apiserver证书为例 cfssl gencert -caca.crt -ca-keyca.key -configca-config.json \ -profilekubernetes apiserver-csr.json | cfssljson -bare apiserver-new mv apiserver-new.crt apiserver.crt mv apiserver-new.key apiserver.key systemctl restart kube-apiserver6.2 自动轮换机制Kubernetes内置了kubelet证书自动轮换功能# 查看当前证书状态 kubeadm alpha certs check-expiration # 手动更新所有证书 kubeadm alpha certs renew all注意自动轮换需要配置好kubeadm的证书管理策略7. 安全加固建议定期轮换证书建议每3-6个月更新一次证书私钥保护设置适当的文件权限chmod 600 /etc/kubernetes/pki/*.key审计日志监控证书相关操作auditctl -w /etc/kubernetes/pki/ -p wa -k k8s_certs备份策略定期备份CA和关键证书tar czvf k8s-certs-backup-$(date %Y%m%d).tar.gz /etc/kubernetes/pki/8. 深度原理解析8.1 双向认证流程Kubernetes使用的双向TLS认证流程如下客户端发送ClientHello列出支持的密码套件服务端响应ServerHello选择密码套件并发送服务端证书客户端验证服务端证书检查签名是否有效检查有效期检查证书用途是否包含服务器认证检查主机名是否匹配服务端请求客户端证书客户端发送客户端证书服务端验证客户端证书类似步骤3建立加密通道8.2 证书字段详解关键字段含义CN (Common Name)标识主体名称在K8s中与RBAC系统关联O (Organization)表示组织对应K8s中的用户组SAN (Subject Alternative Name)扩展的主机名/IP列表Key Usage定义证书用途签名、加密等Extended Key Usage更具体的用途服务器认证、客户端认证等例如kubelet证书的O字段为system:nodes这使得它可以绑定到Kubernetes内置的system:nodes用户组从而获得相应的权限。9. 性能优化技巧ECDSA替代RSA使用更高效的椭圆曲线算法key: { algo: ecdsa, size: 256 }优化证书有效期平衡安全性与运维成本会话复用配置TLS会话票据减少握手开销apiVersion: v1 kind: Pod metadata: name: kube-apiserver spec: containers: - command: - kube-apiserver - --tls-cipher-suitesTLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - --tls-min-versionVersionTLS1210. 实战经验分享在多年的K8s集群部署中我总结了以下血泪教训VIP必须包含在证书中很多高可用故障都是因为忘记在apiserver证书中加入VIP时间同步至关重要证书验证依赖系统时间所有节点必须同步NTP备份CA私钥丢失CA私钥意味着整个证书体系需要重建逐步更新大规模集群中逐个节点更新证书避免服务中断文档记录详细记录每个证书的用途和过期时间一个特别隐蔽的问题某次证书更新后kube-proxy突然无法连接apiserver。经过排查发现新证书的SAN中漏掉了Service网段的DNS名称kubernetes.default.svc.cluster.local而kube-proxy默认使用这个地址访问apiserver。这提醒我们必须严格检查每个证书的SAN列表。