最近刚把公司内网一批业务从 Rancher 管理的 Kubernetes 集群迁移到了 Sealos 私有化集群上。原本以为只是换一个管理面板没想到牵扯出资源梳理、存储卷处理、中间件数据搬迁和流量切换一整套活。整个过程比预想中琐碎但落地之后回头看这笔账是算得过来的。这篇东西就当一次复盘把从 Rancher 迁到 Sealos 的完整思路、关键步骤和踩过的坑都整理出来给正在评估或者已经准备动手做私有化迁移的同行一个参考。先说结论如果你手里只有一两套 K8s 集群Rancher 的集群管理能力其实够用但如果你要做的是面向公司内部或者交付客户的私有化平台需要的是一个自带镜像仓库、应用编排和中间件管理能力的整体底座这时候 Sealos 这种“云操作系统”形态的私有化方案会更顺手。迁移的核心工作不是把 YAML 复制过去而是把资源依赖、数据存储、网络策略这些隐性资产一起搬过去。1. 为什么选择从 Rancher 迁移到 Sealos1.1 Rancher 用着不差但痛点很真实Rancher 在 Kubernetes 圈子里名气很大它解决的是“多个集群集中管理”的问题。一个控制平面可以接入几十个下游集群统一做 RBAC、项目管理、应用目录和监控告警这在多集群规模下确实方便。我之前的团队从单集群起步慢慢扩展到开发、测试、预发三套环境Rancher 帮我们省了不少心。但随着做私有化交付的需求变多Rancher 的一些问题开始冒头。首先是它本身是一套比较重的控制系统Rancher Server 部署在集群里有自己的 CRD、Controller、Agent升级的时候要考虑版本匹配问题一旦控制面出问题下游集群的日常管理也会跟着受影响。其次是 Rancher 的管理面和应用交付面是分离的部署一个业务应用你仍然需要先写 Dockerfile、构建镜像、再写 Deployment/Service/Ingress然后还要配一套 CI 流程说白了它还是一个“Kubernetes 管理器”不是“应用交付平台”。另一个让我下定决心迁移的原因是资源利用率。Rancher 默认会在每个下游集群安装一组 agent加上 logging、monitoring、catalog 等一堆组件一台 8C16G 的机器跑控制面加组件后剩下的资源明显缩水。对于中小规模团队来说这个开销不小。1.2 Sealos 私有化的定位正好不一样Sealos 的定位是“云操作系统”底层依然是 Kubernetes但它在 K8s 之上做了一层应用交付和资源管理抽象。部署完 Sealos 之后你得到的不只是一个容器编排平台而是一个自带镜像仓库、应用商店、可观测面板和数据库中间件一键部署能力的底座。私有化场景里最看重的就是“开箱即用”和“离线交付”。Sealos 的集群安装本身支持离线包把镜像包导入内置 registry 后整个环境完全脱离公网也能正常工作这对内网部署和客户环境交付是刚需。另一个让我觉得差异明显的是应用商店里面对齐了很多常用中间件比如 MySQL、PostgreSQL、Redis、MinIO、Nginx通过图形化界面或者命令行就能拉起这对 Rancher 里的 catalog 来说操作体验根本不在一个层级。还有一个比较关键的对比点Rancher 为了方便多集群纳管会往命名空间、工作负载里注入自己的一堆注解和 CRD 引用你导出 YAML 再往别的集群导经常因为字段不兼容要逐个清洗。而 Sealos 本身就是直接操作原生 Kubernetes 对象资源声明更干净迁移成本天然就低一些。1.3 选型对比不只看功能还要看迁移后的运维模型我整理了一张对比表能比较直观地看出两者在私有化交付场景下的侧重差异对比维度RancherSealos核心定位Kubernetes 多集群管理平台基于 K8s 的应用交付底座私有化离线交付需要额外搭建内网镜像仓库并处理组件依赖自带镜像仓库和离线包机制应用部署模式写 YAML Helm依赖外部工具链应用商店 封装格式开箱即用中间件管理需要自己维护 operator 和存储一键部署常见数据库和消息队列资源开销控制面组件占比较高轻量资源集中在业务 Pod对原生 K8s 资源的侵入性注入大量 cattle 相关字段保持原生对象几乎无侵入选型的逻辑很简单如果团队的核心诉求是“管 K8s 集群”Rancher 依然是很好的选择如果诉求是“搭建一套可持续交付的私有化平台”Sealos 的架构形态更对路。我们迁移的根本原因就是要把平台能力从“K8s 管理”上升到“应用交付和运维一体化”。2. 迁移前准备工作盘点资产和确定策略2.1 先把 Rancher 里的家底全部摸清楚迁移前最怕漏掉东西第一步就是把 Rancher 管理的所有业务资产完整盘点一遍。我会按以下几个维度来梳理工作负载所有 Deployment、StatefulSet、DaemonSet记录命名空间、副本数、镜像地址、资源 request/limit。服务暴露Service、Ingress、ServiceEntry 和证书配置特别是 HTTPS 证书的签发方式Rancher 里常用 cert-manager 还是自定义 Secret。配置数据ConfigMap、Secret这部分最容易迁移也最容易被忽略。存储资源PVC、StorageClass记录每块存储的容量、访问模式、底层存储类型local-path、NFS、云盘。基础组件DNS、网关、日志收集、监控告警确认这些是 Rancher 自带的还是独立部署的。中间件数据库、缓存、队列确认连接地址是否已经写在业务配置里还是通过服务名解析。我这次迁移的规模大概是 30 个命名空间、120 多个服务其中包括三套 PostgreSQL、两套 MySQL、一个 Redis 集群、一个 MinIO 对象存储以及一批无状态 Java 和 Go 服务。盘点之后才发现很多服务之间存在隐式依赖比如业务服务直接通过 PVC 挂载共享目录或者某个 ConfigMap 里硬编码了另一个服务的 IP。2.2 规划目标集群资源避免迁到一半资源不够Sealos 私有化集群的节点规划不能拍脑袋。迁移时要保留一定的扩容余量建议按原集群资源的 1.2 到 1.5 倍来准备。比如原来 120 个服务加起来要 80 核 160G 内存新集群至少准备 100 核 200G 内存。节点划分也建议明确角色Master 节点跑控制面组件承担调度和 API 服务Worker 节点跑业务负载。如果业务里有数据库这类有状态服务建议单独挂一块 SSD 数据盘存储类单独定义避免和日志型应用抢 I/O。另外节点之间注意网络互通私有化环境通常要提前规划好网段避免 Docker 网段和业务网段冲突。存储这块要提前想清楚。原 Rancher 集群如果用的是 local-path-provisioner数据落在各节点本地目录上迁移后要把这些磁盘数据转移过去或者直接把旧磁盘挂载到新机器上如果用 NFS搭建新环境的 NFS 要做好权限映射。总之存储改造是迁移里最容易翻车的点我会在后面单独展开。2.3 设计迁移批次和回退方案一般建议分批迁移而不是一次性全量切换。我采用的策略是三个批次第一批迁无状态应用比如前端静态资源、网关接口、定时任务验证新集群的网络和 Ingress 是否正常。 第二批迁有状态中间件比如数据库、Redis、对象存储这部分涉及数据同步需要预留充足时间窗口。 第三批迁对稳定性要求最高的核心链路确认前两批没有问题之后再做最后切换。每一批迁移都要有回退方案。比如数据库迁移前保留原集群数据并同时开启增量同步万一导入出问题可以切回去。业务层通过负载均衡或者 DNS 权重逐步切流量观察日志和监控指标没有异常再完全切干净。3. Sealos 私有化部署的实操记录3.1 节点环境准备和离线包下载Sealos 的私有化部署在离线环境里非常顺但前提是提前准备好安装介质。我实际用到的核心组件是labring/kubernetes、labring/helm、labring/cert-manager、labring/sealos自带的内置 registry以及应用商店相关的镜像包。在有网的环境下先把这些镜像通过sealos pull拉到本地然后打成人sealos load导入目标机器。我准备了三台机器一台 Master两台 Worker操作系统是 CentOS 7.9内核版本需要确认支持 Kubernetes 的网络要求。所有节点关闭 swap配置好主机名和 hosts 解析然后安装容器运行时。Sealos 支持 containerd 作为运行时配置比较简单只需要确认sandbox_image可以正常拉取。这一步有一个很关键的注意点所有节点的时钟必须同步建议搭一个内网 NTP 服务否则节点之间证书校验会报错排查起来非常耗时。3.2 用 Clusterfile 声明集群并一键安装Sealos 部署集群可以通过命令行直接指定节点也可以写一个 Clusterfile。我用的是 Clusterfile 的方式好处是配置可以保存下来后续扩容就基于这个文件改一改再执行。下面是我实际使用的 Clusterfile 核心内容Hosts 部分定义节点角色和地址后面接 SSH 认证信息。apiVersion: v1beta1 kind: Cluster metadata: name: my-private-cluster spec: hosts: - name: master01 role: master address: 192.168.10.21 user: root passwd: YourStrongPassword arch: amd64 - name: worker01 role: node address: 192.168.10.22 user: root passwd: YourStrongPassword arch: amd64 - name: worker02 role: node address: 192.168.10.23 user: root passwd: YourStrongPassword arch: amd64 ssh: passwd: YourStrongPassword port: 22然后执行安装命令指定要装的 Kubernetes 版本和辅助组件sealos run labring/kubernetes:v1.31.4 \ labring/helm:v3.14.4 \ labring/cert-manager:v1.15.0 \ --cluster my-private-cluster整个过程大概十分钟左右日志会输出每个节点的执行情况。安装完成之后kubectl get node应该能看到所有节点 Ready。3.3 内置镜像仓库和应用商店的启用Sealos 自带镜像仓库这一点在私有化场景里太省心了。部署完成后集群内部会有一个 registry 服务可以手动上传镜像包。日常发布流程里构建机把镜像推到 Sealos 的 registry业务节点拉镜像时走的就是没网也能拉取的内网地址不会再因为公网拉取受限而失败。应用商店是一大亮点。私有化平台经常要部署 Redis、MySQL 这类基础组件如果靠手写 operator 和 YAML工作量大还容易出错。Sealos 的应用商店里提供了一键部署的入口我这边直接通过商店拉起了一套 Redis 和一个 MinIO耗时比从 Rancher 的 catalog 里装快很多状态管理也更直观。不过有一点要注意在离线环境里要用应用商店需要先把商店对应的应用镜像导入内置 registry否则页面客户端会提示找不到镜像。这个步骤我一开始没注意导致后面点安装老是卡在拉镜像后来手动导入镜像包才恢复正常。3.4 存储类和证书的提前配置存储是迁移成功与否的关键。我在 Sealos 集群上提前定义了两个 StorageClass一个用本地盘做默认存储给无状态服务配 PVC一个用 NFS 给有状态中间件提供共享存储比如 MinIO 的持久化目录。NFS 的配置过程中我踩过一个坑新机器上挂载 NFS 时权限锁死容器进程运行用户是 nobody 或者 65534写不进去数据目录。解决办法是设置 NFS 服务端导出目录时指定no_root_squash同时把目录属主改成容器运行用户 UID然后在 StorageClass 里挂载时不要强制改属主。证书这边我直接复用 cert-manager 的流程。Sealos 集群里部署好 cert-manager然后创建 ClusterIssuer内部域名签发用自签名 CA外部域名则对接已有的内网 CA。这样可以保证 HTTPS 证书在迁移后无缝衔接。4. 从 Rancher 导出资源并迁入 Sealos 集群4.1 清洗 Rancher 注入的 CRD 字段和注解Rancher 在命名空间上会打上field.cattle.io/projectId这类注解工作负载里也会出现cattle.io/timestamp或者 ownerReferences 指向 Rancher 管理的 CRD。这些字段在目标集群中大多无效直接 apply 虽然不一定报错但会干扰后续的资源管理和回收。我在每个命名空间执行一次完整导出kubectl get deploy,sts,ds,svc,cm,secret,pvc,ingress -n app-namespace -o yaml app-namespace-backup.yaml然后写了一个简单的 Python 脚本来做字段清理重点删除以下内容metadata.uid、metadata.resourceVersion、metadata.generation、metadata.creationTimestampmetadata.managedFields这整个数组metadata.annotations里所有以field.cattle.io和cattle.io开头的键metadata.ownerReferences指向非原生资源的引用Deployment 里status整个段这个只是运行时状态导入时会自动重新生成清洗的时候要留意有些注解虽然带 cattle 前缀但业务可能依赖比如某些灰度发布配置。稳妥的做法是保留名单机制先拉一个常见删除清单确认无副作用后再批量执行。4.2 适配目标集群的镜像地址和存储类清洗完字段之后第二步是全局替换镜像地址。原 Rancher 集群的镜像放在公网仓库或者公司旧的内网 registry迁移后统一指向 Sealos 内置 registry。替换方法不复杂用 sed 批量处理 YAML 中的镜像前缀sed -i s#old-registry.example.com#registry.sealos.svc.cluster.local:5000#g app-namespace-backup.yaml但有一点要注意不同命名空间拉取镜像的 Secret 可能不同。如果是私有镜像要将原 registry 的 docker-registry Secret 重新创建到 Sealos 集群对应命名空间否则 Pod 启动会报 ImagePullBackOff。存储类的替换更直接把 PVC 定义里的storageClassName从原来的local-path改成目标集群实际存在的存储类名比如nfs-storage。如果原 PVC 容量比较大需要确认目标存储类支持动态扩容否则只能预先按规格创建 PV再通过 label 匹配绑定。4.3 处理 Ingress 和 Service 的访问关系Rancher 的 Ingress 依赖它自己实现的 nginx-ingress 或 Traefik而 Sealos 默认的网关层可能不同因此 IngressClass 要重新指定。我把 PYC 里所有 Ingress 的删除kubernetes.io/ingress.class注解中的旧值在spec.ingressClassName字段填上 Sealos 集群的platform-navigation-ingress或默认网关类Service 本身的 ClusterIP 会变化但集群内通过服务名访问不受影响因为 DNS 解析走的是服务名。要重点检查的是跨集群调用有没有硬编码 IP 的地方比如某些业务配置里写了192.168.10.5:3306这类地址这类地址必须改成新集群中对应服务的对外地址或者集群内服务名。4.4 批量 apply 和资源校验清洗完的 YAML 文件放在一个目录里然后逐个命名空间进行校验和应用kubectl create --dry-runclient -f app-namespace-cleaned.yaml kubectl apply -f app-namespace-cleaned.yaml先跑 dry-run 的目的是尽早在客户端侧发现字段非法或不兼容的问题。批量 apply 之后等 Pod 拉起来检查 PVC 是否 Binding、Service 的 Endpoints 是否正常、Ingress 是否得到地址。我实际导入之后发现部分 Deployment 的 imagePullPolicy 被 Rancher 改写成了 Always导致在离线环境里每次启动都要检查镜像是否存在心跳。这个改为 IfNotPresent 能显著降低拉取延迟也避免网络抖动引起的拉取失败。5. 数据迁移数据库、对象存储和共享目录5.1 数据库迁移要用逻辑导出导入而不是直接搬文件数据库迁移是整个项目里风险最高的环节。我处理了三套 PostgreSQL 和两套 MySQL统一采用逻辑导出导入的方式而不是直接拷贝数据文件这样避免版本兼容性和文件权限问题。MySQL 迁移流程mysqldump -h old-mysql -u root -p --single-transaction --routines --triggers --events --databases db1 db2 db-backup.sql mysql -h new-mysql -u root -p db-backup.sqlPostgreSQL 迁移流程pg_dump -h old-pg -U postgres -d dbname --no-owner -F c dbname.dump pg_restore -h new-pg -U postgres -d dbname --no-owner dbname.dump注意几个细节一是--single-transaction保证 MySQL 导出时的一致性视图避免出现数据中途修改导致备份不一致二是--no-owner解决新旧环境数据库用户名不一致导致的权限问题三是大表一定要分库分表导出不要一把梭全库一次性 dump否则恢复时间太长还会因为某个表出问题被迫从头再来。数据导入完成之后要立刻做表结构和行数对比我写了一个对比脚本遍历每张表统计COUNT(*)与原库做差值。另外跑几个关键业务查询确认索引和存储过程都正常。5.2 Redis 和对象存储的快速迁移Redis 迁移用redis-cli --pipe做全量填充。源库是集群模式下就用redis-cli -c导出格式用MIGRATE脚本或者直接RDB再导入。小数据集下直接取 RDB 文件复制过去再重启最省事但要注意版本Redis 6 和 7 的 RDB 格式多数不通用。安全起见我用dump.rdb的方式时会先匹配版本号。MinIO 这类对象存储我用的是mc mirror命令做同步mc mirror --overwrite --remove source-bucket/ minio-target/bucket/同步完成之后记得做一次抽查对比几个大文件的 ETag 是否一致避免传输中损坏。5.3 共享目录和 PVC 数据怎么处理无状态服务的 PVC 数据量不大可以直接重建空 PVC 再复制数据。但如果是共享目录比如多个服务共用一个 NFS 挂载的目录迁移时要注意保持目录结构和属主一致。我先在旧节点上打包共享目录tar czvf shared-data.tar.gz -C /data shared然后在目标节点上解压并将目录属主改成容器运行的 UID。如果是 NFS先确认目标 NFS 服务端的目录挂载属性避免权限拒绝。还有一类比较特殊的情况服务在启动时对临时目录有大量写入旧集群里用hostPath挂载。我迁移时改成新集群里统一的 StorageClass 动态分配 PVC避免节点重启后数据丢失也不用再和具体节点绑定。6. 流量切换、灰度验证与原集群下线6.1 低风险流量切换到新集群的方式内部服务切流量的方式我做了两种有域名入口的通过 DNS 解析把权重逐步调向新集群的负载均衡 IP没有域名只有集群内访问的直接改动上游调用方配置指向新服务名然后滚动重启上游服务。为了豁免 DNS 缓存对灰度验证的干扰我在切换前先在本地/etc/hosts里把域名指向新集群验证核心链路。之后再改 DNS 的 A 记录权重先切 10%观察告警和接口错误率稳定后切到 50%最后全部切过去。6.2 数据校验必需的清单切换完成后一定要按清单逐项验证而不是简单看 Pod 状态。我用的是下面这个表检查项检查方法Pod 状态所有业务容器 Running无 CrashLoopBackOff服务发现kubectl get endpoints确认对应 Pod IP 已注册PVC 挂载kubectl get pvc状态为 BoundPod 可读写测试数据库连接业务日志无 connection refused 报错定时任务到点后检查任务执行记录和输出日志监控告警基础监控无新增 P1/P2 告警6.3 回退方案和原集群下线时机灰度期间保留原 Rancher 集群不关停数据库有新数据写入时通过增量同步或者业务双向写入过渡。等新集群稳定跑一周以上再把数据库的写流量切过去旧库改成只读模式业务侧验证无异常后才彻底下线。下线前要把旧集群里的 PVC 数据做一次最终备份以防后续审计或追查需要。Rancher 控制面本身不急于删除建议保留到所有业务验证通过并且旧集群的证书、监控、日志等附属系统不再被依赖以后再清理。7. 迁移之后常见问题速查表把这次迁移中实际遇到的几个典型问题整理成一张速查表很多问题都是迁移到新 K8s 环境都会遇到的供参考现象可能原因解决办法Pod 一直 PendingPVC 未绑定或存储类不存在检查 StorageClass 名称重提 PVC 或预建 PVImagePullBackOff镜像在 registry 中不存在导入镜像或者修改镜像标签地址为内置 registry服务间访问超时DNS 解析失败或集群网络策略拦截检查 CoreDNS 配置确认没有残留旧的 hosts 记录Ingress 404IngressClass 不匹配或证书 Secret 没同步删除旧注解设置新的ingressClassName数据库写入权限报错迁移时丢失用户权限授权重新执行GRANT授权更新业务账号密码容器写入目录无权限NFS 导出目录是 root squash调整 NFS 配置no_root_squash或修改属主 UID还有一个容易被忽略的地方Rancher 的命名空间默认带项目隔离策略迁移到 Sealos 后如果不做 NetworkPolicy 限制所有服务之间默认全通。从安全视角看建议对照原 Rancher 项目空间的隔离关系把核心业务命名空间之间用 NetworkPolicy 显式约束好避免新环境网络面被放大。8. 一点个人体会这次迁移让我印象最深的一点是真正花时间的不是安装和部署而是对存量系统的梳理。Rancher 这种平台管理能力很强但长期使用下来工作负载、存储、配置之间的隐式依赖会慢慢沉淀成一个“黑箱”你不做迁移永远不知道里面有多少隐式关联。如果你也在准备从 Rancher 迁到 Sealos 或者其他私有化底座我建议先花两周时间把资产盘点做扎实再启动扑腾。过程中多留后路宁可批次拆碎一点也不要追求一次切换的“英雄主义”。Sealos 在私有化场景里的交付效率确实高但再好的工具也替代不了严谨的迁移规划和数据验证。最后再分享一个小技巧迁移完成后别急着把旧集群删掉在旧集群旁边保留一份核心服务的运行快照比如备份关键 Deployment 和 ConfigMap 到一个 Git 仓库里。后续如果新环境有配置需要比对随时可以拉出来对照这个习惯在长时间运维里非常有用。