UOS上部署Rancher完整指南：从Docker安装到Kubernetes集群创建

上周在测试环境把一台UOS服务器收拾利索，从装系统开始到Rancher Server正常跑起来，再到通过Rancher在Web界面里拉出一个下游Kubernetes集群，整个过程没有重装系统、没有换发行版，完全靠系统本身的兼容层和常规配置项完成。这篇文章就是这次操作的完整记录，包含方案选型、环境准备、Docker安装、Rancher启动、集群创建，以及我在过程中踩到的坑和对应的排查思路。如果你手头正好有一批国产Linux环境需要跑容器管理平台，这篇可以直接照着一步步来。

我先把结论放前面：UOS上部署Rancher完全可行，但有几个基础条件不能省——系统源要能正常更新、Docker版本要和内核匹配、数据盘要单独规划好。只要这三件事做好，后面基本不会出大问题。

1. 部署前必看：方案选型与UOS环境认知

1.1 Rancher是什么，为什么要在UOS上部署

Rancher本质上是一个多集群Kubernetes管理平台，它干的事情可以理解成"管理K8s的K8s"：你通过Rancher的Web界面，可以创建、导入、删除多个Kubernetes集群，还能在上面做用户权限管理、项目隔离、应用商店部署、监控告警配置。对于团队里没有专职K8s运维人员的小团队来说，Rancher最大的价值是降低了K8s的入门门槛——很多操作不需要手写一大段YAML，点几次鼠标就能完成。

为什么要在UOS上部署？原因很实际：很多企业和单位正在逐步把内部系统迁移到国产Linux发行版上，但业务系统又离不开容器和K8s。UOS作为常见的国产Linux发行版之一，本身是一个相对成熟的Debian系系统，对容器生态的整体兼容性是比较好的。问题在于网上可参考的资料大多围绕CentOS或Ubuntu，UOS的踩坑经验散落在各个论坛里，不成体系。所以我这次的记录，就是把UOS上的部署路径完整验证一遍，给后来的人省点时间。

1.2 单节点还是高可用：两种部署形态怎么选

Rancher Server的部署形态主要分两种：单节点部署和高可用部署。

单节点部署是用Docker直接跑一个Rancher容器，所有数据写在宿主机的目录下。这种模式适合测试环境、小规模生产环境、或者暂时不想引入额外K8s集群运维成本的场景。优点很明显——架构简单、备份容易、升级就是"停容器、换镜像、再启动"三步。缺点是它本身没有故障转移能力，如果这台宿主机挂了，Rancher管理面也就不可用了。

高可用部署则是把Rancher Server本身跑在K3s或RKE2集群上，再前置一个负载均衡器。这种模式适合生产环境，具备故障转移能力，但需要至少三台节点，运维复杂度明显上升。我在UOS上做验证时选择的是单节点模式，原因很直接：先把流程打通，确认UOS与Rancher之间的兼容性没有问题之后，再考虑是否需要引入高可用架构。对于多数刚开始做容器平台替代的团队，第一步用单节点跑通是最稳妥的。

1.3 UOS到底兼容不兼容：先查好这几项再动手

在安装之前，有几个检查项建议你先确认好，避免装到一半才发现不兼容。

第一是系统版本。UOS有桌面版和服务器版之分，桌面版的内核和软件包与服务器版有一些差异。我在测试环境用的是UOS服务器版，内核版本在5.4以上，Docker运行得很稳定。如果是桌面版，建议先确认内核模块是否完整，部分桌面版的精简内核可能缺少overlay相关模块。

第二是架构类型。绝大多数UOS服务器版跑的是x86_64架构，但也有部分ARM架构的版本。Rancher对ARM架构有支持，但具体镜像标签不同，而且下游K8s节点如果是混合架构，会有一些兼容性问题。如果环境是ARM架构，建议先查清楚自己用的镜像是否支持该架构。

第三是内存和磁盘。Rancher Server单节点最低要求是4GB内存，但这只是"能跑"的低水位，实际体验下来建议8GB起步。磁盘方面，Rancher Server的数据目录会持续增长，系统盘至少预留50GB，最好单独挂一块数据盘。

一句话总结：UOS不是那种"装完就完事"的系统，基础环境的规范程度直接决定后面Rancher跑得稳不稳。下面就从系统准备开始一步步说。

2. 环境准备：把UOS系统调到"可部署"状态

2.1 系统基础配置：主机名、时区、静态IP

部署Rancher之前，先把系统的基本设置弄规整。这一步虽然简单，但后面K8s集群节点之间的通信、证书校验、日志时间排序都会依赖它。

首先是主机名，设置一个有意义的名字，不要用默认的localhost：

hostnamectl set-hostname rancher-server cat /etc/hosts

在/etc/hosts里把本机IP和主机名对应起来，避免某些组件通过主机名解析时卡住：

192.168.10.10 rancher-server

然后是时区，确保服务器时间和K8s节点、Rancher Server保持一致。K8s集群对时间敏感，如果节点间时间差超过一定阈值，etcd会报错甚至不可用：

timedatectl set-timezone Asia/Shanghai timedatectl status

再确认时间同步服务在运行。UOS默认自带chrony或systemd-timesyncd，可以用以下命令检查：

systemctl status chronyd systemctl status systemd-timesyncd

如果都没运行，手动启用chrony：systemctl enable --now chronyd。

最后配置静态IP。如果服务器是DHCP获取地址，重启之后IP变了，Rancher的Agent连接会出各种诡异问题。UOS服务器版使用NetworkManager或netplan管理网络，我这边直接用nmcli配置：

nmcli connection modify 'Wired connection 1' \ ipv4.method manual \ ipv4.addresses 192.168.10.10/24 \ ipv4.gateway 192.168.10.1 \ ipv4.dns 223.5.5.5 nmcli connection up 'Wired connection 1'

2.2 软件源替换与基础依赖安装

UOS的软件仓库地址默认可能有更新慢的问题，建议先替换成国内镜像源。这一步直接决定后面apt安装软件的速度和成功率。

备份原始源列表：

cp /etc/apt/sources.list /etc/apt/sources.list.bak

查看系统版本代号：

cat /etc/os-release

UOS服务器版多数基于Debian，版本代号一般是eagle或类似名称。把源列表里的默认地址替换为可用的国内镜像地址。这里不做统一命令，因为不同镜像站的结构略有差异，重点是把仓库地址换成响应速度快的即可。修改完成后执行：

apt update apt upgrade -y

基础依赖我建议一次性装全，后面Rancher和K8s节点都会用到：

apt install -y curl wget vim net-tools tar tree \ ca-certificates apt-transport-https gnupg lsb-release

实测下来，提前把这些基础工具装好，后面排查问题时能少很多麻烦。尤其是curl和net-tools，几乎每一步都会用到。

2.3 Docker安装的三种方式和推荐做法

UOS官方源里很可能没有Docker，需要自己处理。有三种常见做法：

第一种是从Docker官方源安装。先添加GPG密钥和仓库：

curl -fsSL https://download.docker.com/linux/debian/gpg | gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/debian $(lsb_release -cs) stable" > /etc/apt/sources.list.d/docker.list apt update apt install -y docker-ce docker-ce-cli containerd.io

不过在UOS上执行时，lsb_release -cs返回的代号如果镜像站不认识，会提示找不到仓库。遇到这种情况，可以直接用UOS基于的Debian版本代号代替，比如填写和当前系统兼容的旧版Debian代号。这个细节很容易被忽略，装不上Docker时先往这里排查。

第二种是下载静态二进制包。这种方式不依赖系统仓库，把二进制解压后放到/usr/bin，再手写systemd服务。适合内网环境，后面离线部署章节会用到。

第三种是用适配脚本：

curl -fsSL https://get.docker.com -o get-docker.sh sh get-docker.sh

但这个脚本同样依赖官方源，UOS上不一定能顺利拉取，表现不如在Debian/Ubuntu上那么稳定。我推荐第一、二种结合使用：能连外网就走官方源，完全内网就直接用二进制包。

安装完成后，配置Docker的daemon.json。这里我直接贴出我用的配置：

{ "exec-opts": ["native.cgroupdriver=systemd"], "log-driver": "json-file", "log-opts": { "max-size": "100m", "max-file": "3" }, "storage-driver": "overlay2", "data-root": "/data/docker", "registry-mirrors": ["https://docker.m.daocloud.io"] }

配置说明：

• cgroupdriver设为systemd，这一点很重要。Rancher创建的下游K8s集群默认使用systemd作为cgroup驱动，如果Docker这边是cgroupfs，节点加入集群后kubelet很容易报错。
• >systemctl daemon-reload systemctl enable --now docker docker info docker run hello-world

  实测中，UOS上Docker 20.10系列和23.0系列都能正常跑Rancher 2.7.x。如果用的内核比较老，建议选Docker 20.10，兼容性更稳。

  2.4 规划防火墙、端口和数据盘

  Rancher各组件之间通信需要特定端口，部署前要把防火墙规划和数据盘挂在前面。

  单节点Rancher Server需要开放的端口：

  • 80端口：HTTP访问，Rancher会把HTTP请求重定向到HTTPS。
  • 443端口：HTTPS访问，这是Rancher Server的主入口。
  • 6443端口：如果创建了下游K8s集群，Rancher需要与集群的Kubernetes API Server通信时使用。

  UOS防火墙默认可能是关闭的，用下面的命令确认并开放端口：

  systemctl status firewalld firewall-cmd --permanent --add-port=80/tcp firewall-cmd --permanent --add-port=443/tcp firewall-cmd --permanent --add-port=6443/tcp firewall-cmd --reload

  数据盘这块，我习惯把Docker和Rancher的数据目录都放到独立磁盘挂载点上。如果服务器上有块空白的云盘或物理磁盘，先格式化再挂载：

  lsblk mkfs.ext4 /dev/sdb mkdir -p /data mount /dev/sdb /data echo "/dev/sdb /data ext4 defaults 0 2" >> /etc/fstab

  这样操作之后，/data目录下的docker、rancher数据都独立于系统盘，后续系统盘出问题或者重装系统时，数据不容易丢。

  3. 核心实操：Docker方式部署Rancher Server

  3.1 拉取Rancher镜像并启动容器

  环境准备好之后，进入核心部分——用Docker启动Rancher Server。

  先拉取镜像。Rancher 2.7.9是我验证过的版本，推荐使用：

  docker pull rancher/rancher:v2.7.9

  如果拉取超时，检查daemon.json里的registry-mirrors是否配置正确。国内网络环境拉取Docker官方镜像时，不做加速的话失败概率很高。

  镜像拉取完成之后，启动Rancher容器：

  docker run -d --restart=unless-stopped \ --name rancher-server \ --privileged \ -p 80:80 -p 443:443 \ -v /data/rancher:/var/lib/rancher \ rancher/rancher:v2.7.9

  参数逐条拆解一下：

  • --name命名容器，方便后续docker logs查看日志。
  • --privileged一直是被讨论很多的一个参数。Rancher容器需要足够的权限来管理Docker和底层内核模块，不加上它，创建下游集群时很多环节会失败。这不是安全隐患，而是Rancher官方推荐的做法。
  • -p 80和443是Rancher的Web入口端口。
  • -v /data/rancher:/var/lib/rancher将容器内的数据目录映射到宿主机的数据盘。这一步不做，容器删除后所有配置、证书、集群信息全部丢失，这是一条不能省的配置。

  启动后观察日志：

  docker logs -f rancher-server

  第一次启动会初始化容器内部的K3s集群，这个过程需要几分钟。日志里可以看到类似"Waiting for Kubernetes cluster to become available"这样的信息。本地网络、磁盘I/O不同，等待时间也不同，一般三到五分钟是正常的。如果超过十分钟还没就绪，大概率是内存不足或磁盘满了，用free -h和df -h确认一下。

  3.2 HTTPS证书与页面初始化的处理

  Rancher容器启动完成后，浏览器访问https://服务器IP。第一次访问会因为自签名证书弹出警告，这是正常现象，点击信任后进入初始化页面。

  初始化流程只有两步：设置管理员密码和设置server-url。

  设置密码时注意，Rancher要求至少12位，并且包含大小写字母和数字。如果密码强度不够，页面会明确提示，但不会告诉你具体规则，第一次设置的人容易在这里卡住。建议直接用20位以上的随机密码，一次通过。

  server-url这一步容易被忽视，但非常关键。它决定了下游集群的Agent节点用什么地址来连接Rancher Server。这里建议填写一个域名，而不是IP。如果没有专门的域名，可以在测试环境中做一条本机hosts解析，例如：

  echo "192.168.10.10 rancher.lab.local" >> /etc/hosts

  然后在初始化页面填写https://rancher.lab.local。这样做的原因是，后续如果Rancher Server的IP变了或者需要迁移，只需要改DNS或hosts，不需要重新注册所有Agent节点。如果一开始填了IP，后面扩容节点时遇到IP变化就很痛苦。

  3.3 配置国内镜像加速，避免拉镜像卡死

  这是我在UOS上实际遇到的一个高频问题。Rancher的Web界面能打开，但在创建下游Kubernetes集群时，节点上的镜像始终拉不下来，具体表现是节点加入后一直处于"Provisioning"状态。排查了很久，最后确认是节点拉取K8s组件镜像超时。

  解决方法是把Docker的registry-mirrors配好。前面daemon.json里加的镜像加速地址，对节点同样生效。每个加入集群的节点，都要确保Docker配置了可用的镜像加速，而且节点上的Docker也需要和Server端保持一致的配置。

  另外，如果是在内网环境，建议直接在节点上配置对应内网镜像仓库的地址。Rancher拉取的镜像虽然名称来自Docker官方，但可以通过镜像仓库的白名单机制让它走内网源。这里不展开讲，实际操作中优先把加速地址配好，已经能解决90%的问题。

  3.4 离线环境部署的镜像搬运法

  很多生产环境是隔离内网，没有外网连接。Rancher在这种环境下部署需要提前准备好离线包。

  我的做法是在一台可以访问外网的机器上，把需要的镜像全部拉取下来并保存为tar包：

  docker pull rancher/rancher:v2.7.9 docker save rancher/rancher:v2.7.9 -o rancher-server.tar

  然后把tar包拷贝到UOS机器上，加载镜像：

  docker load -i rancher-server.tar

  之后用同样的docker run命令启动即可。这种方式适合Rancher Server单节点场景。如果是完整离线部署Rancher并创建下游集群，还需要准备Rancher System Agent、K3s/RKE2等组件镜像，工作量会多不少。建议先用单节点方式跑通，再根据项目需求决定要不要做完整的离线镜像仓库。

  4. 建集群实操：用Rancher创建和管理Kubernetes集群

  4.1 创建自定义集群并生成节点注册命令

  Rancher Server部署好之后，下一步就是通过它创建一个下游Kubernetes集群。我习惯用"自定义"方式来创建集群，因为这个方式最贴合手头有多台裸服务器、想自己控制节点角色的场景。

  在Rancher界面点"创建集群"，选择"自定义"，填写集群名称。集群名称一旦创建不建议修改，后续很多资源命名都依赖它。然后选择Kubernetes版本，默认选择的是Rancher官方维护的稳定版本，通常是一个v1.28.x或更新版本。

  点击创建之后，Rancher会生成一段节点注册命令，类似：

  curl -fL https://rancher.lab.local/system-agent-install.sh | sudo sh -s - --etcd --controlplane --worker --token xxxxx

  在需要加入集群的节点上执行这条命令即可。如果agent脚本下载失败，确认节点能否访问到server-url。如果节点上没有外网访问能力，可能需要先把system-agent-install.sh下载传到节点上再执行。

  4.2 节点角色怎么分配，不合理的踩坑

  Rancher自定义集群支持三个角色：etcd、controlplane、worker。角色分配直接决定集群的稳定性和调度能力。

  小型测试集群（3台节点）我常用的分配方式：

  • 节点A：etcd + controlplane + worker
  • 节点B：etcd + controlplane + worker
  • 节点C：etcd + controlplane + worker

  这种"每个节点都是全角色"的分配方式适合测试，管理简单，任何一台挂了其他节点还能继续服务。但对于生产环境不太推荐全都混布，因为etcd对磁盘性能和网络延迟敏感，和业务Pod抢占资源时容易出现性能抖动。

  更推荐的生产分配方式是：

  • 节点A/B/C：etcd + controlplane（控制面至少3个节点做高可用）
  • 节点D/E/F：worker（业务负载）

  如果节点数量有限，退而求其次可以接受"etcd和controlplane合并"，但worker角色一定要独立出来。我在测试中曾经把大量业务Pod直接调度到控制面节点上，结果kube-apiserver响应变慢、etcd出现leader切换，整集群质量明显下降。

  加入节点之后，可以用kubectl命令在Rancher自带的K8s终端里查看节点状态：

  kubectl get nodes

  所有节点显示Ready才算创建成功。

  4.3 集群网络、存储与Ingress配置建议

  创建集群时可以选择的网络插件包括Calico、Cilium、Flannel等。UOS环境下我推荐Calico，原因有三：性能稳定、支持NetworkPolicy、对底层环境要求不高。Cilium功能更强但依赖内核的BPF能力，部分旧内核的UOS机器上会有兼容问题。Flannel最轻量，适合快速验证，但功能较少。

  如果后续打算在集群里跑生产业务，存储一定要提前规划。Rancher内置了Longhorn作为分布式存储方案，可以通过应用市场一键安装。Longhorn的好处是不依赖外部存储设备，利用节点本地磁盘即可提供块存储。我在测试中给一个MySQL应用挂载了Longhorn卷，使用体验和云厂商的云盘类似，但因为是本地副本机制，数据安全性完全靠副本数保证，建议至少设置2个副本。

  Ingress控制器方面，Rancher默认会部署ingress-nginx，服务类型是NodePort，通过节点的80和443端口对外暴露流量。如果需要域名解析到集群，可以在DNS中把域名解析到任意一个worker节点IP，然后创建Ingress规则。

  4.4 日常运维：节点扩缩容与集群健康检查

  集群创建后日常运维最常用的几个操作，在Rancher界面里都能完成。

  扩容节点：进入集群编辑页，重新生成节点注册命令（会自动带上token），在新节点上执行命令即可。你也可以在界面上只勾选worker角色，让新节点只承担业务负载。

  缩容节点：在节点列表中找到目标节点，点击删除。这里要特别注意，先驱赶节点上的Pod再删除，否则业务会中断。标准流程是先用kubectl cordon和drain命令，或者直接在Rancher界面删除前确认上面的Pod已经迁移到其他节点。

  健康检查方面，Rancher的Dashboard本身会显示集群状态、节点状态和组件状态。如果集群显示警告，一般可以在"事件"里看到具体原因。我平时还会额外执行一条命令来检查节点和Pod的状况：

  kubectl get events -A --sort-by=.metadata.creationTimestamp

  这条命令能看到集群最近的事件记录，排查问题时比看监控图表更直接。

  5. 实战排障：部署与运行中的常见问题

  5.1 Server端：容器启动失败、页面无法访问

  Rancher Server容器启动后，页面一直无法访问是最常见的故障。先把状态确认到位：

  docker ps -a docker logs --tail 200 rancher-server

  我遇到过一次因为服务器内存不足，容器反复被杀掉重启的情况。Rancher容器在初始化阶段会消耗较多内存，如果free -h显示可用内存低于3GB，基本上都会出问题。解决办法是给服务器加内存，或者临时关闭一些占用内存较大的进程。

  另一个常见原因是端口被占用。UOS上有可能有其他Web服务占用了80或443端口。检查方法：

  ss -lnpt | grep -E ':80|:443'

  如果端口被占用，可以修改docker run的端口映射，比如-p 8080:80 -p 8443:443，但此时访问Rancher的地址也要跟着改成对应端口。需要说明的是，如果创建的下游集群使用了默认配置，Agent连接Rancher的地址会包括端口信息，改动端口后需要同步更新server-url，否则Agent会失联。

  5.2 Agent端：节点加入失败、NotReady状态

  新建集群时，节点执行了注册命令，但一直没出现在节点列表里，或者出现后一直是NotReady，这是另一个高频问题。

  排查路径按以下顺序：

  1. 在节点上查看agent日志：

  journalctl -u rancher-system-agent -f

  2. 确认节点能否访问Rancher Server的443端口：

  curl -k https://rancher.lab.local/ping

  如果返回pong，说明网络通。如果超时，检查防火墙、路由和server-url配置。

  3. 检查节点上的K8s组件日志：

  kubectl logs -n kube-system kubelet-xxx -n kube-system

  实际排障中，我看到过NotReady的一个原因很常见：节点上时钟与Server不一致。kubelet和etcd对时钟偏移敏感，时间差超过阈值后，节点的lease续约失败，K8s会判定节点不可用。解决办法是确保所有节点启用NTP同步，并把server、agent节点的时间保持在一个很小的误差范围内。

  5.3 时间不同步、证书过期、端口占用

  时间同步问题不仅影响节点，还会让Rancher的证书校验出问题。Rancher生成的TLS证书有自己的有效期，Server重启后如果系统时间不对，证书会被判定为无效，页面会报证书错误。处理方式分两步：第一步，把系统时间校准，第二步，重启Rancher容器让证书重新加载。

  证书过期也是一个需要提前关注的问题。Rancher内部管理的证书有过期时间，虽然官方会自动轮换部分证书，但自签名证书在长期运行时建议定期检查。单节点部署中，容器内的真实证书存储在/var/lib/rancher下，过期前可以重启容器来触发重新生成流程。如果出现Agent连不上Server且报证书错误，大概率就是这个问题。

  端口占用方面，除了Server端，Agent节点加入集群时用的6443端口也可能被占用，尤其是如果Agent节点以前被初始化过K8s集群，残留的kube-apiserver进程会抢占端口。确认方法：

  ss -lnpt | grep 6443

  如果有其他进程占用，先清理旧进程，再重新执行加入命令。

  5.4 打包一份问题速查表

  为了方便排查，我把部署期间遇到的典型问题做了一份速查表，照着查可以少走很多弯路：

  现象	可能原因	排查命令	解决方案
  Rancher容器反复重启	内存不足	free -h	加内存或关闭占内存进程
  页面一直转圈	初始化未完成	docker logs -f rancher-server	等待3-5分钟
  镜像拉取失败	未配置镜像加速	docker info	配置registry-mirrors
  节点加入后NotReady	时间不同步	timedatectl status	启用NTP同步
  Agent连接失败	server-url配置错误	curl -k https://域名/ping	修改server-url
  6443端口被占用	旧k8s残留进程	ss -lnpt | grep 6443	清理旧进程
  集群创建卡在Provisioning	节点拉镜像超时	kubectl get pods -A	配置镜像加速或离线镜像

  6. 维护心得：备份、升级与使用建议

  6.1 Rancher Server数据备份的正确姿势

  单节点Rancher有一个特性：所有配置都保存在宿主机挂载的目录里。因此备份最简单可靠的方式就是备份这个目录。

  我用的是以下方式：

  tar czf /data/backup/rancher-backup-$(date +%F).tar.gz /data/rancher

  这个目录包含Rancher的数据库、证书、集群配置等一切关键数据。恢复时，在新环境装上Docker，把tar包解压到/data/rancher，再启动相同版本的Rancher容器，数据就全部回来了。整个流程很直接，我甚至不建议在单节点场景下引入复杂备份方案，一个带时间戳的tar包足够应对日常场景。

  备份周期根据集群变更频率来定，我建议至少每周一次，并且在每次重要变更前手动备份一次。例如升级Rancher前、创建新集群前，备份一次再操作，出问题可以快速回滚。

  6.2 升级Rancher版本的三步法

  Rancher的升级流程在单节点模式下很简单，但要注意一些小细节。

  升级前先备份，这是第一步。然后拉取新版本镜像：

  docker pull rancher/rancher:v2.7.16

  第二步，停止并删除旧容器：

  docker stop rancher-server docker rm rancher-server

  第三步，用完全一样的挂载参数启动新版本容器：

  docker run -d --restart=unless-stopped \ --name rancher-server \ --privileged \ -p 80:80 -p 443:443 \ -v /data/rancher:/var/lib/rancher \ rancher/rancher:v2.7.16

  启动后等待初始化完成，访问Web界面确认集群状态正常。

  我升级时踩过的一个坑是：旧容器删除后，终端里执行docker run，忘记加-v数据卷参数，导致Rancher被当成全新安装初始化。虽然发现及时没造成数据损坏，但这是个很低级却可能致命的失误。一定要确认数据卷参数和旧容器一致。

  6.3 一些实用的使用建议

  Rancher在UOS上的使用和在其他Linux发行版上差异不大，但由于硬件可能受限，有几条建议是亲测有效的。

  一是下游集群的Pod数量不要盲目拉高。在测试硬件条件下，单节点跑几百个Pod会发现kubelet的CPU占用明显增加，建议根据节点CPU核数合理设置每个节点的Pod上限。

  二是尽量使用Rancher内置的监控方案。Rancher自带监控组件，安装之后可以看到集群的资源使用曲线。很多时候集群出问题，现象千奇百怪，根源就是资源不足，监控图表比人眼判断快得多。

  三是网络插件选型不要频繁更换。一旦集群建好，网络插件就很难再改，需要在创建集群前想清楚。测试环境用Flannel图省事后期升级会很麻烦，不如一开始用轻量一点的Calico。

  四是把Rancher的账号权限管理用起来。即使团队人少，也不要都用一个管理员账号。Rancher支持基于角色的访问控制，可以按团队划分不同的项目空间，给不同人分配不同权限，这个功能日常使用价值很高，而且配置并不复杂。

  最后再分享一个小技巧：UOS上如果出现某些组件加载异常，优先检查内核模块，尤其是overlay和br_netfilter。我在一台机器上遇到容器网络过不去的问题，最后发现是br_netfilter模块没加载：

  modprobe br_netfilter echo "br_netfilter" >> /etc/modules-load.d/br_netfilter.conf

  这类底层问题排查起来很耗时间，提前把这些系统层面的准备做扎实，后续Rancher的使用体验会顺畅很多。