1. 为什么在企业离线环境里我会选 Sealos1.1 先盘清楚离线私有化到底难在哪我这两年一直在做企业级大模型私有化部署说白了就是帮客户把大模型能力搬进内网。在外网环境里装一个 K8s 集群已经不算什么新鲜事真正的麻烦全在离线环境没有外网源、没有公共镜像仓库、连系统基础依赖都不能在线安装。很多客户的需求又特别一致模型和数据不能出内网、推理链路必须完整、应用要能长期稳定跑于是所有交付动作都得压缩在一台能联网的制作机和一摞拷贝进内网的离线包里完成。以前用 kubeadm 做离线集群时光准备物料就够头疼kubelet、kubeadm、kubectl 这三个二进制要对应版本pause、coredns、etcd、calico 这些镜像要从不同渠道下载还得手工生成证书、配置 containerd、设置 kubelet 启动参数。任何一个组件的版本跟 K8s 主版本不匹配排错可能就要花掉一整天。我第一套离线环境从清点依赖到真正跑通前后磨了一个多月后来切换到 Sealos 重新做两天就能拉起一个新集群。这个对比让我决定把 Sealos 私有化这条链路彻底摸透。1.2 Sealos 集群镜像机制是如何把依赖链收进一个包的Sealos 的核心思路是把整个 K8s 集群当成一个镜像来交付。这里说的集群镜像不是普通容器镜像而是一个包含 Kubernetes 二进制、etcd、containerd、kubelet、kubeadm、网络插件等全套组件的集群运行时镜像。它跟 Docker 镜像类似有仓库、有 tag、有分层复用但加载之后输出的不是一个容器而是一个完整可用的集群。这个机制对离线环境的意义在于依赖收敛。有网环境里执行一条sealos pull就能把集群镜像拉到本地再通过sealos save打成 tar 包拷贝到内网后sealos load导入然后用sealos run或sealos apply直接拉起集群。整个过程不需要访问任何外部 yum 源、apt 源或镜像仓库。我实测下来一个 K8s 1.27 集群的离线包体积大约在 2~3GB比之前手工准备一堆散装二进制和镜像的方式清爽太多而且 tar 包可以反复拷贝交付多少个环境都只需同一份物料。1.3 企业大模型私有化部署场景里 Sealos 能做什么企业大模型私有化部署是一个比单纯装 K8s 复杂得多的场景。常见组合是 FastGPT 这类知识库问答系统做应用入口OneAPI 做模型网关转发Ollama 或者 vLLM 在 GPU 节点上提供推理能力再加上 Milvus、Qdrant 这类向量库做知识检索。这套链路里每个组件都有各自的镜像、依赖和持久化要求离线部署时如果逐个处理工程量非常大。Sealos 能把这些组件以集群镜像或应用镜像的形式统一管理。应用镜像可以先在有网机器上拉取再离线导入集群内部的镜像仓库会自动承担镜像分发应用编排则交给 K8s 原生能力完成。对交付团队来说最大的改变是操作面收窄了不需要在每个节点上手工装容器、配仓库、改证书而是把整集群当成一个镜像来装载和部署。下面我就按实际执行顺序把从物料准备到上线运维的完整过程写出来。2. 动手之前离线部署的物料清点与版本选型2.1 版本选型锁定 tag拒绝 latest离线环境部署有一个天然约束一旦进场就没有后悔药。在有网机器上打包时如果顺手写了latest很可能打包当天拉到的镜像跟客户现场验收时不一致后续升级排查都不知道基线是什么。所以我从一开始就强制自己锁死版本。我这边用的组合是 Sealos v4.3.x配套集群镜像labring/kubernetes:v1.27.7和网络插件labring/calico:v3.26.4。选这套组合的原因有三一是 K8s 1.27 在企业生产环境里已经验证了相当长时间稳定性有保障二是这套镜像组合我踩过所有版本兼容性问题问题都在可控范围三是 v1.27 对内核版本的要求相对宽松很多客户现网还是 CentOS 7.9 或者麒麟系统内核升级的冲击面小。如果是全新的 Ubuntu 22.04 环境我会考虑labring/kubernetes:v1.28.4总之原则是明确记录每个镜像的完整 tag避免任何隐式依赖。2.2 在有网环境制作离线包的三道工序制作离线包最好找一台跟目标环境架构一致的有网机器否则会踩架构不匹配的坑后面我会单独讲。我的标准流程分三步走。第一步拉取集群和附加组件镜像。执行以下命令时建议开启代理或使用加速镜像源不过我这里只写正常拉取方式大家根据自己的网络条件调整sealos pull labring/kubernetes:v1.27.7 sealos pull labring/calico:v3.26.4第二步把镜像保存成 tar 包。这一步相当于把集群镜像落地为可拷贝的离线文件sealos save -o kubernetes-v1.27.7.tar labring/kubernetes:v1.27.7 sealos save -o calico-v3.26.4.tar labring/calico:v3.26.4第三步把大模型应用相关镜像也一并保存。企业大模型私有化部署中常用的 FastGPT、Ollama、Milvus 等组件同样用sealos pull配合sealos save处理。这里给一个我实际用过的组合sealos pull labring/fastgpt:v4.7.5 sealos pull labring/ollama:latest sealos pull labring/milvus:v2.3.10 sealos save -o fastgpt-v4.7.5.tar labring/fastgpt:v4.7.5 sealos save -o ollama.tar labring/ollama:latest sealos save -o milvus-v2.3.10.tar labring/milvus:v2.3.10保存出来的 tar 包建议统一放到一个目录里并在旁边写一个manifest.txt记录每个 tar 包对应的镜像名、tag、大小。到了客户现场很多时候不是技术问题先崩而是混乱的物料让人先崩溃一份清单能救命的。2.3 目标环境预检硬件、系统、网络一个不能少在拿着 U 盘进机房之前我强烈建议先做一次目标环境预检。很多离线部署现场的问题其实在硬件和系统层面就已经注定了。我把预检项整理成下面的清单每项都标注了踩坑轻重度省得大家重复交学费检查项检查要求踩坑影响CPU 架构统一为 amd64 或 arm64不能混用镜像架构不匹配拉取后无法运行内核版本K8s 1.27 建议内核 5.4 及以上kubelet 启动失败、网络组件异常内存与磁盘每 master 建议 16G 内存根分区预留 100G集群组件 OOM、镜像解压空间不足网卡与 IP确认默认路由网卡多网卡必须指定接口名集群内部通讯走错网卡节点反复 NotReady防火墙关闭或放行 6443、10250、2379 等端口节点心跳、apiserver 访问失败swap必须关闭kubelet 直接报错退出主机名各节点 hostname 不能重复且要规范集群节点注册冲突预检时我习惯用一条脚本批量收集节点信息uname -r看内核cat /etc/os-release看系统版本ip addr看网卡和 IPfree -g看内存df -h看磁盘。把结果统一汇总到一张表里发到工作群比到时候逐个节点排查要高效得多。另外别忘了确认目标机器的时间是否同步NTP 没有配好的离线环境证书校验会以很诡异的方式失败这个坑我踩过一次后面会细讲。3. 离线部署实操从导入镜像到集群拉起3.1 镜像导入与 Clusterfile 配置到了离线环境第一件事不是急着执行部署而是先把离线包导入 Sealos 本地镜像库。我在客户现场的标准动作是sealos load -i kubernetes-v1.27.7.tar sealos load -i calico-v3.26.4.tar sealos load -i fastgpt-v4.7.5.tar sealos load -i ollama.tar sealos load -i milvus-v2.3.10.tarsealos load执行完后可以用sealos images确认导入结果。接下来准备 Clusterfile这是 Sealos 声明式部署集群的入口。我常写的模板如下apiVersion: apps.sealos.io/v1beta1 kind: Cluster metadata: name: prod-cluster spec: hosts: - roles: [ master ] ips: [ 192.168.10.11, 192.168.10.12, 192.168.10.13 ] - roles: [ node ] ips: [ 192.168.10.21, 192.168.10.22 ] image: - labring/kubernetes:v1.27.7 - labring/calico:v3.26.4 ssh: passwd: pkFile: registry: domain: sealos.hub port: 5000需要注意 Clusterfile 里的 SSH 认证方式。企业内网环境通常不支持直接用密码登录我一般用pkFile指向管理员下发的那把部署专用公钥。如果只能用密码务必确认密码里没有$、#这类容易被终端转义的字符否则 SSH 连接会以非常隐蔽的方式失败。registry段配置的是 Sealos 内置镜像仓库的域名和端口这个仓库在集群部署完成后会自动运行在第一个 master 节点上承担后续应用镜像的分发任务。3.2 sealos apply 拉起集群的过程与验证Clusterfile 准备好后一条命令就能开始部署sealos apply -f Clusterfile执行过程中 Sealos 会依次完成节点 SSH 探测、环境检查、组件镜像同步、K8s 集群初始化和网络插件部署。这个过程中终端会输出大量日志我的建议是不要只盯着最终结果要留意几个关键节点SSH 连接是否全部成功、镜像是否在节点间正常分发、apiserver 是否健康、calico 是否处于 running 状态。部署完成后登录任意 master 节点执行kubectl get nodes kubectl get pods -A正常状态是所有节点显示 Ready系统组件 pod 没有 CrashLoopBackOff。这里补充一个验证小技巧kubectl get nodes -o wide可以看到每个节点的内部 IP你要确认这个 IP 是内网业务网段的 IP而不是某个管理网段的 IP避免后续业务流量走错链路。3.3 大模型应用的离线编排FastGPT 与 Ollama 的落地K8s 集群就绪后大模型应用的编排是我最关注的部分。以企业大模型私有化部署最常见的 FastGPT OneAPI Ollama Milvus 组合为例FastGPT 提供知识库问答界面OneAPI 做模型 API 的统一封装Ollama 在 GPU 节点上跑本地模型Milvus 负责向量检索。首先要解决模型文件的问题。Ollama 的模型默认存放在~/.ollama/models目录下离线环境的模型文件需要在有网机器上提前拉取然后把整个目录拷到 GPU 节点。我通常这样做# 有网机器上拉取模型并打包 ollama pull qwen2.5:14b tar czf ollama-models.tar.gz -C /root/.ollama models到目标 GPU 节点解压并放到相同路径tar xzf ollama-models.tar.gz -C /root/.ollama。这里最关键的是目录结构要保持一致否则 Ollama 服务识别不到模型。接着是应用容器的编排。FastGPT、Milvus 这些应用镜像已经通过sealos load导入我习惯直接在 K8s 上写 Deployment 和 Service 清单用本地镜像部署。关键的持久化配置要做到位Milvus 的 etcd、MinIO 数据目录FastGPT 的 PostgreSQL 和向量库都要挂载到宿主机目录或已接入的存储上否则容器一重建客户的知识库和问答历史就全没了。Ollama 所在的节点还要打上专门标签用 nodeSelector 让推理 pod 固定调度到 GPU 节点上。4. 踩坑实录五个让我加班到深夜的问题4.1 先看速查表这部分是我最想分享的内容。离线环境排错非常熬人往往一个看似不起眼的系统差异就能让整个集群起不来。下面是我按真实发生频率整理的问题速查表后面的小节再挑典型案例展开说问题现象根因方向快速解法集群内部 IP 混乱节点 NotReady多网卡默认路由指向错误网卡部署时用--interface或 Clusterfile 指定内网网卡kubelet 启动失败报 cgroup 错误内核版本过低或 swap 未关闭升级内核到 5.4并swapoff -aPod 申请 GPU 失败调度到 GPU 节点仍报错containerd 未配置 nvidia runtime安装 nvidia-container-toolkit配置 RuntimeClass应用镜像拉不下来提示 401 或 tls 错误内网仓库认证或 insecure registry 未配置在 containerd 配置中添加内置仓库为 insecureOllama 模型容器重建后丢失模型目录未挂持久化卷将/root/.ollama挂到宿主机目录部署过程 SSH 连接失败密码含特殊字符或目标机禁止密码登录改用密钥避免特殊字符密码证书验证失败节点注册不了NTP 未配置节点间时间偏差大搭建内网 NTP 服务或手动校准时间4.2 多网卡导致集群通讯异常这是我踩得最深的坑。某个客户现场每台机器都有两个网卡一个连业务内网一个连存储管理网。Sealos 默认会选第一条路由所在网卡结果集群的节点间通讯全走了存储管理网K8s 组件心跳时通时断节点反复跳动在 Ready 和 NotReady 之间apiserver 日志里全是 TLS 握手超时。排查到最后才发现是网卡选择问题。解决办法是在 Clusterfile 里给 Sealos 传递指定网卡参数或者在执行sealos apply时通过环境变量明确默认接口名。实际操作中我简化处理先把存储管理网卡临时禁用让默认路由落在业务内网网卡上部署完成后再恢复。这个办法虽然粗暴但效果立竿见影后来我干脆在预检阶段就把目标机器的网卡名全部标注在部署文档里再也没被这个问题绊倒过。4.3 内核版本过低导致 kubelet 无法启动有次交付时客户提供的是 CentOS 7.9 机器预检时只看系统版本没看内核结果kubectl get nodes怎么等都等不齐打开 kubelet 日志发现大量 cgroup v2 相关报错。原因很清楚K8s 1.27 在 CentOS 7.9 默认的 3.10 内核上跑不稳即使勉强启动网络组件和内存管理也会出各种怪问题。解决路径是升级内核。我在客户机器上把内核升到 5.4.x 版本重启后 kubelet 才正常注册节点。这里要特别提醒内核升级涉及机器重启一定要提前跟客户确认变更窗口千万别在业务时段直接执行否则影响面很难收场。另外升级完内核之后swapoff -a和/etc/fstab里 swap 条目注释这两步也别忘了kubelet 对 swap 是零容忍的不关掉照样起不来。4.4 GPU 节点容器无法调用显卡企业大模型私有化部署里 GPU 是刚需但这个环节的坑一个接一个。我把容器调度到 GPU 节点后发现 Pod 能启动日志却提示找不到 CUDA 设备。用nvidia-smi在宿主机上看驱动一切正常问题显然出在容器运行时没有把宿主机的 GPU 设备透传进去。根因是 containerd 里没有配置 NVIDIA 的 runtime。我按官方流程安装了 nvidia-container-toolkit然后修改/etc/containerd/config.toml为 containerd 增加 nvidia runtime handler再创建对应的 RuntimeClassPod 里声明runtimeClassName: nvidia后显卡才能正常使用。这一套配置下来GPU 节点才算真正跑起来。顺带说一句如果客户的驱动版本低于 CUDA 要求模型推理时会报 ban 那么一堆兼容性错误这时候最快的方法不是调驱动而是换一个跟驱动匹配的 CUDA 基础镜像。4.5 内置仓库认证与镜像拉取失败集群是起来了应用镜像也导入了但部署 FastGPT 时节点却拉不到镜像报错要么是unauthorized要么是 TLS 连接失败。原因是 Sealos 内置镜像仓库默认走 HTTP而节点上的 containerd 默认认为所有远程仓库都走 HTTPS不额外配置的话根本无法从内置仓库拉取镜像。解决办法是在每个节点的/etc/containerd/config.toml里把内置仓库地址配置到registry.mirrors和registry.configs中明确使用 HTTP 并开启 skip verify。这里我建议写个一次性脚本在所有节点批量执行比手动一台台改效率高得多。配置完 containerd 要重启节点上的 containerd 服务Pod 重新调度后镜像拉取就正常了。这个坑在离线环境尤其隐蔽因为看起来是认证问题实际是协议和信任策略不匹配。4.6 模型文件没做持久化容器一重建就丢最后这个坑是应用层面的但杀伤力很大。给客户做完演示之后我出于更新配置的目的重建了一次 Ollama 相关 Pod结果重启后模型全部消失服务直接报模型不存在。排查才发现 Ollama 容器把模型文件写在了容器可写层而我没有为/root/.ollama做持久化挂载容器一重建可写层直接被回收。这个问题的教训比技术本身更重要只要是大模型私有化部署凡是模型文件、知识库索引、向量数据这类有状态数据一律要挂到宿主机目录、块存储或网络存储上。应用可以随时重建但数据和模型不能有任何例外。后来我写部署清单时把所有需要持久化的路径列成了一张表逐一确认挂载再也没在这个问题上翻过车。5. 私有化上线后的运维三板斧5.1 离线环境的版本升级路径在线环境的升级可以依赖镜像仓库自动拉取离线环境不行所有新版本镜像都必须通过离线包导入。我的做法是建立一个固定的升级流程先在有网机器上拉取新版本集群镜像或应用镜像执行sealos save打成 tar 包再拷贝到内网执行sealos load然后用sealos upgrade或更新 Deployment 镜像版本的方式滚动升级。这里面有一个经验值得分享升级之前一定要先在测试集群完整走一遍记录每一步耗时和匹配的镜像 tag。离线环境的客户通常不允许频繁变更一次升级窗口可能隔几个月才有一次走完测试流程能让正式操作变得非常快。另外所有升级操作前后都要对 etcd 和应用数据做快照一旦升级失败第一时间回滚才是止损的正确姿势。5.2 备份、恢复与灾难演练私有化交付不只是把系统跑起来更重要的是给客户一个可恢复的兜底方案。我在离线环境里至少做三层备份etcd 快照、应用数据库备份、模型文件归档。etcd 是整个集群状态的核心我会在 master 节点上使用 etcdctl 定期执行快照同时把快照文件同步到独立存储节点或者备份服务器ETCDCTL_API3 etcdctl --cacert/etc/kubernetes/pki/etcd/ca.crt \ --cert/etc/kubernetes/pki/etcd/server.crt \ --key/etc/kubernetes/pki/etcd/server.key \ snapshot save /backup/etcd-$(date %F).db应用数据库方面FastGPT 底层是 PostgreSQL 或 MongoDBMilvus 的元数据和数据存储在 etcd 和 MinIO 中这些都要配置各自的定时备份。我还会每季度做一次完整的恢复演练把备份数据恢复到一台全新的测试集群上确认业务能启动、模型能加载、历史问答记录能查到。备份没有经过恢复验证等于没备份这句话是我踩过几次坑之后最深的体会。5.3 监控告警的离线化落地离线环境的监控不能靠外部 SaaS只能自己把它收敛到离线包里。我在有网机器上提前拉取 Prometheus、Grafana、node-exporter 等组件的镜像用 docker save 或 sealos save 打成 tar 包进内网之后再 load。监控组件和 K8s 集群跑在同一套资源池里即可不需要额外机器。部署时我会重点监控四类指标节点 CPU、内存、磁盘使用率GPU 的利用率与显存占用K8s 核心组件的 pod 状态以及应用层的推理耗时。Grafana 面板里的图表可以事后慢慢调但告警规则一定要在上线前配好。离线环境出了故障可定位的手段本身就少如果监控能第一时间告诉你节点状态变化和容器重启次数排查效率会完全不同。我在实际配置中会把节点磁盘使用率超过 85% 和 GPU 异常两条告警优先级调最高因为这两个出问题的频率最高影响也最直接。我从第一次做 Sealos 私有化到现在前后交付了十几个离线环境最大的体会是这套工具把部署 K8s 集群的复杂度和心智负担降了一个数量级但工具代替不了对系统底层的判断。离线排错时耐心对照预检清单、逐层排查系统差异、保持每一步操作都有据可查的习惯比任何工具都重要。如果你正准备在自己的环境里做企业大模型私有化部署我的建议是先从一套干净的测试环境开始把离线包制作、集群拉起、应用编排、备份恢复完整走两遍再碰客户现场那样你会从容得多。最后再分享一个小技巧给每台目标机器都建一个 deployment 专用账号权限收敛到最小并提前把 SSH 密钥和 sudo 规则配好线下交付时你会感谢自己当初多花的这十分钟。