上周一个做工业数据的客户找到我说要在机房里部署一套大模型问答系统数据和模型权重都要求留在内网不能走任何公网链路。我当时的第一反应不是选模型而是先把底座定下来私有化部署、Kubernetes 集群、GPU 调度这三件事如果用裸机加手工组网的方式做一周都未必能稳定跑通。最后我选了 Sealos半天把三节点高可用集群拉起来另外半天把 GPU 环境和推理镜像调通。整个过程下来最值钱的就是那份配置清单。我把这份清单完整交出来给正在准备企业大模型私有化部署、或者想在内网快速搭建 K8s 集群的团队做一个“直接抄作业”的参考。文章会覆盖硬件规划、网络划分、Sealos 部署命令、Clusterfile 配置、GPU 环境搭建、常见问题排查和日常运维要点。适合有基础 Linux 运维能力的工程师也适合正在评估私有化方案的架构师。1. 为什么要选 Sealos 做私有化部署底座1.1 Sealos 到底解决了什么问题Kubernetes 集群的安装向来是运维老手也要谨慎对待的活。裸机环境下你要自己解决 containerd、kubeadm、kubelet、kube-proxy、CNI 插件、负载均衡器这一整套组件的版本匹配问题任何一个版本不对初始化到一半就开始报错。Sealos 的做法是把所有这些依赖封装成“集群镜像”一条 run 命令就能完成整个集群的初始化。私有化部署环境里这个能力尤其重要。客户的机房里没有外网是常态Docker Hub 根本拉不动更别说国内镜像源。Sealos 的集群镜像支持离线导入你可以在能联网的机器上把镜像和二进制全部打包再拿到内网里 load 进去。这意味着你不需要在客户现场慢慢调试网络代理、配 registry mirror核心依赖一次性分发到位。另一个容易忽略的点是版本一致性。手工搭建集群的时候每个节点的 containerd、kubelet 版本都可能因为安装方式不同而出现细微差异表面上看集群正常遇到故障排查时才发现版本五花八门。Sealos 对所有节点使用同一个集群镜像初始化版本完全对齐后续排障的思路干净很多。1.2 和大模型私有化部署的契合点企业大模型私有化部署这几年已经成了很多甲方项目的标配需求。模型本身只是镜像里的权重真正难的是下面几件事多张 GPU 卡的驱动统一管理、推理服务的高可用调度、模型服务的水平伸缩、内网环境下镜像的分发与更新。这些能力全部依赖 Kubernetes 这一层底座。Sealos 把底座这件事做到了“接近零成本”的启动速度。我在实际项目中验证过从空机器到 K8s 集群可用三节点规模差不多在一个小时内完成。多出来的时间可以全部花在 GPU 驱动、模型镜像和业务验证上这对项目交付节奏的影响是非常直观的。这里补充一句我的选型心得。私有化交付的客户通常有两类一类是有完整运维团队的企业他们只关心底座是不是稳定、规范和可扩展另一类是业务驱动的团队只想快速把模型跑起来没有精力维护复杂的 K8s 安装文档。Sealos 在两类客户那里都能落地因为它的操作方式足够简单同时又保留了 Kubeconfig、CRI 等原生接口不会被锁定在某个私有生态里。2. 部署前的硬件与网络规划2.1 硬件配置清单按角色我一直坚持一个原则私有化项目的硬件规划要在部署之前做死不要在集群起来之后才发现节点磁盘不够用。先给出一份我常用的配置参考按节点角色区分直接对照采购就行。角色CPU内存系统盘数据盘GPU适用场景Master 节点3台8C 起16G 起100G SSD200G SSD不需要跑 kube-apiserver、etcd、controller-managerNode 节点CPU推理32C64G100G SSD500G NVMe不需要运行轻量模型或纯 CPU 推理服务Node 节点GPU推理32C128G100G SSD1T NVMe至少一张 4090 / A10跑 7B / 13B 参数规模的模型Node 节点大模型训练/推理64C512G100G SSD2T NVMe8 卡 A100 / H800处理 70B 以上参数规模或训练任务磁盘部分是私有化项目里最容易被低估的一项。K8s 集群运行过程中容器镜像、容器日志、etcd 数据、PV 存储都会抢占磁盘空间。建议至少准备三块独立的盘系统盘给操作系统数据盘给 containerd 和 kubelet存储盘单独挂给 PV 和模型文件。模型文件体积按模型参数量的三倍估7B 模型的权重文件大约 14G但加上 tokenizer、配置文件和推理时的临时文件预留 50G 是最低限度。内存方面etcd 和 kube-apiserver 对内存并不挑剔真正吃内存的是业务容器。跑 7B 模型的推理服务启动时加载权重就需要 14G 以上内存所以节点内存我一般按模型权重的四倍规划才能给推理框架、缓存和系统留出余量。2.2 网络与地址规划私有化环境最容易出问题的就是网络规划这个环节建议装机前就决定。第一件事是给 K8s 集群单独划分一个网段不要和办公网、业务网混在一起。我常用的做法是单独划一个 10.100.0.0/24 段所有节点只配内网 IP不依赖 DNS 主机名解析直接用 IP 通信。第二件事是预留 Pod 网段和 Service 网段。这个坑我踩过好几次客户以为 Pod 网段随便选一个私有网段就行结果选了和办公网网段冲突的地址跨网段路由直接把包丢到了办公设备上。Pod 网段建议选 10.244.0.0/16 这类非主流地址段Service 网段选 10.96.0.0/12并且在配置之前和客户网络团队确认这两个网段不会跟园区里任何现有网段冲突。第三件事是高可用 VIP 的规划。如果做多 master 高可用Sealos 会用 haproxy 加 keepalived 的方式提供一个虚拟 IPKubeconfig 里的 apiserver 地址就填这个 VIP。VIP 必须在 master 节点所在的二层网络内并且不能落在 DHCP 自动分配的范围里否则一次地址冲突就会导致集群控制面间歇性不可用。2.3 操作系统与基础环境准备操作系统版本对 Sealos 部署的影响比很多人想象的大。我的实际排序是Ubuntu 22.04 LTS 最省心内核 5.15 对 ipvs、overlayfs 的支持都非常完善openEuler 22.03 LTS 适合国内信创项目但要注意 SELinux 默认开启建议直接设成 permissiveCentOS 7.9 不建议新项目再用了内核 3.10 对高版本 Kubernetes 的模块兼容问题太多。节点初始化阶段有几件固定动作。防火墙要关闭或者放行集群网段systemd 环境下执行 systemctl stop firewalld 和 systemctl disable firewalld文件句柄数要调大ulimit -n 65535 写入 /etc/security/limits.conf时间同步一定要确认好私有化机房如果 NTP 出问题etcd 会非常不稳定表现为集群间歇性超时。这里补充一条经验所有节点保持相同配置。如果客户提供的机器型号新旧不一尽量把同型号的机器分到同一角色组里。不同代的 CPU 可能在内核模块加载、GPU 驱动兼容性上有差异分开规划能避免很多诡异问题。3. Sealos 私有化部署核心步骤与配置清单3.1 安装 Sealos 与集群初始化命令Sealos 的安装方式非常直接二进制丢到 /usr/local/bin 下就行。在线环境直接执行官方脚本离线环境把二进制和集群镜像一起拷进去再 load。# 在线环境安装示例 curl -sSL https://raw.githubusercontent.com/labring/sealos/main/scripts/install.sh | sh # 检查版本 sealos version离线环境手动安装的关键步骤是把所有依赖变成文件。我第一次做离线部署时没有导出集群镜像到了客户现场才发现 sealos 命令虽然能跑但集群初始化拉镜像时全部超时白跑一趟。正确做法是提前把 kubernetes.tar.gz 这类集群镜像包传到内网然后执行# 手动安装二进制 cp sealos_amd64 /usr/local/bin/sealos chmod x /usr/local/bin/sealos # 导入集群镜像 sealos load -i kubernetes.tar.gz初始化一个三 Master 高可用集群加两个 Node 节点的最简命令是这样sealos run kubernetes:v1.30.2 \ --masters 192.168.1.10,192.168.1.11,192.168.1.12 \ --nodes 192.168.1.20,192.168.1.21 \ --passwd your-strong-passwd执行这条命令后Sealos 内部会自动完成 SSH 免密打通、所有节点安装 containerd、初始化第一个 master、拉起 haproxy 和 keepalived 提供 VIP、其余 master 加入 etcd 和 control plane、node 节点自动 join、安装 CNI 插件这一整套流程。我提醒一下命令里的 passwd 建议用临时密码初始化完成后立刻改成密钥认证生产环境别省这一步。3.2 高可用与负载均衡参数解析多 Master 高可用形态看起来复杂但 Sealos 把内部的 keepalived 和 haproxy 都封装好了你只需要理解几个关键概念。VIP 是集群所有组件的访问入口。kubectl、Pod 里的 service account、外部 API 调用全部通过 VIP 访问 kube-apiserver。Master 节点发生故障时keepalived 检测到异常后会让 VIP 漂移到其他健康的 master 上haproxy 再把流量转发到正常的 apiserver 实例。这个过程对业务侧是透明的不会因为单个 master 宕机导致控制面不可用。实操中需要确保 VIP 不落在 DHCP 范围内。我见过一个项目客户把 VIP 配成了 192.168.1.100但机房 DHCP 的地址池恰好是从 192.168.1.50 到 192.168.1.150结果一台新设备上线直接抢占了 VIP集群 API 立刻失联。排查了大半天才找到问题。所以 VIP 地址一定要和网络管理员确认选一个静态保留地址。还有个细节是健康检查。Sealos 内置的 haproxy 会对后端 apiserver 做健康检查默认参数在大多数场景下够用。如果机房网络延迟偏高可能出现 apiserver 活着但健康检查超时的情况VIP 频繁切换。这时候需要调整 haproxy 的健康检查间隔和超时时间具体可以在 Seaelos 的配置模板里追加。3.3 Clusterfile 完整配置清单直接抄作业命令行的方式适合快速验证交付客户时建议用 Clusterfile 这一声明式配置把整个集群拓扑写成 YAML以后变更、重建、审计都有据可查。下面是一份我常用的完整清单apiVersion: apps.sealos.io/v1beta1 kind: Cluster metadata: name: private-gpu-cluster spec: hosts: - ssh: root192.168.1.10:22 roles: [master, etcd] env: vip: 192.168.1.100 - ssh: root192.168.1.11:22 roles: [master, etcd] - ssh: root192.168.1.12:22 roles: [master, etcd] - ssh: root192.168.1.20:22 roles: [node] - ssh: root192.168.1.21:22 roles: [node] image: - kubernetes:v1.30.2关于这份清单有几个字段需要解释清楚。hosts 列表里每一个条目对应一台物理机ssh 字段写 root 用户和 SSH 端口Sealos 会用你在命令行传入的密码或密钥自动完成免密配置。roles 字段区分 master、etcd、node 三类角色etcd 一般跟 master 放在一起生产环境建议至少三个 etcd 成员。image 字段指定集群镜像版本这是 Sealos 的灵魂。集群镜像里包含了对应版本的 Kubernetes、containerd、网络插件等所有组件。我建议初次使用时固定一个版本比如 kubernetes:v1.30.2不要随手写 latest否则隔一段时间重新初始化可能遇到版本行为变化。配置完成后保存为 Clusterfile执行 sealos apply -f Clusterfile 即可。整个过程不需要手动 SSH 到每一台机器执行安装命令Sealos 会自动按照 hosts 列表顺序分发配置并完成初始化。4. GPU 与大模型运行环境配置4.1 GPU 驱动安装与容器运行时配置集群起来之后GPU 节点还需要两件事装驱动、部署 device-plugin。大模型私有化部署的标配是 NVIDIA GPU所有 GPU 节点的驱动版本必须统一。我推荐选 535 或 545 系列这种经过市场广泛验证的版本避免跨大版本混用。装驱动之前先确认节点硬件结构然后逐台执行# Ubuntu 22.04 示例 apt update apt install -y nvidia-driver-535 reboot # 重启后确认驱动 nvidia-smi驱动装好之后要让容器能访问 GPU 还需要 nvidia-container-toolkit。这个工具会把 NVIDIA runtime 注入到容器运行时里否则 K8s 调度 Pod 到 GPU 节点上后容器内部根本看不到显卡设备。distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | apt-key add - curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | tee /etc/apt/sources.list.d/libnvidia-container.list apt update apt install -y nvidia-container-toolkit安装完成后需要把 runtime 配置同步给 containerdnvidia-ctk runtime configure --runtimecontainerd systemctl restart containerd这里的坑是很多人在安装 toolkit 之后忽略了最后一步直接重启集群里的 Pod结果 runtime 没有被 containerd 加载GPU 调度永远不成功。配置完成后可以通过 ctr runtime ls 检查是否出现 nvidia 运行时。4.2 GPU 资源管理插件部署GPU 驱动和 runtime 只是让节点“能用 GPU”要让 K8s 调度器识别 nvidia.com/gpu 这个资源还需要部署 device plugin。两种常见方式手动部署 nvidia-device-plugin 的 DaemonSet或者直接用 GPU Operator 统一管理。手动方式用 helm 安装helm repo add nvdp https://nvidia.github.io/k8s-device-plugin helm install --generate-name nvdp/nvidia-device-pluginGPU Operator 方式是把驱动、toolkit、device-plugin、DCGM exporter 这些都打包在一起一条 helm 命令全部部署。它适合 GPU 节点较多的场景但要注意它的驱动管理逻辑会覆盖手工安装的驱动。我的建议是二选一要么全手工要么全 operator混用会非常痛苦。部署完成后在节点上查看可分配资源如果能看到 nvidia.com/gpu 就说明 device-plugin 工作正常kubectl describe node gpu-node-01 | grep -A5 Allocatable4.3 验证 GPU 调度与模型服务验证 GPU 调度最直接的方法是跑一个 CUDA 测试容器kubectl run gpu-test --image nvidia/cuda:12.2.0-base-ubuntu22.04 --restartNever \ --limitsnvidia.com/gpu1 -- /bin/sh -c nvidia-smi容器成功输出 GPU 信息说明驱动、runtime、device-plugin 这条链路已经全部打通。之后就可以部署真实的推理服务了。以 vLLM 为例只需要在 Deployment 的 resources 里声明 nvidia.com/gpu 的数量加上模型权重挂载一个标准的推理服务就能在私有化环境里跑起来。这里有一个实际项目里的提醒GPU 节点上建议预留一部分 CPU 和内存专门处理数据预处理。大模型推理场景下tokenize 和请求排队都会占用 CPUCPU 不足会导致 GPU 利用率上不去推理延迟波动明显。5. 私有化部署常见问题与排查实录5.1 部署失败速查表我在多个项目里趟过不少坑整理成一张速查表遇到问题先对照这个看。现象大概率原因排查命令处理方法sealos 报 SSH 连接失败目标机没开 22 端口或 root 密码错误ssh rootip 手动试检查端口、密钥权限、sudosu 权限初始化卡在拉镜像阶段内网环境无法访问外网镜像源crictl images 看本地镜像离线导入集群镜像包或配置内部 registry mirroretcd 日志频繁报超时磁盘 IO 低或 NTP 时间偏移etcdctl endpoint health确认数据盘为 SSD重新配置时间同步VIP 反复漂移健康检查误判或 VIP 冲突ip addr show 看 VIP 状态调大健康检查间隔确认 VIP 地址不冲突Pod 网络不通CNI 网段与机房网段冲突kubectl get pods -n kube-system重新规划 Pod CIDR重建 CNI部署失败时最忌讳的是反复重跑初始化命令。Sealos 的初始化流程有状态失败后建议先清理节点sealos reset再修正配置否则残留的 etcd 数据或 kubelet 配置会干扰下一轮初始化。5.2 离线镜像仓库与拉取策略私有化环境遇到镜像拉不动是最常见的问题。标准解法是在内网搭一个镜像仓库Harbor 是首选然后把所有业务镜像推进去。# 在能联网的机器上拉取模型镜像 docker pull vllm/vllm-openai:latest # 给镜像打上内网仓库的 tag推送 docker tag vllm/vllm-openai:latest registry.infra.local:5000/vllm/vllm-openai:latest docker push registry.infra.local:5000/vllm/vllm-openai:latest然后配置 containerd 的 registry mirror让所有节点从内网仓库拉取。Secret 证书也要提前放到 /etc/docker/certs.d 或 containerd 对应目录否则 Harbor 的 HTTPS 证书会导致拉取失败。离线环境另一个关键动作是 Sealos 集群镜像本身的导入。我之前遇到过一个客户内网完全隔离所有操作都在内网完成集群镜像包用 U 盘拷贝进去ssealos load 之后初始化非常顺利。这个模式现在已经成为我交付私有化项目的固定流程。5.3 高可用与网络排障细节高可用切换过程中有个容易被忽略的现象master 节点挂掉后 VIP 漂移成功但调用方仍然间歇性报错。原因是 haproxy 对已有连接做 keepalive旧连接还没失效新连接已经转到新的 master 上导致连接池里既有连接全部超时。处理方法是在应用侧设置合理的连接超时和重试机制同时调整 haproxy 的 maxconn 和 timeout 参数。K8s 侧的 kubeconfig 里 apiserver 地址填 VIP默认不会自动刷新连接需要客户端配合重试。私有化环境里我还会在 LB 层加一层简单的四层健康检查比如 TCP 探活这样能显著降低切换对业务的影响。网络层面的另一个高频问题是多个网卡导致路由混乱。有些服务器有两块网卡一块连业务网一块连存储网Sealos 默认选择主网卡进行集群通信如果选错网卡或者没把存储网卡禁用掉节点之间通信会变得极不稳定。解决办法是在 /etc/hosts 里固定所有节点的内网 IP并确保只有一个默认网关。6. 部署后的日常运维与检查清单6.1 节点与集群健康巡检集群部署完成之后运维不是靠“感觉”而是要形成固定巡检命令集。我常用的第一组命令kubectl get nodes kubectl top nodes kubectl get pods -A | grep -v Running通过这三条命令基本能快速判断集群整体状态。节点全部 Ready 并不代表健康还要关注磁盘水位和 etcd 状态。磁盘使用率超过 85% 时容器日志和镜像清理必须马上处理否则 node 会进入 DiskPressure 状态Pod 被驱逐。etcd 健康检查用一条命令能看得比较清楚etcdctl --endpointshttps://192.168.1.10:2379 endpoint health --cacert/etc/kubernetes/pki/etcd/ca.crt --cert... --key...如果 etcd 有大量 leader 切换优先检查磁盘 IO 延迟和网络抖动。etcd 对延迟非常敏感超过 100ms 就会告警。6.2 版本升级与备份恢复私有化项目里的版本升级我的建议是“能不动就不动要动就先备份”。Sealos 支持通过更新集群镜像的方式滚动升级但升级前必须完成三件事etcd 全量快照、K8s 资源清单导出、关键业务镜像备份。etcd 快照可以直接在 master 节点上执行etcdctl snapshot save /backup/etcd-snapshot.db \ --endpointshttps://192.168.1.10:2379 \ --cacert/etc/kubernetes/pki/etcd/ca.crt \ --cert/etc/kubernetes/pki/etcd/server.crt \ --key/etc/kubernetes/pki/etcd/server.key恢复时用 etcdctl snapshot restore 生成新数据目录再替换到 etcd 的>