REECHO大鱼总舵1. 从 kubeadm 到 Rancher：为什么我建议你尽早给集群加个“图形驾驶舱”
这个系列写到第五篇，前面几篇一直在用 kubeadm 手动搭集群、加节点、配网络插件，每一步都能让你对 Kubernetes 各组件的工作方式建立起直接体感。但把集群真正跑起来之后，你会发现一个很现实的问题：生产环境里如果每次查看 Workload 都要敲一串 kubectl 命令，十几个同事共用一个集群时权限和审计又该怎么管？这时候就该把 Rancher 请出来了。
Rancher 的价值不是“Kubernetes 的替代品”，而是 Kubernetes 的图形化管理层。它本身也是跑在 Kubernetes 上的一套应用，通过 agent 方式纳管一个或多个下游集群。你可以用它完成集群的创建、导入、升级、监控、RBAC 授权、应用商店部署，甚至可以直接在 UI 上编辑 Deployment YAML。对于刚入门 Kubernetes 的朋友来说，Rancher 还有一层额外价值：它把概念具象化了。你会在界面上直观看到 Namespace、ConfigMap、Service、Ingress 之间的关联，这对理解 Pod 反而很有帮助。
这篇文章会分成两条主线：前半部分讲 Rancher 的实际部署，以及如何把之前用 kubeadm 建好的集群导入进去；后半部分重点拆解 Pod——它是 Kubernetes 调度的最小单元，也是你在 Rancher 界面上最常见的“物件”。两条线会在一处汇合：当你用 Rancher 点击“创建 Deployment”时，背后到底发生了什么？我们从这里切入。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Rancher 部署实操：单机模式其实够用，别一上来就上 HA
2.1 部署前需要确认的三件事
第一件事：版本兼容性。Rancher 和 Kubernetes 的版本之间有多数时候存在一个匹配窗口。我这次实验环境用的是 Kubernetes v1.26.0，对应 Rancher 2.7.x 和 2.8.x 均能正常工作，建议部署前到官方支持矩阵里核对一下，避免出现 agent 连接不稳定这类玄学问题。第二件事：主机资源。单机部署 Rancher 至少需要 2 核 CPU、4 GB 内存，磁盘留 20 GB 以上。如果笔记本的资源紧张，跑起来会非常卡，UI 加载都要等很久。第三件事：端口规划。Rancher 默认使用 80 和 443 端口，如果你的服务器上已经有 Nginx 或其他 Web 服务占用了这两个端口，需要提前规划，否则启动后会发现端口冲突导致 Rancher 容器反复重启。
这里补充一个容易忽略的点：Rancher 有两种形态，一是单节点 Docker 部署，二是在 Kubernetes 集群上以 Helm Chart 方式部署的 HA 形态。学习阶段我只推荐前者，一条 docker run 命令就能搞定；生产环境再接 HA。不要一上来就想着搭三节点的 Rancher 管理集群——如果连下游 Kubernetes 集群本身还不熟悉，再多一层 Rancher 管理集群只会让排查问题时的链路更长。
2.2 启动命令：数据卷和端口是关键
单机部署 Rancher 的命令非常简洁：
bash复制sudo docker run -d --name rancher-server \
--restart=unless-stopped \
-p 80:80 -p 443:443 \
-v /opt/rancher:/var/lib/rancher \
rancher/rancher:latest
我来逐个解释这几个参数的意思，因为很多人照着文档敲完就忘了，一旦出问题不知道怎么排查。
-p 80:80 -p 443:443 是端口映射。Rancher 的 UI 和 API 都通过 443 提供 HTTPS 访问，80 则是为了 HTTP 自动重定向以及后续配置 Let's Encrypt 证书时用的。这里的映射是容器端口映射到宿主机端口，如果你想用其他外部端口访问，比如改成 -p 8080:443，那么在初始化时填入的 server URL 也要对应调整，否则导入集群后，下游集群里的 agent 无法回调到 Rancher Server，节点状态会一直卡在 Waiting 或 Unhealthy。
-v /opt/rancher:/var/lib/rancher 是数据卷挂载。这一行绝对不能省，否则容器一旦删除或升级，你配置过的管理员密码、导入的集群信息、证书文件全部丢失。我之前碰到过一位同事，Rancher 容器跑了一个月后意外被清掉，恢复时发现所有下游集群都要重新导入，非常被动。所以数据目录一定要挂到宿主机上，并且建议把 /opt/rancher 目录加入每天的备份计划。
2.3 证书方案：临时证书适合学习，生产环境建议自建 CA
Rancher 首次启动时如果没有提供证书，会自动生成一个自签名的临时证书。访问 https://服务器IP 时浏览器会报警告，点过去就能看到初始化页面。这种模式适合学习和测试，但有两个隐患：一是证书有效期只有 90 天左右，到期后 Rancher 会自动轮换，如果续期失败或者你对证书做过替换，容易出各种奇怪问题；二是浏览器报警本身就会吓退团队里的非技术人员，无形中增加沟通成本。
生产环境我建议准备一个正式域名，并将域名解析到 Rancher 服务器 IP，然后在启动时传入自己的证书。命令可以这样写：
bash复制sudo docker run -d --name rancher-server \
--restart=unless-stopped \
-p 80:80 -p 443:443 \
-v /opt/rancher:/var/lib/rancher \
-v /etc/rancher-certs:/etc/rancher/certs \
-e CATTLE_BOOTSTRAP_PASSWORD=your-secure-bootstrap-pass \
rancher/rancher:latest \
--cert-file /etc/rancher/certs/tls.crt \
--key-file /etc/rancher/certs/tls.key
其中 CATTLE_BOOTSTRAP_PASSWORD 是 Rancher 2.6 之后引入的初始密码变量，设置后首次打开登录页时不需要再到容器日志里翻随机生成的 bootstrap 密码。这个变量只在首次初始化时生效，之后管理员密码以你实际登录后设置的为准。
2.4 初始化流程：server URL 一旦填错，后面都是坑
打开 https://服务器IP，Rancher 会引导你设置管理员密码和 server URL。这个 server URL 必须是下游集群的 agent 能够访问到的地址。如果你是在内网环境使用，就填内网 IP；如果之后要从公网管理集群，就需要填公网 IP 或域名。关键经验是：这个地址尽量一次填对，因为它会写进下游集群的 cluster agent 配置里，后期再改需要手动编辑 cattle-cluster-agent 的 Deployment，过程比较绕。
初始化完成后，Rancher 会创建一个本地管理集群，官方叫 local cluster。这个 local 集群其实就是 Rancher 单机部署时内部的 Kubernetes 集群，注意不要在它的默认 Namespace 里随便部署业务应用，至少在深入学习阶段不要这么干，否则容易把管理平面掩盖掉。
3. 把 kubeadm 创建的集群导入 Rancher，完成关联管理
3.1 导入集群与 Rancher 新建集群的区别
在 Rancher 里创建集群有两种路径：一是从零新建，Rancher 会帮你调用云厂商 API 或直接在一批节点上执行初始化，适合还没建集群的场景；二是导入已有集群，Rancher 生成一个 Kubernetes manifest，你在目标集群上执行 kubectl apply，之后 Rancher 通过 Deployment 方式往目标集群里部署 agent 组件，建立连接。
我们的场景是导入。因为前面几篇已经用 kubeadm 把 Kubernetes v1.26.0 集群建好了，没有理由推倒重来。导入的优势很明显：不会动你现有的 Pod 和节点，只是在集群里增加 Rancher 的 agent。切换成本极低，万一不想要了，删掉对应 Namespace 里的资源就能还原。
3.2 在 UI 上获取导入命令并在目标集群执行
操作步骤分三步：
- 在 Rancher UI 左上角点击“添加集群”，在页面顶部选择“已有集群”。
- 输入集群名称，比如 use-k8s-lab，然后点击“创建”。
- 页面会弹出一段命令，类似
kubectl apply -f https://<rancher-server>/v3/import/xxxxx.yaml。复制它，在 kubeadm 建好的集群控制节点上执行即可。
执行完后，Rancher 会在目标集群中创建 cattle-system 等 Namespace，并启动 cattle-cluster-agent、cattle-node-agent 等组件。可以用以下命令观察：
bash复制kubectl -n cattle-system get pods
正常情况下 agent Pod 会进入 Running，随后 Rancher UI 里集群状态从 Provisioning 变为 Active。从点击到 Active 一般需要两到三分钟，如果超过五分钟还没好，优先检查 Rancher 服务器地址是否被下游集群访问，以及两台机器之间的网络策略是否放行了 443 端口。
3.3 导入后发现节点状态异常怎么处理
常见的异常有两种。一种是节点显示状态为 Unavailable，这大概率是 cattle-node-agent 没有正常启动。在目标集群上执行 kubectl -n cattle-system logs <cattle-node-agent-pod>，日志里如果出现连接超时，就确认一下 Rancher server URL 是否使用了下游节点无法解析的域名，或者检查防火墙是否只允许了控制平面访问 Rancher 而屏蔽了工作节点。
另一种是导入后克隆节点去重失败，节点名称在 Rancher UI 里显示正常但资源不可调度。这种情况多数是因为 kubeadm 集群里的节点标签或污点比较特殊，Rancher 的控制逻辑需要适配。我的建议是先在裸 kubectl 环境下用 kubectl describe node 把节点状态理顺，再回 Rancher 界面查看同步结果——Rancher 毕竟只是管理平面，节点底层异常它解决不了，但可以快速暴露出来。
4. Pod 不是“一组容器”这么简单：为什么 Kubernetes 非要加这一层
4.1 Pod 与容器：共享网络命名空间和存储卷
在 Docker 时代，我们习惯用一个容器承载一个应用进程，但 Kubernetes 把调度的最小单元从容器拔高到了 Pod。为什么？因为很多业务场景中，多个进程必须“住在同一间房子里”：共享同一个 localhost、共享同一份临时文件、共享相同的网络身份。
一个 Pod 内的所有容器共享同一个网络命名空间，意味着它们共用同一个 IP、端口空间和 Loopback 接口。容器 A 监听 8080 端口，容器 B 如果想访问它，直接访问 localhost:8080 就可以，不需要知道 Pod IP。这种共享关系最初源于 Kubernetes 底层的 pause 容器设计：每个 Pod 有一个基础容器先占住网络命名空间，业务容器加进来时共享它。
同时 Pod 里的容器还可以挂载同一个 Volume。你可以在 Pod 级别声明一个 emptyDir 卷，所有容器都能读写。典型场景是应用容器把日志写到 /var/log/app，同 Pod 里的日志采集容器从同一个目录读取。这一点在 Rancher UI 里同样适用：创建 Workload 时可以加多个容器，它们的存储挂载可以互相引用。
4.2 Sidecar 模式的典型场景
由 Pod 共享网络和存储带来的是一种非常常见的组网模式：Sidecar。我举两个实际例子，你在 v1.26 集群上都会用到。
第一个是日志收集：主容器是一个 Nginx，Sidecar 容器是 fluent-bit，两者挂载同一个 emptyDir 路径。Nginx 把 access log 写入 /var/log/nginx/access.log，fluent-bit 从这个路径读取并发送到 Elasticsearch 或 Kafka。它的好处是日志采集逻辑与应用容器完全隔离，升级采集器不需要重启业务。
第二个是反向代理或流量劫持：主容器是一个 Java 服务，监听 8080，Sidecar 是 Envoy，监听 8443。Pod 对外暴露的端口是 8443，外部流量先进 Envoy 再到 Java，过程对业务无感。你可以在 Rancher 的 Workload 视图中直观看到这两个容器同属于一个 Pod，它们共享 Pod IP，因此 Service 只需要指向 8443 即可。
4.3 设计 Pod 的三个常见误区
第一个误区：把“一个 Pod 装多个业务容器”当成类似 Docker Compose 的多服务组装。这是很多从 Docker 转 K8s 的人最容易踩的点。Pod 内的容器被调度和生命周期绑定，要么一起启动、一起终止；如果其中一个容器反复崩溃会导致整个 Pod 按策略重启。所以只有那些“唇齿相依”的进程才应该放进同一个 Pod，各司其职、可以独立扩展的业务模块一定拆成多个 Deployment。
第二个误区：在 Pod 里跑两个容器时忽略了端口冲突。因为同一 Pod 内共享网络命名空间，两个容器监听同一端口会直接冲突。我就见过有人把 Nginx 和 Nginx Ingress 硬凑到一个 Pod 里，启动后其中一个容器一直 CrashLoopBackOff。排查起来虽然不难，但完全可以靠设计规避。
第三个误区：把 Pod 当成永久运行的虚拟机，试图在容器里安装 systemd、SSH Daemon 等。Kubernetes 的容器生命周期设计是“一个容器一个主进程”，主进程退出容器就终止。保持容器的单一职责，Pod 才能被 Kubernetes 更好地掌控——无论是优雅终止还是自动重启。
5. 完整生命周期与探针：从 Pending 到 Running 再到终止
5.1 状态流转：Pending、Running、Succeeded/Failed、Unknown
用 kubectl get pods -w 或者 Rancher 的 Workload 列表，你会看到几个反复出现的关键字：Pending、Running、Succeeded、Failed、Unknown。这些是 Pod 级别的 Phase，描述的是 Pod 整体的阶段性处于哪种位置。
- Pending：Pod 已被 API Server 接受，但尚未完成调度，或者镜像正在拉取。
- Running：Pod 已经绑定到某节点，至少一个容器在运行。
- Succeeded：Pod 里的所有容器都正常退出，不会重启，常用于一次性任务 Job。
- Failed：Pod 里有容器以非零退出码退出，且不会重启。
- Unknown：API Server 无法获取 Pod 状态，通常意味着节点失联或 kubelet 出现问题。
很多人把 Running 等同于“健康”，这是不对的。Running 只代表容器进程还活着，业务是否真的可用要看两种更细的信息：容器的 Ready 状态和探针检查结果。例如 Deployment 的滚动更新是否继续，主要看新 Pod 是否 Ready，而这个 Ready 可以在部署 YAML 里由 readinessProbe 自定义。如果你没有配置探针，容器主进程启动后，Kubernetes 就会认为它准备好了，这在流量接入比较早的场景下容易造成请求 502。
5.2 探针配置：startupProbe、livenessProbe、readinessProbe
探针是 Pod 生命周期里最实用的机制之一，在 Rancher UI 创建 Workload 时也可以在高级选项里配置。我要特别强调三者分工，很多人把 liveness 和 readiness 搞混，导致应用启动顺序错乱。
- livenessProbe：决定容器要不要被重启。失败达到阈值，kubelet 会杀死容器并按照 restartPolicy 处理，通常用于检测死锁、内存泄漏这类“进程还活着但已经不干活”的情况。
- readinessProbe：决定容器的 Service 端点是否参与流量转发。失败时 Pod 不会重启，但会把该 Pod 从 Endpoint 列表中剔除，用于优雅处理启动慢、依赖外部组件尚未就绪等情况。
- startupProbe：解决启动速度慢的容器被 livenessProbe 误杀的问题。它先运行，成功了才轮到 livenessProbe 阶段。Java 应用初始化堆内存大、启动要一两分钟，极其需要这个探针。
下面是一个典型的 Deployment 片段，Nginx 容器在 8080 端口提供 /healthz 接口，启动探针给了 60 秒缓冲，存活和就绪都采用 HTTP 探测：
yaml复制containers:
- name: web
image: nginx:1.25
ports:
- containerPort: 8080
startupProbe:
httpGet:
path: /healthz
port: 8080
periodSeconds: 5
failureThreshold: 12
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
timeoutSeconds: 3
readinessProbe:
httpGet:
path: /healthz
port: 8080
periodSeconds: 5
这段配置的意图是：启动探针每 5 秒探测一次，最多允许失败 12 次，即给足 60 秒的启动窗口；窗口通过后才启用 liveness 和 readiness。readiness 每 5 秒检查一次，一旦后端服务不可用，流量立刻摘走；liveness 每 10 秒检查一次，连续失败超过阈值就会重启容器。
5.3 Init 容器：跑通主容器前的准备工作
Pod 里除了常规容器，还可以定义一组 initContainer。它们按照顺序逐个执行，全部成功退出后，业务容器才会启动。如果中途某个 init 容器失败，Kubernetes 会重启整个 Pod，重新从第一个 init 容器开始跑。
我用得最多的场景是等待依赖服务就绪。比如一个应用启动前需要数据库里有初始化表结构，你可以把建表脚本放进 init 容器里执行，而不是把建表步骤塞进应用启动流程。另一种常见场景是文件权限修正：某些镜像默认以非 root 运行，但对挂载卷没有写权限，用一个 init 容器以 root 身份调整目录权限是常规解法。
这里必须提醒一点：v1.26 版本中 init 容器不支持 readinessProbe 和 livenessProbe——它的生命周期被设计为串行简化版，成功继续、失败重来。所以不要在 init 容器里放需要长时间运行的服务或者无限循环等待的脚本，尽量让 init 范围保持小且可控。如果必须做复杂依赖等待，主容器里的探针加上 restartPolicy 的设计会更合适。
6. 资源限制与调度：为什么你的 Pod 迟迟调度不到某个节点
6.1 requests 和 limits 怎么设置才合理
Pod 调度器在决定把 Pod 放到哪个节点时，参考的是 requests，而不是 limits。kubelet 把这些 requests 汇总后与节点可分配资源做比较，只有请求总量小于节点约束才会调度上去。CPU 和内存的单位要格外注意：CPU 的 100m 表示 0.1 核，2000m 才是完整 2 核；内存的 Mi、Gi 是 1024 进制，M、G 则是 1000 进制，在 YAML 里写错会导致预期的 2 GB 实际上变成约 1907 MiB 的换算误差，虽然不算大，但在资源紧张时会影响判断。
看一个实际的配置片段：
yaml复制resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512Mi
这个 Pod 调度时计入 100m CPU 和 128Mi 内存，运行时最多可以跑到 500m CPU 和 512Mi 内存。CPU 是压缩资源，limit 超额时只是被限制调度份额，不会杀容器；但内存是非压缩资源，一旦超过 limit，容器会被 OOM Killer 干掉。所以内存的 limit 设置一定要高于业务实际峰值，给足够的余量，我一般会按压测峰值的 1.5 倍预留。
为了配置“合理”而不是“想当然”，我的建议是给主要业务压测打点，用 Prometheus 或 Rancher 自带的监控看一周的 CPU 使用率 P99，再据此定 requests；limits 则基于压测峰值向上浮动。不要一上来就照着某个博客抄一个 500m/1Gi，业务差异太大了。
6.2 QoS 等级影响驱逐顺序
当节点资源压力过大时，kubelet 需要驱逐一些 Pod 以恢复稳定。Kubernetes 并不“公平”地随机踢人，它通过 QoS 等级决定谁先走：
- Guaranteed：所有容器同时设置了相等的 CPU requests/limits 和内存 requests/limits，优先级最高，最先守住。
- Burstable：至少有一个容器设置了 requests，但 requests 不等于 limits，优先级中等。
- BestEffort：Pod 里没有任何 requests 和 limits，优先级最低，压力一到就先被驱逐。
可以理解为：你向 Kubernetes 承诺的资源越明确、刹车线越紧，节点面对资源压力时就越愿意为你兜底。所以生产环境的敏感业务，建议设计成 Guaranteed 模式，也就是 requests 和 limits 填一样的值。对于可容忍重启的批处理任务，用 Burstable 即可，这样会大大降低资源浪费——因为从统计角度看，大多数 Pod 的实际使用率远低于 requests。
这个逻辑在 Rancher 的视图里同样能看得到：进入某个 Node 的资源图表，如果发现大量容器处于 BestEffort，且节点内存经常打满，那就需要考虑普遍加上 requests/limits，否则某个突发负载可能触发驱逐风暴，多个 Pod 同时被重启，服务瞬间雪崩。我去年就遇到过一次：工作节点的内存使用率到了 96%，BestEffort 的日志采集 Pod 被全部驱逐，部分 DaemonSet 依赖的 Filebeat 消失，导致当天日志链路断了几小时。
7. 我踩过的三个真实坑：证书过期、ConfigMap 引用和 preflight 检查
7.1 Rancher 证书过期后整个 UI 无法访问
Rancher 单机部署使用自签临时证书时，默认有效期为 90 天。到期之后最典型的症状是浏览器访问 https://服务器IP 时提示证书无效，点击继续后页面空白或登录接口返回 401。我第一次遇到时还以为是 Rancher 容器挂了，结果 docker ps 一看容器正常运行。
排查链路是这样的：先用 docker logs rancher-server 2>&1 | tail -100 看日志，通常会找到 certificate has expired 或 EOF 字样；接着进入容器检查证书实际的有效期，命令为 openssl x509 -in /var/lib/rancher/k3s/server/tls/localhost.crt -noout -dates。确认证书过期后，方案比较稳健的是备份数据目录并升级到支持证书轮换的版本，Rancher 2.7+ 的版本里旧证书会自动轮换；如果是老版本，可以参考官方文档执行一次就地恢复。重点实际上是预防：生产环境一定使用正式证书或受信任的内部 CA 签发的证书，不要再依赖 90 天临时证书来扛业务。很多坑不是多复杂，而是你决定“先凑合用”的那一刻就已经埋下了。
7.2 Pod 一直 CreateContainerConfigError，问题出在 ConfigMap 引用上
有一段时间我频繁遇到 Pod 状态停留在 CreateContainerConfigError，这个状态非常直白：容器还没启动，kubelet 在生成容器配置时失败了。Rancher UI 里显示的报错信息相对简短，我第一次看到时完全摸不着头脑，以为镜像拉取失败。
排查高效的路径是：kubectl describe pod <pod-name>，定位到 Events 底部，里面会明确写出类似 error converting YAML to JSON: yaml: line 55: mapping key "key" already defined 或者 configmap "app-config" not found。这两种错误基本覆盖了绝大多数情况——前者是 YAML 里重复定义了同一个字段，后者是引用了一个根本不存在的 ConfigMap 名字。
实际中更隐蔽的错误是 ConfigMap 存在，但 Pod 里 valueFrom.configMapKeyRef.key 指定的键不存在。比如我给应用配置了一个 app-config ConfigMap，里面有 DB_HOST 键，但 Deployment 里误写成 DB_HOSTNAME，Pod 状态也会变成 CreateContainerConfigError。排查时先 kubectl get configmap app-config -o yaml 核对所有键名，再检查 Deployment 的 envFrom 或 valueFrom 字段。这个坑和热搜词里的 pod configmap deploy 几乎是对应的：创建一个连接 Pod、ConfigMap 和 Deployment 的完整链路时，引用关系是最容易出错的地方。
7.3 kubeadm preflight 检查卡住，不是网络问题才叫人头疼
把集群版本升级到 v1.26.0 或新建集群执行 kubeadm init 时，日志里会出现 [init] using kubernetes version: v1.26.0 和 [preflight] running pre-flight checks。preflight 是把所有前置条件集中爆发的阶段，报错并不可怕，怕的是你以为自己配好了，但实际上校验项非常多。
我遇到的一个典型报错是主机名无法解析：preflight 要求当前机器能被自身主机名解析到，而测试服务器的 /etc/hosts 里没有写本机条目。解决办法很简单，把类似 192.168.1.21 node01 加到 /etc/hosts。另一个很常见的是 swap 未关闭，kubelet 会因此不能启动，需要临时或永久关闭 swap。如果你用的容器运行时是 containerd，还要确认它的 cgroup driver 与 kubelet 一致，否则 Kubelet 和 CRI 对资源统计的偏差会导致 Pod 启动后出现各种诡异行为。
我的建议是：解读 preflight 报错时只关注 [ERROR] 开头的行，而不是看整篇日志。这里最省时的做法是执行 kubeadm init --ignore-preflight-errors=Swap——但我不建议直接忽略，因为问题不会消失，后续 kubelet 依然会受影响。正确的操作是把所有 ERROR 项一个个改完，再重新执行 init，整个过程反而更快。
最后分享一个小习惯：无论是用 kubectl 还是 Rancher 操作集群，遇到 Pod 异常时先看 Events，再看容器日志，最后才去翻文档。Events 记录了 kubelet 和调度器对这个 Pod 做过什么判断，大部分问题的根因都会直接写在里面。这套思路在 Rancher 的 UI 里同样适用：点开 Workload，找到异常 Pod，先看“事件”标签页，往往比自己猜测强得多。