Ubuntu 上实现 Kubernetes 高可用的落地方案
一、总体架构与前置要求
- 架构要点
- 控制面高可用：部署至少 3 个 Master 节点，多实例运行 kube-apiserver、kube-controller-manager、kube-scheduler；其中 kube-controller-manager 与 kube-scheduler 自身通过选主机制实现高可用，关键在于消除 kube-apiserver 的单点。
- 数据面高可用：部署 3 或 5 个 etcd 节点（奇数），保证强一致性与可恢复性。
- 入口高可用：在 Master 前配置 HAProxy + Keepalived 提供 VIP（虚拟 IP）:6443，对外或对内统一接入；所有 Node 的 kubelet/kubeproxy 指向该 VIP。
- 网络高可用：选择 Calico、Flannel、Cilium 等 CNI 插件，确保 Pod 网络与策略可靠。
- 节点分布：跨 可用区（AZ） 打散控制面与数据面节点，提升容灾能力。
- 环境与前置
- OS：Ubuntu 22.04/24.04 LTS；容器运行时：Containerd（或 cri-dockerd）；网络：按 CNI 要求开启 IP 转发/桥接流量；内核参数与防火墙按 K8s 要求配置。
- 基本约束：禁用 Swap、节点时间同步（NTP/chrony）、系统资源满足最低要求（建议 ≥2 CPU、≥2GB 内存）。
二、控制面与 etcd 高可用部署步骤
- 步骤 1：安装基础组件
- 在所有节点安装 kubeadm、kubelet、kubectl（Ubuntu 可使用官方 APT 源），并配置 Containerd 作为运行时。
- 步骤 2：部署 HAProxy + Keepalived（提供 VIP）
- 在 2–3 台 Master 上安装并配置 HAProxy，将 6443 端口的四层转发至各 Master 的 6443；配置健康检查与最小连接等策略。
- 配置 Keepalived 管理 VIP，实现主机故障时 VIP 漂移，保证入口不中断。
- 示例 HAProxy 片段（/etc/haproxy/haproxy.cfg）：
- frontend k8s bind *:6443 mode tcp default_backend k8s
- backend k8s mode tcp balance roundrobin server master1 192.168.72.30:6443 check server master2 192.168.72.31:6443 check server master3 192.168.72.32:6443 check
- 步骤 3：使用 kubeadm 初始化控制面（以 3 台 Master 为例）
- 在首个 Master 执行（将 VIP 与证书上传开关加入）：
- kubeadm init --control-plane-endpoint=VIP:6443 --upload-certs --pod-network-cidr=10.244.0.0/16
- 其余 Master 加入控制面：
- kubeadm join VIP:6443 --token --discovery-token-ca-cert-hash --control-plane --certificate-key
- 说明：–upload-certs 会在控制面初始化时共享证书，便于其他控制面节点加入。
- 步骤 4：部署 CNI 网络插件
- 以 Calico 为例（版本号以官网为准）：
- kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml
- 步骤 5：加入 Worker 节点
- 在每台 Worker 执行 kubeadm join 命令（使用 kubeadm init 输出或 kubeadm token create 生成的新 token）。
三、验证与运维要点
- 验证高可用
- 检查控制面与 etcd 健康：kubectl get nodes、kubectl get pods -n kube-system；查看 kube-apiserver、etcd、controller-manager、scheduler 均为 Running 且分布在不同节点。
- 验证 VIP 漂移：在 Keepalived 主节点停止 keepalived 或关闭 HAProxy，确认 VIP 漂移到备机 且 kubectl 仍可正常访问。
- 验证应用容灾：部署 2+ 副本 的 Deployment，删除某副本或某 Node，确认 自动重建与调度 正常。
- 运维与加固
- 备份与恢复：定期为 etcd 做快照（快照与恢复流程按官方文档执行），并演练恢复预案。
- 证书管理：关注 证书有效期，必要时使用 kubeadm 进行 证书轮换。
- 升级策略：采用 滚动升级（kubeadm upgrade apply），逐批升级控制面与数据面，确保业务不中断。
- 监控告警：部署 Prometheus + Grafana + Alertmanager，对 APIServer/etcd/节点资源 建立关键告警。
四、进阶与替代方案
- 云上托管控制面
- 使用云厂商 托管 Kubernetes（如 ACK Pro）：控制面多副本跨 可用区 部署，提供 99.95%（≥3 AZ）/99.50%（≤2 AZ） 控制面 SLA；适合聚焦业务、降低自管复杂度。
- 外部负载均衡器替代
- 使用云上 SLB/NLB 或硬件/虚拟 四层/七层 LB 作为 APIServer 入口，在 Node 上通过 NodePort/Ingress 暴露业务，减少自管 HAProxy/Keepalived 的运维负担。
- 节点本地 API 代理
- 在每个 Node 部署 Nginx/HAProxy 本地代理，kubelet 指向 127.0.0.1:8443，由本地代理转发至多个 APIServer，进一步降低 Node 到控制面的单点风险。