开源方案 | Kubernetes集群高可用搭建

▌ 技术引导

我见过太多人用kubectl apply或者helm chart搞Kubernetes高可用，结果还是挂了。原因往往不是集群配置本身，而是忽略了节点健康检查、网络策略、证书轮换和负载均衡这几个点。真实场景里，单节点问题很隐蔽，像CPU温度过高、磁盘IO延迟、容器镜像拉取失败、NodeIP漂移这些，都可能变成集群不稳定的风险源。在实践中，我用过three-node的etcd架构，也踩过单节点etcd的坑，最终发现真正的高可用方案必须结合etcd多节点、CoreDNS健康检查、Calico网络插件和KeepalivedVIP来兜底。配置的时候别忘了给每个Node打标签区分角色，用kubeadm init的时候别跳过crio的配置，否则容器运行时会出问题。

我见过一些人直接复制官方文档，最后发现不是所有默认参数都适用。比如，etcd的默认存储路径是/var/lib/etcd，但如果你用的是阿里云或者华为云，可能得改成挂载一个本地盘。还有，负载均衡策略不能随便选，比如使用metalLB的时候，要确定你的云厂商是否支持静态IP或者需要配置外部DNS。对于网络策略，Calico的默认是iptables，但如果你在生产环境，最好换成eBPF的Cilium，性能更稳。

另外，监控体系必须跟上。Prometheus+Alertmanager+Grafana的组合确实有效，但要记住配置node-exporter的采集间隔不能太长，否则监控延迟太高。对于证书管理，不要手动替换，要用cert-manager自动处理，否则容易出现证书失效导致API Server通信中断。如果用的是kubeadm，记得在init之后运行kubeadm token create --print-join-token，这个命令在后续的Worker节点加入时非常关键。

容器运行时的选择也很重要，Docker虽然方便，但在大规模集群中，CRI-O的性能表现更稳定。如果用的是k8s 1.25以上版本，kubeadm的配置文件要记得设置--cri-socket参数，否则和CRI-O的通信会出问题。还有个容易被忽略的点是，etcd集群的成员数量应该至少是3个，不是2个，否则脑裂风险太高。我之前用2个etcd节点，结果一次节点重启就导致整个集群不可用。

真实部署中，数据平面和控制平面分离是必须的。比如，把kube-apiserver、kubelet、kube-proxy这些组件部署在不同的节点上，确保单点故障不会影响整个集群。还有，别忘了配置Pod的驱逐策略，比如kubectl taint node 某个节点 node-role.kubernetes.io/control-plane:NoSchedule，这样就不会有Pod跑到控制节点。这些细节都是踩过坑之后才明白的，别想着一步到位。

▌ 技术参考

一 环境准备与节点规划

部署Kubernetes高可用集群的前提是明确节点角色和网络拓扑。控制平面节点至少需要3个，数据平面节点建议3个以上。每个节点必须具备独立的网络接口，推荐使用bonding或VLAN技术实现冗余。对于etcd集群，建议使用三个节点的拓扑结构，确保Paxos算法正常运行。各节点需配置静态IP，避免DHCP导致的网络不稳定。在部署前，使用yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes命令安装Kubernetes组件，同时确保所有节点时间同步，使用ntpdate同步时间并检查ntpstat的状态。

二 etcd集群部署与配置

etcd是Kubernetes的核心存储组件，其高可用依赖于集群成员的冗余性。部署时使用kubeadm init命令初始化控制平面，同时通过--etcd-endpoint参数指定etcd的地址。在etcd配置文件中，需要设置peer-urls和advertise-urls，避免节点通信错误。比如，在/etc/kubernetes/manifests/etcd.yaml中，将--peer-urls参数设置为https://10.0.0.1:2380,https://10.0.0.2:2380,https://10.0.0.3:2380，确保每个节点都有独立的peer地址。此外，etcd的存储路径需要挂载到本地盘，使用mount /dev/vdb /var/lib/etcd命令挂载并设置权限。

三 网络插件配置与优化

Kubernetes网络需要稳定的插件支持。Calico是常用选择，但生产环境中推荐使用Cilium。部署时，使用kubectl apply -f cilium.yaml命令安装Cilium，同时确保集群防火墙规则允许179端口通信。Cilium的性能优于Calico，尤其在大规模集群中，其基于eBPF的网络策略能够减少CPU开销。此外，网络插件的配置必须包含跨节点通信策略，例如使用Cilium的CNI config文件设置ipv4-range参数，避免IP地址分配冲突。

四 负载均衡配置

负载均衡是实现集群高可用的最后一步。使用Keepalived实现VIP漂移，确保API Server的地址不会因为节点宕机而改变。配置Keepalived时，需要在/etc/keepalived/keepalived.conf中设置virtual_router_id和priority参数，避免VIP冲突。同时，使用Nginx作为反向代理，将流量分发到多个API Server节点。如果使用云厂商的负载均衡，如阿里云SLB或AWS ELB，需要确保健康检查端点正确，例如使用curl -k https://localhost:6443检查API Server端口是否通。

五 节点健康检查与自动恢复

在Kubernetes中，节点健康检查是保障集群稳定的基础。使用kubectl get nodes -o wide查看各节点状态，确保所有节点处于Ready状态。对于Pod驱逐，可以配置kubectl taint node 某个节点 node-role.kubernetes.io/control-plane:NoSchedule，防止Pod调度到控制节点。此外，使用kubectl drain node --ignore-daemonsets命令安全驱逐节点，避免数据丢失。在监控方面，Prometheus+Alertmanager能及时发现节点异常，比如CPU使用率过高或内存泄漏，通过Alertmanager配置通知策略，能快速响应故障。

六 API Server高可用方案

API Server是集群的入口，必须确保其高可用。部署时使用kubeadm init命令指定--control-plane-endpoint参数，确保所有控制节点的API Server地址一致。如果使用Nginx做负载均衡，需要配置upstream块，将多个API Server节点加入。例如，在nginx.conf中添加upstream api-server { server 10.0.0.1:6443; server 10.0.0.2:6443; server 10.0.0.3:6443; }。同时，配置health-check的端点，如health_check /healthz，确保Nginx能正确判断API Server状态。

七 kubelet与kube-proxy配置

kubelet是节点上的核心组件，必须确保其正常运行。配置时，使用--pod-infra-container-image参数指定镜像，避免不同节点镜像不一致导致的问题。同时，开启--read-only-rootfs和--node-ip参数，确保kubelet不会因为挂载问题发生异常。对于kube-proxy，建议启用--proxy-mode=ipvs模式，提升性能。在部署时，使用kubectl apply -f kube-proxy.yaml命令，确保IPVS模块已加载，通过lsmod | grep ip_vs确认模块状态。

八 镜像仓库与配置

镜像仓库必须支持高可用，推荐使用Harbor或者Nexus。在集群配置中，通过--image-repository参数指定镜像源，例如在kubeadm config.yaml中设置imageRepository: "harbor.example.com"。此外，配置镜像拉取策略时，使用--imagePullPolicy=IfNotPresent避免频繁拉取。对于私有仓库，需要在节点上配置docker login，通过echo "harbor.example.com:8080" | docker login -u admin -p password --email=admin@example.com -h harbor.example.com命令完成认证。

九 核心DNS与IP分配

CoreDNS是Kubernetes的默认DNS服务，必须确保其高可用。部署时使用kubectl apply -f https://prerelease.k8s.io/coredns/1.9.1/coredns.yaml，确保每个节点都有独立的CoreDNS实例。同时，配置IP地址池时，使用calicoctl apply -f ipam.yaml文件，确保IP分配不会冲突。在CoreDNS配置中，需要设置etcd的地址，例如在CoreDNS的配置文件中加入etcd endpoints: https://10.0.0.1:2379,https://10.0.0.2:2379,https://10.0.0.3:2379。

十 集群证书管理

证书管理是Kubernetes高可用中的关键点。使用cert-manager自动管理证书，通过kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.12.1/cert-manager.yaml部署。配置时，需要在ClusterIssuer中指定签发方式，例如使用Let's Encrypt或者自签名证书。如果手动管理证书，需要定期使用etcdctl endpoint --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --ca=/etc/kubernetes/pki/etcd/ca.crt检查证书状态，避免证书过期导致API Server通信中断。

十一 容器运行时优化

容器运行时的选择直接影响集群性能。Docker虽然简单，但在大规模集群中容易出现性能瓶颈。推荐使用CRI-O，配置时通过systemctl enable crio --now命令启动服务。在crio.conf中，设置default-runtime = runc，避免其他运行时干扰。此外，配置CRI-O的存储驱动为overlay2，使用storage-driver = overlay2参数提升性能。在部署时，使用kubeadm init --container-runtime=cri-o命令，确保容器运行时与kubeadm兼容。

十二 Pod调度策略

Pod调度必须结合节点标签和污点配置。使用kubectl label node node1 role=control-plane命令为控制节点打标签，同时在Deployment中指定nodeSelector: role: control-plane，确保Pod不会被调度到数据节点。污点配置方面，使用kubectl taint node node1 node-role.kubernetes.io/control-plane:NoSchedule防止Pod运行在控制节点。此外，配置Pod的资源限制，使用resources: limits: memory: "2Gi" cpu: "1"确保Pod不会占用过多资源。

十三 安全策略与网络隔离

安全策略必须严格配置，避免横向流量攻击。使用NetworkPolicy限制Pod之间的通信，例如在Kubernetes中添加kind: NetworkPolicy，spec: podSelector: matchLabels: app: myapp，ingress: from: - namespace: default，policyTypes: ["Ingress"]。同时，配置RBAC权限，使用kubectl create rolebinding rb-name --clusterrole=admin --user=admin --namespace=default命令分配权限。网络隔离方面，使用Calico的NetworkPolicy配置，确保不同业务Pod之间不会互相干扰。

十四 高可用集群验证

验证高可用集群必须执行一系列测试，包括节点故障切换、网络断开、API Server宕机等场景。使用kubectl get nodes检查节点状态，确保所有节点处于Ready。对于etcd集群，使用etcdctl endpoint --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --ca=/etc/kubernetes/pki/etcd/ca.crt查看各节点状态。如果某个节点宕机，通过kubectl get nodes发现该节点处于NotReady状态，使用kubectl describe node查看具体原因，通常是因为kubelet未启动或者证书过期。

十五 故障恢复与日志排查

故障恢复必须有详细的日志支持。使用journalctl -u kubelet查看kubelet日志，确保没有异常退出。对于API Server，使用kubectl logs -f kube-apiserver-node1 --namespace=kube-system检查错误信息。在恢复过程中，使用kubectl drain node命令安全驱逐节点，然后通过kubectl delete pod -n kube-system kube-apiserver-node1删除异常Pod。如果使用etcd，需要确保集群状态正常，使用etcdctl cluster-health命令检查健康状态，必要时通过etcdctl --endpoints=https://10.0.0.1:2379,https://10.0.0.2:2379,https://10.0.0.3:2379 --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --ca=/etc/kubernetes/pki/etcd/ca.crt检查成员状态。

十六 系统参数调优

系统调优是提升集群性能的关键。在/etc/sysctl.conf中，设置net.ipv4.ip_local_port_range = 1024 65535，避免端口耗尽。同时，调整net.ipv4.tcp_keepalive_time = 300，防止连接长时间断开。在Linux内核中，启用IPVS模块，使用modprobe ip_vs命令加载模块，并通过ipvsadm -L -n查看状态。如果发现性能瓶颈，可以使用perf top命令分析CPU使用情况，确保没有不必要的资源消耗。

十七 安全加固与权限控制

安全加固必须覆盖多个层面。首先，配置防火墙规则，使用iptables -A FORWARD -s 10.0.0.0/24 -j ACCEPT允许Pod间通信。其次，使用kubeadm token create --print-join-token生成新的加入令牌，并通过kubectl get secret -n kube-system查看令牌状态。在RBAC配置中，使用kubectl create rolebinding命令绑定角色，确保用户只能访问指定资源。同时，配置TLS客户端证书，使用kubectl config set-credentials user --client-certificate=/etc/kubernetes/pki/apiserver.crt --client-key=/etc/kubernetes/pki/apiserver.key命令设置认证信息。

十八 容器镜像版本控制

镜像版本控制可以避免兼容性问题。使用kubeadm config images list查看所有需要的镜像，确保版本一致。在部署时，使用kubectl apply -f deployment.yaml命令应用配置，并通过docker images查看本地镜像是否正确拉取。对于私有仓库，配置docker login命令，并在集群配置中指定镜像源。此外，使用kubectl rollout history deployment/myapp查看部署历史，便于回滚操作。

十九 节点资源监控与预警

节点资源监控必须结合Prometheus和Alertmanager。使用kubectl get pods -n monitoring查看监控组件是否正常运行，确保Prometheus能采集数据。在Alertmanager中配置告警策略，例如当节点CPU使用率超过80%时触发告警。通过kubectl get alertmanager -n monitoring检查配置是否生效，并使用kubectl get rules -n monitoring查看告警规则。在监控数据中，使用Prometheus的查询功能，例如avg by (instance) (rate(container_cpu_usage_seconds_total[5m]))，监控各节点CPU使用情况。

二十 高可用集群的日常维护

日常维护包括证书更新、系统日志清理、资源限制调整等。使用cert-manager自动更新证书，通过kubectl get certificates -n kube-system检查状态。定期清理系统日志，使用journalctl --vacuum-time=1d命令保留1天日志。对于资源限制，使用kubectl describe pod查看Pod资源使用情况，并调整resources中的limits参数。此外，定期使用kubectl get events查看集群事件，确保没有未处理的错误。