简介面向云原生开发者和 Kubernetes 初学者的二进制高可用集群一键部署脚本基于阿良二进制部署文档整理旨在简化多节点高可用 K8s 环境的搭建省去手动下载组件、逐节点配置证书与服务的高门槛操作。压缩包约 398.89MB共 13 个文件包含 4 个 Shell 脚本、2 个 YAML 配置、1 个说明文档以及 docker、etcd、kubernetes-server 等安装包和 cfssl 证书工具链脚本分别负责 etcd、K8s 组件、VIP 与整体部署YAML 对应 Calico 和 CoreDNS。目前已有 1580 人学习下载。脚本将证书签发、etcd 初始化、控制平面高可用、工作节点接入和网络插件安装等关键步骤串成自动化流程读者既能获得直接可复用的部署方案也能通过脚本结构理解各组件协作关系。附带 readme 说明与环境准备要点适合在测试环境先行验证二进制部署路径。1. 二进制高可用 K8s 集群一键部署脚本先想清楚它解决什么问题我维护过一套二进制方式部署的高可用 K8s 集群三台 master 加三台 nodeetcd 独立三节点总共六台机器。第一次手工搭建用了整整两天半大部分时间花在证书、etcd 参数和 systemd unit 文件上每台机器敲的命令几乎一样区别只是 IP 和 hostname。后来我把整个流程固化成了一套一键部署脚本新环境从裸机到kubectl get nodes全部 Ready压缩到四十分钟以内。这篇笔记就把这套脚本的拆法、核心参数和踩过的坑讲清楚。这套东西适合谁生产环境有离线或内网约束的运维和 SRE想在机房或云上自建 K8s 的人以及被 kubeadm 默认行为坑过、需要完全掌控证书和组件参数的人。脚本不是万能的它把“流程”自动化了但“架构决策”还得自己定。读完你会知道二进制高可用集群每个组件在干什么、脚本在哪一层帮你省时间、哪些参数是必须人工确认的。2. 为什么选二进制而不是 kubeadm二进制部署的真实边界2.1 kubeadm 不够用吗什么时候需要二进制kubeadm 是现代 Kubernetes 官方主推的部署方式多数场景下足够好用。但“高可用 二进制”这个组合往往出现在 kubeadm 覆盖不好的地方离线环境不想维护镜像仓库、需要自定义 apiserver 的审计策略、要对 kubelet 的启动参数做精细化调整、或者公司安全规范要求证书体系完全自签可控。二进制部署的本质是从官方 Release 页面下载编译好的可执行文件自己写 systemd unit自己签 CA 和各类证书自己决定组件参数。它没有“隐藏的默认行为”每个参数都是显式写出来的。代价是学习曲线陡、配置项多、排错要自己来。kubeadm 帮你做了大部分默认决策二进制把决策权交还给你同时把所有责任也交给你。我个人选择二进制的另一个原因是可预期性。kubeadm 生成的静态 Pod 在某些网络插件和内核版本组合下有莫名的重启现象排查时还要先解析静态 Pod 的 YAML。二进制方式下每个组件就是一个 systemd 服务日志、重启、回滚全是系统级操作对老运维来说非常直观。2.2 二进制高可用集群的组件架构与关键链路一套典型的二进制高可用集群长这样三台 master 分别跑 kube-apiserver、kube-controller-manager、kube-scheduler三台 node 跑 kubelet 和 kube-proxyetcd 独立三节点也可以复用 master 机器但生产环境我建议独立除非机器实在紧张。apiserver 前端有一层四层负载均衡通常是 keepalived 加 haproxy或者云上的 SLB提供 VIP 和健康检查。高可用链路的关键点有两处。第一处是 apiserver 前面的 VIP所有组件和 kubectl 都通过这个 VIP 访问 apiserverVIP 漂移时 kubelet 和 controller-manager 的连接会短暂中断但 TCP 重连后就能恢复。第二处是 controller-manager 和 scheduler 的 leader election 机制它们通过 etcd 上的 lease 锁选主同一时间只有一个实例在工作master 挂掉后备用实例自动接管不需要人工干预。证书体系是另一个重点。二进制部署需要一套完整的 PKI一个 CA 根证书然后为 etcd 签 peer 和 client 证书为 apiserver 签 server 证书为各组件签发 client 证书还有 kubelet 的证书。apiserver 的 server 证书 SAN 里必须包含所有可能的访问地址包括 VIP、各 master IP、service CIDR 里的 Kubernetes 服务地址、以及kubernetes.default.svc这类域名。漏一个集群跑起来后你会发现kubectl随机报x509: certificate is valid for ...而且不是每次都报玄学级别的问题。2.3 高可用链路里最容易抄错的两个点先说 apiserver 的证书链路。很多教程只会告诉你要在 SAN 里加 VIP但忽略了一件事kubelet 回连 apiserver 用的是 VIP而 kube-proxy 访问 apiserver 也走 VIPcontroller-manager 和 scheduler 走的却是本机回环地址。这三类流量如果共用同一个证书文件SAN 就必须同时包含本机 IP、VIP 和 service CIDR。我见过只配了 VIP 忘了本机 IP 的案例controller-manager 能启动但不断报连接失败因为客户端校验的是 apiserver 证书里的 IP SAN。另一个易错点是 etcd 的--initial-cluster参数。三节点 etcd 集群要求每个节点上这个参数完全一致写的是成员名加地址的列表。很多人只改本机 IP忘了每个节点都要是完整列表结果第一个节点能起第二个节点起不来报member ... is already initialized。这类问题不是脚本能自动发现的所以脚本里我会写一个前置检查比较各节点的 initial-cluster 配置是否一致。3. 一键脚本的分层设计把手工步骤落成可复现的代码3.1 脚本分几个阶段从准备到验收我一般会把整套部署拆成八个阶段每个阶段一个脚本文件外加一个总入口脚本按顺序调用。分阶段不是为了显得工程化而是因为翻车的概率和阶段数成正比拆开之后可以在任意阶段停下重跑。八个阶段是环境检查、证书签发、二进制分发、etcd 集群、apiserver、controller-manager 与 scheduler、kubelet 与 kube-proxy、负载均衡与验收。总入口脚本只做三件事读取全局配置文件、按阶段调用子脚本、在每个阶段结束后检查上一步的退出码。子脚本的退出码是全流程的锚点任何一个阶段非零退出后续阶段不执行并在终端打印出具体失败阶段。下面是总入口的简化版#!/usr/bin/env bash set -euo pipefail CLUSTER_DIR$(cd $(dirname ${BASH_SOURCE[0]}) pwd) source ${CLUSTER_DIR}/config/env.sh STAGES(prepare cert distribute etcd master node lb verify) for stage in ${STAGES[]}; do echo [$(date %H:%M:%S)] 阶段: ${stage} bash ${CLUSTER_DIR}/stages/${stage}.sh if [ $? -ne 0 ]; then echo [ERROR] 阶段 ${stage} 执行失败请检查后从本阶段重跑 exit 1 fi done echo [OK] 二进制高可用 k8s 集群一键部署完成 kubectl --kubeconfig ${CLUSTER_DIR}/config/admin.kubeconfig get nodes逻辑说明env.sh里是所有机器 IP、主机名、VIP、网段、版本号这种全局变量所有子脚本都 source 它这是保证“只改一处、全局生效”的关键。set -euo pipefail让脚本在命令失败时立即退出避免带着错误状态继续往下跑这个习惯在部署脚本里是底线。每个阶段独立成.sh文件可以从任一阶段重跑。参数说明STAGES数组的顺序就是部署依赖顺序cert 必须在 etcd 之前因为 etcd 要用证书master 阶段必须在 node 阶段之前因为 node 要拿 apiserver 的地址lb 放在最后是因为负载均衡健康检查依赖 apiserver 已经就绪。注意lb在架构上应该先于 node 阶段存在但实际部署中可以先让 node 直连某个 master IP 完成初始化再把访问切到 VIP这是减少联动故障的常见做法我一般这么处理。3.2 证书签发脚本CA 与三类证书的生成证书是最容易出错也最难排错的阶段我把它独立成脚本。使用 cfssl 工具生成证书比原始 openssl 命令更简洁且支持批量生成。核心是维护一个 JSON 配置描述 CA然后用三个不同 SAN 的 JSON 分别生成 etcd、apiserver、kubelet 的证书。#!/usr/bin/env bash set -euo pipefail source ${CLUSTER_DIR}/config/env.sh CERT_DIR${CLUSTER_DIR}/certs mkdir -p ${CERT_DIR} # 1. 生成 CA 私有密钥并自签根证书 cfssl gencert -initca ca-csr.json | cfssljson -bare ca这段只是起点。关键在ca-csr.json它的CN我固定写成kubernetes-cakey的algo用rsasize用2048。生产环境不建议用 1024虽然启动快但安全审计过不了。CA 私钥ca-key.pem是整套集群的根部署完成后我会把它单独备份到离线介质并限制只有 root 可读。# 2. 生成 apiserver 证书SAN 是关键 cat apiserver-csr.json EOF { CN: kube-apiserver, key: { algo: rsa, size: 2048 }, names: [ { C: CN, ST: Beijing, L: Beijing } ], hosts: [ 127.0.0.1, ${VIP}, ${MASTER_IPS[0]}, ${MASTER_IPS[1]}, ${MASTER_IPS[2]}, 10.96.0.1, kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local ] } EOF cfssl gencert -caca.pem -ca-keyca-key.pem -configca-config.json \ -profileserver apiserver-csr.json | cfssljson -bare apiserver逻辑说明hosts数组就是 X.509 证书的 SAN 列表这一行决定了客户端能用哪些地址访问 apiserver 而不会报证书错误。10.96.0.1是 service CIDR 里 kube-apiserver Service 的 ClusterIPkubernetes.default.svc.cluster.local是集群内部 DNS 解析到该 IP 的域名。ca-config.json里定义 profileserver profile 里expiry我写 87600 小时也就是十年运维上省心如果公司安全规范要求短证书就把证书轮换也写进脚本后面会提到。参数说明MASTER_IPS是配置里的数组遍历生成多 master 场景时hosts 集合是固定的所以放在数组里引用。profileserver表示这个证书用途是服务端证书会带上extendedKeyUsage里的serverAuth。etcd 的 client 证书和 kubelet 的证书流程完全一致只是 hosts 列表不同etcd 三节点要分别签 peer 证书时用循环生成三个 CSR 文件并分别签出。实际部署时 kubelet 证书有两种做法一是预先为每个 node 生成证书并分发二是让 kubelet 启动时自动向 apiserver 发起 CSR。我二进制部署时用第一种因为脚本化环境下每台 node 的名字和 IP 都是确定的预先签好证书可以控制所有细节同时避免 node 加入集群时还需要人工kubectl certificate approve视频演示里那种“自动审批 CSR 的控制器”增加复杂度不符合脚本化的简洁目标。3.3 etcd 集群脚本member 列表与 initial-clusteretcd 是整套集群的数据底座它的部署顺序在所有控制面组件之前。三节点 etcd 的关键参数是initial-cluster、initial-cluster-state和证书路径。#!/usr/bin/env bash set -euo pipefail source ${CLUSTER_DIR}/config/env.sh ETCD_NAME${HOSTNAME} # 每台机器不同 ETCD_IP${HOST_IPS[$HOSTNAME]} # 映射关系在 env.sh 中配置 cat /etc/etcd/etcd.conf EOF name: ${ETCD_NAME}>ETCDCTL_API3 etcdctl --endpointshttps://10.0.0.11:2379 \ --cacert/etc/etcd/ssl/ca.pem \ --cert/etc/etcd/ssl/etcd-client.pem \ --key/etc/etcd/ssl/etcd-client-key.pem \ endpoint health --cluster逻辑说明endpoint health --cluster会返回整个集群的健康状态只有三个节点都健康才是通过。这里用的 client 证书是专门给客户端访问签的不能和 server 证书混用混用时 etcd 会报证书用途不匹配。ETCDCTL_API3是显式指定 API 版本因为 etcd 同时支持 v2 和 v3 的 API默认可能走 v2看不到 v3 的数据。3.4 控制面脚本apiserver 与 controller-manager、scheduler控制面三个组件中apiserver 负责对外controller-manager 和 scheduler 只通过本机回环地址连 apiserver。三台 master 上这三个组件全部部署靠 leader election 来保证只有一个实例在真正干活。apiserver 的 systemd unit 参数是整套脚本里最长的核心参数要覆盖证书、etcd 地址、service CIDR、审计策略和匿名请求cat /etc/systemd/system/kube-apiserver.service EOF [Unit] DescriptionKubernetes API Server Afternetwork.target [Service] ExecStart/usr/local/bin/kube-apiserver \\ --bind-address0.0.0.0 \\ --secure-port6443 \\ --advertise-address${HOST_IPS[$HOSTNAME]} \\ --etcd-servershttps://10.0.0.11:2379,https://10.0.0.12:2379,https://10.0.0.13:2379 \\ --etcd-cafile/etc/kubernetes/pki/ca.pem \\ --etcd-certfile/etc/kubernetes/pki/apiserver-etcd-client.pem \\ --etcd-keyfile/etc/kubernetes/pki/apiserver-etcd-client-key.pem \\ --client-ca-file/etc/kubernetes/pki/ca.pem \\ --tls-cert-file/etc/kubernetes/pki/apiserver.pem \\ --tls-private-key-file/etc/kubernetes/pki/apiserver-key.pem \\ --service-cluster-ip-range10.96.0.0/12 \\ --service-node-port-range30000-32767 \\ --allow-privilegedtrue \\ --authorization-modeNode,RBAC \\ --anonymous-authfalse \\ --audit-log-path/var/log/kubernetes/audit.log \\ --audit-log-maxsize100 \\ --audit-log-maxbackup5 Restarton-failure RestartSec10 [Install] WantedBymulti-user.target EOF逻辑说明--etcd-servers写三节点的完整地址apiserver 会自己处理 etcd 节点的故障转移。--client-ca-file指向 CA 根证书这样 apiserver 才能验证所有客户端证书。--authorization-modeNode,RBAC是生产环境的标配Node 模式允许 kubelet 访问特定资源RBAC 管理普通用户权限。--anonymous-authfalse在初始化阶段很重要因为后面 kubelet 加入时需要 token 和证书不能允许匿名访问。参数说明--service-cluster-ip-range10.96.0.0/12必须和 kube-proxy、kubelet 里配置的 service CIDR 一致否则 ClusterIP 路由不通。--audit-log-path是二进制部署自带的优势kubeadm 下配置审计策略要改静态 Pod 参数二进制方式直接写命令行。审计日志的文件大小和滚动数量建议根据磁盘规划设置默认 100MB 乘以 5 份通常够用。controller-manager 和 scheduler 的 unit 相对简单关键参数是 leader election 的租约时间和证书ExecStart/usr/local/bin/kube-controller-manager \\ --bind-address127.0.0.1 \\ --leader-electtrue \\ --leader-elect-lease-duration15s \\ --leader-elect-renew-deadline10s \\ --leader-elect-retry-period5s \\ --kubeconfig/etc/kubernetes/controller-manager.kubeconfig \\ --service-account-private-key-file/etc/kubernetes/pki/sa-key.pem \\ --root-ca-file/etc/kubernetes/pki/ca.pem ExecStart/usr/local/bin/kube-scheduler \\ --bind-address127.0.0.1 \\ --leader-electtrue \\ --leader-elect-lease-duration15s \\ --kubeconfig/etc/kubernetes/scheduler.kubeconfig逻辑说明--bind-address127.0.0.1是刻意的controller-manager 和 scheduler 只需要本机访问 apiserver不需要对外暴露端口这是二进制方式默认的安全边界。--leader-electtrue保证高可用三台 master 上同时启动这两个组件同一时刻只有 leader 在工作。租约时间三个参数我按 Kubernetes 官方默认值来配lease-duration15s表示如果 leader 失联 15 秒其他节点开始竞选生产环境这个值够快。参数说明--kubeconfig用的是专门为组件签的 client 证书每个组件一个独立证书文件而不是直接拿 admin 证书。权限分离是二进制部署的重要收益之一controller-manager 的证书只授予system:kube-controller-manager权限scheduler 同理排错时看审计日志能清楚知道是哪个组件干了什么。部署完成后验证控制面是否正常。三台 master 上都要能看到本机组件处于健康状态kubectl --kubeconfig/etc/kubernetes/admin.kubeconfig \ get componentstatuses逻辑说明componentstatuses返回的是 controller-manager 和 scheduler 的健康状态这个命令走 apiserver 代理间接验证 apiserver 到各组件的连通性。如果你看到unhealthy逐行检查 kubeconfig 里的 server 地址是否正确、证书是否被 apiserver 信任、以及组件日志里有没有连接拒绝。3.5 工作节点脚本kubelet 与 kube-proxynode 节点上的部署比 master 简单但有一个前置条件kubelet 的 kubeconfig 里指向的 apiserver 地址必须是 VIP不能是某个具体的 master IP否则负载均衡切换时 kubelet 会与 apiserver 失联。#!/usr/bin/env bash set -euo pipefail source ${CLUSTER_DIR}/config/env.sh NODE_IP${HOST_IPS[$HOSTNAME]} cat /etc/systemd/system/kubelet.service EOF [Unit] DescriptionKubernetes Kubelet Afternetwork.target [Service] ExecStart/usr/local/bin/kubelet \\ --kubeconfig/etc/kubernetes/kubelet.kubeconfig \\ --hostname-override${HOSTNAME} \\ --node-ip${NODE_IP} \\ --pod-infra-container-imageregistry.local/pause:3.9 \\ --image-pull-progress-deadline2m \\ --fail-swap-onfalse \\ --v2 Restartalways RestartSec10 [Install] WantedBymulti-user.target EOF systemctl daemon-reload systemctl enable --now kubelet逻辑说明--hostname-override${HOSTNAME}和--node-ip${NODE_IP}是配套的如果不指定 node-ipkubelet 会去探测本机默认路由 IP多网卡机器上很容易探测错网卡导致 apiserver 看到的 node IP 不是实际 IPkubectl exec 和日志功能全挂。--pod-infra-container-image指向内网镜像仓库的 pause 镜像这是离线集群必须配置的因为 sandbox 镜像要从这里拉取而默认的仓库地址在离线环境永远拉不到。参数说明--kubeconfig里的 server 地址要写成https://${VIP}:6443这个文件在证书阶段就生成好node 节点不需要再发起 CSR。--fail-swap-onfalse需要说明Kubernetes 从某版本开始默认拒绝在有 swap 的节点上启动 kubelet如果你不想关闭 swap就把这个参数设成false但如果你的节点内存确实紧张建议还是关 swap 而不是带 swap 跑这个参数是折中方案不适合内存严重不足的生产环境。kube-proxy 的配置主要是模式选择和服务网段cat /etc/kubernetes/kube-proxy.yaml EOF apiVersion: kubeproxy.config.k8s.io/v1alpha1 kind: KubeProxyConfiguration clusterCIDR: 10.244.0.0/16 mode: ipvs ipvs: scheduler: rr EOF ExecStart/usr/local/bin/kube-proxy \\ --config/etc/kubernetes/kube-proxy.yaml \\ --kubeconfig/etc/kubernetes/kube-proxy.kubeconfig逻辑说明mode: ipvs是生产环境的常见选择比 iptables 模式转发效率高排除问题也更直观。但 ipvs 模式有一个前置条件内核需要加载 ip_vs 相关模块脚本里prepare阶段必须先加载ip_vs,ip_vs_rr,ip_vs_wrr等模块否则 kube-proxy 启动时会报cant initialize ipvs。clusterCIDR是 pod 网段如果你的 CNI 是 calico这个值要与 calico 的 IP 池一致不一致的话 kube-proxy 转发目标会指向错误的地址。4. 高可用负载均衡与校验VIP、健康检查、集群自愈4.1 apiserver 前的四层负载均衡怎么搭apiserver 前面的负载均衡是整个高可用架构的第一道门。常见做法是 keepalived 加 haproxykeepalived 提供 VIPhaproxy 做四层转发。每台 master 上都跑一个 haproxy健康检查探测本机 apiserverVIP 漂移时 kubelet 和 kubectl 只需要重连 VIP不需要感知背后是哪台 apiserver。我一般把 haproxy 和 keepalived 放在 master 节点上而不是单独两台机器这样不额外占用机器且 master 本身要求至少三台数量上天然满足 keepalived 的多数派要求。haproxy 配置关键是去掉对 apiserver 的健康检查干扰cat /etc/haproxy/haproxy.cfg EOF global log /dev/log local0 maxconn 4096 defaults mode tcp timeout connect 5s timeout client 30s timeout server 30s frontend k8s-api bind *:16443 default_backend k8s-masters backend k8s-masters balance roundrobin option tcp-check server master-1 10.0.0.11:6443 check server master-2 10.0.0.12:6443 check server master-3 10.0.0.13:6443 check EOF逻辑说明mode tcp表示这是四层负载均衡不解析 HTTP 协议直接转发原始 TCP 流量。option tcp-check让 haproxy 定期建立 TCP 连接到 apiserver 的 6443 端口连接失败就把该 master 摘除。bind *:16443监听在非标准端口避免与 apiserver 的 6443 混淆。keepalived 配置里最重要的是 VIP 和健康脚本vrrp_script check_haproxy { script /usr/local/bin/check_haproxy.sh interval 2 weight -20 rise 2 fall 2 } vrrp_instance VI_1 { state BACKUP interface ens192 virtual_router_id 51 priority 100 advert_int 1 virtual_ipaddress { 10.0.0.100/24 dev ens192 label ens192:0 } track_script { check_haproxy } }这里有个反直觉的地方我把所有 master 的 keepalived 都配成BACKUP而不是一台MASTER两台BACKUP。因为MASTER和BACKUP的优先级比较在脑裂时会产生争议全 BACKUP 配合 weight 减分机制更稳定。priority 100加上健康检查失败时weight -20实际上优先级的差异来自谁的健康检查先失败谁就自动降级。4.2 集群健康检查的五个维度部署完不等于集群健康我每次交付前都会按固定顺序做五层检查任何一层不过都不能算完成。第一层是 etcd上面提到过endpoint health --cluster这层不过后面全是幻象。第二层是 apiserver用curl --cacert /etc/kubernetes/pki/ca.pem https://${VIP}:16443/healthz验证负载均衡链路上的 VIP 通不通这一步会暴露 haproxy 或 keepalived 的问题。第三层是节点状态kubectl get nodes看所有节点是不是 Ready特别关注NotReady的节点常见原因是 kubelet 证书问题或者 CNI 没装好。第四层是应用层部署一个测试 Deployment确认 pod 能调度、能拉镜像、能访问 Service。第五层是证书时间把集群里所有证书的过期时间拉一遍做成表格这一步在交付当天看不出问题但能避免半年后的深夜告警。检查证书过期时间的命令我认为值得单独拿出来for f in /etc/kubernetes/pki/*.pem; do echo $f openssl x509 -in $f -noout -enddate done逻辑说明遍历证书目录下所有 PEM 文件打印各自的过期时间。这个命令在脚本里应该作为独立阶段存在或者定期巡检。二进制的自签证书过期后组件会突然全部断连没有任何预告所以巡检证书是必须做的日常操作。4.3 故障演练kill master 验证自愈部署完成后一定要做一次破坏性验证否则你永远不知道负载均衡是否真的生效。我的做法是先记录当前 apiserver 的 VIP 落在哪台 master 上然后直接systemctl stop kube-apiserver或者拔网线看集群是否自愈。最简单的模拟故障是停掉 VIP 所在机器的 haproxysystemctl stop haproxy sleep 5 ip addr show | grep 10.0.0.100逻辑说明如果 keepalived 配置正确VIP 在 5 秒内会漂移到另一台 master 上然后kubectl get nodes仍然正常。如果 VIP 没漂移检查 keepalived 日志里的VRRP状态以及check_haproxy.sh的退出码。这里特别容易翻车的点是健康脚本没有执行权限keepalived 对脚本权限很敏感chmod x后还要确认脚本里引用的命令都在 PATH 中keepalived 默认精简 PATH可能找不到curl解决办法是脚本里写绝对路径。更彻底的演练是逐台停掉 apiserver同时持续请求kubectl get nodes观察中断时长。健康运行的集群里这个中断通常在秒级因为 haproxy 的 tcp-check 探测周期是 2 秒。如果中断超过半分钟说明哪一层出了问题通常表现为VIP 漂移了但 haproxy 没有把流量转发到新 apiserver或者 kubelet 缓存的连接还在尝试旧的 apiserver 地址。5. 二进制高可用部署的避坑清单这些坑我至少踩过一次5.1 证书 SAN 漏了 VIPkubectl 随机报错现象集群部署完成后kubectl 有时能通有时报x509: certificate is valid for 10.0.0.11, not 10.0.0.100重启 kubelet 后恢复过一会又报。原因apiserver 证书的 SAN 只写了某一个 master IP没写 VIP客户端的请求正好被负载均衡转发到了证书里没有的那个 IP。解决重签 apiserver 证书把 VIP 和所有 master IP 全部加入 SAN重新分发到所有 master 节点并重启 apiserver。这个坑我只踩过一次但排查花了整整一个下午。5.2 etcd 启动失败报 already initialized现象第二台 etcd 启动时报etcdmain: etcdserver: member xxx is already initialized第一台正常第三台也报。原因initial-cluster-state每台机器上都写了new但集群已经有一个节点完成了初始化新节点带着new状态加入时就会冲突。解决确保所有节点首次启动时initial-cluster-state为new反过来已初始化的节点如果重启这个参数必须为existing。血泪经验是给脚本里加一个检查函数检测>#!/usr/bin/env bash CERT_DIR/etc/kubernetes/pki THRESHOLD_DAYS30 ALERTyouexample.com for cert in ${CERT_DIR}/*.pem; do enddate$(openssl x509 -in ${cert} -noout -enddate | cut -d -f2) end_epoch$(date -d ${enddate} %s) now_epoch$(date %s) remain$(( (end_epoch - now_epoch) / 86400 )) if [ ${remain} -lt ${THRESHOLD_DAYS} ]; then echo [WARN] ${cert} 剩余 ${remain} 天到期 | mailx -s K8s 证书到期预警 ${ALERT} fi done逻辑说明date -d ${enddate}把证书的到期时间字符串转换成标准格式再配合%s得到 epoch 时间戳这样在没有 Python 依赖的纯净环境里也能计算剩余天数。remain小于阈值就发预警邮件实际生产环境可以替换成钉钉或企业微信的 webhook 接口。回滚和告警之外还有一个容易被忽略的动作——把整个部署脚本纳入版本管理。我把自己维护的这套脚本放在内部 git 仓库每次改参数都提交并标注对应环境。这样做的好处是半年后你回看时能知道当时为什么把fail-swap-on设置成 false而不是靠记忆重建。这些都是我自己的习惯不一定适合所有团队但它们让我在升级和排障时不需要从头开始手工敲命令。二进制部署的高可用集群不像 kubeadm 那样有一个统一的管理入口运维工具链必须自己搭把这些固化进脚本比临时查文档可靠得多。希望这篇文章的流程和参数能帮你在自己的环境里少踩几个坑也把二进制高可用集群的部署和维护变成一件可预期的事。本文还有配套的精品资源点击获取