★ FEATURED ARTICLE 1. 为什么非得手撸二进制部署多Master——从“点点点”到“懂原理”的分水岭你有没有在某个凌晨三点盯着控制台里飘红的kubectl get nodes输出发呆三个Master节点明明都通着SSH、systemd服务也显示active可Ready状态却卡在NotReady上整整两小时又或者刚用kubeadm搭好的高可用集群某天突然发现etcd证书过期了翻遍文档却找不到kubeadm certs renew在多Master场景下的精确执行顺序最后只能重装——而业务系统已经停摆47分钟。这不是玄学是绝大多数人跳过二进制部署直接上封装工具后必然踩中的深坑。我带过的某高校实验室团队在做边缘AI推理平台时就栽在这上面他们用kubeadm快速起了一套三Master集群跑了几个月相安无事。直到要对接一个国产加密中间件需要修改kube-apiserver的TLS握手参数。结果发现——kubeadm生成的manifest全在/etc/kubernetes/manifests/下硬编码而kubeadm init phase命令根本不支持自定义TLS配置项。最后团队花了三天重走二进制流程才把--tls-cipher-suitesTLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384这个参数稳稳塞进每个Master的启动命令里。二进制部署不是复古情怀它是Kubernetes治理能力的“源代码级开关”。当你亲手写/usr/lib/systemd/system/kube-apiserver.service你就在定义API Server的内存限制、审计日志路径、服务账户密钥轮换周期当你逐行校验etcdctl member list输出你就在掌控集群脑裂时的仲裁逻辑当你为每个Master节点单独签发含SANSubject Alternative Name的证书你就在构筑整个集群的身份信任根。这和用Docker run启动一个容器有本质区别前者你是在组装一台精密仪器后者只是按下电源键。关键词里没填内容但标题本身已足够锋利——“k8s多master节点”“二进制部署”“实操”三个词像三把刻刀划出了本文的绝对边界不讲概念不画架构图不对比kubeadm与二进制的优劣那种文章网上一搜一大把只聚焦一件事如何用最简练的步骤、最不易出错的配置、最贴近生产环境的验证方式让三个Master节点真正以Leader选举负载分担的方式协同工作。全文所有命令、配置、证书参数均来自我在某跨平台物联网中台项目中真实复现并压测过200次的脚本集合连sed -i s/127.0.0.1/192.168.10.10/g这种容易手抖的替换操作都附带了防误删的校验逻辑。如果你的目标是“今天下午就把集群跑起来”那本文可能让你皱眉——它要求你理解--advertise-address和--bind-address的区别会带你手算etcd client端口与peer端口的防火墙放行规则甚至告诉你为什么kube-controller-manager的--leader-elect-resource-lock必须设为leases而非endpoints。但如果你的目标是“三年后还能从容升级到v1.30且敢对SRE同事说‘这个故障我来定位’”那接下来的每一步都是你技术护城河的砖石。2. 多Master高可用的本质不是堆机器而是建共识——etcd集群与API Server的共生逻辑很多人以为“多Master”就是把kubeadm init执行三次再把token塞进其他节点。这是对Kubernetes控制平面最危险的误解。真正的高可用始于对两个核心组件关系的透彻理解etcd是集群的“大脑记忆体”而API Server是“大脑皮层”——没有记忆体皮层再活跃也是幻觉没有皮层记忆体再完整也无法被外界感知。先看etcd。它不是简单的键值数据库而是一个强一致性的分布式状态机。当三个Master节点各自运行etcd实例时它们通过Raft协议选举Leader并强制所有写操作必须经由Leader同步给多数派quorum节点后才返回成功。这意味着若三节点集群中一个节点宕机剩余两个节点仍能组成多数派2 3/2集群持续可用但若两个节点同时失联仅剩的一个节点无法获得多数派确认将拒绝所有写请求进入只读状态——这正是kubectl apply -f卡住的根本原因。而API Server的角色更微妙。它本身无状态所有状态都存在etcd中。但它的启动参数决定了它能否成为合格的“大脑皮层”--etcd-servershttps://192.168.10.11:2379,https://192.168.10.12:2379,https://192.168.10.13:2379告诉API Server去哪找etcd集群注意这里必须是所有etcd节点的client端口2379而非peer端口2380--advertise-address192.168.10.11声明“我是谁”即该API Server对外提供服务的IP必须与负载均衡器指向的IP完全一致--bind-address0.0.0.0声明“我在哪听”即监听所有网卡但实际生效受--secure-port和防火墙约束。最关键的共生点在于API Server不参与etcd的Raft选举但它依赖etcd的健康状态来决定自身是否Ready。当kubelet执行/healthz探针时API Server会主动检查etcd连接、证书有效性、自身与etcd的数据同步延迟默认阈值5秒。任一环节超时kubectl get nodes就会显示NotReady——哪怕你的systemctl status kube-apiserver显示绿色。这就引出了一个反直觉结论多Master集群的稳定性70%取决于etcd集群的健壮性30%取决于API Server的参数对齐度。我曾见过某金融客户集群反复崩溃排查三天才发现三个Master的etcd证书有效期分别是365天、365天、90天。第91天凌晨第三个节点etcd进程因证书过期自动退出导致etcd集群失去多数派所有API Server瞬间失联。而运维同学只盯着kubectl get componentstatuses该命令在v1.19后已被弃用完全没意识到etcd才是风暴眼。因此二进制部署的第一道生死线就是etcd集群的初始化。它必须满足三个铁律节点标识唯一性每个etcd成员的--name必须全局唯一如etcd-master01且不能包含下划线etcd v3.5会报错网络拓扑显式化--initial-cluster参数必须精确列出所有成员的namehttp://ip:2380顺序无关但拼写零容错证书覆盖全覆盖etcd client证书必须包含所有Master节点IP及负载均衡VIP的SAN字段peer证书则需包含各节点hostname用于内部通信。提示不要试图用etcdctl endpoint health单点检测代替全链路验证。正确姿势是在任意Master节点执行etcdctl --endpointshttps://192.168.10.11:2379,https://192.168.10.12:2379,https://192.168.10.13:2379 --cacert/etc/etcd/ssl/ca.pem --cert/etc/etcd/ssl/member.pem --key/etc/etcd/ssl/member-key.pem endpoint status --write-outtable观察HEALTH列是否全为trueIS LEADER列是否仅有一个true。这是判断etcd集群是否真正形成Raft共识的黄金标准。3. 证书体系不是“生成就完事”而是构建一张可验证的信任网络在二进制部署中证书不是安全装饰品而是控制平面组件间相互认证的“数字身份证”。一套混乱的证书体系足以让集群在启动后数小时内无声崩溃。我统计过某制造企业过去两年的K8s故障工单38%的“集群不可用”问题根源是证书配置错误其中又以SANSubject Alternative Name遗漏最为高频。先明确一个原则Kubernetes控制平面涉及四类证书每类用途截然不同绝不能混用CA证书ca.pem/ca-key.pem根证书用于签发所有其他证书必须严格保管私钥禁止出现在任何节点etcd证书分为client证书供API Server等连接etcd、peer证书供etcd节点间通信、server证书供etcd对外提供服务Kubernetes组件证书包括kube-apiserver、kube-controller-manager、kube-scheduler、kubelet的客户端证书Service Account密钥sa.key/sa.pub用于Pod内ServiceAccount Token签名与TLS证书无关。最易出错的是kube-apiserver证书的SAN字段。很多教程只写-IP:192.168.10.11却忽略以下必需项所有Master节点IP确保每个API Server都能被其他组件访问负载均衡器VIP如192.168.10.100这是Ingress或外部调用的入口Kubernetes Service ClusterIP通常是10.96.0.1否则kubectl cluster-info会失败DNS名称如kubernetes.default.svc.cluster.local这是Pod内访问API Server的默认域名。生成命令示例如下使用cfssl工具cat apiserver-csr.json EOF { CN: kube-apiserver, hosts: [ 127.0.0.1, 192.168.10.11, // Master01 IP 192.168.10.12, // Master02 IP 192.168.10.13, // Master03 IP 192.168.10.100, // LB VIP 10.96.0.1, // kubernetes service IP kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local ], key: { algo: rsa, size: 2048 }, names: [ { C: CN, ST: Shanghai, L: Pudong, O: k8s, OU: System } ] } EOF cfssl gencert -caca.pem -ca-keyca-key.pem -configca-config.json -profilekubernetes apiserver-csr.json | cfssljson -bare apiserver注意hosts数组中127.0.0.1的存在——这是为kubectl本地调试预留的若省略kubectl --insecure-skip-tls-verify get nodes会报x509: certificate is valid for 192.168.10.11, not 127.0.0.1。另一个隐形杀手是证书有效期。etcd默认证书有效期为1年但Kubernetes组件证书常被忽略。我建议统一设为5年expiry: 43800h理由很实在避免在业务高峰期遭遇证书续签。某电商大促前夜运维同学发现kube-controller-manager证书只剩3天紧急执行cfssl gencert后忘记重启服务导致新证书未加载集群在零点流量洪峰时因证书校验失败集体失联。注意证书生成后必须用openssl x509 -in apiserver.pem -text -noout逐个检查SAN字段是否完整。我曾帮某客户排查发现其证书中漏了kubernetes.default.svc.cluster.local导致CoreDNS Pod启动后无法连接API Server整个集群DNS瘫痪。这种错误不会在systemctl start kube-apiserver时报错而是在kubectl get pods --all-namespaces时静默失败。4. 组件启动脚本systemd服务文件里的魔鬼细节当证书和etcd准备就绪真正的“手撸”才刚开始。二进制部署的核心载体是systemd服务文件而每个ExecStart参数背后都藏着影响集群稳定性的关键决策。我见过太多人复制粘贴服务文件后集群跑了一周就莫名卡死最后发现是kube-controller-manager的--concurrent-service-syncs参数设为100默认5导致大量Service对象同步抢占etcd锁拖垮整个控制平面。先看kube-apiserver.service这是所有组件的“总开关”[Unit] DescriptionKubernetes API Server Documentationhttps://github.com/kubernetes/kubernetes Afternetwork.target etcd.service [Service] Typenotify ExecStart/usr/local/bin/kube-apiserver \ --advertise-address192.168.10.11 \ # 必须与本机IP一致 --bind-address0.0.0.0 \ # 监听所有接口 --secure-port6443 \ # HTTPS端口 --insecure-port0 \ # 禁用HTTP端口安全红线 --authorization-modeNode,RBAC \ # 授权模式Node必须在RBAC前 --enable-admission-pluginsNodeRestriction,DefaultStorageClass,ResourceQuota \ --service-account-key-file/etc/kubernetes/pki/sa.pub \ # SA公钥 --service-account-signing-key-file/etc/kubernetes/pki/sa.key \ # SA私钥 --service-cluster-ip-range10.96.0.0/12 \ # Service CIDR --etcd-cafile/etc/etcd/ssl/ca.pem \ # etcd CA证书 --etcd-certfile/etc/etcd/ssl/member.pem \ # etcd client证书 --etcd-keyfile/etc/etcd/ssl/member-key.pem \ # etcd client私钥 --etcd-servershttps://192.168.10.11:2379,https://192.168.10.12:2379,https://192.168.10.13:2379 \ # 所有etcd节点 --client-ca-file/etc/kubernetes/pki/ca.pem \ # 客户端CA用于kubelet认证 --tls-cert-file/etc/kubernetes/pki/apiserver.pem \ # API Server证书 --tls-private-key-file/etc/kubernetes/pki/apiserver-key.pem \ # API Server私钥 --kubelet-client-certificate/etc/kubernetes/pki/apiserver-kubelet-client.pem \ # 访问kubelet的客户端证书 --kubelet-client-key/etc/kubernetes/pki/apiserver-kubelet-client-key.pem \ # 对应私钥 --service-account-issuerkubernetes.default.svc.cluster.local \ # SA签发者 --service-account-api-audiencesapi,spire \ # 允许的audience列表 --runtime-configapi/alltrue \ # 启用所有API组 --audit-log-path/var/log/kubernetes/audit.log \ # 审计日志路径 --audit-policy-file/etc/kubernetes/pki/audit-policy.yaml \ # 审计策略 --v2 Restarton-failure RestartSec5 Userroot LimitNOFILE65536 [Install] WantedBymulti-user.target关键参数解析--authorization-modeNode,RBAC顺序不能颠倒Node模式用于kubelet的Node身份认证RBAC用于用户权限控制若RBAC在前kubelet将因无RBAC规则被拒绝--enable-admission-plugins启用插件列表NodeRestriction必须在首位它限制kubelet只能修改自身Node对象是安全基线--service-account-issuer必须与SA证书的issuer字段完全一致否则Pod内Token校验失败--audit-log-path审计日志路径必须提前创建目录并赋权chown root:root /var/log/kubernetes chmod 755 /var/log/kubernetes否则API Server启动失败。再看kube-controller-manager.service它的稳定性常被低估[Unit] DescriptionKubernetes Controller Manager Documentationhttps://github.com/kubernetes/kubernetes Afternetwork.target kube-apiserver.service [Service] Typenotify ExecStart/usr/local/bin/kube-controller-manager \ --bind-address127.0.0.1 \ # 仅绑定本地不暴露给外部 --secure-port0 \ # 关闭HTTPS端口安全最佳实践 --cluster-cidr10.244.0.0/16 \ # Pod CIDR必须与CNI插件一致 --service-cluster-ip-range10.96.0.0/12 \ # Service CIDR必须与API Server一致 --allocate-node-cidrstrue \ # 启用Node CIDR分配 --leader-electtrue \ # 必须开启Leader选举 --leader-elect-resource-lockleases \ # 锁类型leases比endpoints更轻量 --leader-elect-renew-deadline10s \ # Leader续租宽限期 --leader-elect-retry-period2s \ # 重试间隔 --node-monitor-grace-period40s \ # Node失联判定时间 --pod-eviction-timeout5m0s \ # Pod驱逐超时 --use-service-account-credentialstrue \ # 使用SA凭据访问API Server --controllers*,-statefulset,-deployment \ # 禁用特定控制器按需 --authentication-kubeconfig/etc/kubernetes/controller-manager.kubeconfig \ # 认证配置 --authorization-kubeconfig/etc/kubernetes/controller-manager.kubeconfig \ # 授权配置 --client-ca-file/etc/kubernetes/pki/ca.pem \ # CA证书 --tls-cert-file/etc/kubernetes/pki/controller-manager.pem \ # 自身证书 --tls-private-key-file/etc/kubernetes/pki/controller-manager-key.pem \ # 自身私钥 --service-account-private-key-file/etc/kubernetes/pki/sa.key \ # SA私钥 --root-ca-file/etc/kubernetes/pki/ca.pem \ # 根CA --v2 Restarton-failure RestartSec5 Userroot LimitNOFILE65536 [Install] WantedBymulti-user.target致命细节--bind-address127.0.0.1Controller Manager无需对外提供服务绑定本地更安全--leader-elect-resource-lockleasesKubernetes v1.18推荐使用Leases资源锁它比Endpoints锁更高效且在API Server压力大时不易出现锁争用--node-monitor-grace-period40s此值必须大于kubelet的--node-status-update-frequency默认10s的3倍以上否则正常心跳会被误判为Node失联。最后是kube-scheduler.service它最“轻量”却最不容错[Unit] DescriptionKubernetes Scheduler Documentationhttps://github.com/kubernetes/kubernetes Afternetwork.target kube-apiserver.service [Service] Typenotify ExecStart/usr/local/bin/kube-scheduler \ --bind-address127.0.0.1 \ # 同样只绑本地 --secure-port0 \ # 关闭HTTPS --leader-electtrue \ # 必须开启选举 --authentication-kubeconfig/etc/kubernetes/scheduler.kubeconfig \ # 认证配置 --authorization-kubeconfig/etc/kubernetes/scheduler.kubeconfig \ # 授权配置 --client-ca-file/etc/kubernetes/pki/ca.pem \ # CA证书 --tls-cert-file/etc/kubernetes/pki/scheduler.pem \ # 自身证书 --tls-private-key-file/etc/kubernetes/pki/scheduler-key.pem \ # 自身私钥 --v2 Restarton-failure RestartSec5 Userroot LimitNOFILE65536 [Install] WantedBymulti-user.target提示所有服务文件写入后务必执行systemctl daemon-reload systemctl enable kube-apiserver kube-controller-manager kube-scheduler。切记enable要在start之前否则重启主机后服务不会自启。我曾因漏掉enable在一次意外断电后三个Master全部无法自愈手动start耗时17分钟——而生产环境SLA要求5分钟内恢复。5. 高可用落地负载均衡器不是“配菜”而是集群的呼吸中枢当三个Master节点的API Server都成功启动systemctl status kube-apiserver显示active (running)别急着庆祝。此时集群仍处于“伪高可用”状态——因为外部流量如kubectl、CI/CD流水线、监控系统若直接访问单个Master IP一旦该节点宕机所有流量立即中断。真正的高可用必须通过负载均衡器LB将流量智能分发到健康节点。这里有个关键认知Kubernetes API Server本身不处理负载均衡它依赖外部LB做健康检查与流量分发。而LB的健康检查逻辑直接决定了集群的“呼吸节奏”。我们以HAProxy为例开源免费生产环境广泛使用其配置核心在于option httpchk指令frontend k8s-api bind *:6443 mode tcp default_backend k8s-api-servers backend k8s-api-servers mode tcp balance roundrobin option httpchk GET /healthz http-check expect status 200 server master01 192.168.10.11:6443 check fall 3 rise 2 server master02 192.168.10.12:6443 check fall 3 rise 2 server master03 192.168.10.13:6443 check fall 3 rise 2重点解析mode tcp必须使用TCP模式因为API Server是HTTPS服务HTTP模式会解密TLS增加延迟且破坏端到端加密option httpchk GET /healthz向每个API Server的/healthz端点发送HTTP GET请求这是Kubernetes官方健康检查端点http-check expect status 200期望返回HTTP 200若返回5xx或超时则标记该节点为DOWNfall 3 rise 2连续3次检查失败才标记为不可用连续2次成功才恢复可用——这避免了网络抖动导致的误判。但/healthz只是第一道关卡。真正的“深度健康检查”必须结合/readyz端点。/healthz只检查API Server自身进程而/readyz会额外验证与etcd的连接是否正常与kube-controller-manager的通信是否正常证书是否即将过期默认7天内过期返回500资源锁如lease是否可获取。因此生产环境强烈建议将HAProxy的健康检查升级为option httpchk GET /readyz?verbose http-check expect status 200?verbose参数会返回详细检查项便于排障。某次故障中/healthz返回200但/readyz返回{status:Failure,reason:Error,message:etcd is not healthy}我们立刻定位到etcd节点磁盘IO异常而非盲目重启API Server。另一个常被忽视的点是LB的SSL卸载。绝对不要在HAProxy上做SSL卸载即terminating SSL。因为API Server的TLS证书包含SAN字段若LB解密后再以HTTP转发给API Server会破坏证书链导致kubectl报x509: certificate signed by unknown authority。正确做法是LB仅做TCP转发TLS握手全程由客户端与API Server完成。最后LB的VIP如192.168.10.100必须写入kubeconfig文件kubectl config set-cluster kubernetes \ --certificate-authority/etc/kubernetes/pki/ca.pem \ --embed-certstrue \ --serverhttps://192.168.10.100:6443注意--server参数必须是LB VIP而非某个Master IP。否则kubectl将永远只连向单一节点失去高可用意义。我曾见某团队为图省事在kubeconfig中写了--serverhttps://192.168.10.11:6443结果Master01宕机后所有自动化脚本全部失败而他们甚至没意识到LB的存在。6. 实战验证五步法精准诊断集群“假活”状态当所有组件启动、LB配置完成kubectl get nodes终于显示三个节点Ready恭喜你——但别松懈。90%的“假活”集群在此刻埋下隐患。所谓“假活”指表面命令能执行但深层功能已失效如kubectl logs查不到Pod日志、kubectl exec无法进入容器、HorizontalPodAutoscaler不触发扩缩容。这些故障往往在业务高峰时集中爆发而根因早在部署阶段就已种下。我总结了一套五步验证法每步直击一个高危风险点全部通过才算真正可用6.1 步骤一etcd集群一致性验证在任意Master节点执行ETCD_ENDPOINTShttps://192.168.10.11:2379,https://192.168.10.12:2379,https://192.168.10.13:2379 etcdctl --endpoints$ETCD_ENDPOINTS \ --cacert/etc/etcd/ssl/ca.pem \ --cert/etc/etcd/ssl/member.pem \ --key/etc/etcd/ssl/member-key.pem \ endpoint status --write-outtable预期结果HEALTH列全为trueIS LEADER列仅一个trueRAFT TERM列数值相同表示同一任期RAFT INDEX列数值相近差异1000过大说明同步延迟。失败处理若某节点HEALTHfalse立即检查该节点etcd日志journalctl -u etcd -n 100常见原因为证书过期或防火墙阻断2380端口。6.2 步骤二API Server深度健康检查在LB VIP所在机器或任意能访问VIP的机器执行curl -k https://192.168.10.100:6443/readyz?verbose预期结果HTTP 200且响应体包含status:ok及各子检查项如etcd、informer-sync。失败处理若返回500检查/var/log/kubernetes/audit.log中是否有大量etcdserver: request timed out日志大概率是etcd性能瓶颈。6.3 步骤三Controller Manager Leader选举验证在三个Master节点分别执行kubectl get leases -n kube-system | grep controller-manager预期结果仅一个节点显示AGE为几分钟如5m其余为数小时如2h表明Leader已稳定选举。失败处理若三节点AGE均为0s说明选举失败检查--leader-elect-resource-lock参数是否为leases以及--leader-elect-renew-deadline是否过短。6.4 步骤四Scheduler调度能力验证部署一个测试Podcat nginx-test.yaml EOF apiVersion: v1 kind: Pod metadata: name: nginx-test namespace: default spec: containers: - name: nginx image: nginx:alpine ports: - containerPort: 80 EOF kubectl apply -f nginx-test.yaml kubectl get pod nginx-test -w # 观察状态从Pending到Running预期结果Pod在30秒内变为Running状态。失败处理若长期卡在Pending执行kubectl describe pod nginx-test查看Events中是否有0/3 nodes are available提示说明Scheduler未正常工作。6.5 步骤五kubelet证书轮换验证在任意Worker节点执行sudo journalctl -u kubelet | grep certificate rotation预期结果日志中出现Starting certificate rotation及Successfully rotated certificates。失败处理若无此日志检查kubelet启动参数是否包含--rotate-certificatestrue及--cert-dir/var/lib/kubelet/pki并确认/var/lib/kubelet/pki/kubelet-client-current.pem软链接是否指向最新证书。提示这五步验证必须在集群上线前全部执行且建议每周巡检一次。某次例行检查中我们发现/readyz返回etcd健康但informer-sync超时最终定位到API Server内存不足--max-request-header-size参数过小及时扩容避免了后续故障。7. 运维长跑从“部署完成”到“五年无忧”的可持续维护策略二进制部署的终极价值不在于“一次搞定”而在于“十年可控”。当集群稳定运行真正的挑战才开始证书续期、版本升级、故障自愈、容量规划。我服务过的某国家级科研平台其K8s集群已连续运行4年11个月期间完成7次大版本升级v1.19→v1.26零计划外停机。其核心经验是一套基于二进制特性的“低侵入式”运维策略。首先是证书续期自动化。手动续签是灾难源头。我们采用cfsslcron组合编写renew-certs.sh脚本自动检测/etc/kubernetes/pki/*.pem证书剩余天数当剩余30天时调用cfssl gencert重新签发保留旧证书至新证书生效后7天执行systemctl restart kube-apiserver kube-controller-manager kube-scheduler滚动重启。关键点在于重启必须按顺序进行——先重启controller-manager再scheduler最后apiserver。因为controller-manager负责Node状态更新若apiserver先重启可能因controller-manager未就绪而丢失Node心跳。其次是版本升级的灰度路径。二进制部署的优势在于可精确控制每个组件版本。我们坚持“三步走”单节点验证在Master01上升级kube-apiserver二进制观察/readyz及kubectl get nodes双节点验证升级Master01Master02模拟Leader切换执行kubectl delete pod -n kube-system $(kubectl get pod -n kube-system | grep kube-controller-manager | awk {print $1})强制选举全量升级确认无误后批量升级所有Master。绝不允许“三节点同时升级”这是血泪教训——某次v1.22升级因新版本对etcd v3.5.0的兼容性问题三节点同时重启导致etcd集群脑裂数据恢复耗时8小时。第三是故障自愈的底线思维。我们为每个Master节点配置独立的etcd-backup.sh#!/bin/bash # 每日02:00执行 ETCDCTL_API3 etcdctl --endpointshttps://127.0.0.1:2379 \ --cacert/etc/etcd/ssl/ca.pem \ --cert/etc/etcd/ssl/member.pem \ --key/etc/etcd/ssl/member-key.pem \ snapshot save /backup/etcd-snapshot-$(date %Y-%m-%d).db # 保留最近7天备份 find /backup -name etcd-snapshot-*.db -mtime 7 -delete备份文件存于独立NAS且每日校验MD5。当etcd数据损坏时可在15分钟内用etcdctl snapshot restore重建节点。最后是容量规划的量化指标。我们拒绝“拍脑袋”扩容而是监控三个黄金指标API Server QPSsum(rate(apiserver_request_total{jobapiserver,code~2..}[5m]))超过1000需考虑增加Masteretcd Backend Commit Durationhistogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m]))超过100ms需优化磁盘IOController Manager Sync Latencyhistogram_quantile(0.95, rate(workqueue_longest_running_processor_microseconds{jobkube-controller-manager}[5m]))超过30s需调
阅读完成 · 觉得有帮助？
