企业官网建设流程全解析

用RKE搭K8s再用Helm装Rancher，这事其实能一条龙走完

自建Kubernetes集群这个事，很多团队一开始都是被“自己动手”四个字劝退的。又是配证书、又是初始化集群、又是搞网络插件，等到要装一个像样的可视化管理平台时，往往已经消耗了一大半精力。我自己最早折腾K8s用的还是纯二进制方式，手动把所有组件拉起，那次经历让我意识到，除非你想研究源码级细节，否则生产环境真不该这么干。

后来在交付一套项目时，我选了RKE（Rancher Kubernetes Engine）来建集群，再用Helm把Rancher装上去。整套流程走下来，比预想中顺很多：RKE只依赖Docker，集群组件全部容器化，一条命令就能拉起来一套高可用K8s；Rancher装好之后，多集群管理、项目隔离开箱即用。如果你正好需要自建K8s，又想有一个趁手的界面去运维它，这篇文章就是按我实际操作的顺序整理的，从环境准备到踩坑修复都有，直接照着做基本能复现。

1. 为什么选RKE这条路

1.1 K8s部署方式对比

K8s的部署方式不少，主流的大概有四类：kubeadm、二进制部署、RKE、云厂商托管（如托管版K8s）。前面两类对运维的动手能力要求比较高，二进制部署需要自己管理每个组件的证书、静态Pod、systemd服务；kubeadm虽然把初始化流程简化了，但很多网络层、存储层的细节还是得自己补。托管版最省心，但如果你面对的是国内机房、离线网络或者无法走托管服务的客户现场，这条路基本堵死。

RKE属于那种“在原生K8s和托管服务之间”的务实选择。它把K8s核心组件（etcd、controlplane、worker）都以容器方式分发，安装工具本身是一个二进制文件，通过cluster.yml描述集群拓扑，然后rke up就把集群推起来。不用预装kubelet、kubeadm、kubectl这些二进制，也不用提前配PKI证书，RKE会一并生成好。对交付团队来说，这意味着部署逻辑变成“装好Docker + 写配置文件 + 执行命令”，非常容易被脚本化、被复制到另一套环境。

1.2 为什么这套组合适合大部分生产场景

Rancher装上去之后，你能得到一个相对完整的K8s运维入口：集群状态看板、节点管理、工作负载的图形化部署、监控告警的集成入口，这些功能对于运维团队日常巡检和开发同学自助发版都很有价值。而RKE和Rancher出自同一生态，兼容性几乎不需要担心。实际部署中我甚至遇到过Rancher的Chart市场里直接把RKE集群导入选项做成了“一键导入”，说明设计之初就没打算让你手工拼配置文件。

还有一个实际场景是离线交付。很多项目现场内网和外网是隔离的，你没法像在公有云上那样直接拉镜像。RKE的system-images机制可以把集群依赖镜像一次性导出（rke config export之后用rke etcd snapshot等命令），配合Rancher的镜像导出，整个离线包是可以准备好再搬到现场的。这个特性是很多生产环境选择RKE、Rancher的直接原因。

1.3 我眼中这套方案的适用边界

如果你的目标是快速验证K8s功能，只想单机跑一个All-in-One环境，那完全不用上RKE，直接用k3s或者minikube更轻。如果你们的场景是超大规模集群（上千节点），Rancher可以管理它，但K8s本身更建议结合云厂商托管或多集群联邦方案来设计。RKE最舒服的区间是：生产可用、节点数量几十到几百、需要高可用、环境可联网或可做离线镜像搬运的中大型自建场景。

2. 部署前的准备工作

2.1 主机规划与配置清单

RKE部署时要求主机干净，不能预装K8s相关组件。我这次用三台Linux机器做最小高可用：一台作为controlplane+etcd+worker混合节点，另外两台各司其职。这里有一点要提前说明：RKE官方不太建议把etcd和controlplane拆到不同节点去数，但如果是小规模环境（比如三台机器），官方默认的拓扑就是每个节点都跑controlplane与etcd，worker角色单独指定。

一个参考配置如下：

如果你想要更标准的角色分离，比如3台etcd、2台controlplane、3台worker，那配置会更高，但拓扑上RKE都能用cluster.yml描述清楚。实际项目中，我建议至少预留一套等规模的备用环境，因为K8s版本升级、Rancher升级都需要一个可回滚的沙箱环境来验证。

2.2 操作系统与Docker准备

RKE对操作系统的要求没那么苛刻，CentOS、Ubuntu、Debian都可以，但内核版本和Docker版本需要匹配。我这次用的是主流Linux发行版，Docker版本选择了当时RKE支持的一个稳定版本。关于Docker的安装，建议直接用发行版的软件源装官方版本，不要用发行版自带的旧版本仓库，否则容易出现Docker API版本不匹配的问题。

安装完Docker后，一个容易忽略的点是配置Docker守护进程的镜像源加速。国内环境不配置加速，拉取RKE系统镜像时会非常痛苦。在/etc/docker/daemon.json配置若干可靠的仓库地址，然后重启Docker。另外一个细节是确认Docker的存储驱动，RKE官方推荐的是overlay2，你可以用docker info看当前Storage Driver，确保它没问题。

2.3 系统初始化与SSH配置

RKE有两种执行方式：一种是RKE直接运行在某台机器上，通过SSH连到所有目标主机；另一种是在每台目标主机本地执行。我推荐第一种，适合集中管理。为了SSH能顺利连上，需要在每台目标机器上创建部署用户，并配置好免密。注意RKE要求部署用户对Docker socket有访问权限，简单做法是把用户加入docker组。

提示：千万不要把SSH端口改成非标准端口后忘记在cluster.yml里同步，否则RKE连接失败报错会让你排查半天。

系统层还需要确认几件事：关闭或正确配置交换分区（K8s对swap的策略在不同版本不一样，RKE会在初始化阶段自动处理一部分，但内核参数建议提前调好）、打开必要的内核转发、关闭防火墙或放行必要端口。生产环境建议放行而不是完全关闭防火墙，至少需要打通各节点间的K8s通信端口，具体端口范围Rancher文档中列得很清楚。

3. RKE部署K8s的完整实操

3.1 安装RKE与准备配置文件

RKE的安装非常直接，官网下载二进制文件，加执行权限，放到PATH路径下即可。比如：

# 下载与K8s版本匹配的rke二进制 wget https://github.com/rancher/rke/releases/download/v1.4.x/rke_linux-amd64 mv rke_linux-amd64 /usr/local/bin/rke chmod +x /usr/local/bin/rke rke --version

拿到二进制之后，可以先用以下命令生成一个配置模板：

rke config --name cluster.yml

生成的cluster.yml会自动带上你当前环境中的IP，格式基本可用。不过我还是建议手动写，这样每一项都清楚它是什么意思，后面排障时不会一头雾水。我一般先写成这样：

nodes: - address: 192.168.1.10 user: deploy role: [controlplane, worker, etcd] ssh_key_path: ~/.ssh/id_rsa - address: 192.168.1.11 user: deploy role: [controlplane, worker, etcd] ssh_key_path: ~/.ssh/id_rsa - address: 192.168.1.12 user: deploy role: [worker] ssh_key_path: ~/.ssh/id_rsa services: etcd: backup_config: interval_hours: 12 retention: 30 snapshot: true kube-api: service_cluster_ip_range: 10.43.0.0/16 kube-controller: cluster_cidr: 10.42.0.0/16 service_cluster_ip_range: 10.43.0.0/16 kubelet: cluster_domain: cluster.local cluster_dns_server: 10.43.0.10 network: plugin: calico options: flannel_backend: vxlan mtu: 1450 dns: provider: coredns

3.2 cluster.yml关键字段解析

这一段是干货，我一个个字段拆开说。

nodes部分定义了每台机器的角色。角色可以叠加，但如果某台机器既要跑etcd又要跑worker，RKE会在部署时自动为它分配两个角色组件。这里有一个容易踩的坑：etcd节点数量必须是奇数，否则raft投票会有问题，虽然不是不能跑，但一旦出现故障，脑裂和选主失败的概率会增加。我习惯3节点时要么3台都是etcd，要么单独保证etcd数量为3。

ssh_key_path要注意权限，RKE会对私钥文件做校验，权限过宽会直接报错。

services.kube-api里的service_cluster_ip_range是集群内部Service网段，kube-controller里的cluster_cidr是Pod网段。这两个网段不要和物理机网段、内网管理网段冲突，否则后面路由或者DNS会出诡异问题。我见过有人把Service网段设在和办公室WiFi网段重叠的地方，最后一波访问超时排查了很久。

network.plugin我选择了calico。因为需要在大二层网络下跑跨节点Pod通信，calico的BGP方案性能比flannel的VXLAN好一些。网络插件决定后，后面Rancher里看到的网络方案也基本固定。如果你是刚上手，flannel也不错，配置更简单，但calico对NetworkPolicy的支持更好，长期来看省事。

dns.provider用coredns即可，这基本是现在K8s的默认选择。

3.3 执行部署并验证集群

配置文件写好后，执行：

rke up --config cluster.yml

首次执行会自动拉取镜像、生成证书、编排组件。中间会输出很多日志，我习惯通过观察关键步骤判断进度：先看到节点预检（检查Docker、SSH连接），然后是镜像拉取，再然后是组件启动。整个过程视网络情况10到20分钟不等。

注意：如果执行过程中因为某一步报错中断，别急着改配置重跑。先看看是不是磁盘空间不够、Docker源不通、或者SSH免密失效。RKE对“半成品”集群的处理并不完美，有时需要清掉残留的容器和卷才能重来。

执行成功后会生成kube_config_cluster.yml，这就是kubeconfig文件。把它复制到~/.kube/config，就能用kubectl操作集群了：

cp kube_config_cluster.yml ~/.kube/config kubectl get nodes kubectl get pods -n kube-system

理想状态下所有节点的状态都是Ready，kube-system里的Pod都处于Running或Completed。有一次我部署后节点是NotReady，查日志发现是主机名解析问题——K8s组件对hostname解析比较敏感，建议提前在/etc/hosts里加好各节点的主机名解析。

3.4 集群管理：证书轮换与etcd备份

RKE除了部署，日常维护也很有用。K8s证书到期是自建集群最容易忽视的坑，RKE给了一行命令做证书轮换：

rke cert rotate --config cluster.yml

这个命令对API Server、etcd等组件证书都会处理，不需要手动操作每个节点。etcd备份方面，RKE提供周期快照能力，我在cluster.yml中配置了每12小时快照、保留30个。执行恢复时：

rke etcd snapshot-restore --name snapshot-name --config cluster.yml

这些操作虽然不常用，但真到关键时刻能救命，建议部署完立刻验证一次备份与恢复流程，别等出问题才现学。

4. Helm安装Rancher

4.1 Rancher版本选择与前置条件

Rancher作为K8s管理平台，目前推荐安装的是2.x版本（尤其2.6之后的版本更成熟）。安装Rancher有几种方式，官方最推荐的是Helm方式，这也正好符合我们标题里的路径。安装前确认一下目标K8s集群版本在Rancher官方兼容性列表内，不然装完后可能出现API版本不兼容导致部分资源无法管理。

还有一点需要提前确认的是Ingress Controller。Rancher访问默认走HTTPS，它需要一个Ingress入口。RKE部署时如果没有额外装Ingress Controller，Rancher的Chart会自动尝试部署，但前提是集群能正常工作。如果你想自己控入口（比如后面要接负载均衡），也可以提前装好Ingress Controller，再在安装Rancher时关掉它自带的入口。

4.2 安装Helm与添加Chart仓库

Helm是K8s的包管理工具，安装分两步：先装helm二进制，再在K8s集群里初始化tiller（不过Helm 3不用tiller了，直接使用服务端CRD存储）。现在主流推荐Helm 3，装起来和客户端差不多：

wget https://get.helm.sh/helm-v3.x.x-linux-amd64.tar.gz tar -zxvf helm-v3.x.x-linux-amd64.tar.gz mv linux-amd64/helm /usr/local/bin/helm helm version

这里有一个版本要求需要说明：Rancher和Helm的兼容性要求Rancher Chart支持Helm 3。老版本（比如Rancher 2.1、2.2）走Helm 2的Tiller方式，偶尔会遇到Tiller权限不足或无法连接到K8s API的问题。如果你们还要维护旧版本的Rancher，建议把Helm 3装好，因为新版Rancher的官方Chart刷新和安装命令都针对Helm 3优化。

添加Rancher的Helm仓库：

helm repo add rancher-prime https://charts.rancher.com/server-charts/prime helm repo update

如果你想使用稳定版（非prime），对应仓库是https://charts.rancher.com/server-charts/stable，根据自己需求选择。国内环境如果访问Chart仓库不稳定，可以考虑先下载Chart包再本地使用，但更新机制不如在线仓库灵活。

4.3 通过Helm安装Rancher的完整命令

在安装前，需要一个cattle-system命名空间，并准备TLS证书。Rancher默认会在安装时尝试使用cert-manager自动生成自签证书，这个过程比较顺手，但生产环境我更建议提前准备好可信证书。我这次的流程是开启cert-manager支持然后自动管理证书：

kubectl create namespace cattle-system # 为Rancher设置TLS（方式一：自己提供证书） kubectl -n cattle-system create secret tls tls-rancher-ingress \ --cert=rancher.crt --key=rancher.key # 安装Rancher helm install rancher rancher-prime/rancher \ --namespace cattle-system \ --set hostname=rancher.example.com \ --set ingress.tls.source=secret \ --set privateCA=true \ --version 2.x.x

--set hostname是你后续访问Rancher的域名，需要和证书中的域名一致。ingress.tls.source我用了secret而不是letsEncrypt，因为后者对Let's Encrypt的颁发频率和域名要求更高，不适合所有环境。如果你确实没有可用证书，也可以临时用--set ingress.tls.source=rancher让Rancher内置自签证书，但浏览器会有安全提示，日常演示够用，生产不建议。

安装完成后，等待Pod滚动起来：

kubectl -n cattle-system rollout status deploy/rancher

确认Pod全部Running后，通过配置的域名访问Rancher，首次访问会要求设置管理员账号密码。Rancher初始化之后，需要在“设置”中确认Server URL，这个URL要和helm install设置的hostname保持一致，否则下次登录和集群导入都会有问题。

4.4 安装后的集群导入与管理

Rancher不但可以管理它所在集群，还能管理其他K8s集群。如果在RKE部署的同一台机器上已经跑着Rancher，那这个集群会被自动识别。插入新集群时，有两种方式：其一是在Rancher界面点击“导入集群”，它会生成一段kubectl命令，在目标集群上执行即可；其二是直接提供kubeconfig文件。我习惯用第一种方式，因为Rancher会把导入所需的Service Account和ClusterRole自动创建好，不用手动维护权限。

这里有件事值得注意：如果你用Rancher导入一个由RKE创建的集群，Rancher默认会对集群做一次勘察并进行部分资源同步。如果发现一些核心组件（比如coredns、metrics-server）的版本和Rancher期望的不一致，它会提示升级，但这属于受控操作，建议看清楚再点。

5. 踩坑实录与问题排查

5.1 常见问题速查表

以下问题是我和交付团队在新环境安装RKE + Rancher时遇见过的高频问题，整理成速查表：

5.2 两个我印象最深的坑

第一个坑是部署RKE时不小心在cluster.yml里把某节点写了两个不同IP。当时为了特殊网络设计，给节点配了管理IP和业务IP，RKE通过管理IP认证，但K8s组件绑定用的是业务IP，结果节点一直被标记为NotReady。后来在node配置中加internal_address指向业务IP，才算解决。RKE对多网卡场景支持其实很好，关键在于理解address和internal_address的语义。

第二个坑是Rancher安装后一直显示“等待证书生效”。排查后发现是cert-manager没起来，原因在于K8s集群缺少生效的IngressClass定义。Rancher的Helm Chart可能指定了ingressClassName，而集群里没有这个类，导致Ingress一直没有真实创建成功。解法是提前装好Ingress Controller，或者给Rancher的Ingress指定一个存在的IngressClass，比如nginx。

5.3 经验技巧：升级时先备份再操作

Rancher和RKE的升级本身都很方便，RKE升级只要替换二进制版本后重新执行rke up，Rancher升级用helm upgrade即可。但升级最大的问题不是操作难，而是回滚难。Rancher在升级时会迁移部分CRD数据，如果跳到跨大版本，数据结构和旧版本不兼容，降级回去会报错。我现在的习惯是：升级前先做RKE的etcd快照，再用Rancher的“备份”功能导出一份完整的应用状态，最后在非生产环境验证完才动生产。

如果你同时管理多套集群，升级Rancher时一定注意：升级Rancher会影响它接管的所有集群，不只是当前这个。因此Rancher升级计划要纳入变更管理，选业务低谷期，提前通知相关团队，并且准备好回滚预案。

结尾：一些真实感受

这套RKE + Helm + Rancher的组合，我前后用过不少项目，有成功也有翻过车。翻车的几次，多半是准备工作没做扎实，尤其是主机网络规划、Docker源可用性、证书和域名匹配这三个点。如果这三件事解决掉，整套安装过程其实是相当顺滑的。RKE的容器化设计让集群安装从“每天傻等组件编译”变成了“配置文件即集群”，Rancher再把平台操作变成鼠标点击，整个交付链路对团队来说负担小了很多。

最后我想说，虽然自动化工具越来越多，但别把RKE和Rancher当成黑盒。我遇到的生产故障，很多都和自定义配置有关。建议在正式交付前，至少完整走一遍从零建集群、导入集群、发一个测试应用、做一次etcd恢复的全流程演习，这样你才真正熟悉这套工具的边界在哪里，遇到问题也能更快定位。部署工具只是开始，真正考验人的永远是你对自己集群的理解程度。