企业官网建设流程全解析

这份配置清单，是我在多套企业内网环境里反复验证过之后整理出来的。刚好赶上企业大模型私有化部署的热潮，很多人拿到 Sealos 第一反应是按照官网文档装一套，可真到了有防火墙、有独立机房、有 GPU 服务器的地方，才发现缺的全是细节。Sealos 私有化部署这件事，难点不在“安装”，而在把配置清单补齐：机器选型、磁盘挂载、端口放行、组件取舍、镜像仓库、GPU 调度……每一项缺了都可能返工。

这篇不聊虚的，抛开复杂原理，把可直接复制的配置方案直接摆出来。适合负责基础设施运维和项目交付的同事照着抄，也适合刚接手私有云项目、想快速建立全局清单的朋友参考。

1. 先摸清底细：这版清单适配的 Sealos 部署场景和机器选型

1.1 三种可直接套用的节点规划模板

Sealos 底层是 Kubernetes，所以它的节点规划本质上就是 Kubernetes 集群节点规划。根据我的经验，私有化部署通常跑在这三种场景里，直接抄下面这个模板就行。

为什么 master 一定要 3 台？因为 etcd 使用的是 Raft 共识算法，3 个副本才能容忍一台节点故障。如果图省事只用 1 台 master，etcd、证书、API Server 全部挤在一台机器上，一旦这台机器重启或者磁盘损坏，整个集群就不可用了。对于企业大模型私有化部署来说，模型服务一旦中断，业务损失不是小数目，所以该花的机器钱不能省。

1.2 操作系统、内核参数和主机名这些“零碎项”怎么一次配齐

操作系统我在 Ubuntu 22.04 LTS 和 Rocky Linux 9 上都跑过 Sealos，结论是：只要团队熟悉，两种都可以，但内部测试我更喜欢 Ubuntu 22.04，包管理简单、内核版本够新，对 containerd 和 GPU 驱动的兼容性比较省心。无论选哪个，系统装完第一件事就是完成这些基础配置。

# 关闭 swap，Kubernetes 对 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 --system

net.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 默认用的容器运行时是 containerd，Kubernetes 的 kubelet 数据目录默认在/var/lib/kubelet，containerd 默认在/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 'P@ssw0rd'

如果生产环境禁用了密码登录，也可以用密钥方式：

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

参数含义并不复杂，建议记下来：

这里有个容易被忽略的点：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，或者底层云平台有安全组，一定要提前放行下面的端口：

如果你在安装时发现节点一直NotReady，或者 etcd 状态异常，先别怀疑 Sealos，回头检查一下安全组和防火墙，大概率是没有放行 2379/2380 或者 10250。

3. Sealos 平台组件清单：存储、镜像仓库、数据库和对象存储按需开启

3.1 顶层设计：先画一张私有化平台的组件依赖图

很多同学安装完集群就急着开应用商店，什么 MySQL、Redis、MinIO、Longhorn 一股脑全部装上。结果资源不够，组件之间互相抢占，最后谁也跑不稳。

私有化部署的正确顺序，是先画一张“依赖图”：

• 底层：Kubernetes 集群和网络插件（Sealos run 已经解决）
• 支撑层：分布式存储（Longhorn）、对象存储（MinIO）、镜像仓库（Harbor）
• 数据层：MySQL、Redis、消息队列等中间件
• 应用层：比如大模型推理服务、RAG 服务、内部业务系统

对于企业大模型私有化部署来说，核心支撑层一定不能省。下面的表格是每个组件的“按需度”：

这套组件的核心逻辑是：先把“水龙头和自来水管道”都铺好，再开应用商店，不然应用商店里的组件装到一半发现没 PV 可用，很被动。

3.2 分布式存储选 Longhorn 还是 OpenEBS

存储选型，我直接给结论：私有化部署优先用 Longhorn。

表格对比一下：

Longhorn 的高可用能力是私有化部署最关心的。默认我建议把副本数设为 2，也就是一份数据存两个副本，一台节点宕机不影响数据。安装之前，所有节点需要安装 open-iscsi 依赖：

# Ubuntu apt install -y open-iscsi nfs-common # Rocky / CentOS yum install -y iscsi-initiator-utils nfs-utils

Longhorn 安装用 Helm 就行：

helm repo add longhorn https://charts.longhorn.io helm install longhorn longhorn/longhorn -n longhorn-system --create-namespace \ --set defaultSettings.defaultReplicaCount=2

安装完成后，默认的 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: 200Gi

4. 大模型私有化部署专项：GPU 驱动、模型存储与资源隔离

4.1 NVIDIA 驱动与容器运行时的三层配置

大模型私有化部署前，GPU 节点只有一层裸驱动是不够的。要做三层配置：GPU 驱动、NVIDIA Container Toolkit、Kubernetes 资源调度入口。

第一步，安装驱动。这一步不再多说，装完用nvidia-smi确认显卡能被系统识别。注意驱动版本和 CUDA 版本的兼容关系，尤其是 PyTorch 或 vLLM 对 CUDA 版本有明确要求。

第二步，安装 NVIDIA Container Toolkit，让 containerd 能调用 GPU：

nvidia-ctk runtime configure --runtime=containerd systemctl restart containerd

配置完成后，检查一下 containerd 配置文件里是否生成了 nvidia runtime 相关内容。这个步骤是大模型容器能不能在 Pod 里看到 GPU 的关键。

第三步，给 GPU 节点打标签，并创建一个测试 Pod 验证整条链路：

kubectl label node <gpu-node-name> nvidia.com/gpu=true

测试 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: Container

default字段才是关键：如果某个部署没有显式写资源限制，系统会自动套用这个默认值，避免“裸奔”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 'P@ssw0rd'

实际安装时sealos save和sealos load的具体参数可能随版本有变化，以sealos save --help和sealos load --help输出为准。业务相关的镜像，也建议统一推到内网 Harbor 里，再从 Harbor 拉取。这样做的好处是，后续运维不需要每台机器登录操作，所有镜像统一管理。

5.4 运维备份清单：etcd、PVC 与配置仓库

最后说备份。私有化部署不是装完就完事，日常备份才是长期活得好的关键。

etcd 是集群状态的核心，必须定期做快照。快照命令需要用到 master 节点的证书，推荐用脚本封装：

ETCDCTL_API=3 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

Longhorn 卷的快照可以在 Longhorn Web UI 里手动或定时执行。如果模型文件特别重要，尽量在每次更新模型前做一次卷快照，不要只依赖 MinIO 里的源文件。

另外，把安装时的 Clusterfile、Harbor 配置、Helm values.yaml 这些配置全部纳管到内部 Git 仓库里。我不止一次遇到过这种场景：半年后集群出问题，想重建环境，结果发现当时安装命令用的什么版本、什么参数，早就忘了。配置仓库是“抄作业”最后一块拼图，有了它，这套方案才能被团队其他人真正接手。

最后分享一个我自己的习惯：每次做完私有化交付，我会把巡检命令写成一个脚本放进/root/inspection.sh，再用 cron 每周跑一次，把节点状态、磁盘用量、存储卷状态输出到内部群里。后面团队问我“集群还健康吗”，我直接让他们看群消息，不需要再登服务器敲命令。这个习惯帮我提前发现了不少磁盘暴涨和证书即将过期的问题，你也可以照着配一份。