sealos 部署 Kubernetes 集群：Ubuntu 24.04 实战指南

1. 为什么我用 sealos 而不是 kubeadm 手工拼集群

先交代一下背景。我是运维工程师，最近半年被问得最多的问题就是如何在 Ubuntu 24 上快速搭一套 Kubernetes 集群。过去我一直用的是 kubeadm 手工部署：下载 kubeadm、kubelet、kubectl 三个二进制，然后 init、join、装 CNI、配 kubeconfig，三台机器怎么说也得折腾大半天。中间还得处理 apt 源、容器运行时、内核参数、镜像拉不下来的问题，每次都要走一遍。

后来接触了 sealos，一条命令直接把集群给我拉起来了，从零到能跑 Pod 大概不到十分钟。这个效率差距不是一星半点。

先说清楚一个概念：sealos 不是替代 Kubernetes 的东西，Kubernetes 集群本身还是那个 Kubernetes，节点上跑的还是 kubelet 和 containerd，API 也完全一样。sealos 是一个部署工具，它的作用是帮你把集群的整个搭建过程自动化，把以前手工执行的几十条命令封装成一个简单的动作。

sealos 背后做的是这样几件事：准备机器、分发二进制、生成配置文件、启动集群、把证书签好、把控制平面组件跑起来。用户看到的只有一个 sealos run 命令，但实际发生的是从空机器到可用集群的完整配置过程。

这类工具其实不少，除了 sealos，还有 kubeadm、kubekey、rancher、k3s、kind 这些。但在我实际用下来的体验里，sealos 有几个优势非常明显：

• sealos 把容器运行时（containerd）和控制平面组件作为镜像打包，可以提前下载好离线包，安装过程不依赖在线仓库，在服务器网络环境受限时尤其好用；
• 单机集群和 HA 集群都是同一条命令，只是参数不同，运维心智负担小很多；
• 自带负载均衡（lvs）方案，高可用场景不需要额外部署 keepalived + haproxy；
• 版本管理做得比较清楚，Kubernetes 的每个版本都有对应的 sealos 镜像，升级路径明确，后续要做版本升级，操作也比较简单。

我推荐 sealos 的一个具体理由是，它能让运维人员从纯粹的搭建动作里解脱出来，把精力用在业务侧。如果你的工作职责里经常出现“搭环境”这类的活，比如开发环境、测试环境、预发环境都要各来一套集群，sealos 的优势就很明显了。开发环境需要一套，测试环境需要一套，预发环境需要一套，每套环境都手工 kubeadm 一遍，光重复劳动就能把人逼疯。

这篇内容面向两类人：一是需要快速搭建 K8s 环境做学习验证的初学者，二是需要频繁交付 Kubernetes 集群环境的运维或研发工程师。我会把从 Ubuntu 24 系统初始化到集群跑起来的完整过程写清楚，包括每个环节的注意点和踩坑经验。

2. Ubuntu 24.04 部署前的准备工作和几个容易忽略的细节

sealos 会负责主要的工作，但机器层面还是需要先做基础的检查。我假设你用的是 Ubuntu 24.04 Server 版本——注意，如果你在 VMware 里装的是 Desktop 版本，也不是不行，只是桌面环境会额外占用不少内存资源，跑在笔记本或虚拟机上做 AI 开发或平时学习测试，Server 版会更合适，资源开销更可控。

建议先确认好节点规划。我这次的示例环境是三台机器：一台作为 master，两台作为 worker。生产环境如果对可靠性要求高，master 节点需要奇数个，一般用三台或五台。三台 master 的情况下，虽然可以容忍一台宕机，但实际跑业务时为了保证 Worker 节点能正常调度，通常也会给 Worker 节点留足资源，具体怎么规划要看业务需求，这里涉及到的详细原理可以之后再展开。测试环境用一台机器同时做 master 和 worker 是完全可以的，sealos 支持“单机部署”模式，后面会说。

2.1 主机名、hosts 和固定 IP

每台机器先设置好主机名。主机名最好有区分度，比如 master01、node01、node02。不要偷懒让三台机器都叫 ubuntu，控制平面组件会对主机名比较敏感，主机名重复会导致节点注册混乱。设置方法：

bash复制sudo hostnamectl set-hostname master01

然后编辑 /etc/hosts，把三台机器的 IP 和主机名对应关系写进去。这一步不是必需的，但强烈建议做，避免后续节点间通过 IP 通信可能出现的网络问题。Kubernetes 的组件间通信会大量使用主机名，比如 kubelet 注册到 API Server 时上报的主机名，以及 etcd 成员间的通信配置，如果主机名解析不确定，可能会引发一些隐蔽的故障。

bash复制192.168.1.10 master01
192.168.1.11 node01
192.168.1.12 node02

固定 IP 可以通过 netplan 设置。Ubuntu 24.04 默认的网络配置工具是 netplan，配置文件在 /etc/netplan/ 目录下。如果你是在 VMware 或者其他虚拟化平台安装的，需要把网卡配置为静态 IP，否则 DHCP 分配的 IP 漂移会导致集群节点互相找不到。配置模板：

yaml复制network:
  version: 2
  ethernets:
    ens33:
      dhcp4: false
      addresses: [192.168.1.10/24]
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [114.114.114.114, 8.8.8.8]

应用配置用 sudo netplan apply。有个容易踩的坑是网卡名称，不同平台的网卡名不一样，VMware 一般是 ens33，Physical 机器常见的是 enp0s3 或者 eno1。先用 ip link 查看本机实际网卡名再配，这一点很重要。

2.2 防火墙：哪些端口需要放行

这一步经常有人忘记。安装完系统后，Ubuntu 默认的 ufw 防火墙是关闭的。但我见过有人在云服务器上自己装了别的安全策略。Kubernetes 集群内部组件通信会用到很多端口，如果防火墙拦截了这些端口，sealos 部署过程可能挂掉，而且报错信息特别难排查。通常表现为节点 Timeout 或 kubelet 无法启动。

核心要放行的端口：

如果你确定 ufw 是关闭状态，用 sudo ufw status 确认一下就行。如果是开启状态，直接把 ufw 关掉最省事：

bash复制sudo ufw disable
sudo ufw status

内部测试环境我一般就直接关了。生产环境需要按端口最小化放行，但这是后面的安全加固工作，和部署阶段分开。

2.3 内核模块和系统参数：确保网络转发和 iptables 规则正常

Kubernetes 的 kube