搞 K8s 的人基本都经历过这种时刻你只是想部署一个应用结果先被集群安装、网络插件、证书过期按在地上摩擦一遍。技术方案本身没问题但团队的时间就这样被一层层复杂度消耗掉了。我今天想聊的 Sealos就是干这件事的——它把 Kubernetes 的安装、高可用、运维这些底层复杂度像引擎一样盖进引擎盖里让团队把精力放到业务上。适合谁看准备上 K8s 但还没太强运维能力的中小团队以及已经知道 K8s 痛点、想换一种更低成本姿势管理集群的技术负责人。下文会从 K8s 复杂度的根源讲起再到 Sealos 的设计逻辑、完整部署实战、Prometheus 监控与 GPU 调度最后是踩坑心得。1. K8s到底难在哪它拖垮团队的真实原因网上 K8s 学习资料已经多到爆炸《Kubernetes 权威指南》摆在案头都翻得卷边了但真正动手的时候大多数人还是卡在同一个地方我连一个能跑的生产集群都搭不出来。有人觉得这是看书不够我的经验恰恰相反K8s 的复杂度根本不在概念理解而在把概念落到物理机器的过程里。这一步如果没人替团队趟平光靠文档硬啃会非常消耗士气。先说我见过最多的场景。一个五到十人的后端团队Leader 拍板要上 K8s于是安排两个人去搭集群。这两个人开始翻 kubeadm 文档初始化 master、配置证书、部署 CNI 插件、处理 etcd 高可用、配置负载均衡器。每一条都能在网上找到教程但把每一步串起来中间能出错的地方多得惊人。等集群终于起来了又发现不会用连部署一个带配置项的服务都要查半天。这就是 K8s 拖垮团队的真正机制它不是一个人多学一个技能就能解决的问题而是把大量隐性知识分散到了每一个节点上。谁初始化了集群谁记住了那个 kubeadm join 的 token谁调过某条 iptables 规则这些知识如果不沉淀下来两个月后节点要扩容团队会发现没有人记得当时的配置是怎么做的。1.1 部署一个集群光是初始化就有十几种姿势Kubeadm 是官方工具但新手用它搭一个多节点集群至少会遇到这些坎apiserver 的证书得自己签名或让 kubeadm 自动签etcd 要么用外部集群要么用内置的静态 Podkubelet 的启动参数要跟着容器运行时版本走CNI 插件又分 Calico、Flannel、Cilium 三家每家对网络段、校验模式的要求都不一样。更麻烦的是容器运行时这部分。早期 K8s 用 Docker后来 1.24 版本把 dockershim 移除了很多老教程直接失效。新项目要么用 containerd要么用 cri-o你得重新学习 nerdctl、crictl 这一套命令。K8s 和 Docker 的区别很多人以为是同一类东西其实 Docker 是构建、运行单个容器的工具K8s 是跨几十台机器编排这些容器的操作系统。这个认知不建立起来后面排查问题会永远隔着一层。就算你照着文档顺利跑完了 kubeadm init接着又要面对 kubeconfig 配置、RBAC 权限、ServiceAccount 创建这些东西。我把话放在这里一个没有专职运维的团队靠业余时间去啃这些大概率会搭出一个能用但不敢动的集群。它今天能跑但没人知道它哪天会挂因为里面的证书过期时间、etcd 快照周期、节点内存水位都没有人去管。1.2 三台 Master 不等于高可用很多人一上来就搜k8s 三台 master 怎么保证高可用以为多买两台一样的机器、把 kubeadm init 跑三遍就算高可用了。这是非常危险的误解。K8s 控制平面的高可用核心在于 etcd 的 quorum 机制三副本意味着至少两台存活才能选出 leader、才能写入数据。也就是说三台 master 挂了任何一台集群还能撑住但如果网络分区把其中一台隔离了你反而要小心翼翼地判断哪边才是健康的 majority。这还不是最难的。三台 master 前面需要一个负载均衡器把 kubelet、kubectl 的请求分发到三台 apiserver 上。这个入口要是单点控制平面挂了它跟着挂高可用就成了摆设。有人用 Nginx有人用 HAProxy 加 KeepAlived 拟一个 VIP也有人直接买云厂商的 SLB。方案没有绝对对错但每多设计一个组件就多一层需要维护和理解的复杂度。第二个坑是 etcd 本身。三台 master 上各跑一个 etcd 副本看起来是标准做法但 etcd 对磁盘延迟极其敏感如果只给系统盘随便分个区io 一高整个控制平面就跟着抖。我做过的很多集群最后问题不是 K8s 本身而是把 etcd 数据盘和系统盘混在一起导致写满之后集群完全卡死。这些都是看教程学不到的只有真正被生产环境教育过才懂。第三个坑是节点身份。三台 master 初始化之后如果哪台机器的主机名重了或者 kubelet 缓存了旧的 node 信息证书和注册信息会对不上。这种问题报错特别奇怪原因往往藏在一行内核日志里排查成本极高。1.3 概念多、组件杂团队精力被摊薄K8s 上手之后团队面对的是一大串抽象概念Pod、Deployment、StatefulSet、Service、Ingress、ConfigMap、Secret再往深走还有 Operator、CRD、Webhook、RBAC。每个概念都对应一个真实需求但它们叠加起来非常考验人的心智负担。一个小团队如果每个成员都要把这一套全部吃透那基本没有时间写业务代码了。控制器是这里最核心也最容易被忽略的东西。Deployment 管理副本数量的增删ReplicaSet 负责把 Pod 拉到期望数量StatefulSet 管有状态服务的顺序启动和稳定网络标识DaemonSet 负责每个节点上跑一个代理。这些控制器逻辑一旦配置错比如把滚动更新策略设成Recreate线上服务就会在发布瞬间全部中断。而这些策略的含义、适用场景、参数组合很多人在生产出问题之前根本不会认真看。再提一个反直觉的事实K8s 官方控制器只能覆盖通用场景真正常见的业务需求比如定时任务、数据库备份、应用灰度发布都要靠自定义 Operator 去实现。业界已经有很多成熟案例比如用 Operator 管理数据库、管理消息队列、管理监控组件每个 Operator 的调度逻辑都是某个团队花大力气写出来的。对大多数中小团队来说与其从零写 Operator不如先用现成方案把平台跑起来把精力留给真正差异化的业务逻辑。2. Sealos的设计逻辑把复杂度关进引擎盖2.1 本质一个把集群装进镜像的启动器说了这么多 K8s 的难处该说说 Sealos 了。我第一次接触 Sealos 的时候最直观的感受是它把 K8s 当成了一个应用整个集群被封装成镜像安装命令只有一句话。这里的核心思想是镜像即集群。传统装集群你要先准备一堆二进制、配置文件、证书材料Sealos 的思路则是把 kubeadm、kubelet、containerd、etcd 这些组件预先打包到一个集群镜像里通过sealos run一条命令分发到所有节点上。它自动处理 SSH 连接、密钥配置、kubeadm 初始化、容器运行时安装这些脏活十分钟左右就能看到一台 ready 的 master。这有点类似我们平时用 Docker 镜像你不需要关心镜像里的软件是怎么编译出来的只要拉到本地就能运行。Sealos 把这种体验搬到了集群层面。使用者不用再去纠结 kubeadm init 的每个参数也不用担心 token 过期、证书路径写错之类的问题因为这一切都被封装在镜像的启动逻辑里。它的应用层也有同样的设计。Sealos 可以把 Prometheus、MySQL、MinIO 这类常见中间件也打成镜像一条命令部署到集群里。这对于刚上 K8s 的团队特别舒服平台层和应用层的软件保持一致的交付方式团队不再需要同时维护装集群和装应用两套知识体系。2.2 和 kubeadm、KubeKey 比为什么我选了 Sealos很多人会问kubeadm 是官方工具KubeKey 是 KubeSphere 的开源安装器Sealos 比它们强在哪我的回答是强在把安装和后续运营打通了。kubeadm 只负责把集群拉起来起来之后证书续期、节点扩容、集群升级都是另一套命令和流程。Sealos 则提供了完整的生命周期管理sealos scale可以给集群加 master 或 nodesealos reset能干净地销毁集群证书过期也有相对明确的处理路径。这一点对用集群跑业务的团队来说价值远高于安装本身。KubeKey 的优势在于图形化和 KubeSphere 的集成你跟 KubeSphere 生态的绑定会很深。如果你的团队只是想用 K8s 跑自研业务并不想被某个 PaaS 平台的界面限制住那 Sealos 这种偏底层、偏干净的工具反而更合适。它部署出来的集群就是一个原生 Kubelet 集群你后面想接什么管理面板都可以。还有一个现实因素Sealos 的集群镜像仓库里有大量开箱即用的软件镜像比如 Calico、Prometheus、GPU 插件等。这些镜像把组件版本之间的依赖关系都固定好了避免了版本地狱——这是我踩过的最大坑之一单独安装时 A 组件兼容 B 组件但 C 组件只认某个特定版本调了半天才发现是版本组合问题。2.3 使用边界它不是魔法底层还是 K8sSealos 降低的是把一个集群跑起来的难度但集群跑起来之后你仍然面对一个标准的 Kubernetes 集群。K8s 的控制器概念、网络模型、存储管理、安全策略一样都不会少也不可能少。这一点一定要在团队里讲清楚否则就会出现一种幻觉集群是 Sealos 装的那只要是集群的问题都应该用 Sealos 命令解决。实际排查问题时该用kubectl describe、kubectl logs、journalctl -u kubelet的还是要用。Sealos 把复杂度藏进引擎盖但引擎本身谁来定期保养、机油多久换一次最终还是团队自己的职责。我经常用的一个类比是Sealos 相当于给你配了一台一键发车的车它帮你完成了手动挡到自动挡的跨越。但如果你从来不关心仪表盘上有没有报警灯、不按时保养发动机那车迟早还是会半路熄火。所以团队技术负责人要做的是在享受便利的同时至少留一两个人把 K8s 的核心机制吃透保证出大事故的时候有人能打开引擎盖看一眼。3. 实操用 Sealos 从零搭建一套三 Master K8s 集群3.1 环境准备与版本选型先说结论再做解释。我自己最常用的组合是Ubuntu 22.04 Sealos 4.x Kubernetes 1.27 系列 Calico 作为 CNI。核数建议 master 至少 4C8Gnode 按业务需求定但也不要低于 2C4G。正式环境千万别拿 2 核的小机器硬撑控制平面etcd 和 apiserver 在节点一多的时候会非常吃力。准备阶段要做的检查比较固定关闭 swapswapoff -a并注释/etc/fstab里的 swap 行kubelet 默认要求 swap 关闭。确保 SSH 免密可用Sealos 要登录所有目标节点用户需要有 sudo 权限。检查服务器时间ntp 没同步会导致证书校验和事件时间线乱掉。规划好 VIP虚拟 IP如果做三台 master需要有一个和 master 同网段、未被占用的 IP 作为控制平面入口。磁盘规划上建议把 /var/lib/containerd 和 etcd 数据目录通常是 /var/lib/etcd放在独立的数据盘上。多花一点钱换 SSD对集群稳定性的提升会非常明显。我曾经在一台混合部署的机器上看到 etcd 的 fsync 延迟到几百毫秒那个集群每隔十几分钟就会出现一次 controller 选举震荡排查到最后就是磁盘 IO 问题。3.2 一条命令建起高可用集群环境准备好之后安装 Sealos 本身非常快官方文档会提供一条类似这样的脚本curl -sfL https://mirror.sealos.io/install.sh | sh安装完成后可以用sealos version确认版本。接下来就是整个流程最神奇的部分——一条命令建集群sealos run labring/kubernetes:v1.27.0 labring/calico:v3.25.0 \ --masters 192.168.1.101,192.168.1.102,192.168.1.103 \ --nodes 192.168.1.104 \ --vip 192.168.1.100 \ -p your-ssh-password这里我把 192.168.1.101 到 103 作为三个 master104 作为 nodeVIP 用 192.168.1.100。如果你的环境已经配好了 SSH 密钥-p也可以换成密钥方式具体看sealos run --help。这个命令内部做的事情很多先往所有节点推送集群镜像然后配置 containerd 和各类组件再用 kubeadm 初始化第一个 master接着把第二个、第三个 master 以 join 的方式加入并且把高可用入口指向 VIP。期间如果某个节点网络不通或者 SSH 连不上命令会直接失败不会留下一个半死不活的集群状态。跑完后把 kubeconfig 放到本地mkdir -p $HOME/.kube cp /root/.kube/config $HOME/.kube/config然后验证kubectl get nodes kubectl get pods -A如果看到三个 master 都是 Readynode 也是 Ready而且 CoreDNS、Calico 这些 pod 都处于 Running 状态这个集群就算立住了。整个过程比手动走 kubeadm 省掉至少两个小时而且不容易出错。3.3 集群验证与日常命令清单集群搭好之后我建议把下面这一串命令加入团队的初始笔记这是日常使用中最常用的一批操作kubectl get nodes -o wide # 查看节点状态和 IP kubectl get pods -A | grep -v Running # 查看非 Running 的 pod kubectl logs -n namespace pod-name # 看日志 kubectl describe pod pod-name # 看事件和容器状态 kubectl top node # 看资源水位需要 metrics-server kubectl cordon node # 停止节点调度 kubectl drain node --ignore-daemonsets # 驱逐节点 kubectl rollout status deployment/name # 发布状态这些命令不是背的是早晚都要用到的。真正出了问题是pod 一直 CrashLoopBackOff你用 describe 看事件节点 NotReady你去 nodes -o wide 看 IP 和系统信息发布卡住你 rollout status 看进度。命令就那么几十条多敲几次就熟了。另外建议装 metrics-server 或者直接让 Sealos 帮你把监控那套装好否则kubectl top是没有数据可用的。没有资源监控的 K8s 集群就是一个黑盒子节点挤爆了你都不知道是哪个 pod 在吃内存。3.4 顺手把 Prometheus 监控部署了集群能跑了下一步必然是监控。K8s 官方生态里最标准的方案就是 Prometheus Grafana但自己手动部署要准备一堆 Deployment、Service、ConfigMap、ServiceMonitor 的 YAML很多团队在这一步就放弃了。Sealos 的玩法是把这一整套打成镜像sealos run labring/helm-controller:v0.0.7 sealos run labring/prometheus:v1.0.1第一条命令会部署 helm-controller它用来管理后续的 helm 应用第二条把 Prometheus 全家桶装在集群里。装完后检查monitoring命名空间下的 pod能看到 prometheus-operator、alertmanager、grafana 这些组件。这套方案的好处是Prometheus 的抓取配置、告警规则、ServiceMonitor 定义都被 helm 管理好了你不需要手动维护一大堆配置文件。想加自定义告警去 helm values 里加规则或者直接用 ConfigMap 覆盖。这比自己从零搭监控系统节省大量时间。从使用角度看我个人建议团队把 Grafana 的告警接入飞书或企微机器人一旦节点 CPU 超过 80%、Pod 持续重启就能立刻收到通知。监控的价值不在于看板做得有多花哨而在于故障发生前五分钟能有人介入处理。这是被生产事故教育出来的第一课。3.5 让 K8s 调用 GPU从驱动到底层插件很多做 AI 训练的团队最大的痛点就是 GPU 资源怎么被 K8s 调度。问题分两层第一层是节点上的 NVIDIA 驱动和容器运行时必须配合好第二层是 K8s 需要 device plugin 把 GPU 作为可调度资源上报。如果你用的是 Ubuntu 系统先在 node 上装好 NVIDIA 驱动用nvidia-smi确认显卡能被系统识别。然后通过 Sealos 部署 GPU 插件sealos run labring/gpu-operator:latest它会安装 NFDNode Feature Discovery和 NVIDIA Device Plugin让 K8s 把 GPU 资源上报为nvidia.com/gpu。部署完成后用下面这条命令验证节点是否暴露了该资源kubectl get node node-name -o json | jq .status.capacity如果 Json 输出里能看到nvidia.com/gpu: 2说明 GPU 资源已经被 K8s 识别。之后在 Pod 的 resources 里直接声明resources: limits: nvidia.com/gpu: 1调度器就会把 Pod 分配到有 GPU 的节点上。这块有两个特别容易出现的问题。一是驱动版本和 CUDA 版本不匹配Pod 调度上去但容器里跑不起来二是容器运行时配置问题GPU 设备没有正确挂载进容器。排查时先看nvidia-smi再看 kubelet 日志里的 device plugin 状态。要记住Sealos 帮你解决的是部署层面的繁琐但 GPU 本身的驱动兼容问题还得靠团队自己具备基础的底部排查能力。4. 常见问题与排查实录4.1 初始化失败先查环境残留用 Sealos 装集群最常遇到的失败基本集中在三个地方SSH 连接失败、主机名冲突、环境残留。SSH 连接失败时会一直卡在连接阶段要看 nodes 的 IP 是否可达、22 端口是否开放、密码是否正确。如果是之前手动搭过 K8s 的环境/root/.ssh/known_hosts里可能残留了旧的指纹加上-o StrictHostKeyCheckingno可以绕过。环境残留是最隐蔽的坑。一台机器装过以前的 K8s 版本会有残留的/etc/kubernetes、/var/lib/etcd、/var/lib/cni目录。直接再跑 Sealos它可能不会主动清理不干净的状态。我的建议是重装之前sealos reset如果 reset 失败就把残留目录手动删掉再重新跑。宁可多花几分钟清理也不能带着前一套环境的状态硬装。初始化失败还有一个很常见的原因swap 没有真正关闭。有些云镜像默认启用了 swap光swapoff -a只是临时关重启后又回来了。必须把/etc/fstab里的 swap 行注释掉。这个问题非常经典只要节点重启后失联第一反应就检查这里。4.2 VIP 不生效 / 高可用切换异常三台 master 加上 VIP平时看起来一切正常但真正出问题的时候才发现入口没有自动切换这是很多人踩过的坑。排查思路要从两个方向来。先确认 VIP 是否真的在这三台机器上。Sealos 的高可用方案会在 master 之间用 keepalived 或者类似机制维持虚拟 IP正常情况下 VIP 固定落在其中一台。如果 VIP 没出现检查对应的 keepalived 容器是否健康再查防火墙是不是把 VRRP 协议阻断了。再确认切换是否正常。找一个 master 节点用reboot模拟宕机然后看 VIP 是否在几秒内漂移到另一台。如果漂移失败大概率是网卡上配置了多个 IP 导致 keepalived 路由规则混乱或者 VIP 和物理网段冲突。这个测试最好在业务低峰期做并且要有回退方案。高可用切换这一块我一直提醒团队不要只看集群现在稳定就放松警惕最好每个季度主动做一次故障演练。真到故障发生那天才发现 VIP 不会漂移是最被动的局面。4.3 服务对外暴露externalIPs、NodePort 还是 Ingress集群搭好之后团队最常问的问题就是我里面的服务集群外面怎么访问K8s 给了三种主流方式经常有人分不清我在这里把场景拆开讲。第一种是 Service 里的externalIPs字段直接把一个物理机 IP 绑定到 Service 上。适合集群内部有固定负载均衡器 IP、或者服务只需要暴露给内网特定网段的场景。配置很简单在 Service YAML 里写externalIPs: - 192.168.1.200就行不用额外安装组件。第二种是 NodePort把每个节点的某个端口映射到 Service 的端口。适合临时调试因为直接把kubectl get svc显示的 NodePort 端口用节点IP:端口访问就行。但 NodePort 的端口范围默认 30000-32767生产环境如果大量用 NodePort会把节点端口资源耗尽而且每次访问都要过一层 kube-proxy。第三种也是最推荐的Ingress。把流量统一收口到 Ingress Controller再用域名和路径路由到不同 Service。Sealos 里可以直接部署一个 Nginx Ingress Controller 镜像之后所有访问都走固定入口证书管理、限流、灰度的扩展空间都更大。我的建议很简单调试用 NodePort内网固定 IP 用 externalIPs正式对外服务用 Ingress。不要反过来不然以后加域名、加证书、做路径转发的时候会很痛苦。4.4 证书过期等周期性运维K8s 集群有一个最典型的定时炸弹apiserver 证书默认有效期一年。很多团队搭完集群就忘了这回事一年后突然所有 kubectl 命令都返回证书过期错误然后整个业务链路跟着停摆。Sealos 帮你把集群快速建起来但证书续期这件事并没有被自动化。所以团队无论如何要留一个运维日历提醒自己每隔一段时间做证书检查kubeadm certs check-expiration如果发现快过期了执行kubeadm certs renew all systemctl restart kubelet cp /etc/kubernetes/admin.conf $HOME/.kube/config做完这步之后再用同样的方式把 kubeconfig 分发到所有用 kubectl 的地方。这个操作本身不复杂但需要提前确认所有节点的时间同步。如果服务器时间偏差大证书检查会直接误判出现明明刚续期却还是过期的诡异现象。除了证书周期性运维里还有几项不能漏etcd 定期快照与异地备份、节点磁盘空间检查、镜像仓库里的无用镜像清理。这几项虽然老生常谈但真正坚持做下来的团队并不多所有读到这里的团队我都建议不要跳过它们。5. 踩坑心得接入 Sealos 后团队节奏的变化5.1 运维团队的重心转移导入 Sealos 之前团队里负责 K8s 的同事每天忙的都是救火节点挂了去重启、证书过期去续、镜像拉不下来去配 registry。导入之后这些常规操作被一步步自动化了他们的工作重心自然从维护基础设施转向支撑业务运行。这个转变是质变。过去是集群出问题才知道哪里要修现在团队可以把同样的精力用于做容量规划、设计合理的命名空间、完善灰度发布流程。我见过很多团队在踩坑中成长起来了其中关键的一步就是先把集群搭建的重复劳动降下来否则根本没有余力做更上层的事。不过也别说反话集群运维的能力还是要留至少一个人。就像车可以一键启动但你真的敢完全不学驾驶就把车开上高速吗不行的。最好的人员结构是一个人会用journalctl -u kubelet查底层问题剩下的人用 Sealos 把常规操作管好。5.2 开发者自助式使用K8s 有一个矛盾它对业务开发很友好但对底层操作很冷酷。Sealos 在一定程度上改善了这种割裂让开发者不需要关心节点是怎么加进来的只需要知道在集群里如何部署应用。用 Sealos 部署应用后业务开发可以自助地去看监控、看日志、发布新版本。我比较推荐团队把常用的部署流程模板化用 helm 把应用打包好然后让开发者通过一个固定的发布入口来执行。平台自动化程度越高团队能支撑的业务规模就越大而且不会因为人员流动把知识带走。这里需要提醒的是权限一定要分开。开发需要有 deploy 权限的命名空间但不要给他们整个集群的 admin不然某次误操作把 kube-system 里的核心组件删了整个集群都会停摆。我见到过不止一次因为测试环境用的 admin 权限太宽松直接删掉了集群关键组件的乌龙。5.3 给团队的三条建议第一别追求一步到位。先拿 Sealos 搭出一套测试环境把部署、监控、日志这条链路跑通再逐步把业务迁过来。一上来就上生产是最危险的。第二把命令脚本化。所有sealos run的原始命令、版本号、节点规划都要落到 CMDB 或 Git 仓库里。别让这些信息只存在于某个同事的本地 history 里不然没人能复现这套环境。第三持续学习 K8s 核心概念。Sealos 降低了门槛但没有消除知识需求。至少保证团队里有人理解 Deployment 和 StatefulSet 的差异、会调 Calico 网络策略、知道 etcd 备份怎么恢复。把最底层的知识储备住使用任何上层工具都会有底气。就我个人的实际体会来说团队接入 Sealos 之后真正保留下来的价值不是那几条命令而是让团队养成了把复杂度主动封装、主动自动化的习惯。现在新同事入职从零搭建一套可用的生产级 K8s 集群只需要一小时这在过去是不可想象的。K8s 本身依然是那个复杂的 K8s但封装的思路让它变得足够平易近人这大概才是这件事最值得借鉴的地方。
