★ FEATURED ARTICLE 这份配置清单是我在多套企业内网环境里反复验证过之后整理出来的。刚好赶上企业大模型私有化部署的热潮很多人拿到 Sealos 第一反应是按照官网文档装一套可真到了有防火墙、有独立机房、有 GPU 服务器的地方才发现缺的全是细节。Sealos 私有化部署这件事难点不在“安装”而在把配置清单补齐机器选型、磁盘挂载、端口放行、组件取舍、镜像仓库、GPU 调度……每一项缺了都可能返工。这篇不聊虚的抛开复杂原理把可直接复制的配置方案直接摆出来。适合负责基础设施运维和项目交付的同事照着抄也适合刚接手私有云项目、想快速建立全局清单的朋友参考。1. 先摸清底细这版清单适配的 Sealos 部署场景和机器选型1.1 三种可直接套用的节点规划模板Sealos 底层是 Kubernetes所以它的节点规划本质上就是 Kubernetes 集群节点规划。根据我的经验私有化部署通常跑在这三种场景里直接抄下面这个模板就行。部署场景节点角色建议配置适用说明最小验证环境master 1 台4C 8G系统盘 100G数据盘 200G适合功能验证、内网 POC不推荐承载真实业务生产标准环境master 3 台 node 按需 3 台起master8C 16G系统盘 200G数据盘 500Gnode16C 64G系统盘 500G数据盘 4T NVMe适合一般容器平台、微服务、数据库等常规业务企业大模型私有化部署场景master 3 台 GPU node 按需GPU 节点建议 CPU 16 核以上内存 128G 以上数据盘 2T NVMeGPU 视模型规模而定适合大模型推理、微调、RAG 应用等场景显存决定并行策略为什么 master 一定要 3 台因为 etcd 使用的是 Raft 共识算法3 个副本才能容忍一台节点故障。如果图省事只用 1 台 masteretcd、证书、API Server 全部挤在一台机器上一旦这台机器重启或者磁盘损坏整个集群就不可用了。对于企业大模型私有化部署来说模型服务一旦中断业务损失不是小数目所以该花的机器钱不能省。1.2 操作系统、内核参数和主机名这些“零碎项”怎么一次配齐操作系统我在 Ubuntu 22.04 LTS 和 Rocky Linux 9 上都跑过 Sealos结论是只要团队熟悉两种都可以但内部测试我更喜欢 Ubuntu 22.04包管理简单、内核版本够新对 containerd 和 GPU 驱动的兼容性比较省心。无论选哪个系统装完第一件事就是完成这些基础配置。# 关闭 swapKubernetes 对 swap 的支持一直比较“敏感” swapoff -a sed -i /swap/d /etc/fstab # 设置时区并同步时间节点时间偏差过大会导致证书校验失败 timedatectl set-timezone Asia/Shanghai内核参数和网络模块也需要提前写好不要等集群建好后再回头补cat /etc/sysctl.d/99-sealos.conf EOF net.ipv4.ip_forward 1 net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 vm.swappiness 10 fs.file-max 10485760 EOF modprobe br_netfilter sysctl --systemnet.ipv4.ip_forward 1是 Pod 访问外部网络的前提net.bridge.bridge-nf-call-iptables 1让 bridge 网络的数据包经过 iptables 规则避免 Kubernetes 网络策略和 Service 转发出现奇怪问题。接下来是主机名。很多第一次做交付的同事会忽略这个等 Sealos 安装时 SSH 过去发现 master 节点的 hostname 全是localhost最后 join 失败才发现问题。建议每一台机器设置独立且有规律的主机名hostnamectl set-hostname k8s-master01 hostnamectl set-hostname k8s-worker01同时把所有节点的 IP 和主机名写进/etc/hosts不要依赖内网 DNS。企业里 DNS 偶尔出问题就会让集群节点互相找不到直接用 hosts 文件是最稳的做法。1.3 磁盘怎么接才不会在装完存储组件后翻车不怕说得直白一点很多 Sealos 私有化部署翻车不是倒在安装阶段而是倒在存储组件启用后的第一天。原因就是数据盘没有提前规划好。Sealos 默认用的容器运行时是 containerdKubernetes 的 kubelet 数据目录默认在/var/lib/kubeletcontainerd 默认在/var/lib/containerd如果后面装 Longhorn数据目录默认又在/var/lib/longhorn。如果这些目录全堆在系统盘跑几个月系统盘就满了。我的做法是把数据盘先挂到/mnt/data再用 bind mount 的方式把各个数据目录分流到数据盘上。这样既不需要动系统根分区也能保证 kubelet、containerd、Longhorn 都有独立空间。# 假设数据盘是 /dev/nvme0n1 mkfs.ext4 /dev/nvme0n1 mkdir -p /mnt/data mount /dev/nvme0n1 /mnt/data # 建立子目录并绑定到系统默认路径 mkdir -p /mnt/data/kubelet /mnt/data/containerd /mnt/data/longhorn mkdir -p /var/lib/kubelet /var/lib/containerd /var/lib/longhorn mount --bind /mnt/data/kubelet /var/lib/kubelet mount --bind /mnt/data/containerd /var/lib/containerd mount --bind /mnt/data/longhorn /var/lib/longhorn别忘记写入/etc/fstab否则重启后挂载关系失效存储组件会直接“失联”。# /etc/fstab 追加 UUID你的数据盘UUID /mnt/data ext4 defaults 0 2 /mnt/data/kubelet /var/lib/kubelet none bind 0 0 /mnt/data/containerd /var/lib/containerd none bind 0 0 /mnt/data/longhorn /var/lib/longhorn none bind 0 0这里的核心思路是把“路”提前铺好别等 Longhorn 跑起来才发现数据目录在系统盘上。2. 集群搭建配置项sealos CLI、网络模型和端口放行清单2.1 为什么用 sealos run 而不是手工 kubeadm手工 kubeadm 初始化 Kubernetes 集群不算难但要做到可重复、可交付需要处理的细节太多了证书签发生效、kubelet 启动顺序、网络插件配置、多 master 的负载均衡、join token 有效期……每一步单独看都不复杂连起来跑一遍就是容易出各种幺蛾子。Sealos 的做法很聪明它把 Kubernetes 集群本身做成了镜像一样的制品。安装集群就是一条sealos run命令把 master 和 node 的 IP 一填登录信息一配剩下的事情由 sealos 自动完成。对于企业大模型私有化部署这种交付场景好处特别明显出问题可以重置后重新跑交付文档里只需要写一行命令而不是十页操作手册。先装 sealos CLI。生产环境一定要锁定版本不要每次下载最新版否则过几天环境变了旧的操作记录可能对不上curl -sfL https://raw.githubusercontent.com/labring/sealos/v4.3.0/scripts/install.sh | sh - sealos version如果你所在的网络访问 GitHub 不稳定提前把安装脚本和二进制下载好后放到内网后面我会单独讲离线环境怎么处理。2.2 一条命令跑完集群安装的完整参数以 Kubernetes 1.28 为例完整命令如下sealos run kubernetes:v1.28.0 calico:v3.25.1 helm:v3.12.0 \ --masters 172.16.0.2 172.16.0.3 172.16.0.4 \ --nodes 172.16.0.5 172.16.0.6 172.16.0.7 \ --user root \ --passwd Pssw0rd如果生产环境禁用了密码登录也可以用密钥方式sealos run kubernetes:v1.28.0 calico:v3.25.1 helm:v3.12.0 \ --masters 172.16.0.2 172.16.0.3 172.16.0.4 \ --nodes 172.16.0.5 172.16.0.6 172.16.0.7 \ --user root \ --pk /root/.ssh/sealos_key_ed25519参数含义并不复杂建议记下来参数作用kubernetes:v1.28.0Kubernetes 集群版本建议选稳定维护的版本calico:v3.25.1CNI 网络插件负责 Pod 网络和网络策略helm:v3.12.0Helm 包管理工具后面装 Longhorn、应用商店都用得上--masters所有 master 节点 IP建议 3 个--nodes所有 work 节点 IP按业务量决定--user/--passwdSSH 登录用户和密码--pkSSH 私钥路径--portSSH 端口默认 22如果改过要显式指定这里有个容易被忽略的点Sealos 安装过程中会通过 SSH 从主节点访问所有节点并分发配置。如果你的环境里 SSH 端口不是 22一定要在命令里加--port否则安装会卡在“等待节点加入”这一步。另外一个强烈建议安装前把集群节点的时间同步做好。内网环境尤其重要很多机器没有 NTP 服务时间一偏kubeadm 生成的证书就会因为时间差在校验时失败而且问题是随机出现的非常难排查。建议提前启用 chrony 并且设置内网时间源。2.3 Calico 网络模式选择与防火墙端口放行清单Calico 是 Kubernetes 最常用的网络插件之一有两种主流模式IPIP 和 BGP。IPIP 模式需要把 Pod 网络包封装一层 IP 隧道配置简单不依赖交换机适合大多数私有化环境。BGP 模式则直接把节点和 Pod 路由宣告到物理网络性能更好但需要网络团队配合在交换机上配置 BGP。对于企业大模型私有化部署场景规模没有大到上万节点的情况下我建议默认用 IPIP省去和网络团队扯皮的环节。安装完成后如果要改 Calico 模式可以通过修改 Calico 的 Installation 资源实现但建议安装时就一次定好避免后面反复。端口层面是最大的“隐形坑”。如果你的服务器有 firewalld、ufw或者底层云平台有安全组一定要提前放行下面的端口端口作用放行范围6443Kubernetes API Server所有 master 节点互访以及外部管理端访问2379 / 2380etcd 客户端 / 集群通信master 节点之间10250kubelet 通信所有节点之间10255kubelet 只读端口新版本可选按需放行179Calico BGP节点之间如果用 BGP 模式4789Calico VXLAN节点之间30000 - 32767NodePort 服务端口外部业务访问80 / 443Ingress 入口对外提供 Web 服务如果你在安装时发现节点一直NotReady或者 etcd 状态异常先别怀疑 Sealos回头检查一下安全组和防火墙大概率是没有放行 2379/2380 或者 10250。3. Sealos 平台组件清单存储、镜像仓库、数据库和对象存储按需开启3.1 顶层设计先画一张私有化平台的组件依赖图很多同学安装完集群就急着开应用商店什么 MySQL、Redis、MinIO、Longhorn 一股脑全部装上。结果资源不够组件之间互相抢占最后谁也跑不稳。私有化部署的正确顺序是先画一张“依赖图”底层Kubernetes 集群和网络插件Sealos run 已经解决支撑层分布式存储Longhorn、对象存储MinIO、镜像仓库Harbor数据层MySQL、Redis、消息队列等中间件应用层比如大模型推理服务、RAG 服务、内部业务系统对于企业大模型私有化部署来说核心支撑层一定不能省。下面的表格是每个组件的“按需度”组件用途建议Longhorn持久化存储给 Pod 提供卷生产环境必装MinIO对象存储存放模型文件、备份强烈推荐装Harbor私有镜像仓库强烈推荐装Nginx Ingress对外统一入口推荐装Prometheus Grafana监控告警推荐装MySQL / Redis业务数据缓存按需装这套组件的核心逻辑是先把“水龙头和自来水管道”都铺好再开应用商店不然应用商店里的组件装到一半发现没 PV 可用很被动。3.2 分布式存储选 Longhorn 还是 OpenEBS存储选型我直接给结论私有化部署优先用 Longhorn。表格对比一下对比项LonghornOpenEBS数据高可用多副本复制支持节点故障自动恢复LocalPV 无副本Jiva 性能一般快照备份内置快照、备份恢复需要额外组件支持RWX 支持支持 ReadWriteMany支持有限运维界面自带 Web UI需要 kubectl 操作适用场景生产环境轻量测试、单机环境Longhorn 的高可用能力是私有化部署最关心的。默认我建议把副本数设为 2也就是一份数据存两个副本一台节点宕机不影响数据。安装之前所有节点需要安装 open-iscsi 依赖# Ubuntu apt install -y open-iscsi nfs-common # Rocky / CentOS yum install -y iscsi-initiator-utils nfs-utilsLonghorn 安装用 Helm 就行helm repo add longhorn https://charts.longhorn.io helm install longhorn longhorn/longhorn -n longhorn-system --create-namespace \ --set defaultSettings.defaultReplicaCount2安装完成后默认的 StorageClass 名称通常是longhorn。后面所有有状态应用PVC 里指定这个 StorageClass 即可。3.3 私有镜像仓库是“硬门槛”私有化环境最常见的问题是没有公网或者说公网速度不可控Pod 拉镜像拉半天。所以镜像仓库是绕不过去的一个组件。我推荐 Harbor原因很简单它不仅有镜像存储能力还有 Web UI、镜像复制、安全扫描非常适合企业内部交付。Harbor 的安装细节这里不展开但核心配置可以直接抄# harbor.yml hostname: harbor.example.com http: port: 80 harbor_admin_password: ChangeMe_PrivateCloud data_volume: /data/harbor安装完成后如果你在 containerd 环境里拉取 Harbor 镜像千万别再用 Docker 的daemon.json思路。Sealos 默认使用 containerd正确方式是在/etc/containerd/certs.d/目录下单独配置仓库证书。mkdir -p /etc/containerd/certs.d/harbor.example.com cat /etc/containerd/certs.d/harbor.example.com/hosts.toml EOF server https://harbor.example.com [host.https://harbor.example.com] ca /etc/containerd/certs.d/harbor.example.com/ca.crt EOF这种配置方式的好处是每个镜像仓库独立一个目录不影响其他仓库。之后在 Kubernetes 里创建 Secret 并在 Pod 的imagePullSecrets中引用就可以正常从 Harbor 拉取镜像了。如果内网还没有配置 CA 证书也可以先用 HTTP 协议但一定要在 containerd 里把这个仓库标记为 insecure。这不是最佳实践但能让你快速跑通业务后面再补证书和证书到期自动续签。3.4 数据库和对象存储的初始化配置对象存储建议直接用 MinIO。对于大模型场景模型文件通常体积大、数量多放对象存储是最合适的。MinIO 的部署模式有两类单节点单盘适合测试简单但是没有冗余分布式多节点多盘至少 4 个盘使用纠删码保护数据可靠性高生产私有化环境建议分布式模式。创建后记得把 MinIO 的 Endpoint 地址、Access Key、Secret Key 记录下来后续大模型推理服务读取模型文件会用到。数据库方面如果你通过 Sealos 应用商店安装 MySQL 或 Redis一定不要接受默认的全裸配置。至少要指定root 密码不要用弱口令资源限制CPU、内存都要限防止一个实例把整台节点打满数据目录PVC 使用longhornStorageClass以 MySQL 为例创建 PVC 时直接指定apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mysql-data namespace: default spec: accessModes: - ReadWriteOnce storageClassName: longhorn resources: requests: storage: 200Gi4. 大模型私有化部署专项GPU 驱动、模型存储与资源隔离4.1 NVIDIA 驱动与容器运行时的三层配置大模型私有化部署前GPU 节点只有一层裸驱动是不够的。要做三层配置GPU 驱动、NVIDIA Container Toolkit、Kubernetes 资源调度入口。第一步安装驱动。这一步不再多说装完用nvidia-smi确认显卡能被系统识别。注意驱动版本和 CUDA 版本的兼容关系尤其是 PyTorch 或 vLLM 对 CUDA 版本有明确要求。第二步安装 NVIDIA Container Toolkit让 containerd 能调用 GPUnvidia-ctk runtime configure --runtimecontainerd systemctl restart containerd配置完成后检查一下 containerd 配置文件里是否生成了 nvidia runtime 相关内容。这个步骤是大模型容器能不能在 Pod 里看到 GPU 的关键。第三步给 GPU 节点打标签并创建一个测试 Pod 验证整条链路kubectl label node gpu-node-name nvidia.com/gputrue测试 Pod 直接用nvidia/cuda镜像apiVersion: v1 kind: Pod metadata: name: nvidia-gpu-test spec: restartPolicy: OnFailure nodeSelector: nvidia.com/gpu: true containers: - name: cuda-test image: nvidia/cuda:12.2.0-base-ubuntu22.04 command: [nvidia-smi] resources: limits: nvidia.com/gpu: 1如果kubectl logs nvidia-gpu-test能看到 GPU 信息说明容器运行时和调度器这条链路已经通了后面再部署推理服务就直接在resources.limits里声明nvidia.com/gpu: 1即可。4.2 模型文件用 PVC 还是 MinIO我给大模型场景的存储方案大模型私有化部署绕不开模型文件存放的问题。模型文件经常是几十 G 甚至上 TB 级别不能随便放在某个容器的临时目录里。我的建议是双通道方案模型原始文件放 MinIO 对象存储推理服务运行时挂载 Longhorn PVC首次启动时从 MinIO 拉取到本地后续每次启动直接读本地避免频繁访问对象存储影响性能。模型 PVC 可以这样建apiVersion: v1 kind: PersistentVolumeClaim metadata: name: model-registry namespace: llm-prod spec: accessModes: - ReadWriteMany storageClassName: longhorn resources: requests: storage: 500Gi另外模型目录建议固定结构/models/{model_name}/{version}/。每次更新模型的时候在 MinIO 里保留上一版本方便快速回滚。不要直接把新模型覆盖到同一个路径一旦推理服务加载后发现效果不对再找回旧版本就麻烦了。4.3 命名空间、Quota 和 LimitRange 一次性配完如果企业内部多个部门要共享这套 Sealos 平台尤其是大模型相关项目资源隔离一定要做。否则一个团队跑训练任务可能把整个集群的 CPU 和内存都吃光所有业务一起受影响。先创建独立命名空间kubectl create ns llm-prod kubectl create ns llm-test再给生产命名空间设置资源配额apiVersion: v1 kind: ResourceQuota metadata: name: llm-prod-quota namespace: llm-prod spec: hard: requests.cpu: 32 requests.memory: 256Gi limits.cpu: 64 limits.memory: 512Gi persistentvolumeclaims: 20这样可以保证整个生产空间最多使用 512G 内存不会把集群所有资源占用完。在这个基础上再加一个 LimitRange防止某一个 Pod 无限量申请资源apiVersion: v1 kind: LimitRange metadata: name: pod-min-max namespace: llm-prod spec: limits: - max: cpu: 16 memory: 64Gi min: cpu: 250m memory: 256Mi default: cpu: 2 memory: 4Gi defaultRequest: cpu: 500m memory: 1Gi type: Containerdefault字段才是关键如果某个部署没有显式写资源限制系统会自动套用这个默认值避免“裸奔”Pod 出现。4.4 安全加固从匿名访问到网络策略企业环境做私有化部署安全加固不能只是嘴上说说。很多公司把集群拉起来后默认权限一放所有开发都能kubectl delete这是非常危险的。第一步给不同角色分配最小 RBAC 权限。例如给算法团队只读权限给平台运维团队才有写权限。不要图省事直接给cluster-admin。第二步用 NetworkPolicy 控制 Pod 之间的网络访问。大模型服务只应该被前面网关访问不应该被任意命名空间里的 Pod 随意调用。最简单的基线策略是“默认拒绝”然后再放行需要的路径apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all namespace: llm-prod spec: podSelector: {} policyTypes: - Ingress - Egress创建之后这个命名空间里的所有 Pod 无法被外部流量访问也不会主动访问外部。随后再创建一条策略只允许来自 Ingress 的流量进入模型服务 Pod。这一套做完整个 Sealos 平台才勉强达到“可以交付给企业”的标准。5. 抄完作业怎么验收巡检命令、排障顺序与日常备份5.1 安装完成后的十五分钟巡检清单集群部署完先别急着接业务我习惯花十五分钟做一套巡检确认整个平台健康。先看最基础的节点状态kubectl get nodes -o wide kubectl get pods -A | grep -v Running | grep -v Completed如果所有核心 Pod 都在 Running 或 Completed 状态说明 Sealos 集群基本正常。然后再看存储和资源kubectl get sc kubectl get pvc -A df -h /var/lib/containerd /var/lib/kubelet同时每台节点都检查一下时间同步和磁盘用量timedatectl df -h磁盘用量是长期运维里最常见的问题建议安装完成时就记录一次基线数据后续每周对比一次能提早发现数据盘增长异常。5.2 最容易踩的三个坑安装超时、数据盘没挂、镜像拉不来第一个坑是安装超时。大概率不是 Sealos 的问题而是节点之间某些端口没放行。尤其是 master 节点之间的 2379/2380 端口、各节点之间的 10250 端口。排查方式很直接在任意一台节点 telnet 对端 IP 端口通不通一看便知。第二个坑是数据盘没挂载就装存储。Longhorn 这类存储组件对目录有硬性要求如果/var/lib/longhorn还没绑定到数据盘后面 PV 会一直处于Pending看起来像是存储组件故障实际上只是磁盘没提前铺好。所以 1.3 节的内容一定不要跳过。第三个坑是镜像拉不下来。内网环境要么配好 Harbor要么提前把所有镜像导入 Sealos。如果业务 Pod 一直ImagePullBackOff第一反应是去节点上手动crictl pull试一下能看到具体的报错信息比在控制器里猜效率高得多。遇到集群状态乱到无法修的时候直接重置重装往往更快Sealos 提供了重置命令sealos reset这条命令会清空当前集群执行前务必确认数据已经备份。5.3 离线内网环境的镜像搬运方案很多企业私有化部署环境是物理隔离的不能访问外网。这时候就要求在“有网环境”里把需要的 Sealos 镜像全部拉下来再搬运到内网。具体思路是这样# 有网环境执行拉取安装所需的镜像并导出 sealos pull kubernetes:v1.28.0 calico:v3.25.1 helm:v3.12.0 sealos save -o sealos-images.tar kubernetes:v1.28.0 calico:v3.25.1 helm:v3.12.0 # 拷贝到内网后执行 sealos load -i sealos-images.tar sealos run kubernetes:v1.28.0 calico:v3.25.1 helm:v3.12.0 \ --masters 172.16.0.2 172.16.0.3 172.16.0.4 \ --nodes 172.16.0.5 172.16.0.6 172.16.0.7 \ --user root \ --passwd Pssw0rd实际安装时sealos save和sealos load的具体参数可能随版本有变化以sealos save --help和sealos load --help输出为准。业务相关的镜像也建议统一推到内网 Harbor 里再从 Harbor 拉取。这样做的好处是后续运维不需要每台机器登录操作所有镜像统一管理。5.4 运维备份清单etcd、PVC 与配置仓库最后说备份。私有化部署不是装完就完事日常备份才是长期活得好的关键。etcd 是集群状态的核心必须定期做快照。快照命令需要用到 master 节点的证书推荐用脚本封装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).dbLonghorn 卷的快照可以在 Longhorn Web UI 里手动或定时执行。如果模型文件特别重要尽量在每次更新模型前做一次卷快照不要只依赖 MinIO 里的源文件。另外把安装时的 Clusterfile、Harbor 配置、Helm values.yaml 这些配置全部纳管到内部 Git 仓库里。我不止一次遇到过这种场景半年后集群出问题想重建环境结果发现当时安装命令用的什么版本、什么参数早就忘了。配置仓库是“抄作业”最后一块拼图有了它这套方案才能被团队其他人真正接手。最后分享一个我自己的习惯每次做完私有化交付我会把巡检命令写成一个脚本放进/root/inspection.sh再用 cron 每周跑一次把节点状态、磁盘用量、存储卷状态输出到内部群里。后面团队问我“集群还健康吗”我直接让他们看群消息不需要再登服务器敲命令。这个习惯帮我提前发现了不少磁盘暴涨和证书即将过期的问题你也可以照着配一份。
阅读完成 · 觉得有帮助？
