Kubernetes 基础架构与环境准备Containerd、Kubeadm、Kubelet、Kubectl 初探

现在运维都说——要上 Kubernetes，才能跟上时代脚步。”听上去很厉害，可真要动手时却傻眼了：网上各种教程，看不懂到底安装哪些组件？一头雾水：“Docker 都还没学精，哪里还会 Kubernetes 的那些kube-apiserver、kube-scheduler、kube-controller-manager……还听说新版不推荐 Docker，还要装 Containerd。我怕半路命令报错，又怕只学一堆概念不会用，还容易搭坏集群。

如果你跟我一样，从 Docker 切换到 Kubernetes，总觉得组件太多、名词太乱，连“在哪里执行命令”“哪个组件干什么”都搞不清楚，那本文正适合你：我们从“最基础的环境准备”开始，一步一步讲清楚每个组件的作用、相互关系，以及如何在 AlmaLinux 三台服务器（master、node1、node2）上用 Containerd 拉镜像、安装 kubeadm/kubelet/kubectl，验证命令是否可用，如果报错“未找到命令”怎么办，都用最白话的例子来说明。拿起手机，慢慢跟着做，保证你能在国内互联网环境下，一点点把 Kubernetes 的基础打牢，然后再慢慢学习下一章单独拆解每个组件，逐一贯通。

一、Kubernetes 架构初识：组件之间是怎样“互相信任、互相协作”的？

先用大白话让你对 Kubernetes 的主要组件有个整体印象，不用背一堆名词，先理解“它们之间为什么要存在”以及“彼此之间如何沟通”。

1.1 为什么要用 Kubernetes？

从 Docker 容器运维的角度来说，当你只有几个容器时，直接在宿主机（或几台机器）docker run就 OK。但真到了生产环境，你往往会有几十、上百个服务容器要管理，还要保证容器能自动重启、自动调度、跨机负载均衡、安全隔离、健康检查、自动扩容缩容（Scale Up/Down）、升级回滚……光是 docker run --restart=always远远不够，还要自己写一堆bash脚本或者用第三方工具。

Kubernetes 出现后，它把容器编排（Container Orchestration）的思路“固定住”了：

1. 调度：把你要运行的容器自动分配到集群里合适的机器上；
2. 编排：定义容器该怎么运行、用多少 CPU/内存、副本数量、网络如何暴露等；
3. 高可用：当某台机器或进程挂掉时，它会自动在别的节点上重启容器；
4. 监控与自愈：定期探活（Health Check），若 Pod 不健康，就重启或替换；
5. 负载均衡：自动分发流量到健康的容器；
6. 存储持久化：把容器生成的数据映射到外部存储卷；
7. 日志与监控：集中管理所有容器的日志，跟 Prometheus/Grafana 集成（后续章节会讲）。一句话：Kubernetes 把成百上千个容器的生命周期管理、网络、存储、扩缩容、监控、重启等都“管一管”，你只需要在 YAML 文件里写几个关键的配置，就能实现非常多自动化运维功能。

1.2 核心组件与大白话比喻

Kubernetes 有很多组件，我们先列出最核心的几类，并用简单比喻把它们串联起来。假设你开了家 “容器托管厂”，每一台服务器就是一个 “机房”，里面可以放很多 “机架”（Node）。你要把“容器”放到这些机架里才可以运行。

1. Kube-apiserver（API 服务器）
   • 比喻：“厂长办公室”，所有操作都要到办公室去登记审批。
   • 作用：Kubernetes 的“大脑”就是它，所有的命令、所有的配置请求都要先打给它。比如当你执行 kubectl create deployment nginx时，最终会向 kube-apiserver 发起一个 HTTP 请求，告诉它“我要部署 nginx 这个容器”。
2. Etcd（分布式键值存储）
   • 比喻：“厂长的藏宝箱”，用于存放所有重要的配置信息和集群状态。
   • 作用：存储集群所有的“状态数据”——比如有哪些 Pod 正在运行、每个 Node 还能用多少资源、谁是谁的上下游，等等。所有组件都通过读写 etcd 获取或更新配置和状态信息。
3. Kube-scheduler（调度器）
   • 比喻：“派工员”，责任是负责把“容器”分配到哪个“机架”（Node）上。
   • 作用：当你创建一个 Pod（最小的部署单元）后，Pod 会先处于“待调度”状态，调度器会考量 Pod 要求的 CPU、内存、亲和/反亲和规则，然后挑选一台有空闲资源的 Node，把它派上去运行。
4. Kube-controller-manager（控制管理器）
   • 比喻：“巡检队”，时刻在查看批次计划（Deployment、ReplicaSet、DaemonSet）是否按着脚本在运行，比如某些机架挂了，巡检队就会通知系统重启；或某个容器掉了，它会自动创建一个新容器替补。
   • 作用：里面有多个控制循环（Controller），例如 Deployment Controller、ReplicaSet Controller、Node Controller、Endpoint Controller、Service Account Controller 等，负责维护期望状态与实际状态匹配。
5. Kubelet（节点代理）
   • 比喻：“机架管理员”，安装在每台机器（Node）上，直接把容器拉下来（通过 Containerd），然后看管容器的健康。
   • 作用：它会向 kube-apiserver 注册当前 Node 信息，定期汇报 Node 的资源使用情况，并接收 kube-apiserver 下发的 Pod 启停任务，把 Pod 的容器通过 Containerd（或其他 CRI）拉下来并启动。
6. Containerd（容器运行时）
   • 比喻：“仓库+机械师”，负责实际拉取镜像、解压、创建 Namespace、挂载卷、启动容器。
   • 作用：Containerd 是一个轻量级的容器运行环境，用来替代 Docker 作为 Kubernetes 推荐的 CRI（Container Runtime Interface）。它会从仓库拉取镜像（如果节点上已有缓存就直接用本地版本），再启动这个镜像对应的容器。
   • 我们在本文里要演示的就是用 Containerd 而非 Docker 来处理 Kubernetes 所需的镜像拉取和容器运行。
7. Kubectl（命令行工具）
   • 比喻：“厂长的对讲机”，通过它你才能和 kube-apiserver 对话，下达各种命令。
   • 作用：提供命令行界面，你输入 kubectl get nodes、kubectl apply -f nginx-deployment.yaml，它就会向 kube-apiserver 发送请求，获取集群状态或提交新配置。
8. Kube-proxy（网络代理）
   • 比喻：“流量指挥”，把外部或者 Node 内的网络流量拦到对应的容器上，让各个容器之间能互相访问，以及外部流量能访问到服务。
   • 作用：在每个 Node 上运行，用 iptables 或 IPVS 来配置路由规则，把访问 Service 的流量转发到后端对应的 Pod 上，完成负载均衡。

总结：

• Kubectl：你给“厂长”打电话（发请求）；
• Kube-apiserver：厂长办公室收到电话，各种操作都通过它来发号施令、协调工作；
• Etcd：厂长的记事簿，记载着集群里现在有多少机架（Node）、每个机架剩余多少资源、哪台机架上运行了哪些容器（Pod）、Service 指向了哪些 Pod 等信息；
• Kube-scheduler：厂长秘书，专门负责“容器该放在哪台机架”的问题；
• Kube-controller-manager：厂长的巡视班子，发现机架有问题，赶紧跑去处理；
• Kubelet：每台机架上的管理员，跟厂长办公室保持心跳（汇报本机资源），接到任务就要去 Containerd 把镜像拉下来，然后启动容器；还要定期汇报所管理的容器健康状况（健康探测）；
• Containerd：就像一台工厂里专门负责把“原材料”（镜像）下载、解压、组装成“产品”（容器）的机械手；
• Kube-proxy：机房的“网络管理员”，负责在机架上设置流量转发规则，让请求能准确到达对应容器。

二、环境准备：AlmaLinux 三节点初识 Kubernetes

在真正踏上 Kubernetes 路之前，先把你的三台 AlmaLinux（master、node1、node2）服务器准备好。我们将按如下步骤操作：

1. 确认系统版本与基础工具
2. 设置主机名和 hosts 文件
3. 关闭或调优防火墙与 SELinux
4. 安装 Containerd（容器运行时）
5. 安装 Kubeadm、Kubelet、Kubectl（Kubernetes 组件）
6. 验证各个组件是否可用/运行正常

下面我们来逐条走完，确保你能在国内网络环境下顺利拉取镜像、安装各组件，并在遇到“命令不存在”时知道如何解决。

确认系统版本与基础工具

登录并确认操作系统

执行场景：在三台服务器（master/node1/node2）Shell 终端

# 登录到 master
ssh root@master.example.com

# 登录成功后，查看系统信息
cat /etc/almalinux-release

# 期望输出：AlmaLinux release 8.x (可能是 8.5、8.7 等)

• 如果输出提示找不到文件，说明你不是用 AlmaLinux，可能是 CentOS、Rocky 等，但我们假设你的环境是 AlmaLinux 8.x。

关闭或调优防火墙与 SELinux

Kubernetes 各组件之间会频繁通信，如果防火墙或 SELinux 策略过于严格，会导致各组件无法互相访问。为了演示的简便，这里我们先关闭防火墙和 SELinux，做好环境准备。生产环境可参考官方文档做更细粒度的放行策略。

关闭防火墙

执行场景：在各服务器 Shell 终端

# 停止 firewalld 服务
sudo systemctl stop firewalld

# 禁用开机启动
sudo systemctl disable firewalld

# 确认状态
sudo systemctl status firewalld
# 看到 Active: inactive (dead)，说明已关闭

关闭 SELinux

执行场景：在各服务器 Shell 终端

# 临时关闭
sudo setenforce 

# 永久关闭，编辑 /etc/selinux/config
sudovim /etc/selinux/config
# 将 SELINUX=enforcing 改为 SELINUX=disabled
# 保存并退出

# 重启服务器后生效
sudoreboot

重启后，再次运行 getenforce，应输出 Disabled。

命令不存在排查：

• 如果执行 systemctl stop firewalld时提示 bash: systemctl: 未找到命令，可能是当前用户无 sudo 权限，或者操作系统没有安装 systemd。一般 AlmaLinux 系统默认都有 systemd。
• 如果 setenforce未找到，说明 SELinux 工具未安装或系统环境异常。可以先安装： sudo yum install-y policycoreutils 然后再执行 setenforce 0。

安装 Containerd：Kubernetes 推荐的容器运行时

在 Kubernetes 1.20 之后，官方不再把 Docker Engine 作为首选运行时，推荐使用 Containerd 或 CRI-O。Containerd 集成在 Docker 里，但我们直接安装 Containerd 来作为 CRI（Container Runtime Interface）。下面步骤会详细演示如何在 AlmaLinux 8 上安装和配置 Containerd。

安装 Containerd

执行场景：在各节点（master/node1/node2）Shell 终端

安装依赖

sudo yum install-y yum-utils device-mapper-persistent-data lvm2

1. 添加 Docker 官方仓库（Containerd 包含在内） sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
   • 虽然我们不安装 Docker，但这个仓库里包含了 containerd 的 RPM。
2. 安装 containerd.io sudo yum install-y containerd.io
   • containerd.io包含了 containerd 及其 CLI。
   • 如果提示 N/S（no package available），先运行 sudo yum makecache更新本地缓存，或手动从 GitHub Release 下载 RPM。
3. 启动并设置开机自启 sudo systemctl start containerd sudo systemctl enable containerd
4. 验证 containerd 服务 sudo systemctl status containerd # 期望看到 # Active: active (running)

命令不存在排查：

• 如果 yum-config-manager未找到，可先安装 yum-utils（已在上面第1步示例中体现）。
• 如果 containerd.io包未找到，确认你添加了 Docker CE 官方仓库，或在国内环境下，可以通过阿里云或中科大镜像站点加速： # 编辑 /etc/yum.repos.d/docker-ce.repo，把所有 mirrorlist 或 baseurl 替换为阿里云镜像对应的 URL
• 如果 systemctl start containerd报错，可以查看日志： journalctl -u containerd -n --no-pager 根据提示解决，比如缺少依赖、权限问题、SELinux 未关闭等。

配置 Containerd（可选：使用镜像加速、中英分区路径等）

默认安装后，containerd 在 /etc/containerd/config.toml没有生成，需要手动containerd config default > /etc/containerd/config.toml并调整以下几点：

1. 在国内环境下配置镜像加速（推荐使用阿里云镜像加速器） 编辑 /etc/containerd/config.toml，在 [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]段下添加加速地址： [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"] endpoint=["https://registry.docker-cn.com","https://mirror.ccs.tencentyun.com"]
   • 这样当 Kubernetes 通过 containerd 拉取镜像时，就会优先用这些加速器，提高速度。
2. 设置日志路径或者 CNI 插件默认目录一般不用动，默认配置即可。
3. 重启 containerd 使配置生效 sudo systemctl restart containerd
4. 验证 containerd 配置是否生效 containerd --version crictl info 然后再 crictl info，如果能看到 containerd 的配置信息，说明 CRI 配置正常。

图片

• crictl是一个命令行工具，用来验证 CRI 兼容性。若报错没有安装 crictl，可以执行： VERSION="1.25.0" sudocurl-L-o /usr/local/bin/crictl "https://github.com/kubernetes-sigs/cri-tools/releases/download/v${VERSION}/crictl-v${VERSION}-linux-amd64.tar.gz" sudotar zxvf /usr/local/bin/crictl -C /usr/local/bin sudochmod +x /usr/local/bin/crictl
• 例如输出： containerd containerd.io 1.5.x

安装 Kubeadm、Kubelet、Kubectl：Kubernetes 集群核心工具

Kubernetes 官方推荐使用 kubeadm来快速搭建集群，kubelet是运行在每个 Node 上的守护进程，负责接收控制平面分配的 Pod 任务；kubectl是客户端工具，用来和 kube-apiserver 对话。下面来安装这些工具。

添加 Kubernetes 官方仓库

执行场景：在三台服务器（master/node1/node2） Shell 终端

cat<<EOF|sudotee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
# 阿里云镜像 GPG 公钥
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF

• 这里我们使用国内阿里云镜像地址，避免 kubeadm安装时因为网络原因拉不到包。
• 该地址适用于基于 CentOS/RHEL 7 的仓库，但 AlmaLinux 8 没有专门的官方仓库，因此依然可以使用 CentOS 7 的二进制。

命令不存在排查：

• 如果 tee未找到，执行 sudo yum install -y coreutils；
• 如果 yum、curl、tee都异常，说明系统基础环境严重缺失，需要先恢复或重装 AlmaLinux。

安装 kubeadm、kubelet、kubectl

执行场景：在三台节点（master/node1/node2）Shell 终端

sudo yum install-y kubelet kubeadm kubectl --disableexcludes=kubernetes

• --disableexcludes=kubernetes：确保安装时优先使用我们配置的 Kubernetes 仓库，而不是其他默认仓库。
• 如果出现 “No package kubelet available” 或 “nothing to do”，
  • 先执行 sudo yum clean all && sudo yum makecache更新缓存；
  • 再试一次；
  • 若仍然失败，可能仓库地址不可用，需要手动查找其他国内镜像或使用 GitHub Releases 的二进制包。

安装完成后，需要启动并设置 kubelet 在开机时自启（后续只有 kubelet 在运行，才能把 Node 注册到 kube-apiserver）：

sudo systemctl enable--now kubelet

运行后 systemctl status kubelet，如果状态是 active (running)，说明安装成功。若有报错，可查看 journalctl -u kubelet -n 50 --no-pager获取详细日志，再手动排查。

常见报错及排查：

• “Failed to start kubelet.service: Unit kubelet.service not found.”
  • 说明 kubelet 没安装成功，可尝试 yum list kubelet --showduplicates看可用版本，然后 yum install -y kubelet-<version>；
• “kubelet: error while loading shared libraries: lib <…> not found”
  • 可能有依赖缺失，尝试 sudo yum install -y epel-release，再 yum install -y kubelet；
• “permission denied”
  • 确认你是 root 或者有 sudo 权限；
• “SELinux is enforcing”
  • 如果 SELinux 没关，kubelet 可能因权限不足挂掉，需关闭 SELinux（参见 2.3 节）或配置策略。

验证组件状态与基础联通性

到此为止，你应该在三台服务器上都成功安装好了 containerd、kubeadm、kubelet、kubectl。下面要一步步验证它们是否可用，以及它们之间的基础网络是否打通。

验证 containerd

执行场景：在三台节点 Shell 终端

# 检查 containerd 服务
sudo systemctl status containerd

# 版本信息
containerd --version

# 查看网络配置是否正确
crictl info

• systemctl status containerd要显示 active (running)；
• containerd --version应该能输出版本号，如 containerd containerd.io 1.5.x；
• crictl info会输出类似 “Status: RuntimeReady” 等信息，若看到 RuntimeName: containerd，说明 CRI 接口正常。

如果 crictl未安装，把 crictl二进制下载到 /usr/local/bin/并赋可执行权限。

验证 kubeadm/kubelet

在 master 节点执行以下命令，验证 kubelet 是否正常运行，以及 Kubernetes 版本和模块是否可用：

# kubelet 状态
sudo systemctl status kubelet

# 查看 kubeadm 版本
kubeadm version

# 查看 kubectl 版本
kubectl version --client

# 查看 kubelet 版本
kubelet --version

• 如果 kubeadm version报 command not found，请先确认 /usr/bin/kubeadm是否存在；
• 如果运行 kubelet --version报错 “permission denied”，可尝试 sudo kubelet --version；但通常版本信息不需要 root 也能查看。

图片

验证节点间网络连通性

确保三台机器之间端口可以互通，尤其是 Kubernetes 默认使用一些特定端口。以下示例在 master 节点检查到 node1、node2 的连通性，同理在 node1、node2 检查到 master。

执行场景：在 master Shell 终端

# 检查与 node1 的连通性
ping-c node1
ping-c192.168.1.11

# 检查目标端口（例如 6443，默认 kube-apiserver 端口）
# 如果此时还没启动 kube-apiserver，这个端口不通也是正常的，重点是 NetworkReachable
telnet node1 # 部分系统可能没有 telnet，可安装 by: sudo yum install -y telnet
# 或者使用 ss/netstat 查看 22 端口是否监听
ss -tunlp|grep":22"

• 若出现 Destination Host Unreachable，说明网络不通，需要检查防火墙、网卡配置、VLAN 等；
• 一般把 ICMP（ping）和 SSH（22）开放，就能确认节点间能互访，后续 Kubernetes 组件才能正常互联。

命令不存在排查：

• 如果 ping未找到，可先安装 iputils： sudo yum install-y iputils
• 如果 ss报错未找到，可 sudo yum install -y iproute；
• 如果你想不用 telnet，也可用 nc -zv node1 22检查端口连通。若没有 nc，可以： sudo yum install-y nmap-ncat

三、总结：我们已经完成了哪些工作？

到目前为止，你已经在三台 AlmaLinux 服务器（master、node1、node2）上完成了以下准备工作：

1. 系统基础环境确认与工具安装（wget、curl、vim、net-tools 等）。
2. 主机名设置为 master、node1、node2，并通过 /etc/hosts让三台服务器能用主机名互相 Ping 通。
3. 关闭防火墙（firewalld）与 SELinux，避免 Kubernetes 各组件间通信因权限受限而失败。
4. 安装 Containerd，并配置国内镜像加速（阿里云、腾讯云等），保证后续拉取镜像的速度。
5. 安装了 kubeadm、kubelet、kubectl，并启动 kubelet服务，验证它们的版本和状态。
6. 验证了 containerd、kubelet 在宿主机上是否能正常运行，确保 CRI（Container Runtime Interface）可用，Kubernetes 组件具备最基本的运行前置条件。

这相当于给 Kubernetes 架构搭好了 “地基”：Containerd 是容器执行的“引擎”，kubelet 是节点级别的“司机”，kubeadm 是集群初始化的“施工队”，kubectl 是操作的“对讲机”。明天，我们就可以动手使用 kubeadm init在 master 上真正启动 Kubernetes 控制平面，Node 加入集群，体验“集群就绪→部署应用” 的全流程。

四、下篇预告：深入探究 Kubernetes 控制平面组件

下一篇我们将从 控制平面开始，拆解并实战验证以下核心组件：

1. Etcd：如何在节点间部署高可用的分布式存储？
2. Kube-apiserver：如何在 master 节点生成 TLS 证书，启动 API Server？
3. Kube-scheduler：如何为集群中的 Pod 进行调度？
4. Kube-controller-manager：如何保证 Deployment/ReplicaSet/DaemonSet 等动态4态控制器跑起来？
5. Kube-proxy：如何配置 Service 资源，让 Pod 互联和外部访问正常工作？ 如果你在本篇里对 Containerd 配置镜像加速、或 kubelet 无法启动的问题还有疑惑，共同学习