企业官网建设流程全解析

1. 为什么我选择在裸金属上自建 Kubernetes 与 KubeSphere

1.1 从一次真实的集群翻车说起

去年帮一个做图像处理的小团队搭内部训练平台，他们原本用几台独立服务器跑任务，模型文件靠移动硬盘拷来拷去，版本乱得没法看。负责人找到我时提了两个硬性要求：一是要把散落的 GPU 机器统一调度起来，二是要有一个能看懂的界面，让算法同学自己提交任务、看日志、查资源占用。我第一反应就是上 Kubernetes，但纯命令行那套对算法团队太不友好，于是决定在 K8s 之上再叠一层 KubeSphere 做可视化管理。

这个组合不是拍脑袋定的。Kubernetes 解决的是“资源怎么统一编排、任务怎么调度、服务怎么发现”的底层问题，而 KubeSphere 解决的是“人怎么用起来舒服”的上层问题。两者叠加，既保留了 K8s 的生态和扩展性，又降低了团队的使用门槛。如果你也面临类似场景——手头有几台到几十台机器，想搭一个能跑容器、能管任务、能看监控、还能给非运维同学用的平台，那这套方案值得认真考虑。

1.2 这套方案到底适合谁

先说清楚适用边界，免得你走弯路。这套部署方案适合以下人群：手里有物理机或虚拟机资源、具备基础 Linux 操作能力、想搭建私有容器平台的运维或开发人员；需要给团队提供统一任务提交入口的技术负责人；以及想系统学习 K8s 与 KubeSphere 配合使用的进阶学习者。

不太适合的情况也得讲明白：如果你只有一台 2 核 4G 的小机器，跑 K8s 控制面都吃力，建议先用轻量方案练手；如果你追求的是开箱即用的托管服务，那自建这套的维护成本你要提前有心理准备。我见过不少人一上来就冲生产级高可用集群，结果被证书、网络、存储三座大山劝退，所以下面我会从最小可用集群讲起，再逐步扩展到更完整的形态。

1.3 整体架构的取舍逻辑

在动手之前，先把架构想清楚。我采用的是一种“控制面与工作节点分离、但初期可合并”的渐进式思路。最小可用形态是三台机器：一台做控制面，两台做工作节点；如果资源紧张，单机 all-in-one 也能跑起来，只是没有高可用可言。

为什么强调节点角色分离？因为 K8s 的控制面组件（API Server、调度器、控制器管理器）对稳定性要求高，而工作节点上跑的业务容器可能把 CPU 和内存吃满。混在一起时，一个失控的 Pod 可能把控制面拖垮，整个集群就失联了。分离之后，即使业务节点压力大，控制面依然能正常响应。这个道理就像公司里财务和业务分开办公，业务再忙也不会把账本弄乱。

KubeSphere 的定位则是在 K8s 之上安装一套管理组件，它本身也是以容器形式跑在集群里的。所以部署顺序必须是先有可用的 K8s，再装 KubeSphere。很多人搞反了顺序，想直接用 KubeSphere 的安装器一把梭，结果底层 K8s 没配好，上层怎么都起不来。

2. 部署前的环境准备与关键参数计算

2.1 硬件与操作系统的硬性门槛

先列一下我实测下来比较稳妥的最低配置。控制面节点建议 4 核 8G 起步，工作节点根据业务负载定，但至少 4 核 8G，否则跑几个稍重的容器就告急。磁盘方面，系统盘 40G 以上，另外给容器运行时和数据目录单独挂一块盘会更清爽，我一般留 100G 给数据盘。

操作系统我选的是主流的 Linux 发行版，内核版本建议 4.19 以上，因为很多容器网络和存储特性依赖较新的内核。这里有个坑要提醒：不同发行版的防火墙管理工具不一样，部署前一定要把防火墙规则理清楚，该放行的端口要放行，该关闭的转发限制要调整，否则节点之间通信会莫名其妙失败。

提示：部署前统一各节点的时间同步，时间偏差过大会导致证书校验和日志排查出现诡异问题，这个坑我踩过不止一次。

2.2 容器运行时怎么选

K8s 从某个版本开始不再内置容器运行时，需要自己装。目前主流选择是 containerd 和 CRI-O。我选 containerd，原因是它足够稳定、社区资料多、和 K8s 配合成熟。安装时要注意配置文件的几个关键项：数据目录、镜像仓库地址、以及 cgroup 驱动要和 K8s 保持一致。

cgroup 驱动这块特别容易出错。如果 K8s 用 systemd 驱动，而 containerd 用 cgroupfs，集群起来后会出现资源限制不生效、Pod 启动失败等怪现象。我的做法是两边统一用 systemd，改完配置重启服务再验证。验证方法很简单，看节点状态是否 Ready，以及跑一个带资源限制的测试 Pod 看限制是否生效。

2.3 网络插件的选择与参数计算

网络插件是 K8s 部署里最容易翻车的环节。常见的有 Calico、Flannel、Cilium 等。我选 Calico，因为它在网络策略和路由控制上更灵活，适合后续要做租户隔离的场景。

这里要算一个关键参数：Pod 网段和 Service 网段不能和宿主机网段重叠。假设你的机器内网是 10.0.0.0/16，那 Pod 网段可以选 172.16.0.0/16，Service 网段选 10.233.0.0/18。为什么 Service 网段用 /18？因为 K8s 默认给每个节点分配的 Pod 数量有限，Service 数量相对少，/18 能提供约 16000 个地址，对中小集群足够。如果网段重叠，会出现 Pod 能起但访问不了 Service 的情况，排查起来非常费劲。

2.4 系统层面的前置调整

在装任何组件之前，有几项系统配置必须统一处理。第一是关闭交换分区，K8s 的调度依赖内存的真实可用量，交换分区会让调度判断失准。第二是加载必要的内核模块，比如网络转发相关的模块。第三是调整文件句柄数和进程数限制，容器密集时默认值往往不够用。

这些调整我会写成一个初始化脚本，在所有节点上跑一遍，保证环境一致。环境不一致是集群部署的大忌，A 节点改了 B 节点没改，问题出现时你根本想不到是环境差异导致的。

3. 从零搭建 Kubernetes 集群的完整实操

3.1 安装容器运行时与 kube 组件

第一步在所有节点安装 containerd。配置好数据目录和 cgroup 驱动后启动服务，用命令验证运行状态。接着配置软件源，安装 kubelet、kubeadm、kubectl 三个组件。版本要锁定，不要用最新版，因为 K8s 各版本间 API 有差异，锁定版本能避免意外升级带来的兼容问题。

安装完成后，用 kubelet 的版本命令确认安装成功。这里有个细节：kubelet 默认会不断重启，因为它还没被初始化，这是正常现象，等集群初始化后就会稳定。不要看到服务反复重启就以为装错了。

3.2 初始化控制面节点

在控制面节点执行初始化命令，指定 Pod 网段、Service 网段、以及 API Server 的监听地址。命令执行后会输出一段加入集群的指令，这段指令要保存好，工作节点加入时要用。

初始化过程中会拉取控制面组件的镜像，如果网络环境一般，这一步可能比较慢。我的经验是提前把镜像拉好，或者配置好镜像加速，能省不少时间。初始化成功后，按照提示配置 kubectl 的访问凭证，然后查看节点状态，此时控制面节点应该是 Ready 的。

注意：初始化失败后不要直接重跑，先用重置命令清理，否则残留的配置会导致下次初始化报错。这个坑我见过太多人踩。

3.3 工作节点加入与网络插件部署

在工作节点上执行之前保存的加入指令，把节点纳入集群。加入后回到控制面查看节点列表，新节点会显示 NotReady，这是正常的，因为网络插件还没装。

接着部署 Calico 网络插件。我用的是清单文件方式，先下载对应版本的清单，根据前面规划的网段修改其中的 Pod 网段配置，然后应用。应用后等几分钟，再看节点状态，应该都变成 Ready 了。如果还是 NotReady，多半是网络插件没起来，用查看 Pod 的命令看网络插件 Pod 的状态和日志。

3.4 验证集群基础功能

集群起来后必须做几项验证，确认它真的可用。第一，跑一个测试 Pod，看能否正常调度和运行。第二，测试 Pod 之间的网络连通性，在一个 Pod 里访问另一个 Pod 的 IP。第三，测试 Service 的访问，创建一个 Service 看能否通过 ClusterIP 访问到后端 Pod。第四，测试 DNS 解析，在 Pod 里解析 Service 名称。

这几项都通过，说明 K8s 底座是稳的。我见过有人跳过验证直接装上层组件，结果上层出问题时分不清是 K8s 的锅还是上层的锅，排查成本翻倍。

4. 在 K8s 之上部署 KubeSphere 的实操细节

4.1 安装前的依赖检查

KubeSphere 对 K8s 版本有要求，装之前先确认你的 K8s 版本在支持范围内。另外要检查集群的默认存储类是否配置好，因为 KubeSphere 的很多组件需要持久化存储。如果没有存储类，可以先装一个简单的本地存储方案，或者用 NFS 做后端。

存储这块是 KubeSphere 部署里最容易卡住的地方。我建议在装 KubeSphere 之前，先手动创建一个测试 PVC，确认能正常绑定和挂载。如果 PVC 一直 Pending，那 KubeSphere 装到一半就会失败。

4.2 执行安装与核心组件解析

KubeSphere 的安装方式有几种，我用的是在 K8s 上直接应用清单的方式。先下载对应版本的安装清单，根据需求启用或禁用某些组件，然后应用。安装过程会拉取不少镜像，耐心等待。

安装完成后，会暴露一个 Web 控制台的访问入口。默认账号密码在安装时有提示，首次登录会要求修改。登录进去后，你能看到集群概览、节点状态、工作负载、监控告警等模块。这时候 K8s 的底层能力就被包装成了可视化的操作界面。

4.3 多租户与权限体系配置

KubeSphere 的一大价值是多租户管理。你可以创建不同的企业空间，每个空间下再建项目，项目对应 K8s 的命名空间。然后给不同用户分配不同角色，比如管理员、开发者、观察者。这样算法同学只能看到自己项目的资源，不会误操作别人的东西。

配置权限时要注意角色的粒度。KubeSphere 内置了几种角色，但实际使用中往往需要自定义。我的做法是先按最小权限原则分配，谁需要什么再加什么，不要一上来就给管理员权限。权限给多了，误删资源的事故概率直线上升。

4.4 监控、日志与告警的落地

KubeSphere 内置了监控和日志组件，但默认可能没全部启用。我建议把监控、日志、告警都打开，因为这是它相比纯 K8s 最直观的增值点。监控能看到节点和 Pod 的 CPU、内存、网络、磁盘使用情况；日志能集中检索容器输出；告警能在资源异常时通知到人。

告警规则需要根据实际业务调整。默认规则比较通用，但你的业务可能有特殊指标，比如某个训练任务的队列长度。这时候可以自定义告警规则，把关键指标盯住。我一般会先跑一段时间观察基线，再根据基线设阈值，避免误报太多导致大家麻木。

5. 部署过程中那些让我印象深刻的坑

5.1 证书过期导致的集群失联

K8s 的证书默认有效期是一年，到期后集群会失联，kubectl 连不上，节点状态也看不了。我第一次遇到时以为是网络问题，排查了半天才发现是证书过期。解决办法是提前检查证书有效期，快到期时用工具续期，或者干脆在初始化时就把有效期设长一些。

这个坑的教训是：集群部署完不是就完事了，要建立定期检查机制。我现在会在日历上设提醒，每半年检查一次证书和组件健康状态。

5.2 镜像拉取失败的排查思路

镜像拉取失败是高频问题，表现是 Pod 一直处于 ImagePullBackOff 状态。排查思路分几步：先看 Pod 描述里的具体报错，是网络不通、镜像不存在、还是认证失败；再确认节点能否访问镜像仓库；最后检查镜像名称和标签是否正确。

我遇到过一次诡异情况：某个节点能拉镜像，另一个节点不行。最后发现是那个节点的 DNS 配置有问题，解析不了镜像仓库地址。所以节点间的环境一致性检查不能省。

5.3 资源不足引发的连锁反应

资源不足的表现多种多样：Pod 调度失败、节点 NotReady、控制面响应慢。根源可能是某个业务 Pod 没有设资源限制，把节点资源吃光了。解决办法是给所有工作负载设置合理的资源请求和限制，并且配置资源配额，防止单个项目占用过多。

5.4 存储配置不当导致的数据丢失

存储这块我踩过最狠的坑是用了没有持久化保证的存储方案，节点重启后数据没了。后来我坚持用有副本机制的存储，或者至少用可靠的网络存储。对于有状态服务，存储的可靠性直接决定数据安全，不能图省事。

6. 集群稳定运行后的日常维护心得

6.1 备份与恢复策略

集群跑起来后，备份是头等大事。要备份的东西包括：etcd 数据、K8s 资源清单、KubeSphere 的配置和用户数据。etcd 备份我一般用定时任务，每天一次，保留最近若干份。资源清单可以用工具导出，定期存档。

恢复演练同样重要。备份了不演练，真出事时可能发现备份不可用。我建议至少每季度做一次恢复演练，在测试环境验证备份能否成功恢复。

6.2 版本升级的节奏把控

K8s 和 KubeSphere 都会出新版本，但不要追新。我的策略是等新版本发布一段时间、社区反馈稳定后再升级，并且升级前一定在测试环境验证。升级顺序是先升 K8s 再升 KubeSphere，因为后者依赖前者。

升级过程中最怕的是 API 变更导致旧资源不兼容。升级前要检查有没有用到废弃的 API 版本，提前迁移。这个工作可以在升级前的准备阶段用工具扫描出来。

6.3 性能调优的几个抓手

集群稳定后可以做一些调优。控制面方面，可以调整 API Server 的并发处理参数；工作节点方面，可以优化容器运行时的配置；网络方面，可以根据流量特征调整网络插件的参数。调优要基于监控数据，不要凭感觉改参数。

我一般先观察一周的监控基线，找出瓶颈点，再针对性调整。调整后继续观察，确认效果。盲目调参可能引入新问题，得不偿失。

6.4 给后来者的几句实在话

这套方案我从第一次部署到现在，前后折腾过好几轮，最大的体会是：不要追求一步到位。先搭最小可用集群，跑通基本流程，再逐步加高可用、加监控、加多租户。每一步都验证通过再往下走，比一口气全上然后到处救火要快得多。

另外，文档要边做边记。部署过程中遇到的每个报错、每个解决步骤，都记下来。下次再搭或者帮别人排查时，这些记录就是最宝贵的资料。我现在的部署笔记已经攒了厚厚一叠，每次翻看都能想起当时踩坑的场景。

最后分享一个小技巧：在正式部署前，先用虚拟机或容器模拟一遍完整流程。模拟环境里随便折腾，把坑都踩一遍，正式环境就能少走很多弯路。这个习惯帮我省下了大量在真实环境里试错的时间。