Kubernetes部署与运维03 Kubernetes集群模板虚拟机部署Kubernetes 1.32学习 conta

Kubernetes目前大约每年发布三次，由于迭代速度快，目前市场上绝大部分的教程相对陈旧。更重要的是，从Kubernetes 1.20开始，Kubernetes官方宣布逐步弃用Docker作为容器运行时，并计划在Kubernetes 1.24版本中完全移除对Docker作为容器运行时的支持。这意味着，从Kubernetes 1.24版本开始，将不能使用Docker作为容器运行时来运行Kubernetes节点上的Pods。因此，市场上关于直接使用containerd容器运行时的新版Kubernetes教程几乎没有，更重要的是因为的Kubernetes涉及到镜像需要单独配置才能获取，这无疑拉高了初学者门槛。本教程采用互联网的形式进行发布，便于保持与Kubernetes最新版的同步，尽量自包含，便于读者学习、实践。

关键字：Kubernetes 1.32; containerd; nerdctl; debain 12

Kubernetes部署与运维v3.png

整体规划

为方便后续内容学习，本部分将基于【Kubernetes部署与运维02 Nerdctl Rootful部署】中的环境开展Kubernetes的部署与学习。整体规划如下：

虚拟机名称	IP地址	主机名	域名	CPU核心	内存	角色
`K8s_Template`	`192.168.152.5`	`k8s`	`k8s.rz`	`2`	`2GB`	`模板`
`k8s_Master1_2G`	`192.168.152.200`	`master1`	`master.rz`	`2`	`2GB`	`master`
`K8s_Worker1_2G`	`192.168.152.201`	`worker1`	`worker1.rz`	`1`	`2GB`	`worker`
`K8s_Worker2_2G`	`192.168.152.202`	`worker2`	`worker2.rz`	`1`	`2GB`	`worker`

虽然worker1、worker2分配内存1GB在控制平面初始化时不报错，但是在安装Metrics-Server插件时会报内存不足错误。因此，本部分最低内存要求设置为2GB。CPU核心数除K8s_Master1_2G虚拟机之外，K8s_Worker1_2G与K8s_Worker2_2G虚拟机均可以使用1核心或2核心（建议1核心，因为后续部分内容，2核心演示不出效果），读者可根据自己电脑硬件配置灵活选择。

其中，各虚拟机的克隆关系如下：

源虚拟机	克隆机
`K8s_Nerdctl_Base`	`K8s_Template`
`K8s_Template`	`K8s_Master1_2G`
`K8s_Template`	`K8s_Worker1_2G`
`K8s_Template`	`K8s_Worker2_2G`

参见【Kubernetes部署与运维02 Nerdctl Rootful部署】，Kubernetes基础环境各组件与版本信息如下：

- nerdctl: v1.7.7
- containerd: v1.7.22
- runc: v1.1.14
- CNI plugins: v1.5.1
- BuildKit: v0.15.2
- Stargz Snapshotter: v0.15.1
- imgcrypt: v1.1.11
- RootlessKit: v2.3.1
- slirp4netns: v1.3.1
- bypass4netns: v0.4.1
- fuse-overlayfs: v1.13
- containerd-fuse-overlayfs: v1.0.8
- Kubo (IPFS): v0.29.0
- Tini: v0.19.0
- buildg: v0.4.1

本教程使用的Kubernetes版本号为1.32。

理论知识

本部分开始，将涉及到docker、nerdctl、ctr及crictl等容器命令，这里将介绍它们相关的比较与理论知识。

docker、nerdctl、ctr与crictl都是用于容器管理的命令行工具，但是它们的设计目的、使用场景和技术栈有所不同。

docker：Docker项目提供的官方命令行工具，广泛应用于基本Docker技术的容器管理和操作。用户可通过它来构建、运行、管理和分发Docker容器和镜像。docker的易用性和全面的功能集使其成为容器技术中最流行的工具之一。适用场景为通用的容器开发、部署和管理任务，特别是与Docker引擎集成的环境。
nerdctl：与docker风格和语义兼容的命令行工具，专为Containerd设计，由Rancher Labs开发，旨在为那些熟悉docker使用方式的用户提供一种更加轻量级且与Containerd深度集成的管理工具。nerdctl使得从Docker迁移到Containerd成为一个平滑的过程，因为它支持大部分docker命令和选项，同时利用了Containerd的高效和灵活性。Containerd适合追求更高性能和更小资源占用的场景，非常适合在Kubernetes环境下使用。nerdctl还提供了一些额外的特性和命令，以更好的利用Containerd的特性。
ctr：Containerd项目提供的一个轻量级的命令行工具。ctr提供了直接管理容器、镜像、沙箱等底层功能，相对docker更加面向底层和系统集成。
crictl：Kubernetes项目的容器运行时接口（CRI, Container Runtime Interface）的一个命令行客户端工具。CRI是Kubernetes为了支持多种容器运行时而引入的标准接口，允许Kubernetes与不同的容器运行时（如Docker、Containerd、CRI-O等）通信。crictl专门设计用来与实现了CRI接口的容器运行时进行交互，对容器和Pod的管理。

通过CLI与Containerd交互的各工具定位差异如下所示：

工具名	社区	`API`	目标
`ctr`	`containerd`	`Native`原生	仅用于调试
`nerdctl`	`containerd`非核心	`Native`原生	通用目的
`crictl`	`Kubernetes SIG-node`	`CRI`	仅用于调试

目标用户和场景区别：

docker面向更广泛的用户群体，特别是那些直接与Docker引擎交互的开发者和运维人员；
ctr更适用于与containerd集成的底层操作和系统级管理；
crictl聚焦于Kubernetes环境下的容器管理，提供跨容器运行时的一致性操作。

功能和深度区别：

docker功能最为全面，覆盖了从构建到部署的整个容器生命周期；
ctr与crictl更专注于底层容器操作，其中crictl通过CRI标准化了与容器运行时的交互。

集成与生态系统区别：

docker与Docker生态紧密集成；
ctr与containerd（及背后的CNFC生态）相辅相成；
crictl是Kubernetes生态中的一部分，特别适合云原生应用管理。

docker、nerdctl、ctr与crictl命令支持参数对比如下表所示：

命令描述	`docker`	`nerdctl`	`ctr`	`crictl`
显示正在运行的容器	`docker ps`	`nerdctl ps`	`ctr task ls` `ctr containers ls`	`crictl ps`
显示所有容器（包含退出等）	`docker ps -a`	`nerdctl ps -a`	`N/A`	`crictl ps -a`
仅显示容器`id`	`docker ps -q`	`nerdctl ps -q`	`ctr containers ls -q`	`crictl ps -q`
创建并启动容器	`docker run`	`nerdctl run`	`ctr run`	`crictl run`
进入容器	`docker exec`	`nerdctl exec`	`N/A`	`crictl exec`
停止容器	`docker stop`	`nerdctl stop`	`ctr pause`	`N/A`
删除容器	`docker rm`	`nerdctl rm`	`ctr task rm`	`N/A`
强制删除	`docker rm -f`	`nerdctl rm -f`	`ctr task rm -f`	`N/A`
删除退出状态的所有容器	`docker container prune`	`nerdctl container prune`	`N/A`	`N/A`
拷贝文件	`docker cp`	`nerdctl cp`	`N/A`	`N/A`
查看日志	`docker logs`	`nerdctl logs`	`N/A`	`crictl logs`
查看容器/镜像元信息	`docker inspect`	`nerdctl inspect`	`N/A`	`crictl inspect/inspecti`
查看版本	`docker version`	`nerdctl version`	`ctr version`	`crictl version`
查看系统级信息	`docker info`	`nerdctl info`	`N/A`	`crictl info`
下载镜像	`docker pull`	`nerdctl pull`	`ctr images pull`	`crictl pull`
删除镜像	`docker rmi`	`nerdctl rmi`	`ctr image rm`	`crictl rmi`
查看镜像列表	`docker images`	`nerdctl images`	`ctr image ls`	`crictl images`
镜像`tag`	`docker tag`	`nerdctl tag`	`ctr image tag`	`N/A`
镜像仓库登录	`docker login`	`nerdctl login`	`N/A`	`N/A`
镜像仓库登出	`docker logout`	`nerdctl logout`	`N/A`	`N/A`
包方式导入镜像	`docker load -i` `docker import`	`nerdctl load -i` `nerdctl import`	`ctr image import`	`N/A`
包方式导出镜像	`docker save -o` `docker export`	`nerdctl save -o`	`ctr image export`	`N/A`
镜像`Label`	`docker label`	`N/A`	`ctr image label`	`N/A`
镜像`push`	`docker push`	`nerdctl push`	`ctr image push`	`N/A`
镜像构建	`docker build`	`nerdctl build`	`N/A`	`N/A`

docker、nerdctl、ctr与crictl命令指定运行时sock：

docker、nerdctl、ctr和crictl这四个命令行工具在与容器运行时（如Containerd）交互时，对于指定运行时socket（通常为containerd.sock）的方式存在一些差异，这主要是由于它们的设计目的、使用场景以及与底层容器运行时的集成方式不同所致；
docker：Docker有自己的守护进程（daemon）。默认情况下，Docker客户端会连接到本地的Docker守护进程，而不是直接与Containerd交互。Docker守护进程自身负责与容器运行时（可能是Docker自带的或其他，如Containerd）的通信。Docker守护进程的socket位置通常是固定的（例如，在Linux上通常是/var/run/docker.sock），用户通常不需要直接指定socket地址；
nerdctl：nerdctl是为了提供一个与Docker CLI风格和功能相匹配的工具，专为Containerd设计。它直接与Containerd交互，模仿Docker CLI的使用体验。默认情况下，nerdctl会查找Containerd的默认socket位置（通常是/run/containerd/containerd.sock）。如果修改了containerd.sock路径，可以通过环境变量或如下命令行参数指定不同的socket，例如：nerdctl --address /path/to/containerd.sock ps；
ctr：ctr是Containerd自带的低级别命令行工具，主要用于调试和直接管理Containerd。它提供了更底层的控制能力。ctr也默认查找/run/containerd/containerd.sock，但可以通过-a或--address参数显式指定socket位置，例如：ctr -a /path/to/containerd.sock containers ls；
crictl：crictl是为Kubernetes与CRI兼容的容器运行时（包括Containerd）设计的。它通过CRI接口与运行时通信，主要用于Kubernetes环境下的容器管理。crictl通常通过环境变量或配置文件（如/etc/crictl.yaml）来指定运行时socket，而不是每次执行命令时都指定。例如，在配置文件中，可以设置runtime-endpoint来指定Containerd的socket地址。

docker、nerdctl、ctr与crictl命令创建并启动容器run命令参数差异：

参数	`docker run`	`nerdctl run`	`ctrl run`	`crictl run`
`-i`	[v]	[v]	[v]	[x]
`-t`	[v]	[v]	[v]	[x]
`-d`	[v]	[v]	[v]	[x]
`-it`	[v]	[v]	[x]	[x]
`-itd`	[v]	[x]	[x]	[x]
`--env`	[v]	[v]	[v]	[x]
`--network`	[v]	[v]	[x]	[x]
`--name`	[v]	[v]	[x]	[x]

docker、nerdctl、ctr与crictl命令覆盖或指定entrypoint差异：

docker run允许通过--entrypoint参数覆盖镜像中定义的ENTRYPOINT。如果提供了这个参数，指定的命令将会替代镜像中的ENTRYPOINT，并且可以结合命令参数。例如，docker run --entrypoint "/bin/bash" myimage将使用/bin/bash作为容器的入口点；
nerdctl run设计上力求与Docker CLI兼容，因此它也支持--entrypoint参数来覆盖镜像的默认入口点。用法与docker run相似，允许自定义容器启动时执行的第一个命令或脚本；
ctr run的命令行参数较为基础，它没有直接提供一个等同于--entrypoint的参数来轻松覆盖镜像的ENTRYPOINT。通常，需要通过直接指定命令来间接改变入口点行为，这意味着输入的命令会替代镜像的默认ENTRYPOINT和CMD；
crictl命令行工具并不直接提供run命令来启动独立容器，因为它主要针对Kubernetes环境下的容器管理。在Kubernetes中，容器的启动配置是通过Pod的定义（YAML文件）来完成的，其中包括command和args字段，它们分别对应于镜像的ENTRYPOINT和CMD。这意味着，不是通过crictl直接指定entrypoint，而是通过修改Pod配置文件来达到目的；

ctr和crictl实现docker login功能

ctr和crictl并没有像docker login这样直接管理registry权限的命令；
ctr用containerd的配置文件/etc/containerd/config.toml来存储账号密码；
crictl通常与Kubernetes集群一起使用，而Kubernetes集群的镜像拉取认证信息是通过集群内的服务账户（ServiceAccount）或ImagePullSecrets来管理的，而不是直接通过crictl登录。但如果需要在没有Kubernetes环境下使用crictl与私有registry交互，可能需要通过相应registry的认证令牌或证书来配置。另外，还可以通过创建secret来实现使用docker的配置文件~/.docker/config.json。

docker login配置示例：

   # /etc/containerd/config.toml registry账号密码配置
   [plugins."io.containerd.grpc.v1.cri".registry.configs."https://index.docker.io/v1/"]
     auth = "YOUR_AUTH_TOKEN"
     username = "YOUR_USERNAME"
   
   # SecretTypeDockerConfigJson contains a dockercfg file that follows the same format rules as ~/.docker/config.json
   #
   # Required fields:
   # - Secret.Data[".dockerconfigjson"] - a serialized ~/.docker/config.json file
   SecretTypeDockerConfigJson SecretType = "kubernetes.io/dockerconfigjson"

案例实践

前期准备

1）从K8s_Nerdctl_Base虚拟机克隆K8s_Template虚拟机，后者将是所有Kubernetes节点的克隆源。模板K8s_Template虚拟机将安装、配置所有节点均需要软件环境。

2）根据【整体规划】，配置K8s_Template虚拟机的IP 地址为192.168.152.5，具体参考【Kubernetes部署与运维01 Debian 12部署-静态IP配置】。

3）根据【整体规划】，配置K8s_Template虚拟机主机名为k8s，具体参考【Kubernetes部署与运维01 Debian 12部署- 主机名配置】。同时，修改/etc/hosts文件，内容如下：

127.0.0.1       localhost
127.0.1.1       k8s
192.168.152.4   k8s.rz
192.168.152.200 master1
192.168.152.201 worker1
192.168.152.202 worker2

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

4）重新登录，使配置生效。

交换分区swap配置

【实践01-交换分区swap配置】

禁用swap交换分区。

1）kubelet的默认行为是在节点上检测到交换分区时无法启动。这意味着要么禁用交换（swap）分区，要么让kubelet容忍交换。本方案将禁用交换分区。可使用命令swapoff -a暂时关闭交换分区功能。

root@k8s:~# swapoff -a

2）设置重启后依然禁用交换分区，修改配置文件/etc/fstab：

# swap was on /dev/sda5 during installation
# UUID=d1b8a9ef-f9ca-4f91-bd2f-cd56b0dfc3cd none   swap   sw   0   0

注释UUID=...行

容器运行时配置

【实践02-容器运行时配置】

配置containerd容器运行时环境。

1）默认情况下，Linux内核不允许IPv4数据包在接口之间路由。在手动启用IPv4数据包转发前，查看nerdctl info：

root@k8s:~# nerdctl info
Client:
 Namespace:     default
 Debug Mode:    false

Server:
 Server Version: v1.7.22
 Storage Driver: overlayfs
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Log: fluentd journald json-file syslog
  Storage: native overlayfs
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.1.0-30-amd64
 Operating System: Debian GNU/Linux 12 (bookworm)
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 1.887GiB
 Name: k8s
 ID: e3c42486-76a2-46c2-ab5d-4db55b14a772

WARNING: IPv4 forwarding is disabled
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

存在三条警告信息，分别为IPv4 forwarding is disabled、bridge-nf-call-iptables is disabled，以及bridge-nf-call-ip6tables is disabled。在部署Kubernetes时，需要消除这些警告信息。

2）创建/etc/sysctl.d/k8s.conf文件，内容如下，启用IPv4数据包转发：

net.ipv4.ip_forward = 1

3）应用sysctl参数，并验证net.ipv4.ip_forward是否设置为1：

root@k8s:~# sysctl --system
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /usr/lib/sysctl.d/99-protect-links.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.d/k8s.conf ...
* Applying /etc/sysctl.conf ...
kernel.pid_max = 4194304
fs.protected_fifos = 1
fs.protected_hardlinks = 1
fs.protected_regular = 2
fs.protected_symlinks = 1
net.ipv4.ip_forward = 1

root@k8s:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

4）Kubernetes需要使通过网桥的数据包由主机系统上的iptables规则处理，其默认为关闭状态，因此需要修改配置开启。再次修/etc/sysctl.d/k8s.conf文件，内容如下：

net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1

5）应用sysctl参数，并验证net.bridge.bridge-nf-call-iptables与net.bridge.bridge-nf-call-ip6tables是否设置为1：

root@k8s:~# sysctl --system
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /usr/lib/sysctl.d/99-protect-links.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.d/k8s.conf ...
* Applying /etc/sysctl.conf ...
kernel.pid_max = 4194304
fs.protected_fifos = 1
fs.protected_hardlinks = 1
fs.protected_regular = 2
fs.protected_symlinks = 1
net.ipv4.ip_forward = 1

root@k8s:~# sysctl net.bridge.bridge-nf-call-iptables
sysctl: cannot stat /proc/sys/net/bridge/bridge-nf-call-iptables: No such file or directory

表明桥接模块未加载。需要内核加载桥接模块br_netfilter。

6）向Linux内核加载br_netfilter模块，在/etc/modules文件尾追加如下一行，以确保每次系统启动均加载br_netfilter模块。

br_netfilter

7）为不重启系统，直接使用modprobe br_netfilter命令加载br_netfilter：

root@k8s:~# modprobe br_netfilter

再次查看nerdctl info，已经无任何警告信息：

root@k8s:~# nerdctl info
Client:
 Namespace:     default
 Debug Mode:    false

Server:
 Server Version: v1.7.22
 Storage Driver: overlayfs
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Log: fluentd journald json-file syslog
  Storage: native overlayfs
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.1.0-30-amd64
 Operating System: Debian GNU/Linux 12 (bookworm)
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 1.887GiB
 Name: k8s
 ID: e3c42486-76a2-46c2-ab5d-4db55b14a772

在Linux上，控制组（CGroup）用于限制分配给进程的资源。

kubelet和底层容器运行时都需要对接控制组来增强Pod与容器的资源管理，并为CPU、内存请求与限制设置资源限额。若要对接控制组，kubelet和容器运行时需要使用一个cgroup驱动。关键的一点是kubelet和容器运行时需使用相同的cgroup驱动并且采用相同的配置。可用的cgroup驱动有两个：cgroupfs与systemd。

当systemd是初始化系统时，不推荐使用cgroupfs驱动，因为systemd期望系统上只有一个cgroup管理器。

如果将systemd配置为kubelet的cgroup驱动，也必须将systemd配置为容器运行时的cgroup驱动。

8）修改/etc/containerd/config.toml文件，将SystemdCgroup值由false修改为true：

 128   │           [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
 129   │             BinaryName = ""
 130   │             CriuImagePath = ""
 131   │             CriuPath = ""
 132   │             CriuWorkPath = ""
 133   │             IoGid = 0
 134   │             IoUid = 0
 135   │             NoNewKeyring = false
 136   │             NoPivotRoot = false
 137   │             Root = ""
 138   │             ShimCgroup = ""
 139   │             SystemdCgroup = true

修改/etc/containerd/config.toml文件，将其第67行sandbox_image = "registry.k8s.io/pause:3.8"，将值改为registry.aliyuncs.com/google_containers/pause:3.10，以使containerd使用的沙盒与Kubernetes保持一致：

  67   │     sandbox_image = "registry.aliyuncs.com/google_containers/pause:3.10"

在后续部署Kubernetes中，需要使用国内的Kubernetes 镜像源，所以，要求Containerd使用的沙盒镜像与与Kubernetes的一致。

9）重启containerd服务，以使配置生效。

root@k8s:~# systemctl restart containerd.service

root@k8s:~# systemctl status containerd.service
● containerd.service - containerd container runtime
     Loaded: loaded (/usr/local/lib/systemd/system/containerd.service; enabled; >
     Active: active (running) since Tue 2025-01-28 08:10:03 CST; 5s ago
       Docs: https://containerd.io
    Process: 13979 ExecStartPre=/sbin/modprobe overlay (code=exited, status=0/SU>
   Main PID: 13982 (containerd)
      Tasks: 7
     Memory: 12.0M
        CPU: 63ms
     CGroup: /system.slice/containerd.service
             └─13982 /usr/local/bin/containerd

Kubernetes 1.32安装

【实践03-Kubernetes1.32安装】

基于containerd容器运行时环境，安装Kubernetes 1.32。

1）创建/root/software/k8s文件夹，以存放在安装与部署Kubernetes过程中涉及到的配置文件与相关软件。

root@k8s:~# mkdir /root/software/k8s

root@k8s:~# tree software/
software/
├── k8s
└── nerdctl-full-1.7.7-linux-amd64.tar.gz

2 directories, 1 file

root@k8s:~# cd /root/software/k8s/

2）更新apt包索引并安装使用Kubernetes apt仓库所需要的包：

root@k8s:~/software/k8s# apt update
Hit:1 http://mirrors.tuna.tsinghua.edu.cn/debian bookworm InRelease
Get:2 http://mirrors.tuna.tsinghua.edu.cn/debian bookworm-updates InRelease [55.4 kB]
...
All packages are up to date.

root@k8s:~/software/k8s# apt install -y apt-transport-https ca-certificates curl gpg
Reading package lists... Done
Building dependency tree... Done
...

3）下载用于Kubernetes软件包仓库的公共签名密钥。所有仓库都使用相同的签名密钥，因此可以忽略URL中的版本：

root@k8s:~/software/k8s# curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.32/deb/Release.key | gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

root@k8s:~/software/k8s# cp /etc/apt/keyrings/kubernetes-apt-keyring.gpg .

root@k8s:~/software/k8s# ll
total 4
-rw-r--r-- 1 root root 1200 Jan 28 08:21 kubernetes-apt-keyring.gpg

cp /etc/apt/keyrings/kubernetes-apt-keyring.gpg .命令仅用于将仓库的公共签名密钥备份一份至当前目录。若无法下载，请查看本教程最后的百度网盘下载链接，其中提供了本教程所涉及到的相关文件与资源。

4）添加Kubernetes apt仓库。请注意，此仓库仅包含适用于Kubernetes 1.32的软件包。创建/etc/apt/sources.list.d/kubernetes.list，内容如下：

deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://mirrors.tuna.tsinghua.edu.cn/kubernetes/core:/stable:/v1.32/deb/ /

此处使用了清华安装源。

5）更新apt包索引，查看具体可用版本信息：

root@k8s:~/software/k8s# apt update
Hit:1 http://mirrors.tuna.tsinghua.edu.cn/debian bookworm InRelease
Hit:2 http://mirrors.tuna.tsinghua.edu.cn/debian bookworm-updates InRelease
Get:3 https://mirrors.tuna.tsinghua.edu.cn/kubernetes/core:/stable:/v1.32/deb  InRelease [1,186 B]
Get:4 https://mirrors.tuna.tsinghua.edu.cn/kubernetes/core:/stable:/v1.32/deb  Packages [3,954 B]
...
All packages are up to date.

root@k8s:~/software/k8s# apt-cache madison kubeadm
   kubeadm | 1.32.1-1.1 | https://mirrors.tuna.tsinghua.edu.cn/kubernetes/core:/stable:/v1.32/deb  Packages
   kubeadm | 1.32.0-1.1 | https://mirrors.tuna.tsinghua.edu.cn/kubernetes/core:/stable:/v1.32/deb  Packages

root@k8s:~/software/k8s# apt-cache madison kubelet
   kubelet | 1.32.1-1.1 | https://mirrors.tuna.tsinghua.edu.cn/kubernetes/core:/stable:/v1.32/deb  Packages
   kubelet | 1.32.0-1.1 | https://mirrors.tuna.tsinghua.edu.cn/kubernetes/core:/stable:/v1.32/deb  Packages

root@k8s:~/software/k8s# apt-cache madison kubectl
   kubectl | 1.32.1-1.1 | https://mirrors.tuna.tsinghua.edu.cn/kubernetes/core:/stable:/v1.32/deb  Packages
   kubectl | 1.32.0-1.1 | https://mirrors.tuna.tsinghua.edu.cn/kubernetes/core:/stable:/v1.32/deb  Packages

6）安装kubelet、kubeadm和kubectl，并锁定其版本：

root@k8s:~/software/k8s# apt-get install -y kubelet=1.32.1-1.1 kubeadm=1.32.1-1.1 kubectl=1.32.1-1.1
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  conntrack cri-tools iptables kubernetes-cni libip6tc2 libnetfilter-conntrack3
  libnfnetlink0
Suggested packages:
  firewalld
The following NEW packages will be installed:
  conntrack cri-tools iptables kubeadm kubectl kubelet kubernetes-cni libip6tc2
  libnetfilter-conntrack3 libnfnetlink0
0 upgraded, 10 newly installed, 0 to remove and 0 not upgraded.
Need to get 93.1 MB of archives.
...

root@k8s:~/software/k8s# apt-mark hold kubelet kubeadm kubectl
kubelet set on hold.
kubeadm set on hold.
kubectl set on hold.

7）明确指定kubelet的CGroup驱动为systemd，参考【容器运行时配置】，修改/etc/default/kubelet文件，内容如下：

KUBELET_EXTRA_ARGS="--cgroup-driver=systemd"

8）重启kubelet.service服务，使配置生效：

root@k8s:~/software/k8s# systemctl restart kubelet.service

root@k8s:~/software/k8s# systemctl status kubelet.service
● kubelet.service - kubelet: The Kubernetes Node Agent
     Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; preset: enabl>
    Drop-In: /usr/lib/systemd/system/kubelet.service.d
             └─10-kubeadm.conf
     Active: activating (auto-restart) (Result: exit-code) since Tue 2025-01-28 >
       Docs: https://kubernetes.io/docs/
    Process: 30561 ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_>
   Main PID: 30561 (code=exited, status=1/FAILURE)
        CPU: 41ms

crictl配置

【实践04-crictl命令配置】

Kubernetes提供了crictl，其为一个命令行工具，用于与Kubernetes节点上的容器运行时接口（CRI）兼容的容器运行时进行交互。它是Kubelet容器接口（CRI）的命令行工具和验证工具，主要用于检查和调试Kubernetes节点上的容器运行时和应用程序‌。本部分将对crictl命令进行配置。

1）在未配置crictl时，运行crictl命令：

root@k8s:~/software/k8s# crictl images
WARN[0000] Config "/etc/crictl.yaml" does not exist, trying next: "/usr/bin/crictl.yaml"
WARN[0000] Image connect using default endpoints: [unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock unix:///var/run/cri-dockerd.sock]. As the default settings are now deprecated, you should set the endpoint instead.
IMAGE               TAG                 IMAGE ID            SIZE

因此，在使用crictl命令之前，需要对其配置。

2）创建/etc/crictl.yaml文件，内容如下：

runtime-endpoint: unix:///run/containerd/containerd.sock
image-endpoint: unix:///run/containerd/containerd.sock
timeout: 10
debug: false

3）再次执行crictl images命令：

root@k8s:~/software/k8s# crictl images
IMAGE               TAG                 IMAGE ID            SIZE

不再有警告信息。

4）配置crictl命令行自动补全，执行如下命令：

root@k8s:~/software/k8s# crictl completion bash >/etc/bash_completion.d/crictl

收尾工作

1）使用poweroff关闭K8s_Template虚拟机。

2）为K8s_Template虚拟机拍摄快照kubeadm1.32安装配置完成，以备后续在克隆时使用。

3）需要强调的是，后续内容，将不再启动K8s_Template虚拟机，该虚拟机仅作为集群中其他节点的克隆源存在，不要删除或再启动K8s_Template虚拟机。

4）AI时代背景之下，运维将从传统CPU服务器切入到GPU服务器与端边设备，对于运维开发人员，技术玩家而言，也同步需要跟上新的技术栈。本学习内容涉及到的软件包、配置文件等资源，可以直接从百度网盘下载获取：

百度网盘分享文件：Kubernetes1.32
链接：https://pan.baidu.com/s/18XeGQ28BDPjHh8JKj0uZFQ?pwd=6x17 提取码：6x17