最近在帮客户搭一套信创环境下的 Kubernetes 多主高可用集群过程比预想的曲折——网上资料要么只讲概念不讲实操要么一上来就是生产环境的复杂细节初学者很容易被劝退。我打算把这次从规划到落地的完整过程整理出来包括架构设计的思路、关键配置文件、每一步为什么这么做以及信创环境下特有的坑。这篇文章定位是给已经会用单节点 Kubernetes、准备在国产化环境里搭多主集群的同学讲清楚高可用到底是怎么实现的、有哪些不同的选型路径、实际搭建时该注意什么以及踩坑之后怎么定位问题。先说说为什么这个话题值得单独写一篇。信创环境下的 Kubernetes 集群本质上是把以国外闭源/开源软件为主的技术栈替换成国产 CPU、国产操作系统和开源社区的云原生组件。听起来只是换了个底座但实际操作里你会发现软件源的差异、内核模块的差异、离线部署的要求、甚至证书配置的细节都会让原本在普通服务器上的部署流程变得处处是坑。这篇内容里我不讲理论空话全是我在实际操作中验证过的、可直接照着复现的东西。1. 先把“高可用”这件事想清楚多主架构是怎么设计的1.1 为什么单 Master 不够用很多人刚接触 Kubernetes 时用的是 kubeadm 单节点部署一个 master 节点承载所有控制面组件。这在测试环境完全没问题但一旦进入生产或准生产单 master 就是整个集群的致命单点。控制面如果挂了虽然已经运行的工作负载还在但新的调度、弹性伸缩、故障恢复、配置更新全部瘫痪。用一个不太严谨但好理解的类比服务器就像一家餐厅apiserver 是前台接待controller-manager 和 scheduler 是后厨调度etcd 是菜单和账本。接待挂了客人进不来后厨调度挂了菜做不下去账本丢了一切归零。控制面里有三个关键组件它们的高可用语义完全不同kube-apiserver无状态服务多个副本之间没有共享数据依赖只要前面有负载均衡把请求分发到不同实例即可。kube-controller-manager和kube-scheduler它们是有状态的“选主”组件多副本同时存在但同一时刻只有一个是 leader 在干活其余处于待命状态。etcd强一致性的分布式存储通过 Raft 协议实现数据复制和故障切换必须部署奇数个节点才能容忍少数节点故障。理解了这三类组件的差异多主高可用的架构就自然浮现了多副本的 apiserver 挂在负载均衡后面controller-manager 和 scheduler 靠选主机制保证单活etcd 用奇数节点做冗余。初学者容易混淆的是“多主”不等于“每个 master 都在同时处理一切”而是“每个 master 都具备随时接管全部能力”。1.2 两种 etcd 部署模式怎么选kubeadm 支持两种控制面高可用模式区别主要在 etcd 的部署方式上模式etcd 位置优点缺点Stacked etcdetcd 与控制面组件部署在同一组 master 节点部署简单节点数少初学者友好控制面和存储互相影响master 节点压力大External etcdetcd 独立部署在专门节点上组件隔离生产环境推荐扩容灵活需要额外维护一组 etcd 节点部署复杂度高信创环境里通常机器资源比较宝贵我个人的建议是如果是测试、验证或非核心业务用 stacked etcd 模式就够了三台 master 全部装上控制面和 etcd性价比最高。如果是正式生产、对稳定性和故障隔离要求极高那就拉两台机器单独部署 external etcd三节点比较好配合三台 master 组一个五节点的整体架构。这次分享的实操过程以 stacked etcd 为主线因为这是初学者最容易上手的路径external etcd 的差异点我会在相应位置提出来。1.3 从客户端到 etcd一条完整链路多主高可用架构下一次 kubectl 请求会经历这样的路径用户/业务客户端 ↓ VIP:6443keepalived 虚拟IP haproxy三个 master 上各跑一个keepalived 把 VIP 绑定到活跃节点上 ↓ 轮询/健康检查 任意一个 master 的 kube-apiserver:6443 ↓ kube-apiserver 通过证书认证 etcd 集群2379 端口选主读写这里有几个关键点需要强调。第一VIP 是浮动地址keepalived 负责保证 VIP 始终绑定在存活的节点上第二haproxy 在前面做 TCP 层的四层负载均衡它不终止 TLS只是把流量原样转发给后端的 apiserver第三controller-manager 和 scheduler 通过--leader-elect参数参与选主kubeadm 默认开启了这两个组件的选主机制所以这几个组件不需要负载均衡它们自己会通过 etcd 里的租约决定谁是当前活跃的 leader。初学者在设计架构时最容易忽略的是证书 SANSubject Alternative Name。apiserver 的证书里必须包含 VIP、所有 master 节点 IP、以及你打算用来访问集群的域名否则客户端或 kubelet 用 VIP 访问时TLS 校验会直接失败。这也是信创环境下最容易遇到的问题之一后面实操部分我会详细讲。2. 动手前的准备版本、规划与系统初始化2.1 版本选型要提前定好信创环境部署 Kubernetes版本选择比普通环境更敏感因为牵涉到国产操作系统软件源里有没有对应的包、内核版本够不够新、容器运行时镜像能不能离线拉取。我的建议是选择当前社区稳定支持且已经发布一段时间的版本比如 v1.28.x 或 v1.29.x不要追最新也不要停留在太老的版本上。信创环境的“三大件”搭配我这次用的是操作系统某国产服务器操作系统麒麟系/统信UOS系内核版本 4.19架构aarch64ARM架构国产CPU如飞腾/鲲鹏系列如果机房是 x86_64 的海光/兆芯流程基本一致只有镜像架构标签不同容器运行时containerd 1.7.x容器编排Kubernetes v1.28.x网络插件Calico也可以选 Cilium但信创环境离线部署 Cilium 的依赖更重Calico 更稳妥v1.28 这个版本足够稳定对 containerd、systemd 的支持都很成熟各种第三方组件适配也多。更关键的是信创环境很多机器是离线内网你需要提前把所有需要的容器镜像下载好、推送到内网镜像仓库所以版本一旦定了就不要随便改否则离线包全部白准备。2.2 主机规划与网络设计多主高可用至少需要三台 master 节点这是硬性要求因为 etcd 要能容忍单节点故障。演示环境可以只加一台 worker生产环境建议至少三台 worker。以下是我这次实验环境的规划IP 地址和 hostname 按需替换角色主机名IP 地址配置要求Master1k8s-m1172.16.10.114C8G / 100G 系统盘Master2k8s-m2172.16.10.124C8G / 100G 系统盘Master3k8s-m3172.16.10.134C8G / 100G 系统盘Worker1k8s-w1172.16.10.218C16G / 100G 系统盘VIPk8s-vip172.16.10.100供 keepalived 漂移使用这里有一个细节VIP 不建议和业务网段冲突也尽量不要让 VIP 落在 DHCP 动态分配范围内。在实验环境里手动绑静态 IP 最稳妥。磁盘方面etcd 对 IOPS 比较敏感如果预算允许给 master 单独挂一块高性能数据盘用于 etcd 数据目录是加分项下面的操作我不会强制要求但会提到。DNS 方面所有节点的/etc/hosts都要互相同名解析包括 VIP 也要出现在 hosts 里。这样 kubelet 和 apiserver 之间、apiserver 和 etcd 之间可以通过主机名而不是裸 IP 来建立连接证书里的 SAN 也能少踩坑。2.3 系统基础配置关闭 swap、加载 ipvs、同步时钟无论是不是信创环境以下几项系统配置是所有 master 和 worker 节点的“标配”我建议做成一个初始化脚本批量执行# 1. 关闭 swapkubelet 默认要求关闭交换分区 swapoff -a sed -i /swap/s/^/#/ /etc/fstab # 2. 加载内核模块ipvs 模式需要 modprobe br_netfilter modprobe ip_vs modprobe ip_vs_rr modprobe ip_vs_wrr modprobe ip_vs_sh modprobe nf_conntrack cat /etc/modules-load.d/k8s.conf EOF br_netfilter ip_vs ip_vs_rr ip_vs_wrr ip_vs_sh nf_conntrack EOF # 3. 设置内核参数确保 iptables 规则对桥接流量生效 cat /etc/sysctl.d/k8s.conf EOF net.bridge.bridge-nf-call-ip6tables 1 net.bridge.bridge-nf-call-iptables 1 net.ipv4.ip_forward 1 EOF sysctl --system # 4. 时钟同步etcd 和证书都对时间敏感 systemctl enable --now chronyd这几条里最容易忽略的是nf_conntrack。在信创环境的某些精简内核版本里这个模块默认可能没有加载没有它会导致 kube-proxy 使用 ipvs 模式时报错。另外 swap 不关闭kubelet 会直接拒绝启动所以这一步千万别省。3. 一步步搭建多主高可用集群3.1 安装 kubeadm、kubelet、kubectl这一步在信创环境里和普通环境有个非常重要的区别不要直接拿公网上的安装脚本一把梭要先确认操作系统自带的软件源里有没有 Kubernetes 相关的包。如果没有需要自己准备 rpm 包和依赖包离线安装。我这次是以离线 rpm 包方式安装的# 在已下载好 rpm 包的目录下执行 rpm -ivh kubeadm-1.28.2-0.aarch64.rpm \ kubelet-1.28.2-0.aarch64.rpm \ kubectl-1.28.2-0.aarch64.rpm \ cri-tools-*.aarch64.rpm \ kubernetes-cni-*.aarch64.rpm systemctl enable --now kubelet注意 kubelet 在这个阶段启动后可能会报错或者处于重启循环这是正常的因为集群还没初始化、没有相关的 pod 配置。很多初学者看到 kubelet 红色状态就慌了其实只要systemctl status kubelet能说明“找不到静态 pod 文件”或者能正常执行 join/init 命令就可以继续往下走。3.2 配置 containerd 的 systemd cgroup 驱动容器运行时驱动和 kubelet 的 cgroup 驱动必须保持一致否则节点状态会一直是 NotReady。信创系统默认通常使用 systemd 作为 init 系统所以两头都要设成 systemd。# 生成默认配置 containerd config default /etc/containerd/config.toml然后修改/etc/containerd/config.toml中两个关键位置# 镜像加速/离线仓库地址视环境而定 [plugins.io.containerd.grpc.v1.cri] sandbox_image registry.local/pause:3.9 [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc.options] SystemdCgroup truesandbox_image就是 pause 镜像地址。在信创离线环境里这一步不做的话每个 Pod 创建时都会去公网拉取 pause 镜像然后铁定失败。SystemdCgroup 设置为 true 后重启 containerdsystemctl restart containerd systemctl enable --now containerd3.3 在 master 节点部署 keepalived haproxy这是多主高可用里最具有“基建感”的一层初学者需要理解一个冲突keepalived 用 VIP 保证接入不中断haproxy 用负载均衡保证 apiserver 的多副本真正被使用到。如果只有 VIP 指向一台 master那 VIP 所在的 master 挂了keepalived 会切走但平时流量都是打在同一台 master 上另外两台 master 的 apiserver 虽然活着也接不到流量这台 master 反而成了瓶颈。三台 master 节点都安装 keepalived 和 haproxy# 信创系统可能自带了 haproxy/keepalived没有则用离线包安装 rpm -ivh keepalived-*.aarch64.rpm haproxy-*.aarch64.rpmhaproxy 配置监听在 6443 端口转发到三台 master 的本机及对端 6443 端口。因为 kubeadm 的--control-plane-endpoint参数会使用https://VIP:6443所以我这里直接让 haproxy 监听 6443。如果担心和 kubectl 直接访问 master 的 API 冲突也可以让 haproxy 监听在 8443然后在 kubeadm 配置里指定controlPlaneEndpoint: https://172.16.10.100:8443。为了统一我这里监听 8443转发到各 master 的 6443。/etc/haproxy/haproxy.cfg关键配置global log /dev/log local0 maxconn 4096 user haproxy group haproxy defaults log global mode tcp timeout connect 5s timeout client 50s timeout server 50s frontend k8s-api bind *:8443 default_backend k8s-master backend k8s-master balance roundrobin option tcp-check server k8s-m1 172.16.10.11:6443 check inter 3s fall 3 rise 2 server k8s-m2 172.16.10.12:6443 check inter 3s fall 3 rise 2 server k8s-m3 172.16.10.13:6443 check inter 3s fall 3 rise 2这里用mode tcp做的是四层转发不需要关心 HTTP 协议细节也不终止 TLS逻辑最简单排错也容易。option tcp-check的含义是会尝试与后端建立 TCP 连接连不上就自动摘除这样某个 master 上的 apiserver 挂了haproxy 就不会再把流量发给它。keepalived 的核心配置/etc/keepalived/keepalived.confglobal_defs { router_id LVS_K8S } vrrp_script check_haproxy { script /usr/local/bin/check_haproxy.sh interval 2 weight -20 } vrrp_instance VI_1 { state MASTER interface ens160 # 网卡名按实际改 virtual_router_id 100 priority 100 advert_int 1 authentication { auth_type PASS auth_pass K8s1234 } virtual_ipaddress { 172.16.10.100/24 dev ens160 } track_script { check_haproxy } }其中两个重点state MASTER只是初始角色真正决定谁是主的是priority。三台 master 的配置里想让哪台优先成为主就给它稍高的 priority但不建议三台都一样否则切换不稳定。我这里把 m1 设为 100m2 和 m3 设为 99。track_script的作用是当本节点的 haproxy 进程挂了keepalived 自动降低自身权重并放弃 VIP 所有权让 VIP 漂移到其他节点。如果没有这段haproxy 挂了但 keepalived 还活着VIP 依然绑在本机流量到了却转发不出去整个集群就“僵死”了。健康检查脚本/usr/local/bin/check_haproxy.sh#!/bin/bash if pgrep -x haproxy /dev/null; then exit 0 else exit 1 fi三个 master 节点都完成以上配置后启动服务systemctl enable --now haproxy systemctl enable --now keepalived然后在任意节点上验证ip addr show | grep 172.16.10.100正常情况下VIP 应该出现在一台 master 的网卡上。如果 VIP 不出来优先检查 keepalived 日志和防火墙是不是拦截了 VRRP 协议报文。3.4 初始化第一个控制平面节点控制平面初始化是整个过程中最容易出错的环节关键点在于kubeadm-config.yaml里必须指定controlPlaneEndpoint为 VIP并预留证书 SAN。我用的配置文件如下apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration controlPlaneEndpoint: 172.16.10.100:8443 kubernetesVersion: v1.28.2 apiServer: certSANs: - 172.16.10.100 - 172.16.10.11 - 172.16.10.12 - 172.16.10.13 - k8s-vip networking: podSubnet: 10.244.0.0/16 serviceSubnet: 10.96.0.0/12 --- apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration etcd: local: dataDir: /var/lib/etcd这里controlPlaneEndpoint决定了 kubeadm 会把负载均衡地址写进 apiserver 的证书 SAN以及各 kubelet 和客户端访问集群时使用的主机名。certSANs必须包含 VIP 和三台 master 地址否则后续节点 join 时kubelet 访问 apiserver 会报证书校验失败。Pod 网段选了 Calico 默认的10.244.0.0/16如果你的内网网段和它冲突记得同时改 CNI 的配置。初始化命令kubeadm init --config kubeadm-config.yaml --upload-certs--upload-certs这个参数很多人不理解它表示把控制面节点之间同步所需的证书通过 kubeadm 管理的 Secret 上传到集群。这样后续其他控制面节点 join 时就能自动拉取这些证书不需要手动拷贝。执行完成后把输出尾部的 join 命令保存好尤其是带--certificate-key的那条它是给其他 master 节点加入控制面用的。初始化过程会拉取一组镜像apiserver、controller-manager、scheduler、etcd、pause、coredns。如果离线环境已经提前把镜像导入到 containerd就不会报错。检查镜像是否就绪kubeadm config images list --kubernetes-version v1.28.2 ctr -n k8s.io images list | grep registry.local3.5 加入第二、第三个控制平面节点在 m2 和 m3 上使用第一条 join 命令带--control-plane和--certificate-key比如kubeadm join 172.16.10.100:8443 \ --token xxxxx.yyyyy \ --discovery-token-ca-cert-hash sha256:xxxxxxxx \ --control-plane \ --certificate-key xxxxxxxxxxxxxxxxxxxxx这里有个很容易遇到的报错certificate-key 过期。--upload-certs生成的证书密钥默认有效期只有 2 小时如果过了期限还没 join需要回到 m1 上重新执行kubeadm init phase upload-certs --upload-certs然后重新拿到一条带新 certificate-key 的 join 命令。这个坑我至少见过三次初学者记一下免得以为整个集群配置出了问题。等三台 master 都 join 完成后查看节点状态kubectl get nodes这时节点可能都是 NotReady 状态因为网络插件还没安装这是正常的。3.6 安装 Calico 网络插件Calico 的安装方式我习惯用 manifest 方式因为它利于离线定制。下载对应版本的calico.yaml修改两处一是镜像地址改成内网仓库地址二是 ConfigMap 里的CALICO_IPV4POOL_CIDR改成和控制面 podSubnet 一致的10.244.0.0/16。在信创环境里Calico 用的是“DaemonSet 多数工作负载”它会在每个节点上启动 BGP agentPod 之间的网络流量走三层路由。镜像需要预置到 containerd常见的镜像有calico/cnicalico/nodecalico/kube-controllers导入后执行kubectl apply -f calico.yaml然后轮询 Pod 状态kubectl get pods -n kube-system -w等 calico-node 和 coredns 都 Running 后再看节点状态kubectl get nodes正常输出里三台 master 应该都是 Ready而且没有“master 节点不可调度”的困扰——因为我们只需要验证高可用不强行让 master 跑业务 Pod 也没关系。3.7 验证多主高可用效果到这里集群已经起来了但“高可用”到底有没有生效建议做一个简单的故障演练。先确认能通过 VIP 正常访问kubectl --serverhttps://172.16.10.100:8443 get nodes然后做两类故障测试停掉一台 master 上的 kubeletsystemctl stop kubelet观察 apiserver 是否依然可用、VIP 是否还在原来那台。停掉当前持有 VIP 节点上的 keepalived 和 haproxysystemctl stop keepalived之后在另外两台 master 上执行ip addr show | grep 172.16.10.100应该能看到 VIP 飘到其中一台。这两类测试分别验证了“kubelet 层面的故障容忍”和“接入层 VIP 的故障切换”。如果这两条都通过说明多主高可用的核心链路是通的。初学者往往只看节点 Ready 状态忽略了故障切换测试这是不对的——高可用不是“三台都活着”而是“挂了一台还剩两台时服务依然完整”。4. 踩坑实录信创环境下最常见的几类问题4.1 问题排查速查表现象可能原因排查命令/方法节点状态 NotReady网络插件未安装 / CNI 镜像拉取失败kubectl get pods -n kube-system看 calico-node 日志kubelet 一直重启swap 未关闭 / cgroup 驱动不一致systemctl status kubeletjournalctl -u kubelet查看具体报错通过 VIP 访问 apiserver 报证书错误证书 SAN 没加 VIP重新初始化时在 config 里加 certSANs或重新生成证书join 控制面时报 certificate-key 无效证书密钥 2 小时过期重新执行kubeadm init phase upload-certs --upload-certskeepalived 不切换 VIP 或脑裂VRRP 报文被防火墙拦截 / 网卡名配置错误tcpdump -i ens160 vrrp检查报文systemctl status keepalivedhaproxy 显示后端全 down健康检查脚本路径错误 / selinux 拦截haproxy -c检查配置/var/log/haproxy.logetcd 报“space is too small”或数据不一致历史数据膨胀 / 时钟不同步etcdctl member list确认 chronyd 已同步拉取镜像超时离线环境没有内部镜像仓库crictl images确认镜像是否存在配置好私有仓库kube-proxy 无法使用 ipvs 模式缺 nf_conntrack 等模块lsmodmaster 节点无法调度业务 Pod默认设置了污点生产不建议移除污点测试可kubectl taint nodes --all node-role.kubernetes.io/control-plane-4.2 三个典型案例的深入排查第一个案例虚拟机克隆导致网卡问题。信创环境里很多人先在一台虚拟机上装好系统然后克隆出另外两台节点。克隆出来的机器网卡配置、hostname、甚至/etc/machine-id可能跟着被复制结果 kubelet 起不来keepalived 也互相冲突。排查方式先hostnamectl确认主机名唯一再改网卡配置文件里的 IP最后重新生成 machine-idrm -f /etc/machine-id systemd-machine-id-setup这个步骤不起眼但能省至少半天折腾。第二个案例cgroup 驱动不一致。节点上 containerd 没用 systemd cgroup 驱动而 kubelet 默认是 systemd结果节点一直 NotReadykubelet 日志里有 “failed to run Kubelet” 或者 “cgroup driver” 报错。解决方式是统一两边的驱动类型。这个我在前面 3.2 小节已经强调过是初学者最容易忽略的“隐形配置”。第三个案例keepalived 脑裂。所谓脑裂就是两台节点同时认为自己是主VIP 同时出现在两台机器的网卡上。原因通常是 VRRP 组播报文被防火墙拦截或者两边的 virtual_router_id 配置不一致。排查方式在疑似脑裂的两台机器上同时ip addr show如果 VIP 都出现就检查防火墙规则和交换机是否放行 VRRP。# 确保不禁用 VRRP 组播 iptables -I INPUT -p vrrp -j ACCEPT还有一个小技巧在三台 master 上分别用curl -k https://127.0.0.1:6443/healthz检查 apiserver 健康状态再用curl -k https://172.16.10.100:8443/healthz检查 VIP 链路是否全通。如果 VIP 链路不通但 node IP 直连正常问题多半出在 haproxy 或 keepalived 这一层。最后的几点实际操作体会这套集群我前后搭了两次才彻底跑顺第一次败在证书 SAN 上第二次败在离线镜像源不完整上。根据个人经验给准备照着做的同学几个额外建议。第一强烈建议先在虚拟化环境里完整演练一遍再上物理机。信创物理机的 BIOS、网卡、阵列卡驱动往往有更多不确定因素如果在虚拟机上能把流程跑通再迁移到物理机时至少能确定软件层面没问题剩下的就是硬件适配问题。第二一定提前把离线资源包整理全。包括所有 rpm 包、容器镜像、Calico manifest、kubeadm 配置文件。特别是容器镜像多花时间把kubeadm config images list列出的镜像和 Calico 相关镜像全部下载并导入 containerd后面会顺畅很多。第三注意证书有效期和备份。Kubernetes 控制面证书默认一年有效期生产环境里要计划好续期方案。至少在集群搭建完成后把/etc/kubernetes、/etc/etcd如单独部署 etcd、/var/lib/etcd的数据目录备份一次后面恢复和迁移都用得上。第四如果是从单主集群临时打补丁转多主别硬改建议直接重建集群。单主集群的控制面没有为多主做证书和负载均衡配置硬加节点容易造成数据不一致。把应用迁走、重新初始化一套多主集群再迁回来花费的时间其实远小于踩坑时间。这套架构跑起来之后你就能体会到真正的稳定不是来源于某个软件特性而是来源于你清楚地知道每一个组件在故障时会发生什么、以及你验证过它会怎么发生。