1. 为什么是Sealos而不是kubeadm装集群这件事的痛点复盘先说说我自己的经历。早些年给客户部署K8s集群用的还是kubeadm那套流程先装容器运行时再初始化控制平面接着配置etcd、Calico网络插件、CoreDNS还得处理证书有效期、镜像仓库加速、负载均衡转发规则……一套流程走下来熟练工也得小半天。如果踩到某个组件版本不匹配的坑直接干到深夜也不算稀奇。所以当Sealos出现在视野里我的第一反应是怀疑一条命令装K8s这靠谱吗实际测试之后我的结论是对于大多数场景Sealos确实把集群安装这件事的复杂度降了一个量级。这篇博文我就以v1.33.6这个新版本为例完整记录一下用Sealos装新版K8s的流程包括踩过的坑和排查思路。1.1 传统安装方式的真实代价kubeadm本身是个优秀的设计但从官方组件到可用集群之间还隔着大量手工步骤。我列一下常规流程里那些容易出问题的环节容器运行时选择和配置containerd版本、systemd_cgroup参数、pause镜像地址每一步都可能因为版本不对齐而报错而且报错信息经常晦涩难懂。服务发现与网络插件Calico、Flannel、Cilium选型后面是一连串的yaml文件需要编辑调整。尤其是涉及Pod网段和Service网段时一旦配置错位集群里的DNS和网络策略就会到处出问题。证书与高可用kubeadm虽然能自动生成证书但kubeconfig文件的分布、CA证书的传递、apiserver负载均衡的配置都需要手动处理。三台master的高可用方案更是让人头疼——VIP、haproxy、keepalived每一样都要独立部署。组件版本矩阵K8s、etcd、containerd、网络插件、crictl工具之间的版本兼容性官方文档虽然有矩阵但实际安装时并不会替你检查问题往往要到运行时才暴露。这些环节不是会不会操作的问题而是有多少种出错方式的问题。对团队来说部署一台集群的隐性成本远不止那几行命令。1.2 Sealos在架构上解决了什么问题Sealos的解决思路很直接把整个集群需要的组件——包括K8s核心组件、容器运行时、网络插件、kubeconfig配置等——预先打包成镜像安装时一次性拉取并编排部署。你可以把Sealos的镜像理解成一个会自解压的集群工具包原来需要手动安装的十几种组件被预置在镜像里安装命令只需要指定目标机器和版本号Sealos会自动完成分发、解压和启动的流程。这比Helm Charts或Ansible脚本更进一步——它不只编排应用连系统层的组件也编排好了。从架构上看Sealos是根据你传入的节点信息自动判断角色分工master还是node然后生成相应的证书、配置文件和系统服务。整个过程对使用者来说是黑盒式的但每一步的输出日志都是透明的方便排查。1.3 和其他安装方式的对比对比维度kubeadm 手工配置SealosKubekey/KubeSpherekind/k3d安装耗时三节点1-3小时10-15分钟30-60分钟5分钟仅单机高可用支持手动配置VIP内置方案支持不支持版本升级手动脉冲Sealos镜像更新支持重建生产环境适用性高需要经验高设计目标中高低偏开发学习曲线陡平缓中等平缓表格里有个比较关键的对比点kind/k3d很快但它们只是测试环境工具并不适合生产。Kubekey本身也是个好工具但和KubeSphere套件耦合较深如果不需要那一层完整的可观测性和DevOps平台反而显得重。Sealos在纯K8s集群安装这个细分领域里定位最精准。2. 安装前的规划v1.33.6版本对应的环境与节点准备不管用多优秀的工具安装前的规划总是少不了的。Sealos能省去的是操作复杂度但版本选型和节点规划的决策责任还是得自己承担。2.1 版本选型和对应关系v1.33.6是Kubernetes在1.33系列里的一个稳定补丁版本。这类版本x.y.z中的z只做bug修复和安全性补丁不会引入新功能所以作为生产版本是相对稳妥的。Sealos这边的版本组织方式是每个K8s版本对应一个Sealos镜像名格式一般是labring/kubernetes:v1.33.6。安装时直接在命令里引用这个镜像即可。这里有个容易忽略的细节Sealos本身是个独立工具有自己的版本号。旧版本Sealos的兼容性列表不一定覆盖最新的K8s版本。所以在装v1.33.6之前务必先把Sealos升级到较新版本。我的建议是直接用官方安装脚本装最新稳定版避免因为Sealos版本过旧导致镜像解析失败。关注项推荐配置/版本操作系统Ubuntu 22.04/24.04 LTS、CentOS 7.9、openEuler、Debian系均可内核5.4生产环境建议5.15 LTS内核Sealos版本官方最新稳定版脚本安装即可K8s镜像labring/kubernetes:v1.33.6以实际拉取时可用镜像为准架构amd64为主arm64支持需确认镜像存在2.2 节点规划高可用与资源预判在官方文档里Sealos支持单master测试用和多master生产建议至少3台两种模式。三台master的高可用方案中Sealos内置的方式是在多master节点之间配置负载均衡转发类似VIP机制控制平面的apiserver通过这个入口对外提供服务任意一台master宕机不影响API服务。我的建议是下面这样的规划读者可以按需调整角色数量最低配置建议配置用途master12C/4G4C/16G测试或小型项目master34C/8G8C/16G生产高可用master3 worker 34C/8G 8C/32G生产高可用业务扩展资源预判有个经验值可以分享如果业务有100个Pod左右3台8C16G的节点是比较轻松的如果还要跑Prometheus这类监控组件内存预算至少再翻一倍。另外如果业务里要调GPU热搜词里有k8s调用gpu建议在规划节点时提前分好GPU节点标签worker节点里单独划出一组带GPU的机器并用nodeSelector或污点容忍机制管理Pod调度避免普通业务挤占GPU资源。2.3 系统初始化四步操作不能省在跑Sealos之前新的机器最好先做一遍系统初始化虽然Sealos会处理一部分但下面四件事我建议手动做掉能规避大量莫名其妙的问题设置主机名和hosts解析master和node节点的主机名不能重复修改/etc/hosts添加各节点IP和主机名的映射。这一步看似简单漏掉的话kubelet在节点注册时经常出现证书SAN不匹配的报错。关闭swapswapoff -a并且注释掉/etc/fstab里的swap行。K8s从1.22开始支持swap但生产环境为了性能和稳定性默认仍然建议关闭。同步时间集群内节点时间偏差超过一定范围证书验证会失败。建议配置chrony或systemd-timesyncd对齐到同一时间源。确认防火墙放行端口如果开了iptables或firewalld需要放行K8s和Sealos所需的端口否则节点加入时会失败。方向端口范围用途master之间2379-2380etcd通信master之间6443kube-apiserver节点之间10250kubelet指标和命令执行节点之间10255kubelet只读端口旧版本节点之间30000-32767NodePort服务端口master入站179Calico BGP如果使用BGP模式这里有个细节有些云厂商的安全组默认全放行内网本地机房部署则必须严格检查这些端口。我在真实项目里遇到过一次节点加入失败折腾了很久最后定位是安全组没放行10250端口导致的。3. 手把手安装流程从空机器到集群可用的完整命令规划好之后安装流程本身其实非常简单我把每一步都记录下来。3.1 安装Sealos命令行工具在一台管理机上安装Sealos即可这台机器不需要加入集群只作为远程操作入口。如果你习惯在某个master节点上管理装在那里也完全没问题。官方提供了脚本安装方式curl -sfL https://mirrors.syseleven.de/sealos/install/v4.0.0/sealos-4.0.0-linux-amd64.tar.gz | sudo tar zx -C /usr/local/bin sudo sealos version因为安装地址属于官方提供的标准路径不同区域的用户可能访问速度不同如果脚本超时也可以直接从GitHub Release页面下载对应架构的二进制包手动解压到/usr/local/bin后chmod x即可。验证输出类似这样clientVersion: version: v4.x.x ...看到版本号输出就说明安装成功了。这里提醒一句版本号比预期的旧时一定要先升级我遇到过直接在老版本v4.0.0上安装新K8s镜像导致解析失败的场景升级Sealos后问题立刻消失。3.2 一条命令拉起v1.33.6集群假设我有三台机器master节点192.168.1.10、192.168.1.11、192.168.1.12node节点192.168.1.20、192.168.1.21SSH密钥已经配置好或者用密码统一执行sudo sealos run labring/kubernetes:v1.33.6 \ --masters 192.168.1.10,192.168.1.11,192.168.1.12 \ --nodes 192.168.1.20,192.168.1.21 \ -p your-ssh-password解释一下各参数的含义labring/kubernetes:v1.33.6Sealos镜像名包含完整K8s组件。--mastersmaster节点IP列表逗号分隔。传多个IP时Sealos会自动配置高可用模式。--nodesworker节点IP列表。-pSSH密码。生产环境建议改用-k ~/.ssh/id_rsa指定私钥路径避免密码出现在shell历史记录里。如果想用私钥免密登录sudo sealos run labring/kubernetes:v1.33.6 \ --masters 192.168.1.10,192.168.1.11,192.168.1.12 \ --nodes 192.168.1.20,192.168.1.21 \ -k ~/.ssh/id_rsa执行之后Sealos会先检查节点连通性包括SSH端口、系统发行版、磁盘空间等然后开始拉取镜像并安装组件。这个过程大概10-15分钟日志会逐步显示初始化进度像这样Init cluster ... - Installing docker - Installing kubernetes - Installing network plugin ... Cluster installed successfully!看到最后这行输出基本就可以收工了。3.3 验证集群状态与访问Dashboard安装完成后首先在管理机上配置一下kubeconfigmkdir -p ~/.kube sudo cp /root/.kube/config ~/.kube/config chmod 644 ~/.kube/config然后验证节点状态kubectl get nodes NAME STATUS ROLES AGE VERSION 192.168.1.10 Ready control-plane 5m v1.33.6 192.168.1.11 Ready control-plane 5m v1.33.6 192.168.1.12 Ready control-plane 5m v1.33.6 192.168.1.20 Ready none 5m v1.33.6 192.168.1.21 Ready none 5m v1.33.6看到所有节点Ready集群就算真正跑起来了。接下来装一个Dashboard方便日常查看sudo sealos run labring/kubernetes-dashboard:v1.10.1 kubectl -n kubernetes-dashboard get svcSealos生态里另一个非常实用的点是可以直接用Sealos部署Helm和Prometheus这类配套组件sudo sealos run labring/helm:v3.14.0 sudo sealos run labring/prometheus-operator:v1.0.0如果想规划GPU调度那配套节点上的nvidia驱动和device plugin属于另一步工作。Sealos社区有对应的镜像方案也可以直接用Helm安装NVIDIA device plugin这个我在后面章节补充说明。4. 集群扩容与日常运维从装起来到用起来集群装好了只是第一步日常运维中的扩容、缩容、清理、升级才是真正考验工具顺手程度的地方。Sealos这几个常用操作我都实测过。4.1 添加节点加到既有集群里扩容一个worker节点sudo sealos add --nodes 192.168.1.22也可以一次性加一组sudo sealos add --nodes 192.168.1.22,192.168.1.23 -p your-ssh-passwordSealos会按照原来集群的配置把kubelet、kube-proxy、网络插件等组件分发到新节点并启动。整个过程大约3-5分钟完成后直接kubectl get nodes就能看到新节点加入。添加master节点的命令类似sudo sealos add --masters 192.168.1.13这里有个血的教训添加master节点前务必确认新master的hostname跟已有的任何节点都不重复否则kubelet注册时会跟旧节点冲突证书也会生成错乱。我在测试环境踩过这个坑最后只能清掉那个节点重新加入。删除节点也有对等命令sudo sealos delete --nodes 192.168.1.22 sudo sealos delete --masters 192.168.1.13删除前建议手动执行kubectl drain将Pod驱逐干净Sealos虽然会做Cordon操作但有些长耗时任务还是建议业务侧先处理避免数据不一致。4.2 集群清理与重建一条命令回到起点开发环境版本迭代频繁装坏了重来是最高频的需求。Sealos提供了reset命令sudo sealos reset这条命令会把所有节点上的K8s组件、配置、数据目录全部清空回到装之前的状态。如果你的集群还跑着重要的存储类应用请务必做好数据备份reset会清理/var/lib/etcd等目录。重置单节点也是同样的命令只需在目标节点上执行。实测下来reset比手动删除然后重新加入要干净得多不会残留证书文件或service文件干扰下次安装。4.3 升级K8s小版本的思路小版本升级比如v1.33.6升到v1.33.7在Sealos里思路很清晰直接重新run一次新版本镜像。Sealos会检测当前集群版本执行相应的升级流程保留已有工作负载。sudo sealos run labring/kubernetes:v1.33.7不过大版本升级比如v1.33升级到v1.34我的建议是先在测试集群验证一遍因为Sealos镜像升级逻辑依赖K8s官方的版本升级路径跨大版本时API组的变动风险还是得靠业务验证兜底。5. 安装路上我知道的坑v1.33.x系列实测问题与排查思路工具再顺手也不是完全一帆风顺。以下是我在测试和真实部署v1.33.x版本过程中实际遇到的问题以及对应的排查路径。这些内容官方文档不一定写得很详细但遇到了能省下大量时间。5.1 内核版本太低导致网络插件异常现象集群初始化成功节点也显示Ready但Pod之间网络不通。查看Calico的Pod日志会看到关于conntrack或者nf_conntrack相关的错误。原因CentOS 7.9默认内核3.10对于K8s v1.33版本来说实在太旧了尤其是Calico的iptables和eBPF相关特性对内核版本有明确要求。处理把内核升级到5.15或者直接选用Ubuntu 22.04/24.04这类自带新内核的系统。这个坑在安装工具层解决不了属于操作系统选型问题建议装新版K8s时直接用新系统。5.2 cgroup驱动不一致导致kubelet启动失败现象节点加入失败kubelet服务处于failed状态。查看日志journalctl -u kubelet能看到failed to run Kubelet: failed to validate kubelet flags之类的信息。原因系统里的容器运行时containerd/Docker如果默认cgroup驱动是cgroupfs而kubelet默认期望systemd两者的不一致会直接阻止kubelet启动。kubeadm时代这个问题需要手动改配置文件Sealos的镜像一般已经内置处理好但如果你是在已有运行时环境的旧机器上跑的就可能冲突。处理清理掉机器上原有的Docker/containerd配置让Sealos统一管理运行时。这也是为什么我建议用原生的干净系统装集群避免环境冲突。5.3 镜像拉取超时现象执行sealos run时卡在拉取镜像阶段最终报context deadline exceeded或failed to pull image。原因一是网络环境访问镜像源不稳定不同地区确实存在差异二是节点磁盘空间不足导致拉取失败。处理第一步先清理空间df -h确认磁盘余量第二步如果确实因为网络因素可以考虑在节点上配置可用的镜像加速源但要注意镜像完整性校验。我的实际经验是优先选择就近的云节点或调整Sealos的镜像仓库配置而不是反复重试同一条命令。5.4 节点加入时hang住没有进展现象sealos run或sealos add执行到某一步后一直卡住日志停在一个位置不再更新。排查链路我验证过的顺序先确认SSH连通性ssh usernode能登录不代表Sealos用的通道没问题注意检查是否是root登录、是否被限制了命令执行。检查节点上的Sealos服务日志Sealos会把安装过程分步记录在节点日志里优先看目标节点上是否有挂起的进程。确认网络telnet 192.168.1.10 6443检查apiserver端口是否监听。对于新加节点还要检查10250端口是否可达。最后再检查版本兼容性用kubectl version确认server端版本与镜像版本一致。一般来说按这个顺序排查95%的问题都能定位。最忌讳的是跳过SSH连通性检查直接重装那大概率浪费时间。5.5 高可用模式下VIP不生效多master安装完成后我遇到过客户端访问VIP偶尔超时的情况。原因大多在负载均衡转发规则没有正确下发或者VIP绑定网卡未设置promiscuous模式云环境下需要确认安全组是否拦截。排查方法很简单在master节点上ip a查看VIP是否绑定成功然后从外部机器curl https://VIP:6443/version测试连通性。如果VIP没绑定重新执行Sealos的LB组件初始化和配置步骤即可如果VIP已绑定但外部不通优先检查防火墙。6. 装完后我建议立刻做的事集群装完不等于交付完成。从我维护生产集群的经验看下面这几件事一定要尽早做不然用着用着就会埋雷。6.1 给节点打标签和污点刚装好的集群所有worker节点都是裸的没有任何调度限制。建议立刻把节点按用途打上标签kubectl label node 192.168.1.20 node-role.kubernetes.io/gputrue kubectl label node 192.168.1.21 node-role.kubernetes.io/statefultrue需要隔离某些资源时给节点打污点kubectl taint nodes 192.168.1.20 dedicatedgpu:NoSchedule这样普通业务不会误调度到GPU机器上有GPU需求的工作负载再通过容忍度toleration来调度过去。尤其是k8s调用gpu这个场景污点和标签的组合是必须做好的前置规划。6.2 配置RBAC和命名空间策略Sealos默认安装的集群没有做细粒度的权限控制所有操作都走admin。如果团队多人共用一个集群建议尽早划分命名空间并创建对应的ServiceAccount和RBAC绑定。我曾经见过一个误操作执行kubectl delete ns导致整个环境被清掉的事故从那以后我每套集群都会先建好开发、测试、生产三个命名空间并配上权限边界。6.3 部署监控链路热搜词里出现k8s部署prometheus不是偶然这确实是集群交付后的标配。用Sealos装Prometheus栈也很方便sudo sealos run labring/prometheus-operator:v1.0.0安装后通过Dashboard或Grafana观察节点CPU、内存、磁盘IO、网络流量。我的经验是监控的告警规则不要一开始就配太细先把节点层和集群组件层的告警跑起来业务层告警等稳定运行一两个迭代再逐步补充。6.4 规划备份策略etcd备份是K8s运维的底线。建议每天凌晨备份一次etcd快照到本地和异地存储。Sealos集群的etcd数据在master节点的/var/lib/etcd目录可以用etcdctl手动做快照也可以直接用Velero这类工具做整个集群的备份。没有备份的高可用集群只能说是一个看起来高可用的集群。7. 个人体会与最后的小技巧用Sealos装K8s这件事我的最大感受是它把集群生命周期管理里最烦人的部分——环境准备、组件编排、版本对齐、证书生成——封装成了标准动作让我能把精力放到真正需要思考的业务架构和技术选型上。最后分享两个我自己总结的小技巧。第一个是关于脚本化交付。把整套安装过程写成一个可重复执行的脚本或配置文件是非常值得的。Sealos支持用Clusterfile定义整个集群的规格节点列表、镜像版本、SSH信息把这个文件放进Git仓库以后不管是灾难恢复还是环境重建一条命令就能拉起一套一模一样的集群。这对于频繁搭建新环境或做交付项目的团队尤其有用。第二个是关于版本锁定。在Clusterfile或安装脚本里明确锁定Sealos和K8s的版本号不要用latest或v4.x这种模糊引用。我见过因为自动拉取到新版镜像导致升级意外触发的情况对生产环境来说可控永远比最新更重要。如果你正打算从kubeadm迁移到工具化安装或者第一次尝试搭建K8s集群建议先在虚拟机里用Sealos跑通一遍v1.33.6的完整流程感受一下从空机器到可用集群的整个时间开销。等你熟练了再上生产环境会从容很多。