CentOS容器编排如何配置_CentOS部署Kubernetes集群

爱谁谁

发布时间：2025-09-16 11:56:01

550人浏览过

来源于php中文网

原创

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

centos容器编排如何配置_centos部署kubernetes集群

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

解决方案

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

系统初始化与优化：
- 更新系统：
```
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地址映射，确保节点间可以通过主机名互相解析。

安装容器运行时（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
```

安装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会持续尝试启动，直到集群初始化完成)

初始化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插件及其配置）

加入工作节点（在所有工作节点执行）：
- 在主节点初始化成功后，会得到一个
```
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服务。全面禁用防火墙虽然简单粗暴，但能有效避免初期因网络策略不当引发的问题。

拍我AI

AI视频生成平台PixVerse的国内版本

下载

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

kubelet

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

swapoff -a

临时关闭，还是修改

/etc/fstab

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

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

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的理由很直接：

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

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