CentOS 7 搭建 Kubernetes 集群实战：从 kubeadm 初始化到 CNI 配置

先在前面说一句实在话：CentOS 7 这套系统虽然已经停止维护，但存量机器真的太多太多，公司机房、测试环境、个人服务器上到处都是它的身影，而“CentOS 7 搭建 K8s”也依然是容器圈最经典的入门实战题之一。这篇文章不堆概念，直接按我实际搭过好几套集群的流程走一遍，从版本选型、系统初始化、containerd 配置，到 kubeadm 部署控制面、工作节点加入、CNI 网络插件安装和常见故障排查，每一步都告诉你为什么要这么做。适合刚开始接触容器编排的开发者，也适合要在内网快速交付一套可用 Kubernetes 集群的运维同学，照着抄基本就能跑通。

1. 先定方案：版本搭配和集群架构不能拍脑袋

很多人一上来就找最新版 Kubernetes，装完才发现各种不兼容，这是新手最容易踩的坑。在 CentOS 7 上搭 K8s，版本选型决定了后面整个过程的顺利程度，真不能随手装个 latest。

1.1 选对 Kubernetes 版本，别让 CentOS 7 硬扛新版

CentOS 7 的底子是 EL7 架构，glibc 停留在 2.17，默认内核 3.10.x，systemd 版本也比较老。Kubernetes 越往后版本对系统的要求越高，尤其到了 v1.28 之后，官方开始逐步收紧对旧系统的兼容范围。我见过有人直接装新版 kubeadm，初始化时一堆组件起不来，日志里全是底层依赖缺失，最后只能重装。

我个人在 CentOS 7 上的版本组合基本锁定在 v1.27.x 这条线。这个系列在 EL7 上经过充分验证，稳定性不错，功能也够用，同时还在维护窗口内。如果你没有特殊的新特性需求，别追新，v1.27 就是 CentOS 7 的舒适区。

还有一个延续了很多年的误区：网上不少老教程还在教你先装 Docker，然后把集群的运行时指给 Docker。但 Kubernetes 从 1.24 版本开始就移除了对 Docker 作为底层运行时的支持，现在统一走 CRI 协议对接 containerd。你要是照着老教程的思路来，新版本下 kubelet 根本起不来。

这里我把推荐的版本组合直接列出来，方便对照参考：

关于内核再啰嗦一句：有些人上来就升级内核到 5.x，想借新内核换性能。但 CentOS 7 上贸然升内核，yum 依赖会出现各种诡异问题，对绝大多数 K8s 场景来说收益也不大，不建议折腾。保持系统自带内核，Clusters 照样跑得很稳。

1.2 三节点还是单节点：按场景决定拓扑

集群拓扑要根据实际用途来定。最常见的测试学习环境是 1 个控制平面节点加 2 个工作节点，共 3 台机器。控制面节点建议至少 2 核 4G，工作节点也是 2 核 4G 起步。这个配置跑一些测试应用和中间件 Demo 完全够用。

如果你只有一台高配机器，想把控制平面和业务 Pod 放在同一个节点上，也不是不行。K8s 默认会给控制面节点打上污点，你只要把污点去掉，业务 Pod 就能调度上去。但我不推荐这么干，因为你体验不到工作节点加入集群的完整流程，后面真遇到节点加不进去的故障，排查经验就是零。两台机器的话，就搭“1 控制面 + 1 工作节点”，至少能验证跨节点组网，比一台机器自嗨有价值得多。

1.3 三个网段提前规划好

集群里要提前划分的网段有三个，别等初始化的时候临时想：

• Pod 网段：建议 10.244.0.0/16，这个网段和 Flannel 默认配置一致，用起来省心。
• Service 网段：一般用 10.96.0.0/12，这是 kubeadm 的默认值。
• 集群 API 地址：就是控制面节点的 IP，比如 192.168.1.10。

这里有个非常重要的提醒：前两个网段是在 kubeadm init 时通过参数一次性传给集群的，部署完再改几乎等于重新搭一套。选网段时一定要避开公司或者实验环境的现有网段，特别不要和物理网络冲突，否则后面访问 Service 会莫名出现各种路由不通的问题。

2. 系统初始化：把环境底子一次打牢

系统层面的准备工作看似机械，但实际上排掉了后面 70% 的隐患。这部分命令在每一台节点上都要执行，不要只配 master，worker 节点漏了后面必然出问题。

2.1 主机名、hosts、时间同步三件套

先把每个节点的主机名设置好，方便集群内部识别：

hostnamectl set-hostname master01

工作节点分别设置 node01、node02。然后在每台机器的 /etc/hosts 里把三个节点的映射写进去：

192.168.1.10 master01 192.168.1.11 node01 192.168.1.12 node02

为什么这一步不能省？kubelet 启动之后会拿着节点名去做证书校验和注册，如果主机名解析不了，服务起不来不说，还容易出现“证书签发给 master01，但实际访问的地址解析不到 master01”这种让人一头雾水的报错。K8s 组件之间默认通过主机名通信而不是裸 IP，统一 hosts 是必须做的前置工作。

时间同步也很关键，K8s 内部大量使用证书和 token 做身份认证，这些机制都依赖时间戳。节点之间时间差太大会导致 TLS 握手失败，表现就是组件之间通信时好时坏。装个 chrony 就搞定：

yum install -y chrony systemctl enable --now chronyd

2.2 加载内核模块和调优 sysctl 参数

Kubernetes 里的容器网络依赖两个关键内核模块：overlay 文件系统模块，以及用于 iptables 网桥过滤的 br_netfilter。CentOS 7 默认不加载 br_netfilter，所以你要主动让它在开机时加载：

cat > /etc/modules-load.d/k8s.conf <<EOF overlay br_netfilter EOF modprobe overlay modprobe br_netfilter

接下来调整内核参数，这部分直接决定 Pod 网络能不能正常跨节点通信：

cat > /etc/sysctl.d/k8s.conf <<EOF net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 EOF sysctl --system

这三个参数每个都有存在的理由。bridge-nf-call-iptables 默认是 0，意味着经过网桥的流量不会被 iptables 规则处理，而 kube-proxy 设置的转发规则恰恰挂在 iptables 链上。结果就是 Pod 之间互相能 ping 通，但访问 Service 的集群 IP 完全没反应。这类问题现象很隐蔽，排查起来特别费时间，所以前置参数一定得配好。

2.3 防火墙、SELinux、swap 一次处理干净

测试环境里，这三个东西直接全部关掉：

systemctl stop firewalld && systemctl disable firewalld setenforce 0 sed -i 's/^SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config swapoff -a sed -i '/ swap / s/^/#/' /etc/fstab

分别说说为什么要动它们。SELinux 保持 enforcing 状态时，容器挂载卷、访问某些文件系统目录会被拒绝，Pod 起不来时日志里报的权限错误非常绕。防火墙会挡掉 Flannel 或 Calico 的通信端口，导致跨节点隧道建不起来。swap 方面，kubelet 默认不接受开启了 swap 的机器，不关的话 kubelet 直接拒绝启动。

提示：生产环境不建议简单粗暴关防火墙，应该按 CNI 插件的端口清单做精细放行。但如果你是在内网做验证或者 POC，关掉是成本最低、见效最快的方式。SELinux 设为 permissive 而不是 disabled，是为了保留日志能力，排查问题时更舒服。

3. 容器运行时：containerd 的安装与关键配置

这一章单独拎出来讲，是因为我接手过的故障排查里，至少一半集群起不来的原因都出在容器运行时配置上。

3.1 为什么是 containerd 而不是 Docker

Kubernetes 的 kubelet 通过 CRI（Container Runtime Interface）协议和容器运行时交互。Docker 本身并没有直接实现 CRI，早期需要 dockershim 这个中间层做转换，而 dockershim 在 1.24 版本已经被移除了。containerd 直接面向 CRI 提供服务，kubelet 通过 gRPC 调用它的接口，链路短、依赖少、出问题更好排查。所以新搭的集群一律选 containerd，别再纠结 Docker 了。

打个比方，Docker 像是一个带全套前台服务的餐厅，而 containerd 更像后厨档口，K8s kubelet 不需要前面的点菜结账服务，只需要后厨出菜，直接对接后厨显然效率更高、故障点更少。

3.2 安装 containerd 并生成配置

在 CentOS 7 上，我习惯通过 docker-ce 的软件源来安装 containerd.io，因为这样依赖处理比较省事：

yum install -y yum-utils yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo yum install -y containerd.io

装完先别急着用，containerd 默认没有配置文件，需要手动生成：

mkdir -p /etc/containerd containerd config default > /etc/containerd/config.toml

生成完之后，配置文件里有一个地方必须改：cgroup 驱动。kubelet 在 CentOS 7 上默认使用 systemd 作为 cgroup 驱动，而 containerd 的默认配置是 cgroupfs。两者不一致时，kubelet 会报 “failed to validate kubelet cgroup” 之类的错误，直接拒绝启动。改法是在 config.toml 里找到 runc 相关的段落，把 SystemdCgroup 设为 true：

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc] [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] SystemdCgroup = true

另外，如果你所在网络环境拉取容器镜像比较慢或者超时，可以在 config.toml 的 registry.mirrors 段配置一个可用的镜像加速地址。具体地址根据你的网络情况填写，配置结构大致是这样：

[plugins."io.containerd.grpc.v1.cri".registry.mirrors] [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"] endpoint = ["https://你的加速地址"]

改完配置后重启并设置开机自启：

systemctl daemon-reload systemctl restart containerd systemctl enable containerd

3.3 用一个命令验证运行时可用

配置完别急着往下走，先验证 containerd 能不能正常拉镜像。用 ctr 命令拉一个 busybox 测一下：

ctr images pull docker.io/library/busybox:latest

能拉下来说明运行时工作正常，网络也通。这一步能在集群初始化之前就提前暴露镜像拉取类的问题，省得后面 kubeadm init 卡在拉镜像阶段干瞪眼。

4. kubeadm 部署：控制面和节点加入全流程

系统底子打好之后，接下来就是正式的集群搭建环节。kubeadm 是官方推荐的集群创建工具，能帮你完成控制面组件部署、证书签发、kubeconfig 生成等一系列繁琐工作，是 CentOS 7 上最稳妥的部署方式。

4.1 三个核心组件固定版本安装

控制面和所有工作节点都要安装 kubeadm、kubelet、kubectl 这三个组件。先配置 Kubernetes 的 yum 源，这里用一个通用形式，baseurl 替换成你实际网络环境能访问的镜像源地址：

cat > /etc/yum.repos.d/kubernetes.repo <<EOF [kubernetes] name=Kubernetes baseurl=https://你的镜像源地址/kubernetes/yum/repos/kubernetes-el7-x86_64/ enabled=1 gpgcheck=0 EOF

然后锁定版本安装：

yum install -y kubeadm-1.27.5 kubelet-1.27.5 kubectl-1.27.5

为什么要把版本写死？因为 kubeadm init 的时候，kubeadm 会检查 kubelet 的版本是否匹配，版本不一致会直接拒绝执行。如果你用默认的 yum install -y kubeadm 安装，装的是当前仓库里的最新版，而 kubelet 可能因为依赖关系装了另一个版本，这种版本错位最折磨人。从源头上锁定版本，一次到位。

4.2 初始化控制平面节点

正式初始化之前，建议先看一下需要拉取哪些镜像：

kubeadm config images list --kubernetes-version=v1.27.5

这条命令会列出初始化时需要的全部镜像清单。如果你担心默认镜像仓库在你的网络环境下不可达，可以在 init 的时候通过 --image-repository 参数指定一个你自己能访问的镜像仓库地址。这是官方支持的参数，用法是在地址后面跟上 google_containers 路径。

然后执行初始化命令：

kubeadm init \ --kubernetes-version=v1.27.5 \ --apiserver-advertise-address=192.168.1.10 \ --pod-network-cidr=10.244.0.0/16 \ --service-cidr=10.96.0.0/12 \ --image-repository=你的镜像仓库地址/google_containers

解释一下几个参数的用意。--apiserver-advertise-address 填控制面节点的 IP，也就是工作节点要连接的 API 地址。--pod-network-cidr 和 --service-cidr 就是我们第 1 章规划好的网段。这里有个前后关联的伏笔：后面的 CNI 插件默认网段必须和 --pod-network-cidr 保持一致，否则集群网络会出错。所以用 10.244.0.0/16 的话，Flannel 默认就能直接对接，而 Calico 需要你手动改配置，这部分第 5 章详聊。

初始化成功以后，屏幕输出里有两段关键信息要重点关注。第一段是配置 kubectl 的命令：

mkdir -p $HOME/.kube cp -i /etc/kubernetes/admin.conf $HOME/.kube/config chown $(id -u):$(id -g) $HOME/.kube/config

第二段是工作节点加入集群的 join 命令，格式类似这样：

kubeadm join 192.168.1.10:6443 --token xxxx --discovery-token-ca-cert-hash sha256:xxxx

这条命令一定要保存好，token 默认有效期为 24 小时，过期了就得重新生成。就算没过期，也建议先存到一个文本文件里，后面两台 worker 节点都要用它。

4.3 工作节点加入集群

工作节点需要先完成第 2 章和第 3 章的所有系统初始化步骤，然后安装同样的 kubeadm、kubelet、kubectl。装好后直接执行 join 命令：

kubeadm join 192.168.1.10:6443 --token xxxx --discovery-token-ca-cert-hash sha256:xxxx

加入后回到控制面节点查看节点状态：

kubectl get nodes

这时候你会看到几个节点都处于 NotReady 状态，这个现象是正常的。原因很统一：集群里还没有网络插件，节点之间的 Pod 网络还没有打通。这正好是下一步要处理的事情。

5. 网络插件：从 NotReady 到 Ready 的关键一跃

如果你以为节点状态 NotReady 是哪里配错了，先别慌，绝大多数情况下只是因为 CNI 插件还没部署。这一步不做，节点永远都不会 Ready。

5.1 为什么要装 CNI 插件

Kubernetes 本身不负责 Pod 网络的具体实现，它只定义了一套规范，叫 CNI（Container Network Interface）。真正给 Pod 分配 IP、打通跨节点通信、实现网络策略的，是 Calico、Flannel、Weave 这些网络插件。没有它们，Pod 只能在自己的网络命名空间里孤立存在，和外界完全断连。

5.2 追求简单：Flannel 一行搞定

如果你的需求只是让 Pod 之间能互相通信，Flannel 是最快、最省心的选择。它的默认 Pod 网段正好是 10.244.0.0/16，和第 4 章 kubeadm init 的参数天然匹配：

kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

Flannel 用 VXLAN 隧道在节点之间转发数据包，对内核版本要求低，CentOS 7 上跑得很稳定。缺点是对 NetworkPolicy 的支持很弱，如果你后续要做精细的网络安全隔离，Flannel 会力不从心。

5.3 功能更强：Calico 部署和它的配置坑

Calico 功能比 Flannel 强不少，支持 NetworkPolicy，性能也更好，但部署时有一个非常经典的坑。Calico 默认的 Pod 网段写的是 192.168.0.0/16，而我们在 kubeadm init 时指定的是 10.244.0.0/16。两者不一致时，Calico 会按自己的网段来分配 IP，和你初始化时的配置冲突，表现为节点状态反复横跳。

解决办法是先把为了离线部署而下载到本地的 custom-resources.yaml 打开，找到 calicoNetwork 下面的 ipPools 配置，把 cidr 改成你自己的 Pod 网段，然后再 apply：

kubectl create -f tigera-operator.yaml kubectl create -f custom-resources.yaml

custom-resources.yaml 里的关键配置长这样：

spec: calicoNetwork: ipPools: - name: default-ipv4-ippool cidr: 10.244.0.0/16

这个 cidr 字段必须和 kubeadm init 的 --pod-network-cidr 一致，是这类 CNI 部署最容易出错的点。

5.4 怎么判断网络插件部署成功了

部署完观察系统命名空间里的 Pod 状态：

kubectl get pods -n kube-system

等所有 Pod 都变成 Running，特别是每个节点上都有一个的 DaemonSet Pod（比如 calico-node 或 flannel）都正常之后，再查看节点状态：

kubectl get nodes

如果节点从 NotReady 变为 Ready，说明集群网络已经通了。如果等了五分钟还在 NotReady，就去翻第 7 章的排查思路。

6. 集群验证和后续配套

集群搭建完成不等于验收通过，至少要跑通一两个业务验证一下，确认整个链路是完整的。

6.1 跑一个 Nginx 验证完整业务链路

先在控制面节点上创建测试应用：

kubectl create deployment nginx-test --image=nginx kubectl expose deployment nginx-test --port=80 --type=NodePort

然后查看 Pod 和 Service 的状态：

kubectl get pods -o wide kubectl get svc

等 Pod 变成 Running，Service 里会出现一个 NodePort 端口。随便挑一个集群节点的 IP，加上这个端口访问，比如curl http://192.168.1.11:32080，能返回 Nginx 的页面，说明镜像拉取、Pod 调度、Service 转发、网络插件这几个环节全部正常。

6.2 跨节点容器通信测试

这一步很关键，别只在同一个节点上自测。让两个 Pod 分别调度到不同的节点，然后让其中一个去访问另一个的 Pod IP。这个操作能直接验证 CNI 插件是否真正完成了跨节点转发。如果通了，说明 VXLAN 隧道或者 BGP 模式工作正常，集群的网络才算真正落地。

6.3 管理面板装不装看需求

如果你不习惯纯命令行操作，可以装一个 Dashboard 作为可视化辅助：

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml

装 Dashboard 要注意 manifest 版本和你的集群版本兼容。登录时需要通过 ServiceAccount 获取 token，并绑定相应的 RBAC 权限。不过我个人建议，刚上手阶段尽量多用 kubectl，把命令行操作练熟，Dashboard 当辅助工具就好。

7. 常见问题与排查速查

最后把我在实际操作中遇到的高频问题和排查思路整理成清单，按图索骥能省很多时间。

7.1 swap 和 cgroup 导致的 kubelet 启动失败

典型的报错出现在journalctl -u kubelet里，内容要么提到 swap，要么提到 cgroup 驱动不一致。前者说明节点还有 swap 处于激活状态，后者说明 containerd 的 SystemdCgroup 没设成 true。

处理顺序固定：先执行 swapoff -a 并注释 fstab 里的 swap 行，再检查 containerd 的 config.toml 配置，最后重启 containerd 和 kubelet：

systemctl restart containerd systemctl restart kubelet

7.2 初始化时报 kubelet 版本不一致

初始化时如果提示 kubelet 版本和 kubeadm 版本不匹配，别慌，这是版本锁定的问题。先分别查看两个版本号：

kubeadm version kubelet --version

然后把低版本的一方升级或降级到与另一方完全相同的版本。最稳妥的办法是重新执行一次带版本号的 yum install，确保两者一致再继续。

7.3 Pod 一直 ImagePullBackOff

先用kubectl describe pod <pod名>看一下详细事件，多半是镜像拉取失败。排查思路是先确认镜像 tag 是否存在，不管你是用 ctr 手动拉还是通过 containerd 的加速配置拉，最终 Pod 使用的镜像名和 tag 必须和你拉下来的完全一致。

7.4 节点 NotReady 的三种常见原因

节点长时间 NotReady，重点检查三个方向：

• CNI 插件没部署或者没起来，看 kube-system 命名空间里对应 Pod 的状态。
• CNI manifest 里的网段和 kubeadm init 指定的 pod-network-cidr 不一致，这是 Calico 部署时最常见的坑。
• kube-proxy 的 Pod 起不来，大概率也是镜像拉取失败。

排查时把三处日志一起看：

journalctl -u kubelet -f kubectl describe pod -n kube-system <网络插件pod> kubectl logs -n kube-system <网络插件pod>

顺着日志找线索，比瞎猜高效得多。

7.5 token 过期怎么处理

kubeadm init 生成的 token 默认 24 小时过期。如果过期后在 worker 节点执行 join 命令报错，回到控制面节点重新生成一份：

kubeadm token create --print-join-command

这条命令会直接打印出新的 join 命令，复制到 worker 节点执行即可。

7.6 证书过期怎么续期

测试环境搭完之后放个大半年再回来用，kubectl 会提示证书过期。处理方法：

kubeadm certs renew all

然后重启 kubelet 和相关组件。注意证书续期只是治标，长期运行的集群最好用定时任务定期续期，或者调长证书有效期。

提示：我一般会把整套环境初始化过程写成一个 Shell 脚本，把第 2 章到第 4 章的所有命令固化进去，并固定好版本号。新机器只要跑一遍脚本，基础环境就位，后面直接 kubeadm init 或 join。这套流程我留了好几年，每次只是调整版本号数字，操作骨架一直没变。

我个人在反复部署多套集群后的体会是：CentOS 7 搭 K8s 本身不复杂，难的是每一步背后的“为什么”没搞清楚。比如不装 CNI 就急着跑业务 Pod，Pod 会一直 ContainerCreating；不配 hosts，kubelet 证书报错能让你排查一整天；版本号不锁定，一个版本错位就能卡住整个流程。最后再分享一个小技巧：分阶段验证，别一口气把所有命令跑完再看结果。每完成一个阶段的配置，就先确认这一步的结果没问题，逐层推进。基础设施类部署，分步验证、及时止损，才是最省时间的做法。