CentOS容器编排如何配置_CentOS部署Kubernetes集群-小浪学习网

答案：在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服务。全面禁用防火墙虽然简单粗暴，但能有效避免初期因网络策略不当引发的问题。

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

kubelet

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

swapoff -a

临时关闭，还是修改

/etc/fstab

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

Logomaster.ai

Logo在线生成工具

查看详情

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

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更直接，只需要安装

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

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

大家都在看：

linux怎么查看是不是centos版本 centos是linux还是unix centos是什么公司的linux centos和linux是什么关系 centos是linux系统吗

文章版权归作者所有，未经允许请勿转载。

THE END

互联网运维
# 工具 # linux # 接口 # git # centos # 架构 # docker # github # 负载均衡 # go # Token # print # app # Interface # kubernetes # node # 防火墙 # 虚拟机 # 端口 # kubelet # 阿里云