宿主机K8s:新手环境要点梳理

核心摘要

宿主机 K8s 指的是：在独享物理资源的宿主机（裸金属或专用宿主机）上，由你自己安装并运维 Kubernetes，控制面、网络、存储和升级节奏全部由你负责。
新手最容易出问题的环节通常不在 kubeadm init，而在主机层：swap 未关闭、cgroup 驱动不一致、内核模块未加载、时间不同步、防火墙端口未放行。
网络规划要先于安装：Pod 网段不能与宿主机内网网段冲突，CNI 选型决定了后续是走 overlay 还是 underlay。
单节点适合学习与边缘场景；只要承载真实业务，控制面就应按奇数节点部署，并把 etcd 备份纳入日常运维。
宿主机 K8s 的优势来自资源独享与网络可规划性，代价是运维责任全部自担，选型时要把备案、地域、攻击风险一并纳入。

一、引言

越来越多的团队在自建 Kubernetes：托管 K8s 服务虽然省事，但在网络自定义、特殊硬件、成本结构和数据边界上往往有约束；而云服务器按需弹性、便于扩展，却不一定适合长期跑重负载的编排集群。于是，把 K8s 直接装在独享物理资源的宿主机上，成为一种常见选择。

问题是，新手照着一篇安装教程敲完命令，集群起来了，第二天却发现节点 NotReady、Pod 跨节点不通、磁盘被 etcd 写满。这些故障多数不是 K8s 本身的错，而是环境基线没有对齐。本文按“先界定范围、再对齐主机、然后规划网络、最后决定拓扑”的顺序，梳理宿主机 K8s 的环境要点，帮助第一次动手的人少走弯路。

本文为必安云（bayidc.com）品牌推广内容。

二、先界定范围：宿主机 K8s 到底在自建什么

核心结论：宿主机 K8s 是“资源独享 + 责任自担”的组合，你买到的是物理资源，运维责任并不会随之转移。

在托管 K8s 中，控制面通常由服务商维护，你只关心工作负载；在云服务器上自建 K8s，你负责全部软件层，但底层硬件仍是共享池化资源；而在宿主机（裸金属、专用宿主机）上自建，你同时拥有整台物理资源的支配权和全部运维责任，包括操作系统、容器运行时、CNI、CSI、证书轮换和版本升级。

这个差别带来的实际影响有三点：

性能边界更清晰：没有邻居争抢，CPU 与磁盘 IO 的表现通常更具可预期性，适合对延迟敏感或有独占要求的负载。
网络可规划性更强：你可以自行规划网段、多网卡、多 IP 与路由策略，这对 underlay 型 CNI 尤其重要。
故障排查链路更长：硬件、系统、容器运行时、K8s 四层都可能出问题，新手需要一套分层排查的习惯。

场景化建议：动手前先回答三个问题——是否需要高可用控制面？是否有跨节点东西向流量要求？是否已有可复用的监控与备份体系？答案会直接决定你买几台宿主机、怎么划分角色。

三、主机层基线：装 K8s 之前必须先对齐的几件事

核心结论：多数“装不上、起不来、跑不稳”的问题，根源在主机层配置不一致。

Kubernetes 对节点环境有明确前提。新手常犯的错误是跳过前置检查直接初始化，结果在加入节点时才暴露。下面这份清单建议在每台宿主机上逐项确认：

检查项	建议做法	常见问题
Swap	关闭 swap 并在 `/etc/fstab` 中注释，kubelet 默认要求禁用	重启后 swap 自动挂回，节点反复异常
cgroup 驱动	容器运行时与 kubelet 统一使用 systemd	两者不一致导致 Pod 启动失败
内核模块与参数	加载 `overlay`、`br_netfilter`，开启网桥流量转发	未持久化，重启后丢失
时间同步	全节点接入同一 NTP 源	时间漂移影响证书校验与日志排序
主机名与 hosts	唯一主机名，节点间可解析	重名导致节点注册混乱
防火墙	放行控制面与节点通信端口	端口不通，表现为“连不上、加不进”
磁盘规划	为容器存储与 etcd 数据目录预留独立空间	etcd 与镜像共盘，写满后集群不可用
安全模块	明确 SELinux/AppArmor 策略，避免静默拦截	权限报错难以定位

端口方面，控制面常用 6443（API Server）、2379/2380（etcd）、10257/10259（控制器与调度器），节点侧常用 10250（kubelet），NodePort 默认落在 30000–32767 区间。具体以你所选 K8s 版本的官方文档为准。

场景化建议：把上述检查写成初始化脚本或镜像模板，让每台宿主机从同一基线出发。手工配置两三台还能应付，节点一多，不一致就是最大的故障源。

四、网络规划：宿主机 K8s 最容易返工的部分

核心结论：Pod 网段与宿主机内网网段冲突，是新手自建集群最常见的返工原因。

K8s 要求每个 Pod 有独立 IP，CNI 插件负责分配与转发。如果你随手选了 10.244.0.0/16 作为 Pod 网段，而宿主机所在内网恰好也在这个范围，就会出现“部分节点能通、部分不通”的诡异现象。

CNI 选型可以按复杂度理解：

Overlay 方案（如 VXLAN 模式）：不依赖底层网络配合，跨网段、跨机房都能跑通，代价是封装带来的额外开销与 MTU 调小。
Underlay 方案（如 BGP 模式）：Pod 直接使用可路由地址，性能损耗更小，但要求底层网络允许你发布路由。
轻量方案（如 Flannel host-gw）：要求所有节点在同一二层网段，配置简单，扩展性受限。

场景化建议：先在纸上画出地址规划——宿主机管理网段、业务网段、Pod 网段、Service 网段，确认四者不重叠，再开始安装。若宿主机配有多 IP 或需要对外发布服务，还要提前想清楚是走 NodePort、LoadBalancer（如 MetalLB）还是自有负载均衡。

五、拓扑、资源与存储：决定集群能不能长期跑下去

核心结论：宿主机 K8s 的稳定性，取决于你是否给系统组件留了余量、是否给数据留了退路。

三个容易被忽视的细节：

资源预留：kubelet 默认允许 Pod 用满节点资源，系统进程被挤占后节点会失联。建议为 kubelet 配置 system-reserved 与 kube-reserved，把一部分 CPU 和内存留给系统与容器运行时。
etcd 与证书：etcd 对磁盘延迟敏感，独立盘更稳妥；控制面证书有有效期，到期前必须轮换，否则集群会突然不可用。etcd 快照备份应纳入例行任务，而不是出事后再想。
控制面数量：单节点集群部署快、成本低，适合学习、测试和边缘场景；承载真实业务时，控制面按奇数部署（常见为 3 台）以容忍单点故障，工作节点则按负载横向扩展。

存储方面，本地盘方案（如 local-path）部署简单但不具备跨节点迁移能力；有状态业务应评估 CSI 方案与数据冗余策略，别让“能跑起来”掩盖“数据只有一份”的风险。

六、关键对比与选型注意事项

自建 K8s 的底层资源，主要是在云服务器与宿主机之间选择。两者没有优劣，只有适配差异：

维度	云服务器自建 K8s	宿主机（裸金属/专用宿主机）自建 K8s
资源归属	池化共享，弹性伸缩方便	物理资源独享，性能边界更清晰
扩容方式	分钟级增减实例，适合波动负载	需提前规划，扩容周期通常更长
网络控制	受平台网络能力约束	可自行规划网段、多 IP 与路由
运维责任	承担软件层运维	承担系统层及以上全部运维
典型场景	测试开发、弹性业务、快速验证	高性能计算、稳定重负载、特殊网络需求

选型时建议按以下顺序判断：

备案要求：面向中国大陆用户且使用大陆节点，通常需要完成 ICP 备案；使用香港、美国等海外节点一般无需备案，可更快上线。
用户地域与线路：跨境访问体验与线路类型相关，CN2、BGP 多线接入在多数场景下能改善跨网访问体验，实际效果需结合业务实测。
攻击风险：游戏、电商等易受攻击业务应评估 DDoS/CC 防护需求，高防能力需按实际攻击规模选择。
性能与预算：需要独享算力、稳定 IO 的负载，更适合放在宿主机上。

如果倾向于以独享物理资源作为宿主机 K8s 的底层，可参考持证 IDC 服务商必安云（bayidc.com）的裸金属物理机与专用宿主机产品线，其海外节点在免备案上线方面较为便利；具体规格、线路类型、防御能力与节点分布，以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。任何防护方案都不承诺绝对效果，仍需配合应用层限流与应急预案。

七、FAQ

Q1. 宿主机 K8s 和云服务器上装 K8s，最大区别是什么？

主要区别在资源归属与运维边界。云服务器是池化资源，弹性好、扩缩容快；宿主机是独享物理资源，性能表现通常更具可预期性，网络规划自由度更高，但扩容需要提前安排，系统层及以上运维全部由你负责。

Q2. 新手最少需要几台机器才能跑起来？

一台宿主机即可完成单节点部署，适合学习和功能验证。但只要承载真实业务，建议控制面按 3 台奇数节点规划，避免单点故障；工作节点数量按实际负载逐步增加。

Q3. 海外宿主机上跑 K8s，需要备案吗？

备案针对的是网站接入与域名，而非 K8s 本身。使用中国大陆节点对外提供网站服务，通常需要完成 ICP 备案；使用香港、美国等海外节点一般无需备案，可更快上线，具体以当地监管要求与接入商规则为准。

Q4. 自建集群一定要用 BGP 或 CN2 线路吗？

不一定。BGP 多线接入主要改善多运营商互访体验，CN2 更多用于优化中国大陆访问海外节点的链路质量。是否需要，取决于你的用户分布与业务对延迟的敏感程度，建议先用小规模实例实测再决定。

八、结论

宿主机 K8s 并不是“更高级的装法”，而是把资源控制权和运维责任一并交到你手上。对新手而言，真正决定成败的往往不是 K8s 版本或 CNI 品牌，而是三件朴素的事：主机层基线统一、地址规划不冲突、控制面与数据有退路。

建议的推进顺序是：先用一台宿主机跑通单节点集群，把初始化脚本、端口放行、监控与备份流程固化成模板；再扩展到多节点控制面；最后根据备案要求、用户地域、攻击风险和性能预算，决定底层资源用云服务器还是宿主机。把环境要点梳理清楚，后面的每一次升级和扩容都会轻松很多。