当你的应用从一个演示项目真正长成承载用户的服务，最早暴露的问题往往不是性能，而是可用性：一台服务器重启，所有容器跟着下线；控制平面一宕机，整个集群既不能发布也不能自愈。本文将介绍如何用三台云服务器（可按需开通和扩容的远程服务器）搭建一套 K3s 高可用集群，帮助你在运维成本几乎不变的前提下，消除控制平面的单点故障。整个过程只需要几条命令，读完即可照做。
在正式动手之前，我们先花两分钟弄清楚 K3s 的定位，以及为什么它特别适合中小团队的三节点方案。如果你此前接触过完整的 Kubernetes 集群，会发现 K3s 砍掉了大量非核心组件，但保留了搭建高可用架构所需的关键能力。更多服务器侧的基础选型思路，可以参考我们此前整理的服务器运维专题。
K3s 是什么，为什么三台是高可用的起点
K3s 是一个为边缘和中小规模场景设计的轻量级 Kubernetes 发行版，单个二进制文件就包含了 API Server、调度器、控制器管理器和容器运行时，安装包不到 100MB，默认内存占用不到 512MB。它和标准 Kubernetes 的 API 完全兼容：你在别处学到的 Deployment、Service、Ingress 写法可以原样迁移过来。
高可用的核心不在”服务器多”，而在控制平面（负责集群调度和状态管理的组件集合）是否有冗余。单节点 K3s 就像只有一名值班员的机房：值班员打盹，业务就中断。K3s 内置的 etcd（分布式键值存储，保存整个集群的状态数据）高可用部署要求至少 3 个 server 节点——这是 Raft 一致性算法对容错的要求：3 节点可容忍 1 台故障，5 节点可容忍 2 台。对大多数业务，3 台 server 起步、之后按需追加 agent 工作节点，是成本和可靠性的平衡点：任一台故障，集群管理能力不受影响；滚动维护不再需要停机窗口；集群状态有三副本，配合备份即使一台数据损坏也能恢复。如果你还在评估业务该用什么形态的主机承载，可以先看这篇独立服务器与 VPS（虚拟专用服务器）的选型对比。
搭建前的准备清单
三台服务器是唯一的硬性投入。每台建议至少 2 核 CPU、4GB 内存和 40GB 系统盘，运行主流的 64 位 Linux 发行版（如 Ubuntu 22.04 或 Debian 12），并预先安装好容器运行时依赖。三台机器之间必须能互相解析主机名——最简单的做法是在每台的 /etc/hosts 里写上另外两台的内网 IP 和主机名，例如 10.0.0.11 k3s-server-1。如果云服务器在同一内网，优先走内网通信，既降低延迟也减少公网暴露面。
网络和安全组方面，节点间需要放行 K3s 使用的端口：6443（Kubernetes API）、2379 和 2380（etcd 客户端与节点间通信）、10250（kubelet）。出于安全考虑，2379/2380 只应对集群内网开放，不要暴露到公网。同时给每台服务器配好独立的 SSH 密钥登录，关闭密码认证——这套集群将承载你的业务流量，入口安全不能省。
规划好机器之后，就可以进入正式安装。下面的操作全部以 root 或具备 sudo 权限的用户执行，三台服务器分别命名为 k3s-server-1、k3s-server-2、k3s-server-3。
第一步：初始化第一个 server 节点
在第一台服务器上执行 K3s 官方安装脚本，并显式指定使用内置 etcd：
curl -sfL https://get.k3s.io | sh -s - server \ --node-name k3s-server-1 \ --write-kubeconfig-mode 644
脚本执行完成后，用两条命令验证服务状态：systemctl status k3s 应显示 active (running)；kubectl get nodes 应输出一个 Ready 状态的 control-plane 节点。此时集群仍是单节点形态，etcd 里只有一份投票成员，接下来要把另外两台加进来凑满三票。
安装过程会在 /var/lib/rancher/k3s/server 下生成节点证书和 token。执行 cat /var/lib/rancher/k3s/server/node-token，记下这个 token，加入集群的节点都要用它完成认证。这个文件等同于集群的钥匙，读取后建议限制权限，不要留在命令行历史里。
第二步：加入第二、三台 server 节点
在另外两台服务器上执行同样的安装脚本，多传两个参数——server 节点地址和上一步拿到的 token：
curl -sfL https://get.k3s.io | sh -s - server \ --node-name k3s-server-2 \ --server https://10.0.0.11:6443 \ --token <你的node-token>
第三台把 --node-name 换成 k3s-server-3 即可。每台加入后，回到第一台执行 kubectl get nodes，正常情况下你会看到节点列表从 1 个逐渐变成 3 个，全部为 Ready，角色为 control-plane,etcd,master。再执行 kubectl get componentstatuses 或查看 k3s etcd 相关日志，确认 etcd 集群有三个健康的成员。
至此高可用控制平面已经成型。一个直观的验证方法是模拟故障：直接 shutdown -r now 重启其中任意一台，然后在剩下两台上执行 kubectl get pods -A——命令应当正常返回，说明 API Server 的冗余生效了；等重启的节点回来，它会自动重新同步数据。如果后续要扩展业务承载能力，用同样的 token 加入 --agent 模式的纯工作节点即可，不需要再动控制平面。
第三步：部署业务并验证调度行为
控制平面就绪后，先部署一个多副本应用观察调度。把下面的清单保存为 demo-deployment.yaml：
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:1.27
ports:
- containerPort: 80
执行 kubectl apply -f demo-deployment.yaml，然后 kubectl get pods -o wide。你会看到三个副本被自动分散到不同节点——这是调度器对高可用集群的基本功。接着重复一次前面的重启实验：关掉一台 server，稍等片刻再 kubectl get pods -o wide，web 副本会被重新调度到存活的节点上，业务请求不中断。这个”关一台、业务照常”的现象，就是三节点架构交付的核心价值。
对外暴露服务时，K3s 默认内置了 Service LB（把负载均衡器跑在集群节点上）和 Traefik Ingress，不需要额外安装组件。把 Service 类型设为 LoadBalancer，或在 Ingress 里绑定域名，即可让流量进入集群。集群对外依赖服务器之间的网络质量，三台机器之间的延迟和丢包直接决定 etcd 的同步效率，选购或自查时可以参考这篇海外服务器连通性检测方法，先把内网链路质量确认好再上线业务。
证书自动续期与日常运维
K3s 的组件证书默认有效期一年，且会在节点启动时对已过期或 120 天内到期的证书自动续期。这意味着只要你保持服务器定期重启或升级（大多数团队每月至少一次），就不需要手动干预证书。想确认当前证书状态，可以查看 /var/lib/rancher/k3s/server/tls 目录下各 .crt 文件的到期时间，例如用 openssl x509 -enddate -noout -in serving-kube-apiserver.crt。
备份是另一条生命线。K3s 官方明确：使用内置 etcd 时，快照必须包含整个 server/db/ 目录和 server/token 文件，只拷贝其中一部分无法可靠恢复。日常可以用 k3s etcd-snapshot save 生成快照，再把 /var/lib/rancher/k3s/server/db/ 和 /var/lib/rancher/k3s/server/token 一起同步到集群外的存储。恢复时在新节点上通过 --cluster-reset 加快照路径重建，具体命令以你所用版本的官方文档为准。
节点的系统层维护同样不能忽略：定期更新内核与安全补丁、监控磁盘和内存水位、为容器镜像保留清理策略（K3s 自带镜像垃圾回收，但阈值需要按业务调校）。这些日常动作看似琐碎，却决定了高可用架构在真实故障面前的成色。想系统了解主机层面的运维节奏，可以参考主机性能优化指南。
单节点与三节点高可用的取舍
在收尾之前，把两种形态的差异说透，方便你对照自己的业务做决策。单节点 K3s 的控制平面和数据面在同一台机器上，优点是成本最低、运维最简单，缺点是这台机器的任何故障都会直接体现为业务中断，升级也必须停机。
从成本看，三台 2 核 4GB 的云服务器月支出通常仍低于一台同等总算力的高配独立服务器，但换到的是故障隔离和滚动维护能力。如果你的业务已有明确的服务等级要求（比如更新不许停机、单机故障必须在几分钟内自愈），三节点是必要投入；如果还处于早期验证阶段，先用单节点跑通、数据备份做扎实，再平滑扩到三节点也不迟——K3s 允许后续追加 server 节点，不需要推倒重来。云服务器（Cloud Server）厂商的质量参差也会直接影响集群稳定性，选型时可以结合这篇海外云服务器风险审计逐项排查，避免把集群建在不牢靠的地基上。
总结与下一步行动
总结一下：三台云服务器加内置 etcd 的 K3s 是中小团队性价比很高的高可用容器集群方案——3 节点容忍 1 台故障，证书自动续期省去手工运维，快照备份覆盖 server/db/ 与 server/token 后即可可靠恢复。我们的建议是分三步走：先用一台机器跑通应用部署，再补齐三节点控制平面，最后把自动化备份接到集群外的存储上。如果你需要为这套集群挑选稳定、内网互通的云服务器，可以考虑 Hostease 的云服务器方案，三台同区域内网组建 K3s 集群即开即用。