1. 为什么我选择在裸金属上自建 Kubernetes 与 KubeSphere1.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/16Service 网段选 10.233.0.0/18。为什么 Service 网段用 /18因为 K8s 默认给每个节点分配的 Pod 数量有限Service 数量相对少/18 能提供约 16000 个地址对中小集群足够。如果网段重叠会出现 Pod 能起但访问不了 Service 的情况排查起来非常费劲。组件推荐网段地址数量说明宿主机内网10.0.0.0/16约 65000按实际规划Pod 网段172.16.0.0/16约 65000不能与宿主机重叠Service 网段10.233.0.0/18约 16000不能与宿主机重叠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 没有设资源限制把节点资源吃光了。解决办法是给所有工作负载设置合理的资源请求和限制并且配置资源配额防止单个项目占用过多。问题现象可能原因排查方向解决手段Pod 一直 Pending资源不足或调度约束看 Pod 事件和节点资源调整资源或节点节点 NotReady网络或运行时异常看节点状态和 kubelet 日志修复网络或重启服务镜像拉取失败网络或认证问题看 Pod 描述和节点网络修 DNS 或配凭证Service 访问不通网段重叠或插件异常看网络插件 Pod 日志调整网段或重装插件5.4 存储配置不当导致的数据丢失存储这块我踩过最狠的坑是用了没有持久化保证的存储方案节点重启后数据没了。后来我坚持用有副本机制的存储或者至少用可靠的网络存储。对于有状态服务存储的可靠性直接决定数据安全不能图省事。6. 集群稳定运行后的日常维护心得6.1 备份与恢复策略集群跑起来后备份是头等大事。要备份的东西包括etcd 数据、K8s 资源清单、KubeSphere 的配置和用户数据。etcd 备份我一般用定时任务每天一次保留最近若干份。资源清单可以用工具导出定期存档。恢复演练同样重要。备份了不演练真出事时可能发现备份不可用。我建议至少每季度做一次恢复演练在测试环境验证备份能否成功恢复。6.2 版本升级的节奏把控K8s 和 KubeSphere 都会出新版本但不要追新。我的策略是等新版本发布一段时间、社区反馈稳定后再升级并且升级前一定在测试环境验证。升级顺序是先升 K8s 再升 KubeSphere因为后者依赖前者。升级过程中最怕的是 API 变更导致旧资源不兼容。升级前要检查有没有用到废弃的 API 版本提前迁移。这个工作可以在升级前的准备阶段用工具扫描出来。6.3 性能调优的几个抓手集群稳定后可以做一些调优。控制面方面可以调整 API Server 的并发处理参数工作节点方面可以优化容器运行时的配置网络方面可以根据流量特征调整网络插件的参数。调优要基于监控数据不要凭感觉改参数。我一般先观察一周的监控基线找出瓶颈点再针对性调整。调整后继续观察确认效果。盲目调参可能引入新问题得不偿失。6.4 给后来者的几句实在话这套方案我从第一次部署到现在前后折腾过好几轮最大的体会是不要追求一步到位。先搭最小可用集群跑通基本流程再逐步加高可用、加监控、加多租户。每一步都验证通过再往下走比一口气全上然后到处救火要快得多。另外文档要边做边记。部署过程中遇到的每个报错、每个解决步骤都记下来。下次再搭或者帮别人排查时这些记录就是最宝贵的资料。我现在的部署笔记已经攒了厚厚一叠每次翻看都能想起当时踩坑的场景。最后分享一个小技巧在正式部署前先用虚拟机或容器模拟一遍完整流程。模拟环境里随便折腾把坑都踩一遍正式环境就能少走很多弯路。这个习惯帮我省下了大量在真实环境里试错的时间。
