企业官网建设流程全解析

Rancher的高可用搭建，圈内一直有个误区：以为把Rancher Server容器在几台机器上各跑一遍，前面挂个负载均衡，就算HA。真正在生产环境做过的人都知道，这套方案连第一个真实的故障都扛不过去——容器里的token、证书、数据库状态各自为政，一旦某台机器上的副本掉线，整个管理面就会出现各种不一致的脏数据。

Rancher Server本身是Kubernetes多集群管理的控制面，它下面往往挂着几十上百个业务集群。控制面一旦挂掉，日常变更、告警联动、权限审批全部瘫痪。所以生产环境的Rancher，业界通行做法是用RKE（Rancher Kubernetes Engine）先拉起一套独立的Kubernetes集群，再把Rancher通过Helm部署进去。这套方案覆盖Rancher 2.x整个生命周期，也是官方文档在高可用章节一直推荐的标准路径。这份手顺就是从裸节点起步，按生产标准把整套HA环境完整走一遍。所谓手顺，其实就是从制造业传出来的说法——按固定顺序执行的可重复操作流程，适合负责Rancher落地的运维同学，或者正在做生产架构规划的同学直接按步骤抄作业。

1. 架构选型：为什么生产环境必须把Rancher装进Kubernetes

1.1 Rancher在集群管理体系里的真实位置

很多刚接触Rancher的人，把它当成一个普通的Web管理面板来用。这个理解不能说错，但会低估它对基础设施的依赖。Rancher的核心能力不只是展示几个Kubernetes集群的状态，它还要承担多集群的统一认证、RBAC策略下发、项目资源配额、监控告警和审计日志。这些能力全部依赖Rancher自身所依托的etcd和Kubernetes API来存储状态、派发任务。

也就是说，Rancher自身是一个运行在Kubernetes之上的复杂应用，它的元数据、用户账号、集群注册信息都会写入自己所在K8s集群的etcd。如果只在单台机器上docker run一个容器，机器重启、磁盘故障、docker daemon异常，都可能导致管理面长时间不可用。更麻烦的是，单节点模式下数据和状态都在容器里，想迁移都难。

1.2 三条技术路线的对比

生产环境规划Rancher，我见过的主要有三条路线。

一是直接在多个节点上启动Rancher容器，再用NFS共享数据或手工同步。这种做法维护成本极高，官方也不支持，属于"看起来高可用，实际上全是单点"。

二是用RKE1创建一套独立Kubernetes集群，然后在上面通过Helm安装Rancher。这是Rancher 2.x从早期到中期最主流的方案，配套工具成熟，etcd快照、集群恢复、节点升级都有现成命令。

三是从2.7左右开始官方主推的RKE2方案，部署方式更贴近K8s原生，但引入了新组件和新的升级逻辑，运维团队需要重新适应。

三条方案的特点放在一起对比会更直观：

我这次手里这套环境是老团队维护，目标Rancher版本是2.6.x，大家已经习惯用rke命令管理集群状态，所以最终选了RKE1。这个选择放到今天也不算过时，生产环境最重要的不是追新，而是可控。

1.3 一句话说清最终架构

整套环境的链路是这样的：办公网用户访问https://rancher.example.com，域名解析到一个虚拟IP（VIP）；VIP由keepalived管理，流量交给HAProxy；HAProxy以四层方式把TCP 443转发到三个Rancher节点中的任意一个；节点上的Nginx Ingress Controller负责TLS终止，再把请求转发到cattle-system命名空间里的Rancher三个Pod副本；Rancher通过API访问自己所在的Kubernetes集群，同时通过agent与一个个下游业务集群保持长连接。

理解这条链路很重要，后面每一步配置、每一个故障排查，都绕不开它。

2. 基础设施清单：节点、VIP、端口和DNS，先把地基画清楚

2.1 节点角色与资源规划

生产环境Rancher管理集群，我建议至少三台节点。在小规模场景下，每台节点同时承担controlplane、etcd、worker三个角色就够了；如果以后要纳管的集群数量很大，或者Rancher上要跑的监控数据量猛增，再考虑把worker角色拆出去单独部署。

拿我这次环境举例，规划的节点信息如下：

管理集群本身负载不重，真正吃资源的是etcd的磁盘IO，而不是CPU。控制面三节点全角色部署，可以保证任何一台节点宕机，etcd仲裁仍然超过半数组件。

2.2 VIP、DNS和hosts文件

VIP我规划为10.10.20.100。DNS上把rancher.example.com解析到VIP，办公网和运维网都能访问。这里有个细节：企业内部DNS偶尔会出问题，所以我会在三个Rancher节点和两台LB的 /etc/hosts 里把hostname和内部IP写死，避免组件之间跨网络解析时依赖外部DNS。

另外，hostname在RKE部署前就要定好，不要中途修改。Kubelet注册节点时用的是hostname，如果部署到一半把节点名改了，会出现旧的NotReady节点残留，处理起来比较麻烦。

2.3 端口清单与防火墙放行

生产环境的端口放行，最怕的就是"开多了"和"漏开了"。以这套架构为例，需要放行的端口集中在以下几个方向：

keepalived的VRRP报文如果交换机开启了组播隔离，还要在安全组里放行相关协议。很多人只记得开443，结果部署完发现VIP漂移不了，一查就是VRRP报文被防火墙丢了。

2.4 提前写好环境登记表

每次搭建Rancher前，我会先做一张环境登记表，把节点IP、主机名、角色、VIP、域名、证书负责人、备份路径一次填完。别小看这个动作，生产环境出问题时，这张表能节省大量排查时间。我踩过的坑是：环境搭到一半发现两台节点的IP段不在同一网卡下，导致etcd peer之间互相不通，最后只能重新编排IP。前期把清单画清楚，比后期返工便宜太多。

3. 节点初始化：从裸机到可被RKE接管的基础配置

3.1 内核参数与模块加载

RKE在部署Kubernetes时，对节点操作系统有一组硬性要求，任何一个不满足，都有可能在rke up阶段或者集群运行后冒出各种难以解释的现象。最基础的是加载br_netfilter和overlay内核模块，然后设置一组sysctl参数。为了不让这些操作散布在多个步骤里，我习惯把这些配置写成一个文件，一次性下发到三台节点，避免每台机器遗漏不同的参数。下面这段脚本我在Ubuntu 20.04和22.04上都验证过，可以原样复制。

cat > /etc/sysctl.d/99-rancher.conf <<'EOF' net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 vm.swappiness = 0 fs.inotify.max_user_instances = 8192 fs.file-max = 2097152 vm.max_map_count = 262144 EOF sysctl --system modprobe br_netfilter modprobe overlay swapoff -a sed -i '/ swap / s/^\\(.*\\)$/#\\1/' /etc/fstab

参数含义很简单：bridge-nf让防火墙规则对桥接流量生效，是网络插件工作的前提；ip_forward用于容器流量转发；swappiness设成0是避免swap拖慢etcd这种IO敏感组件。inotify和file-max的上限，防止节点上文件句柄或inotify实例耗尽，这在Pod数量多的时候经常遇到。

3.2 Docker安装与版本锁定

RKE1通过SSH在节点上执行docker命令，所以Docker的版本和稳定性直接决定集群能不能起来。以Ubuntu 20.04为例，推荐直接从Docker官方仓库安装并锁定版本：

apt-get update apt-get install -y ca-certificates curl gnupg install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | tee /etc/apt/sources.list.d/docker.list > /dev/null apt-get update apt-get install -y docker-ce=5:20.10.24~3-0~ubuntu-focal docker-ce-cli containerd.io apt-mark hold docker-ce docker-ce-cli containerd.io systemctl enable --now docker

为什么一定要apt-mark hold？生产环境最防不胜防的就是某个例行升级把docker daemon版本悄悄改了，RKE不兼容新版本，集群出现一堆异常。我在早期维护一套环境时吃过这个亏，升级完docker，整组节点被Kubelet标记为NotReady，事后才意识到是版本漂移。

除了版本，还要注意节点用户权限。RKE通过配置里指定的user登录节点执行docker命令，如果这个用户不是root，需要把它加入docker组，否则rke up会报权限错误。

3.3 etcd磁盘：IO敏感，别省这块

etcd是Rancher管理集群最核心的存储，Rancher的配置、用户、集群注册信息最终都落在etcd里。它每次写入都要落盘，而且对延迟极其敏感，一条毫秒级的写请求排队都可能拖慢整个控制面。生产环境强烈建议把etcd的数据目录放到独立SSD数据盘上。RKE默认会把etcd数据放在宿主机的/var/lib/etcd目录，所以至少这个目录要承载在SSD盘上，不要在机械盘上尝试跑生产环境，性能差距在故障场景下会被放大得很明显。

我自己的标准是：控制面节点配一块数据盘，单独挂载到/var/lib/etcd，文件系统用ext4或xfs。硬件条件有限时，至少保证etcd目录不要和系统盘、Docker数据目录混用。否则一旦日志把系统盘写满，etcd会先跟着出问题——这个后面故障复盘时还会再提到。

3.4 时间同步：etcd的隐形依赖

很多Kubernetes问题排查到最后都会发现，根因其实是时钟漂移。etcd对节点间时间偏移极其敏感，时间差距一旦超过阈值，就会导致心跳乱序、leader频繁切换，最终表现为整个集群间歇性不可用。所以三台节点在初始化时就要统一配置chrony，指向企业内网NTP源。配置好之后一定要当场验证，我习惯执行timedatectl status查看系统时间，再执行chronyc sources确认同步源的状态和延迟。这一步看似简单，但漏掉的后果往往要等出故障时才暴露出来。之前有一回某台虚拟机重启后chrony服务没起来，时钟慢了两分钟，etcd的选举日志刷了一整屏，排查了一晚上才定位到时间问题。

3.5 部署机的准备工作

RKE是从部署机的角度发起操作的，所以部署机只需要安装rke、kubectl和helm三个工具，并保存三台节点的SSH私钥。强烈建议不要用root登录节点，而是创建一个专门的运维用户，把公钥部署到三台节点的~/.ssh/authorized_keys里。这样RKE配置里指定user为这个运维用户即可，安全性和可维护性都会好很多。

部署机上最好也固定工具版本，我习惯把rke、kubectl版本写在环境登记表里。这里再提醒一次：rke工具不是越新越好，它的版本要和目标Rancher版本、目标Kubernetes版本匹配。版本错配是rke up阶段最常见的失败原因之一。

4. 三节点Rancher集群的RKE部署实录：cluster.yml与rke up

4.1 一份可复用的cluster.yml

在部署机上创建目录，比如/opt/rancher-ops，把SSH私钥放进去，然后写cluster.yml。三节点全角色的一套配置文件大致长这样：

nodes: - address: 10.10.20.11 hostname_override: rke-node-1 user: ops role: [controlplane, etcd, worker] ssh_key_path: /opt/rancher-ops/id_rsa - address: 10.10.20.12 hostname_override: rke-node-2 user: ops role: [controlplane, etcd, worker] ssh_key_path: /opt/rancher-ops/id_rsa - address: 10.10.20.13 hostname_override: rke-node-3 user: ops role: [controlplane, etcd, worker] ssh_key_path: /opt/rancher-ops/id_rsa services: etcd: snapshot: true creation: 6h retention: 6h backup_config: interval_hours: 12 retention: 3 kube-api: service_node_port_range: 30000-32767 kubelet: extra_args: max-pods: "200" ingress: provider: nginx

hostname_override是很有用的字段。如果节点本身主机名不规范，或者有多张网卡导致地址选择混乱，可以直接在这里强制指定。address是RKE用来SSH的地址，如果节点有内网外网多张网卡，还要加internal_address字段，让集群内部组件走内网通信，避免流量绕公网。

services.etcd里的snapshot、creation和retention，控制的是etcd自动快照的生成与保留。我习惯把自动快照间隔设为6小时、保留6份；另外再用backup_config做一层更稳妥的定期备份，间隔12小时、保留3份。注意：快照目录默认在/var/lib/etcd/snapshots，千万别把它和etcd数据放在同一个物理磁盘上，否则磁盘一坏就全没了。

4.2 为什么角色要三件套全给

可能会有同学问，controlplane节点为什么还要带worker？其实对一套管理型集群来说，Rancher自身的Pod数量不算多，三节点全角色完全可以承载。而且这样的部署形态最简洁：任何一台节点宕机，其余两台仍能保证etcd仲裁和API可用，Rancher的Pod也能在其它节点重新调度起来。如果纳管集群规模很大，或者要在管理集群上额外跑监控、日志组件，再拆出独立worker节点也不迟。

4.3 拨动rke up，第一次耗时最长

配置写好后，执行：

cd /opt/rancher-ops rke up --config cluster.yml

第一次rke up会拉取一堆镜像：kube-apiserver、etcd、nginx-ingress、metrics-server、coredns等。网络环境一般的话，这一步可能拖很久。解决办法是在Docker daemon配置里设置镜像加速源（registry mirror），并把镜像预拉到三台节点上。注意镜像下载慢的时候不要反复按Ctrl+C重启，rke的状态文件会残留，最好是等日志明确报错后再处理。

如果一切顺利，结束后当前目录会生成kube_config_cluster.yml和cluster.rkestate。用kubeconfig验证：

kubectl --kubeconfig kube_config_cluster.yml get nodes

三台节点都是Ready状态，说明RKE这一步已经完成。

4.4 立刻备份三样东西，少一样都危险

rke up完成后，部署机上最宝贵的三个产物是：cluster.yml、kube_config_cluster.yml、cluster.rkestate。其中cluster.rkestate尤其重要，它记录了集群当前完整状态。没有它，后续执行etcd恢复、节点替换、集群更新时，rke无法识别现有集群，等于钥匙丢了。

我会把这三个文件加上etcd快照，一起打包加密后放到灾备目录。任何一次变更操作之前，都要重新备份一次cluster.rkestate。这个习惯在恢复演练和故障处置时价值巨大。

4.5 RKE阶段常见失败点

RKE阶段我遇到过的失败，主要集中在三类：一是SSH连通性，密钥权限太高或者用户不在docker组；二是镜像拉取超时；三是节点之间网络端口没放行，特别是etcd端口。排查时不要盯着rke日志最后几行无脑重试，先用ssh、nc、openssl s_client这类工具逐层确认，再回到rke up。

5. 负载均衡与VIP：HAProxy + Keepalived 的落地细节

5.1 前置判断：什么时候可以跳过这一节

如果企业已经买了商业负载均衡或云上NLB，Rancher架构可以简化：直接把NLB后端指向三台节点的443端口，DNS解析到NLB即可，后面关于HAProxy的配置都可以跳过，只要保证健康检查指向的是TCP 443而不是节点管理地址。如果机房是自建物理机或云主机，没有统一的LB服务，那么HAProxy加Keepalived就是性价比最高的组合。下面写的是自建LB场景，采用四层转发方案，思路和云上NLB完全一致，理解后很容易迁移。

5.2 HAProxy只做四层透传，TLS证书交给Ingress

这里有个关键的架构决策：HAProxy用mode tcp，而不是mode http。原因在于Rancher入口的TLS证书已经有了，证书由节点上的Nginx Ingress统一终结。如果HAProxy做七层反代，就必须在LB上再维护一份证书，而且要把证书配置、续期流程在LB上重复一遍，完全没有必要。

四层转发的好处是简单、稳定、天然支持WebSocket长连接。Rancher UI里终端、日志等实时功能都依赖WebSocket，四层模式下连接直接透传，不用额外调超时。

global log /dev/log local0 maxconn 4096 defaults log global mode tcp retries 3 timeout connect 5s timeout client 60s timeout server 60s frontend rancher_frontend bind *:80 bind *:443 default_backend rancher_backend backend rancher_backend balance roundrobin option tcp-check tcp-check connect port 443 server rke-node-1 10.10.20.11:443 check inter 3s fall 3 rise 2 server rke-node-2 10.10.20.12:443 check inter 3s fall 3 rise 2 server rke-node-3 10.10.20.13:443 check inter 3s fall 3 rise 2

tcp-check是用来做后端健康检查的，它每3秒尝试和节点443端口建立TCP连接，连续失败3次把节点标记为DOWN，连续成功2次标记为UP。这样的健康检查比单纯ping节点IP要可靠得多，它能直接反映出Ingress层面的接收能力。

5.3 Keepalived：让VIP在故障时自动漂移

两台LB上分别安装keepalived，一个MASTER一个BACKUP。配置核心如下：

vrrp_script check_haproxy { script "/usr/bin/killall -0 haproxy" interval 2 weight -2 } vrrp_instance VI_RANCHER { state MASTER # BACKUP机器上写 BACKUP interface eth0 virtual_router_id 55 priority 150 # BACKUP机器写 120 advert_int 1 virtual_ipaddress { 10.10.20.100/24 dev eth0 } track_script { check_haproxy } }

track_script是灵魂。它每2秒检查一次本机haproxy进程是否存活，如果进程挂了，权重自动降低，VIP会立刻漂移到另一台LB。这样即使haproxy卡死或崩溃，入口流量也不会断在单一节点上。

有个容易被忽略的细节：如果交换机启用了组播限制，VRRP广播报文会被丢弃，导致两台LB都认为自己是MASTER，VIP冲突。此时要在配置里加上unicast_peer，把对端的真实IP明确告诉keepalived，用单播方式通告心跳。

5.4 上生产前的验证动作

配置完成后，按这个顺序验证：第一，ip addr show eth0确认VIP在主LB上；第二，从办公网访问https://rancher.example.com，确认证书和页面正常；第三，故意停掉主LB的haproxy进程，观察VIP是否在几秒内漂移到BACKUP，再恢复主LB状态。我每次都会把这个故障演练记录下来，作为生产环境运维档案的一部分。

6. Helm安装Rancher Server：证书、Secret和关键参数

6.1 证书是前置条件，别等装完再想

在Helm安装Rancher之前，就得先把证书准备好。生产环境推荐使用企业内部CA签发的证书，SAN里必须包含Rancher访问域名rancher.example.com，最好再把VIP加上。证书有效期建议直接申请三年，同时定好到期续期流程。没有内部CA体系的，也可以用公有信任的自动签发证书，但要注意这类证书有效期短，续期自动化要提前配好。

6.2 先创建两个Secret，这是最常见的坑

Rancher需要两个Secret。第一个是Ingress使用的证书密钥，第二个是内网CA的根证书。操作如下：

kubectl create ns cattle-system kubectl -n cattle-system create secret tls tls-rancher-ingress \ --cert=fullchain.pem \ --key=private.key kubectl -n cattle-system create secret generic tls-ca \ --from-file=cacerts.pem=internal-ca.pem

很多人第一次装Rancher只创建了tls-rancher-ingress，忘了tls-ca，结果装完以后Rancher内部的webhook、审计、集群代理组件互相不信任，界面能打开，但操作经常报奇怪的TLS错误。tls-ca这个Secret的作用，就是让Rancher内部组件能够验证由内网CA签发的证书。

6.3 Helm安装命令与参数解释

用Helm 3安装Rancher官方chart：

helm repo add rancher-stable https://releases.rancher.com/server-chart/stable helm repo update helm upgrade --install rancher rancher-stable/rancher \ --namespace cattle-system --create-namespace \ --set hostname=rancher.example.com \ --set replicas=3 \ --set ingress.tls.source=secret \ --set privateCA=true \ --set bootstrapPassword='YourStrongPassw0rd!'

逐个说明：hostname是访问域名，必须和证书SAN一致；replicas设成3，对应三个节点上跑3个Rancher副本；ingress.tls.source=secret表示证书来自前面创建的secret，而不是cert-manager自动签发；privateCA=true配合tls-ca secret使用；bootstrapPassword是首次登录时需要使用的管理员临时密码。部署完成后可以用如下命令跟踪状态：

kubectl -n cattle-system rollout status deployment/rancher kubectl -n cattle-system get pods

6.4 首次访问与初始化

浏览器打开https://rancher.example.com，使用bootstrapPassword登录，系统会要求设置新的admin密码。之后进入主界面，Rancher会自动把当前集群登记为local集群。到这里，Rancher Server本身已经高可用：三个Pod副本、三个etcd节点、两套LB和VIP在前面承接流量。我习惯把首次登录后的页面截图存进环境档案，作为交付证据和后续对比基准。

有一点要特别说明：Rancher应用本身不依赖持久化卷，它的所有状态都存在K8s的etcd和secret中。所以Pod哪怕全部被删掉，也能重新拉起并恢复状态。这也是为什么前面反复强调etcd备份的重要性——Rancher高可用的本质，其实就是这套底层Kubernetes集群的高可用。

7. 生产上线前的验证清单与日常运维基线

7.1 全链路检查清单

新环境交付给业务方之前，我会按下面这张清单过一遍：

这个清单每次上线都要走一遍，别觉得重复。生产事故里相当一部分，就是上线前少查了一两项，导致域名、证书、VIP、后端这些环节埋了雷。

7.2 备份：etcd快照、Rancher备份和恢复演练

RKE阶段已经在cluster.yml里配置了etcd自动快照，手动备份则用：

rke etcd snapshot-save --name manual-backup-202501 --config cluster.yml

快照文件会落到节点的/var/lib/etcd/snapshots目录。光有快照还不够，我建议再装一套Rancher Backup Chart，它可以备份Rancher的CRD和全局配置，把备份文件推到对象存储或NFS上。etcd快照和Rancher备份配合使用，才能保证完整恢复。

恢复演练必须真的做过一次。我会准备一套临时环境，按照备份恢复手顺把数据还原，验证登录、下游集群列表、权限菜单都还在。如果演练都没做，所谓高可用也就是个纸面方案。

7.3 升级顺序：先K8s，再Rancher

Rancher升级有一个雷打不动的顺序：先升级底层Kubernetes集群，再升级Rancher chart。底层K8s升级用rke up --update-only，RKE会按照cluster.yml里指定的版本增量更新。升级前看官方兼容矩阵，确认RKE版本、K8s版本和Rancher版本三者匹配。

我见过不少团队图省事，直接helm upgrade把Rancher升到新大版本，结果底层的RKE/K8s版本太老，一堆API兼容问题冒出来。运维老手的原则是：小版本谨慎升，大版本先看release notes再动手。

7.4 巡检节奏与告警

生产环境跑起来之后，巡检不靠人肉，要变成自动化任务。我维护这套环境时，至少会配置以下告警：VIP端口拨测失败、haproxy进程挂掉、任一节点磁盘使用率超过80%、etcd leader频繁切换、证书剩余天数低于30天。每季度做一次LB故障切换演练，每半年做一次完整恢复演练。这些动作写进运维日历，比出事后再熬夜救火划算得多。

8. 故障复盘：生产里真实翻过的车

8.1 案例一：证书过期，全站UI直接不可用

管理集群上线大概第11个月，某天早上业务方反馈Rancher页面打不开。我第一时间用curl -v访问域名，发现TLS握手直接失败，再看证书截止日期，正好过期两天。整个链路排查很顺利，因为现象太典型了。

修复步骤分三步：第一步，从内部CA重新申请证书，SAN保持不变；第二步，更新Ingress的Secret；第三步，重新加载Ingress Controller。具体命令如下：

kubectl -n cattle-system create secret tls tls-rancher-ingress \ --cert=fullchain.pem --key=private.key \ --dry-run=client -o yaml | kubectl apply -f - kubectl -n cattle-system delete pods -l app=rancher --force --grace-period=0

删Pod是为了让Ingress和Rancher重新加载证书。这个案例的教训有两点：一是证书到期告警必须提前配，不要依赖人的记忆；二是证书内容要保证完整链，很多中间证书缺失的情况浏览器报错信息会很怪，容易误导排查方向。

8.2 案例二：系统盘写满，etcd跟着遭殃

另一套环境出现过一次"全集群NotReady"事故。当时是凌晨，监控先弹出一台节点磁盘使用率99%，接着集群节点陆续进入NotReady。排查链路是：kubectl get nodes看到异常，ssh进节点df -h显示根分区已满，du逐层定位发现是Docker容器日志和etcd自动快照堆满了系统盘。

临时处理是清掉过期的快照文件和日志，再把自动快照的保留份数调小。根治方案是把数据盘重新规划，让/var/lib/etcd和/var/lib/docker都落在独立大容量盘上，系统盘只放操作系统。这个案例说明一个道理：高可用架构的脆弱点，往往不在组件数量，而在那些没有容量基线的目录。

8.3 案例三：HAProxy健康检查把所有节点标红

还有一次，HAProxy的后端全部显示DOWN，VIP却是通的，页面访问超时。按这个现象逐层排查：先看haproxy日志，发现TCP连接超时；再在LB上手动nc到节点443端口，端口拒绝；进节点检查发现是安全组规则变更把LB到节点的TCP 443拦截了。把规则恢复后的第二天，又碰上健康检查的3秒间隔和防火墙conntrack会话超时时间不一致，导致节点被间歇标记DOWN。调整tcp-check间隔后恢复正常。

这个案例想说的是：四层健康检查只能证明TCP端口通，链路里任何一个防火墙、安全组、conntrack参数都可能成为隐藏故障源。排查时不要被"端口不通"这个表象牵着走，要沿着链路把每一跳都验证一遍。

8.4 我把这些教训沉淀成了一条自查顺序

在这些故障之后，我手头Rancher环境每次出问题，都按固定顺序自查：一看证书有效期，二看VIP和LB后端状态，三看磁盘容量，四看etcd健康，五看Kubernetes节点状态。这个顺序基本覆盖了Rancher生产环境80%以上的故障面。做完再下结论，不要一上来就重装Rancher，那种做法只会加重问题。

个人体会：Rancher高可用搭建本身并不难，真正难的是把它当作一台精密仪器来看待。前期每多一点规划、每一次故障演练，都在降低未来凌晨被电话叫醒的概率。如果你现在刚开始搭建，不要急着把页面跑起来就庆祝，先按上面的检查和备份基线过一遍，再决定是否交付生产。