答案：在CentOS上部署Kubernetes集群的关键前置准备包括禁用SELinux、关闭防火墙、禁用Swap、配置内核参数及设置hosts解析。这些步骤确保系统安全策略、网络通信和资源管理符合Kubernetes运行要求，是集群稳定部署的基础。

要在CentOS上配置容器编排，尤其是部署Kubernetes集群，核心在于系统环境的精心准备、容器运行时的选择与安装，以及Kubernetes组件的正确部署与初始化。这不仅仅是执行一系列命令，更需要理解每个步骤背后的逻辑，确保集群能够稳定、高效地运行。

解决方案

在CentOS系统上部署Kubernetes集群，通常遵循以下步骤，这其中包含了许多细节，需要耐心和细致：

1. 系统初始化与优化：

   • 更新系统：

     sudo yum update -y
   • 禁用SELinux： 编辑

     /etc/selinux/config

     文件，将

     SELINUX=enforcing

     改为

     SELINUX=disabled

     ，然后重启系统或运行

     sudo setenforce 0

     。SELinux有时会无故阻碍Kubernetes组件间的通信。

   • 禁用防火墙：

     sudo systemctl stop firewalld && sudo systemctl disable firewalld

     。为了集群内部通信的顺畅，通常会禁用防火墙，或者精确配置规则，但初期禁用更省心。

   • 禁用Swap分区：

     sudo swapoff -a

     并注释掉

     /etc/fstab

     中所有

     swap

     行。Kubernetes的

     kubelet

     组件在检测到Swap开启时会拒绝启动。

   • 配置内核参数： 允许

     br_netfilter

     模块，使Linux桥接流量能够被

     iptables

     处理，这是Kubernetes网络模型所必需的。

     sudo modprobe br_netfilter echo '1' | sudo tee /proc/sys/net/bridge/bridge-nf-call-iptables echo '1' | sudo tee /proc/sys/net/bridge/bridge-nf-call-ip6tables echo 'net.bridge.bridge-nf-call-iptables = 1' | sudo tee -a /etc/sysctl.d/k8s.conf echo 'net.bridge.bridge-nf-call-ip6tables = 1' | sudo tee -a /etc/sysctl.d/k8s.conf sudo sysctl --system
   • 配置

     /etc/hosts

     ： 添加所有节点的主机名和IP地址映射，确保节点间可以通过主机名互相解析。

2. 安装容器运行时（Containerd）：

   • 安装必要工具：

     sudo yum install -y yum-utils device-mapper-persistent-data lvm2
   • 添加Docker官方repo（Containerd通常随Docker安装包提供）：

     sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
   • 安装Containerd：

     sudo yum install -y containerd.io
   • 配置Containerd： 生成默认配置文件并修改

     SystemdCgroup

     为

     true

     。

     sudo mkdir -p /etc/containerd sudo containerd config default | sudo tee /etc/containerd/config.toml # 修改 config.toml 文件，找到 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] # 将 SystemdCgroup = false 改为 SystemdCgroup = true # 可以用 sed 命令简化： sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/g' /etc/containerd/config.toml
   • 启动Containerd：

     sudo systemctl enable --now containerd

3. 安装Kubernetes组件（kubeadm, kubelet, kubectl）：

   • 添加Kubernetes YUM仓库：

     cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/ enabled=1 gpgcheck=0 repo_gpgcheck=0 gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg EOF

     （这里使用了阿里云镜像，国内访问更快）

   • 安装组件：

     sudo yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
   • 启动Kubelet：

     sudo systemctl enable --now kubelet

     (Kubelet会持续尝试启动，直到集群初始化完成)

4. 初始化Kubernetes主节点（仅在主节点执行）：

   • 拉取镜像：

     sudo kubeadm config images pull

     (如果网络不佳，可能需要配置镜像加速器或使用国内镜像源)

   • 初始化集群：

     sudo kubeadm init    --apiserver-advertise-address=<Master节点IP地址>    --pod-network-cidr=<Pod网络的CIDR，例如10.244.0.0/16，取决于你选择的CNI插件>    --kubernetes-version v1.28.0 # 根据实际情况调整版本

     初始化成功后，会输出

     kubeadm join

     命令，以及配置

     kubectl

     的方法。

   • 配置kubectl：

     mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config
   • 安装网络插件（CNI）： 例如Flannel。

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

     （注意：根据你

     kubeadm init

     时指定的

     --pod-network-cidr

     选择合适的CNI插件及其配置）

5. 加入工作节点（在所有工作节点执行）：

   • 在主节点初始化成功后，会得到一个

     kubeadm join

     命令，将其复制到工作节点上执行。

   • 如果Token过期或丢失，可以在主节点上生成新的：

     sudo kubeadm token create --print-join-command

在CentOS上部署Kubernetes集群，有哪些关键的系统前置准备工作？

部署Kubernetes集群，系统前置准备工作是基石，它直接决定了集群的稳定性和性能。我的经验告诉我，很多初学者在这一步上踩坑，往往导致后续部署失败或集群运行异常。

首先，禁用SELinux是几乎成了惯例。SELinux的安全机制非常严格，它可能阻止Kubernetes组件，尤其是

kubelet

和容器运行时之间进行必要的通信，导致各种奇怪的权限错误。虽然理论上可以通过精确配置SELinux策略来允许这些操作，但在实际操作中，为了快速部署和减少不必要的复杂性，暂时禁用它是一个普遍且有效的选择。当然，生产环境中应该考虑更安全的替代方案或定制策略。

其次，禁用防火墙（或至少配置精确的规则）也是不可或缺的。Kubernetes集群内部有大量的网络通信，包括Pod到Pod、Pod到Service、API Server到各个组件等等。如果防火墙规则过于严格，这些通信就会被阻断，导致集群无法正常工作。例如，

kube-proxy

需要访问API Server，

kubelet

需要与

containerd

通信，并且需要通过端口暴露Pod服务。全面禁用防火墙虽然简单粗暴，但能有效避免初期因网络策略不当引发的问题。

再者，禁用Swap分区是Kubernetes官方明确要求的。

kubelet

在检测到系统开启了Swap时会拒绝启动，或者即使启动了也可能导致Pod性能下降或不稳定。Kubernetes倾向于将节点视为可支配的计算资源，它希望对内存资源有完全的控制权，Swap的存在会干扰其调度和资源管理。所以，无论是通过

swapoff -a

临时关闭，还是修改

/etc/fstab

永久禁用，都是必须执行的步骤。

Designer

Microsoft推出的图形设计应用程序

63

查看详情

最后，配置内核参数，特别是启用

br_netfilter

模块并设置

net.bridge.bridge-nf-call-iptables

为1，这对于Kubernetes的网络模型至关重要。Kubernetes使用CNI（Container Network Interface）插件来管理Pod网络，这些插件通常依赖于Linux桥接和

iptables

来实现Pod间的通信和Service负载均衡。没有这些内核参数，Pod之间的网络隔离和通信可能会出现问题，Service的虚拟IP也无法正常工作。我曾经就遇到过Pod无法跨节点通信的问题，排查下来就是这个内核参数没有正确设置。

这些前置准备工作，看似琐碎，实则环环相扣，是确保Kubernetes集群健康运行的基石。

CentOS部署Kubernetes时，选择Docker还是Containerd作为容器运行时更合适？

这是一个很有意思的问题，尤其是在Kubernetes社区经历了从Docker到Containerd的“运行时之争”之后。从我的实践经验和社区趋势来看，Containerd无疑是目前更推荐的选择。

早期，Docker是容器技术的代名词，Kubernetes也理所当然地将其作为默认的容器运行时。但随着Kubernetes生态的成熟，Docker作为一个包含大量上层工具（如

docker build

、

docker compose

等）的完整平台，其内部的

containerd

部分才是Kubernetes真正需要的。Docker的架构是“Docker Client -> Docker Daemon -> containerd -> runc”，而Kubernetes通过CRI（Container Runtime Interface）直接与

containerd

通信，绕过了Docker Daemon的很多非核心功能。

选择Containerd的理由很直接：

1. 轻量与高效： Containerd是专门为Kubernetes设计的CRI运行时，它更轻量、更专注于容器生命周期管理的核心功能。这意味着更少的资源占用和更快的操作响应速度。
2. 稳定性与兼容性： Kubernetes社区已经将Containerd作为首选和默认的CRI运行时，这意味着它得到了更好的测试和维护，与Kubernetes的兼容性也更强。
3. 减少抽象层： 直接使用Containerd减少了中间的抽象层，降低了潜在的故障点。当出现问题时，排查起来也相对更容易，因为你不需要去考虑Docker Daemon本身的复杂性。
4. 未来趋势： 随着Kubernetes的发展，直接与CRI兼容的运行时（如Containerd、CRI-O）将是主流，它们提供了更贴合Kubernetes需求的接口和更优化的性能。

当然，这并不是说Docker不好。Docker仍然是开发和本地测试的优秀工具。但对于生产级别的Kubernetes集群，追求极致的稳定、高效和与Kubernetes的深度集成，Containerd是更明智的选择。在CentOS上安装Containerd，通常也比安装完整的Docker-CE更直接，只需要安装

containerd.io

包并进行简单的配置即可。在配置时，务必注意将Containerd的cgroup驱动设置为

systemd

，与

kubelet

保持一致，这是避免集群启动失败的一个常见陷阱。

使用kubeadm在CentOS上初始化Kubernetes主节点时，常会遇到哪些问题及如何排查？

使用

kubeadm init

命令来初始化Kubernetes主节点，是部署过程中最关键的一步，也常常是问题的高发区。我见过不少人卡在这里，反复尝试，最终发现是某个前置条件没满足。

一个最常见的问题是镜像拉取失败。

kubeadm init

会尝试从

k8s.gcr.io

（或

registry.k8s.io

）拉取核心组件镜像，如

kube-apiserver

、

kube-controller-manager

等。在中国大陆，由于网络限制，直接拉取这些镜像往往会超时或失败。这时候，你需要配置一个国内的镜像加速器，或者在

kubeadm init

命令中指定

--image-repository

参数，指向一个国内可访问的镜像源，例如阿里云的

registry.aliyuncs.com/google_containers

。排查时，可以先手动尝试

sudo crictl pull <image_name>

（如果安装了crictl）或查看

kubeadm config images pull

的输出。

其次，网络配置问题也频繁出现。这包括

--pod-network-cidr

参数与实际CNI插件不匹配，或者主机防火墙、SELinux未正确禁用。如果

kubeadm init

完成后，

kubectl get nodes

显示节点状态为

NotReady

，或者

kubectl get pods -A

发现核心组件（如

coredns

）一直处于

Pending

或

CrashLoopBackOff

状态，这很可能就是网络问题。排查时，首先检查

kubelet

的日志：

sudo journalctl -u kubelet -f

，看是否有关于网络插件或API Server连接的错误。同时，确保

--pod-network-cidr

与你后续安装的CNI插件（如Flannel的默认CIDR是

10.244.0.0/16

）一致。

Cgroup驱动不匹配是另一个隐蔽的问题。

kubelet

和容器运行时（Containerd）需要使用相同的cgroup驱动（

systemd

或

cgroupfs

）。如果Containerd的配置文件中

SystemdCgroup

设置为

false

，而

kubelet

默认使用

systemd

，就会导致

kubelet

无法正常启动。排查时，查看

kubelet

日志会发现类似“failed to find cgroupfs mount point”或“cgroup driver mismatch”的错误。解决办法是修改Containerd的

config.toml

文件，将

SystemdCgroup = true

，然后重启Containerd和kubelet。

最后，资源不足也是常见问题。如果你的CentOS虚拟机内存太小（例如低于2GB），

kubeadm init

可能会因为资源限制而失败。虽然

kubeadm

会给出警告，但有时会被忽略。确保每个节点至少有2GB内存和2个CPU核心，是运行Kubernetes的基本要求。

排查这些问题时，始终牢记

sudo journalctl -u kubelet -f

是你的好帮手，它能实时输出

kubelet

的运行日志，是定位问题的关键线索。如果问题复杂，

kubeadm reset

后重新尝试，并仔细检查每一步的前置条件，往往能解决大部分问题。