Kubernetes1.28+Calico3.25 基于Centos7部署保姆级详细步骤

kevin·zhao &&

已于 2024-08-01 10:50:39 修改

阅读量653

点赞数 5

文章标签： kubernetes 贪心算法容器

于 2024-08-01 10:49:13 首次发布

本文链接：https://blog.csdn.net/zxcsd11/article/details/140839442

版权

附录（一）Kubelet与Calico的兼容性对照表

Kubelet与Calico的兼容性是Kubernetes集群网络插件的重要一环。不同版本的Kubernetes与Calico之间的兼容性以及说明文档总结如下（截至20240730）：

Kubernetes版本	Calico版本	Calico 文档	Calico文件下载地址
1.181.191.20	3.18	https://projectcalico.docs.tigera.io/archive/v3.18/getting-started/kubernetes/requirements	https://projectcalico.docs.tigera.io/archive/v3.18/manifests/calico.yaml
1.191.201.21	3.19	https://projectcalico.docs.tigera.io/archive/v3.19/getting-started/kubernetes/requirements	https://projectcalico.docs.tigera.io/archive/v3.19/manifests/calico.yaml
1.191.201.21	3.20	https://projectcalico.docs.tigera.io/archive/v3.20/getting-started/kubernetes/requirements	https://projectcalico.docs.tigera.io/archive/v3.20/manifests/calico.yaml
1.201.211.22	3.21	https://projectcalico.docs.tigera.io/archive/v3.21/getting-started/kubernetes/requirements	https://projectcalico.docs.tigera.io/archive/v3.21/manifests/calico.yaml
1.211.221.23	3.22	https://projectcalico.docs.tigera.io/archive/v3.22/getting-started/kubernetes/requirements	https://projectcalico.docs.tigera.io/archive/v3.22/manifests/calico.yaml
1.211.221.23	3.23	https://docs.tigera.io/archive/v3.23/getting-started/kubernetes/requirements	https://projectcalico.docs.tigera.io/archive/v3.23/manifests/calico.yaml
1.221.231.241.25	3.24	https://docs.tigera.io/calico/3.24/getting-started/kubernetes/requirements	https://projectcalico.docs.tigera.io/archive/v3.24/manifests/calico.yaml
1.231.241.251.261.271.28	3.25	https://docs.tigera.io/calico/3.25/getting-started/kubernetes/requirements	https://projectcalico.docs.tigera.io/archive/v3.25/manifests/calico.yaml
1.241.251.261.271.28	3.26	https://docs.tigera.io/calico/3.26/getting-started/kubernetes/requirements	https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/calico.yaml
1.271.281.29	3.27	https://docs.tigera.io/calico/3.27/getting-started/kubernetes/requirements	https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/calico.yaml
1.271.281.291.30	3.28	https://docs.tigera.io/calico/latest/getting-started/kubernetes/requirements	https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/calico.yaml

注意事项

版本升级：在升级Kubernetes或Calico之前，务必检查兼容性列表，并确保网络插件的版本与Kubernetes的版本相匹配。
文档和发布说明：参考Kubernetes和Calico的官方文档和发布说明，以获取详细的版本信息和升级指导。
测试环境：在生产环境进行版本升级之前，建议在测试环境中验证兼容性和稳定性。

这些信息通常可以在官方文档中找到。为了确保准确性，建议您查阅最新的Kubernetes和Calico官方文档：

· Kubernetes Compatibility

· Calico Release Note

附录（二）本文参考及引用地址

rpm包下载地址：

https://mirrors.aliyun.com/centos/7/os/x86_64/Packages/

YUM源地址

http://mirrors.aliyun.com/repo/Centos-7.repo

ELPepo仓库公共密钥地址

https://www.elrepo.org/RPM-GPG-KEY-elrepo.org

Docker相关地址

源文件地址

https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

常用命令总结

https://blog.csdn.net/zxcsd11/article/details/140373233?spm=1001.2014.3001.5501

containerd常用命令总结

https://blog.csdn.net/zxcsd11/article/details/140261514?spm=1001.2014.3001.5501

https://blog.csdn.net/zxcsd11/article/details/140261609?spm=1001.2014.3001.5501

nerdctl工具下载地址

https://github.com/containerd/nerdctl/releases/

crictl工具下载地址

https://github.com/kubernetes-sigs/cri-tools/releases/

KubernetersYUM源地址

https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/

https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg

https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg

Calico的yaml文件下载地址

（根据所需版本修改版本号即可下载）

https://projectcalico.docs.tigera.io/archive/v3.25/manifests/calico.yaml

Docker-hub地址

https://hub.docker.com/

国内docker镜像下载地址

（可获取docker-hub中最新镜像的国内替换信息）

https://docker.aityp.com/

1. 简述

随着自动化运维的不断普及，K8s使用范围越来越广，随着k8s版本的迭代，截至2024年7月，目前发布最新版本为1.30.2（发布于2024 年 6 月 11 日）。通过早期官方说明我们得知，Kubernetes 从 2020 年 12 月发布的 1.20 版开始弃用 Docker 容器做底层管理。真正 2022 年 5 月发布的 Kubernetes 1.24 版正式取消 Docker 支持。这一变化是由于 Kubernetes 转向使用 containerd 或 CRI-O 作为容器运行时接口 (CRI) 兼容运行，其提供与 Kubernetes 更好的集成和性能。而Docker 被取代是因为它本身并不符合 CRI，并且需要额外的组件 dockershim 才能在 Kubernetes 中运行，增加了额外的复杂性和维护开销。

本文意在指导那些喜欢K8s服务的小伙伴或系统小白们在Centos7中部署基于containerd 管理的K8s集群环境，基于安全性和稳定性，本次安装选取kuberneters版本为v1.28.0。下面让我们开启本次的Kuberneters之旅。

2. 部署版本说明

与早期版本相比，Kubernetes 1.28.0 带来了多项新功能和改进，但也存在一些潜在缺点。以下是主要功能和潜在缺点的总结：

参考官方版本说明文档，地址如下：https://kubernetes.io/blog/2023/08/15/kubernetes-v1-28-release/

2.1. 主要功能

扩展的控制平面和节点版本偏差：

功能：核心节点和控制平面组件之间支持的版本偏差从 n-2 扩展到 n-3。此更改允许运行最旧支持的次要版本的节点与最新的控制平面组件兼容。

优点：减少集群运营商必要升级的频率，从而减少中断和维护时间。

非正常节点关闭恢复：

功能：此功能现已稳定，并可确保如果原始节点意外关闭或无法恢复，有状态工作负载可以故障转移到其他节点。

优点：通过防止由于节点故障而导致的长期中断，增强有状态应用程序的可靠性和可用性。

功能的改进及优化：

功能：包括 45 项增强功能，其中 19 项进入 Alpha 阶段，14 项升级为 Beta 阶段，12 项达到稳定状态。

优点：功能的持续改进和稳定确保更好的性能和可靠性。

2.2. 潜在缺点

升级的复杂性：

缺点：即使扩大了版本偏差，管理跨不同组件和版本的升级仍然很复杂，需要仔细规划。

影响：如果管理不善，可能会导致潜在的停机或中断。

资源需求：

缺点：新功能和增强功能可能需要额外的资源，这可能会增加运行 Kubernetes 集群的成本。

影响：小型且资源受限的环境可能会发现，如果不扩大其基础设施，采用最新版本将会很困难。

新功能中可能存在的错误和问题：

缺点：Alpha 或 Beta 中的新功能可能仍然存在影响稳定性的错误或问题。

影响：早期采用新功能的用户可能会遇到意外问题，需要依靠社区支持来修复。

总体而言，Kubernetes 1.28.0 引入了重大改进，增强了平台的稳定性、可扩展性和易维护性。然而，这些改进也伴随着潜在的复杂性和资源需求增加。升级时需要仔细规划和考虑，以确保平稳过渡并有效利用新功能。

3. 生产环境参考

在生产环境中部署 Kubernetes (K8s) 集群时，需要仔细规划服务器配置以确保高可用性、性能和可扩展性。以下是针对 Kubernetes 集群不同组件的一些推荐配置：

控制（管理）节点（master）

CPU：至少 4 核，对于大型集群最好是 8 核或更多。
内存：至少 16 GB RAM，对于较大的工作负载，理想情况下最好为 32 GB 或更多。
存储：SSD 更适合更快的 I/O 操作。
网络：高速网络接口卡 (NIC)，至少 1 Gbps；大型集群则为 10 Gbps。
冗余：使用至少 3 个控制节点来实现高可用性。

工作节点（node）

CPU：至少 4 个核心；根据工作负载可能需要更多核心。
内存：对于资源密集型应用程序，至少 8 GB RAM，最好是 16 GB 或更多。
存储：为了获得更好的性能，最好使用 SSD。存储的大小取决于应用程序的需求。
网络：高速 NIC，至少 1 Gbps；高性能工作负载则为 10 Gbps。

Etcd 节点

CPU：至少4核。
内存：至少 8 GB RAM。
存储：具有高 IOPS 的快速 SSD，以确保 etcd 操作的性能。
网络：高速网卡。
冗余：高可用性 etcd 集群至少需要 3 个 etcd 节点。

负载均衡器

类型：使用硬件负载均衡器或基于云的负载均衡器将流量分配到控制平面节点。
配置：确保它支持健康检查并能处理预期的流量。

一般建议

操作系统：使用 Kubernetes 良好支持的 Linux 发行版，例如 Ubuntu、CentOS 或 Red Hat Enterprise Linux。
容器运行时：建议使用Containerd作为容器运行时。
Kubernetes 版本：使用 Kubernetes 的最新稳定版本，确保它得到良好的支持和维护。

示例配置

对于中型 Kubernetes 部署：

控制平面节点：

CPU：8 核

内存：32 GB

存储：500 GB SSD

网络：10 Gbps NIC

工作节点：

CPU：8 核

内存：32 GB

存储：1 TB SSD

网络：10 Gbps NIC

Etcd节点：

CPU：4 核

内存：16 GB

存储：500 GB SSD

网络：10 Gbps NIC

其他注意事项

· 备份和恢复：确保您对 etcd 和其他关键组件有一个强大的备份和恢复计划。
· 监控和日志记录：使用 Prometheus、Grafana 和 ELK 堆栈（Elasticsearch、Logstash 和 Kibana）等工具实现全面的监控和日志记录。

安全性

使用网络策略、RBAC（基于角色的访问控制）和定期安全更新来保护您的集群

4. 实验环境部署

4.1. 主机及操作系统

注意：本实验环境，不作为生产环境使用，仅做kuberneters部署演示及基础功能使用，实际生产环境请参考本章节对生产环境的阐述，硬盘大小不应小于200G。

操作系统	系统版本	系统小版本	CPU	内存	硬盘
CentOS	7.8	3.10.0-1127.el7.x86_64	4C	3G	20G

4.2. IP分配情况

角色	主机名	IP
master	k8smaster	192.168.115.101
worker(node)	k8snode01	192.168.115.102
worker(node)	k8snode02	192.168.115.103

4.3. 主机名配置

检查主机名配置是否正确（hostname），若不是本文指定主机名，请使用下面命令进行主机名重置（在主机名对应的服务器中分别执行），下面命令可以永久修改主机名，并立即生效无需重启：

#master节点
hostnamectl set-hostname k8smaster
#worker01节点
hostnamectl set-hostname k8snode01
#worker02节点
hostnamectl set-hostname k8snode02
检查主机名方法
#hostname

4.4. 主机名与IP地址解析

4.4.1. 固定IP配置

分配配置各服务器的IP绑定，不要使用自动获取（dhcp）使用固定IP（static或none），请根据您实际网卡进行配置，本实验使用Centos默认网卡eth33（Redhat默认网卡为eth0）。

Master节点配置

 #vim /etc/sysconfig/network-scripts/ifcfg-ens33
TYPE="Ethernet"
PROXY_METHOD="none"
BROWSER_ONLY="no"
BOOTPROTO="none"   #变更固定IP模式，dhcp为自动获取IP模式
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
IPV6_ADDR_GEN_MODE="stable-privacy"
NAME="ens33"
UUID="22b0a1ff-00f3-4142-b87f-f5c5851d3f62"
DEVICE="ens33"
ONBOOT="yes" #开机网卡自启动
IPADDR=192.168.115.101  #本机服务IP
NETMASK=255.255.255.0   #子网掩码
GATEWAY=192.168.115.2   #网关
ARPCHECK=no             #禁用特定网络接口的 ARP（地址解析协议）检查
DNS1=114.114.114.114    #电信DNS服务地址
DNS2=8.8.8.8            #Google提供的免费DNS服务器的IP地址

Worker01节点配置

TYPE="Ethernet"
PROXY_METHOD="none"
BROWSER_ONLY="no"
BOOTPROTO="none"   #变更固定IP模式，dhcp为自动获取IP模式
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
IPV6_ADDR_GEN_MODE="stable-privacy"
NAME="ens33"
UUID="d114a879-597b-4d35-ad8c-42b2353775f0"
DEVICE="ens33"
DEVICE="ens33"
ONBOOT="yes" #开机网卡自启动
IPADDR=192.168.115.102  #本机服务IP
NETMASK=255.255.255.0   #子网掩码
GATEWAY=192.168.115.2   #网关
ARPCHECK=no             #禁用特定网络接口的 ARP（地址解析协议）检查
DNS1=114.114.114.114    #电信DNS服务地址
DNS2=8.8.8.8            #Google提供的免费DNS服务器的IP地址

Worker02节点配置

TYPE="Ethernet"
PROXY_METHOD="none"
BROWSER_ONLY="no"
BOOTPROTO="none"   #变更固定IP模式，dhcp为自动获取IP模式
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
IPV6_ADDR_GEN_MODE="stable-privacy"
NAME="ens33"
UUID="fe4ed1b5-6c80-45b7-b712-e8e9e2845879"
DEVICE="ens33"
ONBOOT="yes" #开机网卡自启动
IPADDR=192.168.115.103  #本机服务IP
NETMASK=255.255.255.0   #子网掩码
GATEWAY=192.168.115.2   #网关
ARPCHECK=no             #禁用特定网络接口的 ARP（地址解析协议）检查
DNS1=114.114.114.114    #电信DNS服务地址
DNS2=8.8.8.8            #Google提供的免费DNS服务器的IP地址

注意：在做网络配置时，需根据实际环境配置DNS网络，本实验连接互联网因此配置上述DNS，在做修改时注意只修改标注部分，一但误删或配置失败，网络服务将无法启动。UUID切记不要修改。每台服务器中UUID均是唯一不变的。

4.4.2. 网卡无法启动

在日常使用中若发现网卡配置文件ifc-*文件配置无异常或第一次配置生效后无异常，服务器重启后网络服务却一直无法启动，甚至重置网卡后，网络服务仍无法正常运行，则检查服务器中是否存在NetworkManager服务，若存在该服务并处于启动状态，请手动关闭该服务并关闭开机自启服务，该服务是有nmcli进行自动管理，若开启可能引起网卡配置冲突而导致网络无法启动，若遇到上述问题，请优先执行下面命令

#关闭NetworkManager
systemctl stop NetworkManager
#禁止开机自启动
systemctl disable NetworkManager
#启动网卡服务
systemctl start network
#将网卡服务设置为开机自启动项
systemctl enable network
#查看网卡服务状态
systemctl status network

4.4.3. 主机名解析

检查主机名解析，所有集群主机均需进行检查，若未配置则按如下配置进行修改；

cat >> /etc/hosts << EOF
#Add host name resolution
192.168.115.101 k8smaster
192.168.115.102 k8snode01
192.168.115.103 k8snode02
EOF

在这里插入图片描述

配置完成后，使用如下命令进行验证，若网络连接正常，则配置成功（如下图）

ping k8smaster
ping k8snode01
ping k8snode02

在这里插入图片描述

4.5. 防火墙配置

所有主机均需要操作。

#关闭现有防火墙（firewalld）
systemctl disable firewalld --now
#查看防火墙（firewalld）状态
systemctl status firewalld.service
#若使用上述两条命令无法关闭firewalld时，执行如下命令
systemctl stop firewalld.service

执行结果如下图，则防火墙已经关闭，若显示防火墙服务为running，则使用“systemctl stop firewalld.service”命令在关闭一次，并查看最终状态。

在这里插入图片描述

若服务器使用iptables防火墙，则使用如下命令关闭防火墙

#关闭现有防火墙（iptables）
systemctl disable iptables --now
#查看防火墙（iptables）状态
systemctl status iptables.service
#若使用上述两条命令无法关闭iptables时，执行如下命令
systemctl stop iptables.service

若显示如下结果，则说明本机未部署iptables服务

在这里插入图片描述

4.6. 关闭SELINUX配置

所有主机均需要操作

#永久修改关闭selinux
sed -ri 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config
#重启服务器
reboot

上述配置将用久关闭selinux服务，服务器不重启，配置不生效，若配置完不立即重启，则可执行如下操作：

setenforce 0

setenforce 0是临时关闭selinux服务，执行后直至服务器重启后，恢复为/etc/selinux/conf中针对selinux的配置。

#查看当前的运行模式
getenforce
#可以查看selinux的概要状态信息
sestatus
#可以查看selinux的详情状态信息
sestatus -v

上述命令用于查看当前selinux的基础信息，显示Permissive则可以向下操作

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png? 在这里插入图片描述

注：selinux的模式配置说明

enforcing：强制模式，SELinux 正在运行中，已经在限制 domain/type。

permissive：宽容模式：SELinux 正在运行中，但仅发出警告信息,并不会实际限制 domain/type 的存取(permissive模式可以用在测试环境中供调试规则时使用)。

disabled：关闭，SELinux 不再运行。

4.7. 在线YUM源更新替换

所有主机均需要操作

①下载YUM变更所需要的rpm安装包（可能有些包之间的小版本号不一样，可以直接去阿里云上下载）

#下载yum-metadata-parser-1.1.4-10.el7.x86_64.rpm
wget https://mirrors.aliyun.com/centos/7/os/x86_64/Packages/yum-metadata-parser-1.1.4-10.el7.x86_64.rpm
#下载yum-3.4.3-168.el7.centos.noarch.rpm
wget https://mirrors.aliyun.com/centos/7/os/x86_64/Packages/yum-3.4.3-168.el7.centos.noarch.rpm
#下载yum-plugin-fastestmirror-1.1.31-54.el7_8.noarch.rpm
wget https://mirrors.aliyun.com/centos/7/os/x86_64/Packages/yum-plugin-fastestmirror-1.1.31-54.el7_8.noarch.rpm
#下载yum-utils-1.1.31-54.el7_8.noarch.rpm
wget https://mirrors.aliyun.com/centos/7/os/x86_64/Packages/yum-utils-1.1.31-54.el7_8.noarch.rpm
#下载python-urlgrabber-3.10-10.el7.noarch.rpm
wget https://mirrors.aliyun.com/centos/7/os/x86_64/Packages/python-urlgrabber-3.10-10.el7.noarch.rpm
#下载yum-langpacks-0.4.2-7.el7.noarch.rpm
wget https://mirrors.aliyun.com/centos/7/os/x86_64/Packages/yum-langpacks-0.4.2-7.el7.noarch.rpm

②查询yum包和删除yum现有rpm包，删完以后再查看一下，是否删除干净，删除完成后安装刚刚下载好的rpm包，yum包安装时必须取消依赖关系和强制安装

#查看系统安装的YUM包
rpm -qa | grep yum
#查询系统安装的YUM包，并直接删除
rpm -qa | grep yum | xargs rpm -e --nodeps
#安装python-urlgrabber-3.10-10.el7.noarch.rpm包
rpm -ivh python-urlgrabber-3.10-10.el7.noarch.rpm
#重新安装YUM需要的包忽略异常信息，强制安装
rpm -ivh yum-* --force --nodeps

③更新在线YUM源文件，替换为阿里云镜像仓库地址（在/etc/yum.repos.d路径下执行）

#下载部署YUM源
wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
#修改YUM源配置文件CentOS-Base.repo指定centos7版本
sed -i 's#$releasever#7#g' CentOS-Base.repo
#清理原YUM源
yum clean all
#重新加载YUM源
yum makecache

4.8. 时间同步配置

所有主机均需要操作。

部署安装ntpdate软件。

#检查是否部署ntp服务
yum list |grep  ntpdate
#若未安装nto服务，则执行下面安装 
yum -y install ntpdate
#与阿里在线时间进行同步时间
ntpdate time1.aliyun.com
#检查crontab内容 ，修改常见crontab命令为“crontab -e”
crontab -l
0 */1 * * * /usr/sbin/ntpdate time1.aliyun.com

优先使用“yum list”确认nptdate服务是否安装若已经安装，则直接配置crontab任务，若本地有ntpdate时钟同步器，则直接与其同步，若可以连接互联网，那么也可以直接与阿里时钟同步器进行时间同步，本实验与阿里时钟同步器进行同步“ntpdate time1.aliyun.com”

4.9. 在线升级操作系统内核

所有主机均需要操作，将系统内核升级至最新。

4.9.1. 查看当前内核版本

# 查看当前系统内核版本
uname -a
#以下为执行结果
Linux k8smaster 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

可使用uname -r 直接获取当前内核版本显示如下

# 查看当前系统内核版本，只显示版本信息
uname -r
#3.10.0-1127.el7.x86_64

4.9.2. 更新内核

#在线升级系统内核
 yum update -y

**该操作将操作系统内核升级至当前V7版本的最新小版本，若网络环境良好，直接执行“yum update -y”更新所有即可，若网络延时严重，不建议直接更新。可以使用如下步骤升级操作系统

①导入ELPepo仓库公共密钥

rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org

②安装ELPepo的仓库yum源

#手动拉取elrepo-release
yum -y install elrepo-release
#或在线拉取官方rpm包
rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
#以下为执行结果显示内容
获取#http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
获取http://elrepo.org/elrepo-release-7.0-4.el7.elrepo.noarch.rpm
准备中...                          ################################# [100%]
正在升级/安装...
   1:elrepo-release-7.0-4.el7.elrepo  ################################# [100%]

③列出可用的系统内核包

#列出可用的系统内核包
yum --disablerepo="*" --enablerepo="elrepo-kernel" list available
#以下为执行结果显示内容
已加载插件：fastestmirror
Determining fastest mirrors
 * elrepo-kernel: mirrors.neusoft.edu.cn
elrepo-kernel                                                                                                                                                                                              | 2.9 kB  00:00:00     
elrepo-kernel/primary_db                                                                                                                                                                                   | 1.9 MB  00:00:01     
可安装的软件包
elrepo-release.noarch                                                                       7.0-5.el7.elrepo                                                                              elrepo-kernel
……
elrepo-kernel

说明：查询结果由于版本不同，显示结果也存在差异，查询结果中lt长期维护版；ml最新稳定版，安装时优先选取长期维护版本。

④****选择lt版本安装

# 在线使用yum安装部署内核长期文档版本（lt）
yum -y  --enablerepo=elrepo-kernel install kernel-lt
#以下为执行结果显示内容
已加载插件：fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirrors.aliyun.com
 * elrepo: mirrors.neusoft.edu.cn
 * elrepo-kernel: mirrors.neusoft.edu.cn
 * extras: mirrors.aliyun.com
 * updates: mirrors.163.com
base                                                                                                                                                                                                       | 3.6 kB  00:00:00     
elrepo                                                                                                                                                                                                     | 2.9 kB  00:00:00     
extras                                                                                                                                                                                                     | 2.9 kB  00:00:00     
updates                                                                                                                                                                                                    | 2.9 kB  00:00:00     
(1/5): extras/7/x86_64/primary_db                                                                                                                                                                          | 222 kB  00:00:00     
(2/5): base/7/x86_64/group_gz                                                                                                                                                                              | 153 kB  00:00:00     
(3/5): elrepo/primary_db                                                                                                                                                                                   | 481 kB  00:00:00     
(4/5): base/7/x86_64/primary_db                                                                                                                                                                            | 6.1 MB  00:00:02     
(5/5): updates/7/x86_64/primary_db                                                                                                                                                                         | 3.6 MB  00:00:03     
正在解决依赖关系
--> 正在检查事务
---> 软件包 kernel-lt.x86_64.0.4.4.244-1.el7.elrepo 将被 安装
--> 解决依赖关系完成
依赖关系解决
========================================================================================
 Package                                            架构                                            版本                                                             源                                                      大小
========================================================================================
……
警告：RPM 数据库已被非 yum 程序修改。
  正在安装    : kernel-lt-4.4.244-1.el7.elrepo.x86_64                                                                                                                                                                         1/1 
  验证中      : kernel-lt-4.4.244-1.el7.elrepo.x86_64                                                                                                                                                                         1/1 
已安装:
  kernel-lt.x86_64 0:4.4.244-1.el7.elrepo                                                                                                                                                                                         
完毕！

若显示如下异常信息

Loaded plugins: fastestmirror, langpacksLoading mirror speeds from cached hostfileCould not retrieve mirrorlist http://mirrors.elrepo.org/mirrors-elrepo.el7 error was14: curl#7 - "Failed connect to mirrors.elrepo.org:80; Connection refused"Could not retrieve mirrorlist http://mirrors.elrepo.org/mirrors-elrepo-kernel.el7 error was14: curl#7 - “Failed connect to mirrors.elrepo.org:80; Connection refused”

该异常表明系统在尝试访问 ELRepo 镜像列表时遇到了网络连接问题。具体来说，curl#7 错误代码表示无法连接到目标服务器（mirrors.elrepo.org）可直接使用手动下载，或者替换为阿里源。

⑤设置内核默认启动

#  查看内核启动顺序
sudo awk -F\' '$1=="menuentry " {print i++ " : " $2}' /etc/grub2.cfg
0 : CentOS Linux (3.10.0-1160.119.1.el7.x86_64) 7 (Core)
1 : CentOS Linux (3.10.0-1127.el7.x86_64) 7 (Core)
2 : CentOS Linux (0-rescue-ac0ac0b2f9d343cea9cbc293b9aaaf69) 7 (Core)#修改内核启动顺序
grub2-set-default 0

4.9.3. 重启系统

reboot

4.9.4. 重启结束后，查看内核版本

# 查看内核版本uname -a#Linux k8smaster 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

可使用uname -r 直接获取当前内核版本显示如下

# 查看内核版本，只显示版本信息
uname -r
#3.10.0-1160.119.1.el7.x86_64

4.10. 配置内核转发及网桥过滤

所有主机均需要操作

#添加网桥过滤及内核转发配置文件
cat > /etc/sysctl.d/kerneters.conf << EOF
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
vm.swappiness = 0
EOF

#检查k8s.conf文件及内容是否生成
cat /etc/sysctl.d/kerneters.conf
#以下为显示结果
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
vm.swappiness = 0

#加载br_netfilter模块
modprobe br_netfilter

#查看br_netfilter模块是否加载成功
lsmod | grep br_netfilter
#以下为显示结果
br_netfilter           22256  0
bridge                151336  1 br_netfilter
#加载网桥过滤及内核转发配置文件
sysctl -p /etc/sysctl.d/kerneters.conf
#以下为显示结果
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
vm.swappiness = 0

注：若br_netfilter模块加载失败时，部署k8s的网络组件Calico时，会因为pod无法绑定，而无法完成网络组件的部署。必须确保该组件加载成功。

4.11. 安装ipset及ipvsadm（选装）

所有主机均需要操作。该步骤用于配置服务主机中针对k8s管理使用的防火墙，若不需要使用，则不需要执行如下操作。

#安装ipset及ipvsadm
yum -y install ipset ipvsadm
#配置ipvsadm模块加载方式，添加需要加载的模块
cat > /etc/sysconfig/modules/ipvs.modules <<EOF
#!/bin/bash
modprobe -- ip_vs
modprobe -- ip_vs_rr
modprobe -- ip_vs_wrr
modprobe -- ip_vs_sh
modprobe -- nf_conntrack
EOF
# 脚本文件添加执行权限
chmod +x /etc/sysconfig/modules/ipvs.modules
# 执行脚本文件
/bin/bash /etc/sysconfig/modules/ipvs.modules
# 查看对应的模块是否加载成功
lsmod | grep -e ip_vs -e nf_conntrack_ipv4

4.12. 关闭SWAP分区

在 Kubernetes (K8s) 集群中，默认情况下，节点上的 swap 需要禁用。这是因为 Kubernetes 对资源的调度和管理依赖于准确的内存使用情况，而 swap 的使用可能导致内存使用的不可预测性，从而影响调度的准确性和稳定性。

4.12.1. 为什么需要禁用 Swap

Ø 资源调度准确性：

Kubernetes 依赖于节点报告的内存使用情况来进行资源调度。如果节点使用了 swap，内存使用情况可能会变得不准确，从而影响调度决策。

Ø 性能稳定性：

Swap 的使用可能会导致性能问题，尤其是在内存密集型工作负载下。物理内存的访问速度远快于 swap，因此频繁的 swap 使用可能会显著降低性能。

4.12.2. 如何禁用 Swap

为了在 Kubernetes 集群中部署服务，需要禁用所有节点上的 swap。以下是禁用 swap 的步骤：

临时禁用 Swap：

swapoff -a

永久禁用 Swap：

编辑 /etc/fstab 文件，注释掉或删除与 swap 分区相关的行。保存文件并退出。例如，将类似于以下内容的行注释掉：

#注释掉swap的配置信息
#/dev/mapper/centos-swap swap             swap    defaults        0 0

注意：修改配置文件后，必须重启服务器，才能使修改配置生效。如不重启，可结合临时关闭命令使用，命令为swapoff -a

4.12.3. 开启Swap时，如何部署Kuberneters

如果你必须在节点上启用 swap，则需要修改 Kubelet 配置，

这个选项并不推荐，因为它可能会导致意想不到的问题。

在 kubelet 的配置中添加 --fail-swap-on=false 参数来允许 kubelet 在 swap 启用时启动。

修改 kubelet 启动配置文件，通常是 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf，添加以下内容：

Environment="KUBELET_EXTRA_ARGS=--fail-swap-on=false"

然后，重新加载 systemd 配置并重启 kubelet：

systemctl daemon-reload
systemctl restart kubelet

检查 Kubelet 状态

确保 kubelet 正常运行并没有因为 swap 问题而出现错误：

systemctl status kubelet

虽然可以通过修改 kubelet 配置来在启用 swap 的情况下运行 Kubernetes，但这不是推荐的做法。最佳实践仍然是禁用 swap 以确保 Kubernetes 集群的稳定性和性能。如果可能，按照上述步骤永久禁用 swap，以避免潜在的问题。

4.13. Docker环境准备

在kuberneters1.24.0版本及以后，kuberneters底层已经不在使用docker做为底层支持服务，对于V1.24.0版本及以上版本的kuberneters环境中无需在部署docker环境，请安装containerd环境，但考虑到containerd镜像环境的不足，建议在其中某一台服务器中部署docker服务，便于底层镜像的拉取及变更。

4.13.1. Docker源地址更新

按如下步骤在/etc/yum.repos.d路径下新增docker源配置

#下载docker的YUM源地址
wget https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo -O /etc/yum.repos.d/docker-ce.repo
#修改配置文件中系统版本指定为7版本
sed -i 's#$releasever#7#g' docker-ce.repo
#加载YUM源
yum makecache fast

配置完成后使用“yum makecache”无异常输出，且显示docker地址加载则配置完成。

4.13.2. daemon.json文件配置

“/etc/docker/daemon.json” 文件是 Docker 守护进程（daemon）的配置文件。通过编辑这个文件，你可以配置 Docker 守护进程的各种参数和选项，例如网络设置、日志记录、存储驱动等。此文件使用 JSON 格式。

4.13.2.1. 常见配置选项

以下是一些常见的配置选项及其作用：

配置镜像加速器

{ 
"registry-mirrors": ["https://your-mirror-address"] 
}

指定存储驱动

{
  "storage-driver": "overlay2" 
}

配置日志驱动和选项

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

配置 Docker 守护进程监听的地址

{
  "hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2375"]
}

配置默认 ulimit

{
  "hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2375"]
}

配置自定义数据根目录

{
  "default-ulimits": {
    "nofile": {
      "Name": "nofile",
      "Hard": 64000,
      "Soft": 64000
    }
  }
}

4.13.2.2. 示例配置文件

一个完整的示例配置文件可能如下所示：

{
  "registry-mirrors": ["https://mirror.gcr.io"],
  "storage-driver": "overlay2",
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2375"],
  "default-ulimits": {
    "nofile": {
      "Name": "nofile",
      "Hard": 64000,
      "Soft": 64000
    }
  },
  "data-root": "/mnt/docker-data"
}

4.13.2.3. 本案例最终daemon.json配置如下

mkdir /etc/docker && touch /etc/docker/daemon.json
cat > /etc/docker/daemon.json <<EOF
{ 
	"registry-mirrors":[
	"https://i1el1i0w.mirror.aliyuncs.com",
	"https://hub-mirror.c.163.com",
	"https://registry.aliyuncs.com",
	"https://registry.docker-cn.com",
	"https://docker.mirrors.ustc.edu.cn"
	],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  },
  "storage-driver": "overlay2",
    "storage-opts": [
    "overlay2.override_kernel_check=true"
  ],
  "data-root": "/var/lib/docker",
  "exec-opts": ["native.cgroupdriver=systemd"],
  "insecure-registries": [],
  "live-restore": true,
  "max-concurrent-downloads": 3,
  "max-concurrent-uploads": 5,
  "default-ulimits": {
    "nofile": {
      "Name": "nofile",
      "Hard": 64000,
      "Soft": 64000
    }
  }
}
EOF

注：按上述配置文件配置daemon.json后，若docker服务无法启动，则删除红色部分，无法启动原因请查看本文档4.13.4章节

查看daemon.json内容：

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传] 在这里插入图片描述

4.13.3. Docker环境安装

#查看当前系统可部署docker-ce版本（可忽略，不执行）
yum list docker-ce --showduplicates | sort -r
#默认安装最新版
yum -y install docker-ce
#查看部署docker版本
docker version
#启动docker服务
systemctl start docker
#查看docker服务状态
systemctl status docker

当“systemctl status docker”结果显示running状态则docker服务安装部署完成，若使用kubernlters版本低于V1.28.2，则将Docker服务设置为开机自启动服务。并在每台服务节点中均安装Docker服务，若使用版本高于等于V1.24.0版本，则无需配置Docker为开机自启动服务。设置开机自启动服务命令如下：

systemctl endable docker

Docker常用命令参考：

https://blog.csdn.net/zxcsd11/article/details/140373233?spm=1001.2014.3001.5501

4.13.4. 本实例docker无法启动案例

报错信息

failed to start daemon: error initializing graphdriver: overlay2: unknown option overlay2.override_kernel_check: overlay2

使用“journalctl -xe”查询时，出现 “failed to start daemon: error initializing graphdriver: overlay2: unknown option overlay2.override_kernel_check: overlay2” 错误，表示 Docker 不识别 overlay2.override_kernel_check 选项。这通常发生在 Docker 版本或内核版本不支持该选项的情况下。本案例去掉“overlay2.override_kernel_check”配置问题排除：

#原配置：
  "storage-driver": "overlay2",
    "storage-opts": [
    "overlay2.override_kernel_check=true"
  ],
#修改后配置
  "storage-driver": "overlay2",

在这里插入图片描述

4.13.5. Docker无法启动排查步骤方法

当 Docker 无法启动时，可能有多种原因。要诊断和解决这个问题，您可以按照以下步骤进行操作：

① 检查 Docker 服务状态

首先，查看 Docker 服务的状态，以获取有关问题的初步信息：

systemctl status docker.service

这条命令会显示 Docker 服务的当前状态以及最近的日志条目。

② 查看详细日志

使用 journalctl 查看与 Docker 相关的详细日志信息：

journalctl -u docker.service

将提供更多的上下文和错误细节，以帮助您诊断问题。

③****常见问题及解决方法

配置文件错误

Docker 配置文件（通常位于 /etc/docker/daemon.json）中的语法错误可能会导致服务启动失败。检查并确保配置文件的 JSON 语法正确：

cat /etc/docker/daemon.json

可以使用 jq 工具来验证 JSON 文件的语法是否正确：

jq . /etc/docker/daemon.json

如果文件中有语法错误，修正它们并重启 Docker 服务：

systemctl restart docker

端口冲突

如果 Docker 服务尝试绑定的端口已经被其他服务占用，也会导致启动失败。检查 Docker 配置文件中的端口设置，并确保这些端口没有被其他服务占用。

存储驱动问题

有时 Docker 的存储驱动配置不正确也会导致启动失败。您可以通过查看 Docker 日志来确定是否是存储驱动的问题：

journalctl -u docker.service

如果是存储驱动的问题，尝试更改 Docker 的存储驱动。编辑 /etc/docker/daemon.json 文件，添加或修改 storage-driver 设置：

{
  "storage-driver": "overlay2"
}

然后重启 Docker 服务：

systemctl restart docker

内核模块问题

确保系统加载了 Docker 所需的内核模块。您可以通过以下命令加载必要的模块：

modprobe overlay

然后重启 Docker 服务：

systemctl restart docker

清理旧的 Docker 数据

有时候，旧的或损坏的 Docker 数据可能会导致服务启动失败。尝试清理旧数据（注意：这将删除所有容器和镜像）：

rm -rf /var/lib/docker

然后重启 Docker 服务：

systemctl restart docker

④****验证解决方案

在完成以上步骤后，再次检查 Docker 服务的状态：

systemctl status docker

4.14. containerd环境准备

4.14.1. 为什么使用containerd

早期docker势大，但docker没有实现CRI，Kubernetes只能用dockershim做适配器来兼容docker，使其可以接入cri，但是这个dockershim在Kubernetes1.24版本就被放弃维护了，转而强制使用容器运行时Container Runtime作为kubelet和容器的桥梁。containerd是从docker中分离出来的开源项目，强调简单性、健壮性和可移植性。它负责以下工作：

管理容器的生命周期（从创建容器到销毁容器）
拉取/推送容器镜像
存储管理（管理镜像及容器数据的存储）
调用 runc 运行容器（与 runc 等容器运行时交互，runc是oci 开放容器标准的一个实现。oci就是创建容器需要做一些 namespaces 和 cgroups 的配置，以及挂载 root 文件系统等操作的规范）
Ø 管理容器网络接口及网络

目前容器运行时有两种选择：

一：docker有强关联的cri-dockerd；

二：containerd，用containerd替代docker对k8s进行底层管理；

两种都可以管理k8s底层镜像，但在高版本的k8s集群中docker需要cri-dockerd进行强绑定才能使用，缺少灵活性，对于新架构的K8s集群，建议使用containerd，但containerd镜像不足，还需要依赖于docker拉取镜像，虽然使用的是containerd，但是不能完全摒弃docker。

containerd常用命令参考地址

https://blog.csdn.net/zxcsd11/article/details/140261514?spm=1001.2014.3001.5501

https://blog.csdn.net/zxcsd11/article/details/140261609?spm=1001.2014.3001.5501

4.14.2. containerd环境安装

所有主机均需要操作

部署containerd依赖插件

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

添加docker-ce源地址（若当前环境中Docker环境已完成配置，请忽略该步骤)

yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

配置 containerd

cat >>/etc/modules-load.d/containerd.conf <<EOF
 Overlay
 br_netfilter
EOF

说明：

overlay 是一个文件系统类型，它支持在不改变底层文件的情况下，将改动保存在另一个分离的文件层。它常用于 Docker 和其他容器运行时中，用来创建容器的文件系统。（写时复制）

br_netfilter 是一个网络相关的内核模块，它允许 iptables 和其他网络工具对桥接流量进行过滤。这在 Kubernetes 网络设置中很重要，特别是在使用 overlay 网络（如 flannel、Calico 等）时。

确保br_netfilter加载成功，否则在部署网络Caclico时，最后pod绑定时将失败，无法完成部署。

查看br_netfilter加载情况（显示如下则直接部署containerd）

lsmod | grep br_netfilter
#br_netfilter           22256  0 
#bridge                155432  2 br_netfilter,ebtable_broute

立刻加载 overlay模块**（若当前系统已加载，请忽略当前步骤）**

modprobe overlay

立刻加载 br_netfilter模块**（若当前系统已加载，请忽略当前步骤）**

modprobe br_netfilter

安装containerd

yum install containerd.io -y

4.14.3. containerd配置及优化

Containerd安装完成后，其自带的配置文件/etc/containerd/config.toml中的内容，需要用打印出的containerd默认配置替换。

（1）Containerd的Cgroup设为systemd，以和k8s默认的Cgroup保持一致。

（2）pause镜像路径改为国内源registry.aliyuncs.com/google_containers/pause:3.9。

#备份原始配置文件config.toml，若文件不存在则忽略该步骤；并执行“mkdir -p /etc/containerd”创建containerd的默认配置文件夹；
cp /etc/containerd/config.toml /etc/containerd/config.toml.ori
#生成containerd的默认配置存放在config.toml下
containerd config default > /etc/containerd/config.toml
# 使用systemd管理cgroups
sed -i '/SystemdCgroup/s/false/true/g' /etc/containerd/config.toml
# 配置sadnbox image从阿里云拉取并修改下载版本为pause:3.9
sed -i 's#sandbox_image = "registry.k8s.io/pause:3.6"#sandbox_image = "registry.aliyuncs.com/google_containers/pause:3.9"#' /etc/containerd/config.toml

若只修改image拉取镜像地址，则执行下面命令将镜像由k8s官网变更为阿里云镜像，（建议变更pause的镜像版本）

sed -i '/sandbox_image/s/registry.k8s.io/registry.aliyuncs.com\/google_containers/g' /etc/containerd/config.toml

配置后，启动containerd服务，并保证containerd状态正确

#containerd服务启动
systemctl start containerd.service
#containerd服务查看
systemctl status containerd.service
#containerd设置为开机自启动
systemctl enable containerd.service

验证containerd管理命令

ctr --version
#ctr containerd.io 1.6.33

如上显示，则表明containerd部署完成且管理命令正常使用。

4.15. containerd管理工具

containerd 是一个开源的高性能的容器运行时，提提供了丰富的 API 用于管理容器生命周期、镜像和存储等。为了方便用户与 containerd 交互，社区和 containerd 本身提供了一些工具。并非唯一管理工具，以下是常用与 containerd 交互的工具及部署方法，请根据个人习惯进行选者管理工具，优先选择crictl或nerdctl

4.15.1. ctr命令行工具

ctr 是 containerd 自带的命令行工具，用于直接与 containerd 交互。它主要用于开发和调试。

4.15.1.1. ctr安装

ctr 通常随 containerd 一起安装，因此无需单独安装。安装 containerd 后即可使用 ctr。

4.15.1.2. 配置优化

ctr工具与containerd 一起部署安装，无需做特殊配置，containerd正常部署之后，ctr工具则可以正常使用。

4.15.1.3. 使用方法

本章节列举了ctr 日常使用命令，以便方便大家学习使用。

帮助和版本信息

#查看命令帮助，及相关参数说明
ctr --help
#查看ctr命令版本
ctr version

镜像操作

#列出镜像：
ctr images list
#拉取镜像：
ctr images pull docker.io/library/nginx:latest
#删除镜像：
ctr images rm docker.io/library/nginx:latest

容器管理

#创建并运行容器：
ctr run --rm -t docker.io/library/nginx:latest mynginx /bin/bash
#列出容器：
ctr containers list
#删除容器:
ctr containers delete mynginx

任务和进程管理

#启动任务（容器）：ctr tasks start mynginx#查看任务列表：ctr tasks list#杀死任务：ctr tasks kill mynginx

4.15.2. nerdctl命令行工具

nerdctl 是一个与 docker cli 风格兼容的 containerd 客户端工具，而且直接兼容 docker compose 的语法的，使用nerdctl 提高了直接将 containerd 作为本地开发、测试或者单机容器部署使用的效率。对于早期docker熟练的执行者优先考虑部署该工具。

4.15.2.1. nerdctl 安装

安装包获取

访问 nerdctl 的 GitHub Releases 页面（https://github.com/containerd/nerdctl/），下载适合当前系统的二进制文件。建议选择最新版部署安装。

# 如果没有安装 containerd，则可以下载 nerdctl-full-<VERSION>-linux-amd64.tar.gz 包进行安装，建议部署最新版，具体版本请查询获取，例如部署1.7.6版本
wget https://github.com/containerd/nerdctl/releases/download/v1.7.6/nerdctl-1.7.6-linux-amd64.tar.gz

nerdctl 部署

#创建nerdctl 解压路径，并解压nerdctl-1.7.6-linux-amd64.tar.gz
mkdir -p /usr/local/nerdctl && tar -zxvf nerdctl-1.7.6-linux-amd64.tar.gz -C /usr/local/nerdctl
# 将nerdctl 部署为系统命令
cd /usr/local/nerdctl && cp nerdctl /usr/local/bin/
#为nerdctl增加执行权限
chmod +x /usr/local/bin/nerdctl
#验证nerdctl 部署是否成功
nerdctl version

或直接将/usr/local/nerdctl下的nerdctl软连接到/usr/local/bin/下，根据个人习惯进行配置。

#为nerdctl创建软连接#ln -s /usr/local/containerd/bin/nerdctl /usr/local/bin/nerdctl

4.15.2.2. 配置优化

nerdctl 是一种用于容器管理的命令行工具，与 Docker 类似，但专注于使用容器d（containerd）作为容器运行时。优化 nerdctl 命令的使用，可以提高操作效率、资源利用率和容器管理的灵活性。以下是一些优化建议：

①使用正确的基础镜像

选择合适的基础镜像可以显著减少镜像大小和构建时间。例如，使用 Alpine 或者其他精简版的操作系统镜像

nerdctl run -it --name my-container alpine:latest

②优化容器启动性能

使用 --entrypoint 和 CMD 指令来优化启动脚本。通过直接在启动时指定命令，可以减少容器启动时间。

nerdctl run -it --name my-container --entrypoint "/bin/sh" my-image

③资源限制

为容器设置 CPU 和内存限制，避免资源过度使用。

nerdctl run -it --name my-container --cpus="1.5" --memory="500m" my-image

④使用多阶段构建*

多阶段构建可以显著减少最终镜像的大小，保留必要的文件和依赖。（dockerfile实例）

# First stage: build the application
FROM golang:1.16 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp .

# Second stage: create a minimal image
FROM alpine:latest
WORKDIR /app
COPY --from=builder /app/myapp .
CMD ["./myapp"]

⑤执行部署镜像

nerdctl build -t my-image .

⑥优化网络性能

利用 --network 选项选择适当的网络模式，优化网络性能。

nerdctl run -it --name my-container --network=host my-image

⑦持久化数据

使用 -v 选项挂载卷，持久化容器中的数据。

nerdctl run -it --name my-container -v /host/path:/container/path my-image

⑧安全性

使用 --security-opt 选项强化容器的安全性。

nerdctl run -it --name my-container --security-opt no-new-privileges my-image

⑨日志管理

使用 --log-driver 和 --log-opt 选项来管理日志的存储和轮转，优化日志性能。

nerdctl run -it --name my-container --log-driver json-file --log-opt max-size=10m my-image

通过这些优化建议，你可以更高效地使用 nerdctl 来管理和运行容器。根据实际需求调整这些选项，可以进一步优化性能和资源利用。

4.15.2.3. 使用方法

本章节列举了nerdctl 日常使用命令，以便方便大家学习使用。

帮助和版本信息

#查看命令帮助，及相关参数说明
nerdctl --help
#查看nerdctl 命令版本
nerdctl version

镜像操作

#列出镜像：
nerdctl images
#拉取镜像：
nerdctl pull nginx:latest
#删除镜像：
nerdctl rmi nginx
#镜像标签
nerdctl tag
#导出镜像
nerdctl save -o xxx.tar xxx
#导入镜像
nerdctl load -i xxx.tar

容器管理

#创建并运行容器：
nerdctl run -d --name nginx nginx:latest
#列出容器：
nerdctl ps
#删除容器:
nerdctl rm -f nginx
#获取容器的详细信息
nerdctl inspect nginx
#获取容器日志
nerdctl logs -f nginx

网络和卷管理

#创建网络（容器）：
nerdctl network create mynetwork
#创建卷：
nerdctl volume create myvolume

4.15.3. crictl命令行工具

crictl是遵循CRI接口规范的一个命令行工具，用于与符合 Kubernetes 容器运行时接口（CRI, Container Runtime Interface）标准的容器运行时进行交互。它可以用于查看和管理 Kubernetes 集群中的容器和镜像，是调试 Kubernetes 中容器问题的有用工具。

crictl 的主要功能

容器管理：查看、启动、停止、删除容器。
镜像管理：列出、拉取、删除镜像。
日志查看：查看容器的日志，帮助诊断和解决问题。
执行命令：在容器内部执行命令，类似于 docker exec 或 kubectl exec。
调试和排错：提供详细的容器和沙箱（Pod）信息，如状态、资源使用等，帮助调试问题。

crictl工具不是k8s镜像管理的唯一工具，每个工具都有其特定的功能和用途，下列就列举几款常见的管理工具：

crictl: 适用于与 CRI 兼容的容器运行时直接交互。
ctr: 提供对 containerd 的底层操作。
docker 和 podman: 适用于本地镜像构建和管理，尤其是在开发环境中。
skopeo 和 kaniko: 适用于镜像复制、构建和推送，尤其是在 CI/CD 环境中。
img: 提供容器镜像构建和推送功能，适用于无 Docker 环境。
kubectl: 用于部署和管理 Kubernetes 中的容器和镜像。

这些工具可以根据具体的需求和环境选择使用，有时可能需要多个工具配合使用。

4.15.3.1. crictl安装

要安装 crictl，你可以从官方 GitHub releases 页面下载适合你操作系统的版本。以下是一个示例安装步骤：

下载 crictl 二进制文件：

VERSION="vX.XX.X"  # 将X.XX.X替换为所需版本
curl -LO https://github.com/kubernetes-sigs/cri-tools/releases/download/${VERSION}/crictl-${VERSION}-linux-amd64.tar.gz

对于crictl命令行，建议部署最新或与部署k8s相同或相近版本。以保证最优的兼容性，本案件k8s部署v1.28，所以选择crictl的1.28版本。

crictl命令无非加载本地镜像，当需要加载本地镜像时请结合ctr命令进行部署。在ctr加载镜像时，需考虑到命名空间namespace。

解压并移动到可执行路径：

sudo tar zxvf crictl-${VERSION}-linux-amd64.tar.gz -C /usr/local/bin

4.15.3.2. 配置优化

crictl下载镜像时使用的默认端点（endpoint）是/var/run/dockershim.sock，这个已经在k8s v1.24起被废弃，需要我们手工指定为新的端点containerd.sock。

重新指定的工作需要通过配置/etc/crictl.yaml来完成。

# 创建配置文件
cat <<EOF | tee /etc/crictl.yaml
runtime-endpoint: unix:///run/containerd/containerd.sock
image-endpoint: unix:///run/containerd/containerd.sock
timeout: 10
debug: true
EOF
#查看crictl.yaml文件内容
cat  /etc/crictl.yaml

4.15.3.3. 使用方法

本章节列举了nerdctl 日常使用命令，以便方便大家学习使用。

帮助和版本信息

#查看命令帮助，及相关参数说明
crictl --help
#查看crictl命令版本
crictlversion

镜像操作

#列出镜像：
crictl images
#拉取镜像：
crictl pull nginx:latest
#删除镜像：
crictl rmi
#查看容器镜像详细信息（70f5e18fddce8为镜像ID）
crictl inspecti 70f5e18fddce8

容器管理

#列出容器：
crictl ps
#查看容器详细信息（5389d4e04a974为podID）
crictl inspect 5389d4e04a974

Pod管理

#查看运行中的pod
crictl pods
#查看容器详细信息（eea1584366c1d为podID）
crictl inspectp eea1584366c1d

4.15.4. 命令行工具对比

docker、ctr、nerdctl 和 crictl 都是与容器管理相关的命令行工具，但它们有不同的用途和目标。

4.15.4.1. 工具简介

Docker: 最广泛使用的容器管理工具，提供了从镜像管理到容器运行的全套功能。它使用 Docker Engine 作为容器运行时。

ctr: containerd 自带的低级命令行工具，主要用于开发和调试。它直接与 containerd 交互，提供了容器和镜像的基本操作。

nerdctl: 一个与 Docker CLI 兼容的工具，专为 containerd 设计。它提供了类似 Docker 的命令体验，适合熟悉 Docker 的用户。

crictl: 专为 Kubernetes CRI 兼容的容器运行时（如 containerd、CRI-O 等）设计的通用命令行工具，主要用于与 Kubernetes 集成的容器操作。

4.15.4.2. 命令对比

基础命令

操作	Docker	ctr	nerdctl	crictl
版本信息	docker version	ctr version	nerdctl version	crictl version
帮助信息	docker --help	ctr --help	nerdctl --help	crictl --help

镜像管理

操作	Docker	ctr	nerdctl	crictl
拉取镜像	docker pull	ctr images pull	nerdctl pull	crictl pull
列出镜像	docker images	ctr images list	nerdctl images	-
删除镜像	docker rmi	ctr images rm	nerdctl rmi	-
导出镜像	docker save -o	ctr images export	nerdctl save -o	-
导入镜像	docker load -i	ctr images import	nerdctl load -i	-

容器管理

操作	Docker	ctr	nerdctl	crictl
运行容器	docker run	ctr run	nerdctl run	crictl runp (Pod)
列出容器	docker ps	ctr containers list	nerdctl ps	crictl ps
停止容器	docker stop	ctr tasks kill	nerdctl stop	-
删除容器	docker rm	ctr containers delete	nerdctl rm	crictl stopp <pod_id> && crictl rmp <pod_id>
查看容器日志	docker logs	-	nerdctl logs	crictl logs <container_id>

网络和卷管理

操作	Docker	ctr	nerdctl	crictl
创建网络	docker network create	-	nerdctl network create	-
列出网络	docker network ls	-	nerdctl network ls	-
删除网络	docker network rm	-	nerdctl network rm	-
创建卷	docker volume create	-	nerdctl volume create	-
列出卷	docker volume ls	-	nerdctl volume ls	-
删除卷	docker volume rm	-	nerdctl volume rm	-

4.15.4.3. 工具选择指南

Docker: 最适合那些已经熟悉 Docker 生态系统并需要完整解决方案的用户。提供从开发到生产的全流程工具链。

ctr: 主要用于开发者和高级用户的调试和低级操作。它提供了对 containerd 的直接访问，但没有 Docker 那样的高级功能。

nerdctl: 适合那些想要使用 containerd 而仍然希望保持与 Docker 类似的命令体验的用户。它对 containerd 的使用体验进行了包装，使其更易于 Docker 用户迁移。

crictl: 主要用于与 Kubernetes 集成的场景，专注于容器运行时的调试和操作。它与 Kubernetes 的 CRI 接口兼容，适合 Kubernetes 管理员和开发人员。

4.15.4.4. 工具选择总结

四种工具各有优缺点，选择哪种工具主要取决于具体需求、使用场景和环境。对于Docker老玩家，在K8s版本在v1.24版本以上nerdctl工具更加友好，但对于在K8s集群中便于与镜像管理那么crictl则性能则更加。所以在实际使用请根据实际情况合理的选择对于命令行管理工具。本实例使用crictl命令行工具。

4.16. crictl部署

本实例使用crictl作为containerd和k8s的管理工具，在命令安装部署前首先明确服务器中是否已经部署crictl，使用“crictl versin”查看当前crictl版本，若显示“bash: crictl: command not found…”说明命令不存在，则直接按如下步骤进行crictl命令部署，若执行“crictl versin”后报错，则优先检查/etc/crictl.yaml文件，文件不存在则直接创建，若文件存在请核对/etc/crictl.yaml文件内容。

具体步骤

①下载crictl二进制安装包（建议部署与k8s相同版本，降低由于版本不同而引发兼容性问题）

VERSION="v1.28.0"  
curl -LO https://github.com/kubernetes-sigs/cri-tools/releases/download/${VERSION}/crictl-${VERSION}-linux-amd64.tar.gz

②核查文件完整性

“crictl-v1.28.0-linux-amd64.tar.gz”文件大小大约为23M，官网sha值比对文件完整性，文件末尾为9ef2508

#查看文件大小
du -sh crictl-v1.28.0-linux-amd64.tar.gz 
#sha值比较
sha256sum crictl-v1.28.0-linux-amd64.tar.gz

在这里插入图片描述

③解压

创建crictl解压路径并解压tar包

#路径/home/kube下创建crictl解压路径
mkdir /home/kube/crictl
#解压文件
tar -zxvf crictl-v1.28.0-linux-amd64.tar.gz -C /home/kube/crictl

④文件权限修改

#修改crictl命令数组，将文件权限赋予k8s启动用户（根据实际情况修改）
chown -R kube.users crictl 
#赋予当前命令执行和查看权限
chmod 755 crictl

⑤部署系统命令

cp /home/kube/crictl/crictl /usr/local/bin

⑥创建指定的工作需要的配置文件/etc/crictl.yaml

# 创建配置文件
cat <<EOF | tee /etc/crictl.yaml
runtime-endpoint: unix:///run/containerd/containerd.sock
image-endpoint: unix:///run/containerd/containerd.sock
timeout: 10
debug: true
EOF
#查看crictl.yaml文件内容
cat  /etc/crictl.yaml

在这里插入图片描述

⑦验证crictl命令

#查看部署crictl版本crictl version#查看命令帮助crictl -help

在这里插入图片描述

4.17. Kuberneters部署

通过不懈努力，基础环境终于准备完成，下面开始正式部署K8S环境。

下面的操作所有K8s宿主节点全部执行，后面如果要给集群新增节点也要做这个操作

4.17.1. 新增YUM源-K8S

新增k8s的yum源，配置如下：

cat <<EOF > /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

参数说明：

[kubernetes]：这是 YUM 源的名称，用于在配置文件中标识这个部分的作用域。

name=Kubernetes：指定了 YUM 源的名称，通常用于显示在 YUM 的列表中。

baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/：

baseurl 指定了 YUM 源的基础 URL，即 YUM 应该从这个 URL 下载软件包。在这里，https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/ 是 Kubernetes 软件包在阿里云镜像的地址，适用于 CentOS 7 x86_64 架构。

enabled=1：

enabled 表示该 YUM 源是否启用。
值为 1 表示启用，即 YUM 在执行更新或安装时将会检查该源。

gpgcheck=0：

gpgcheck 控制 YUM 是否验证下载的软件包的 GPG 签名。
值为 0 表示禁用 GPG 签名检查，即 YUM 不会验证下载的软件包的合法性。

repo_gpgcheck=0：

repo_gpgcheck 控制 YUM 是否验证仓库的 GPG 签名。
值为 0 表示禁用仓库的 GPG 签名检查，即 YUM 不会验证从该仓库下载软件包的合法性。

gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg 和 https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg：

gpgkey 指定了用于验证软件包和仓库的 GPG 密钥的 URL。
这里列出了两个 GPG 密钥的 URL，分别用于验证仓库和软件包。

由于国内谷歌源限制，无法连接国外地址，所以不要使用k8s官网，若存在VPN可以尝试使用，源k8s的repo地址如下（在国内不建议使用）：

[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.28/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.28/rpm/repodata/repomd.xml.key
exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni

4.17.2. K8S组件（kubeadm、kubelet、kubectl）安装

查询可安装的kubeadm、kubelet、kubectl版本

#检查支持部署的kubelet有那些版本
yum list available '*kubelet*'
#检查支持部署的kubeadm有那些版本
yum list available '*kubeadm*'
#检查支持部署的kubectl有那些版本
yum list available '*kubectl*'
#列出所有可用的 kubelet 包及其版本，同时按降序排列（最新的版本在最前面）
yum list kubelet --showduplicates | sort -r
yum list kubeadm --showduplicates | sort -r
yum list kubectl --showduplicates | sort -r

在这里插入图片描述

若查询结果中可部署版本存在多个，选择最新稳定版本（Stable），若查询结果如图所示，则可以执行执行下面命令进行安装：

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

若查询结果中存在多个可部署版本，则可指定版本进行安装

yum install -y install kubeadm-1.28.0-0 kubelet-1.28.0-0 kubectl-1.28.0-0 --disableexcludes=kubernetes

参数解析：

kubelet: Kubernetes 的节点代理，负责管理节点上的容器和 Pod 生命周期。
kubeadm: Kubernetes 的集群引导工具，用于部署 Kubernetes 集群。
kubectl: Kubernetes 命令行工具，用于与 Kubernetes 集群进行交互和管理。
–disableexcludes=kubernetes 参数确保安装过程中不会受到 kubernetes 源排除配置的影响，以便正确安装这些软件包。

4.17.3. 版本说明及注意事项

Kubernetes 版本标签说明

稳定版（Stable）*：稳定版指已经通过大规模测试并且被广泛认可在生产环境中可靠使用的版本。这些版本通常是带有主要版本号（如 1.x、1.22.x）的正式发布版。
预览版（Preview）或测试版（RC）：预览版或测试版是即将发布为稳定版的候选版本。它们可能包含新的功能和改进，但尚未经过广泛的生产环境测试。这些版本的版本号可能会带有后缀如 rc（Release Candidate）、alpha、beta 等。

注意事项

稳定性与功能：选择适当的 Kubernetes 版本时，除了考虑稳定性外，还需根据具体功能和需求做出选择。
更新策略：在生产环境中，建议使用稳定版本，并遵循适当的更新和测试策略。

4.17.4. Kubelet服务启停

设置kubelet为开机自启动即可，由于没有生成配置文件，kubelet启动会出现异常，暂时无需处理，在网络组件部署完成后，异常自动恢复

#设置kubelet开机自启动服务。并立即启动
systemctl enable kubelet --now
#查看kubelet节点状态
systemctl status kubelet
#启动kubelet节点服务
systemctl start kubelet
#停止kubelet节点服务
systemctl stop kubelet
#重启kubelet节点服务
systemctl restart kubelet

4.17.5. Kuberneters集群初始化

初始化 Kubernetes 集群通常是通过 kubeadm 工具来完成的。kubeadm 是一个官方支持的工具，用于快速引导 Kubernetes 集群。Kuberneters集群初始化需要在选定的k8s集群的master节点执行，命令如下：

kubeadm init \
  --image-repository registry.aliyuncs.com/google_containers \
  --kubernetes-version v1.28.0 \
  --apiserver-advertise-address 192.168.115.101 \
--service-cidr=10.96.0.0/12 \
  --pod-network-cidr=10.244.0.0/16 \
  --token-ttl 0 \
--ignore-preflight-errors=all

参数说明：

--image-repository registry.aliyuncs.com/google_containers

使用阿里云的镜像仓库来拉取 Kubernetes 相关的镜像，解决国内访问 Google Container Registry 困难的问题。

–kubernetes-version v1.28.2

指定要安装的 Kubernetes 版本，这里指定的是 v1.28.2。

--apiserver-advertise-address 192.168.115.101

  	<span style="color: blue;">指定 API 服务器向外广告的 IP 地址。其他节点将通过这个地址访问 API 服务器。（即master节点的宿主机地址）</span>

--service-cidr=10.96.0.0/12

指定 Kubernetes 服务的 IP 地址范围（CIDR）。默认值是 10.96.0.0/12。

--pod-network-cidr=10.244.0.0/16

指定 Pod 网络的 CIDR（Classless Inter-Domain Routing）。
--token-ttl 0

用于生成一个永不过期的 token，常用在开发和测试环境中，生产环境中不建议使用，以确保集群的安全性。

--ignore-preflight-errors=all

  	<span style="color: blue;"> 忽略初始化过程中的所有预检错误。</span>

注意：–pod-network-cidr与下面部署的CNI网络组件yaml中保持一致，和–service-cidr的IP地址不能重叠，且两者都不能与–apiserver-advertise-address的IP地址重叠

执行结果如下，则说明初始化成功

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/ima 在这里插入图片描述

记录当前token信息，该信息用于worker节点加入集群使用。若未记录当前token信息，或token信息过期（正常token有效期为24小时），可根据本文档的4.17.7重新获取token信息。

4.17.6. Kuberneters的worker节点加入

针对V1.28.2版本以上kubernters集群，环境中无需部署docker环境，其余与集群master节点保持一致，将主节点生成的token拷贝至需要加入K8s集群worker节点中执行，（确保kubelet服务已启动）加入完成后，在master节点中查看节点信息若正常，则说明添加成功。

kubeadm join 192.168.115.101:6443 --token 4tpk9h.28h37xu6ye7lhvm7 --discovery-token-ca-cert-hash sha256:e6a8259abce1f251a1e5b2bffdf593f644fa162e575f473d75315079ddf2dee2

当提示token过期时，需重新生成token或查找新的token地址，具体获取token方法请参考4.17.7章节。

4.17.7. 获取集群token方法（备用）

在 Kubernetes 中，获取集群的 token 通常用于集群扩容，将新的节点加入到现有的集群中。以下是如何生成和获取 Kubernetes 集群 token 的详细步骤。

方法一：通过 kubeadm 生成新 token

可以使用 kubeadm token create 命令来生成一个新的 token。该命令可以在集群控制的任意一个master主节点上运行。

kubeadm token create --print-join-command

这个命令将生成一个新的 token 并输出 kubeadm join 命令的完整语法，包括生成的 token 和 discovery-token-ca-cert-hash，直接复制并在工作节点上运行这个命令来加入当前集群。

方法二：查看现有的 token

查看当前已有的 token，可以使用以下命令：

kubeadm token list

该命令可以在集群控制的任意一个master主节点上运行。同时列出当前所有有效的 token 及其相关信息。

方法三：通过手动生成 token

kubeadm token create <your-token> --ttl <duration>

这里，是你想要生成的 token，是 token 的有效期，例如 24h 表示 24 小时。

获取 discovery-token-ca-cert-hash

openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | \
openssl rsa -pubin -outform der 2>/dev/null | \
openssl dgst -sha256 -hex | \
sed 's/^.* //'

通过以上步骤，你可以通过生成新的token或查看现有token ，并使用这些token 将新的节点加入到 Kubernetes 集群中。该步骤主要使用于K8s集群扩容中，方便使用，记录在这里，供集群扩容使用。

4.17.8. Kubectl配置

Kubectl为Kubernters的管理工具。将 Kubernetes 管理配置文件 (admin.conf) 复制到用户的主目录中，并确保该配置文件的权限正确设置。通过配置加载的config文件，kubectl可以在不同的k8s集群中进行切换。（该配置只需在k8s管理节点中执行，且命令通用，但需注意的是该命令是配置在当前登入用户中）

mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config

说明：

创建 .kube 目录：

mkdir -p $HOME/.kube

这行命令在用户的主目录中创建一个名为 .kube 的目录。如果该目录已经存在，-p 选项将不会报错。

复制 admin.conf 到 .kube/config：

cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

这行命令将 /etc/kubernetes/admin.conf 文件复制到用户主目录下的 .kube/config 文件中。-i 选项表示如果目标文件已经存在，cp 命令会提示用户进行确认后再覆盖。

更改 .kube/config 的所有权：

chown $(i d - u) :$ (id -g) $HOME/.kube/config

这行命令将 .kube/config 文件的所有权更改为当前用户。 $(i d - u) 获取当前用户的用户 I D ，$ (id -g) 获取当前用户的组ID。

整个过程的总结

这些命令将 Kubernetes 的管理配置文件设置为当前用户的默认配置文件。这允许用户使用 kubectl 命令来管理 Kubernetes 集群，而无需每次都指定配置文件路径。

验证配置

执行这些命令后，可以通过以下命令验证配置是否正确：

kubectl get nodes

如果配置正确并且 Kubernetes 集群正常运行，这个命令会列出集群中的节点。

4.17.9. Kubectl命令补全配置

在K8s的日常运维和管理过程中，kubectl存在大量的管理命令，单靠死记硬背难免有遗漏，在实际生产中建议配置kubectl命令补全。下面是具体的配置方法以供参考（推荐设置为永久启动）：

方法一：启用自动补全功能：

在终端中运行以下命令：

source <(kubectl completion bash)

上述仅是临时配置方法，当访问页面关闭后，在打开时，配置将失效

方法二：永久性启用自动补全功能：

将上述命令添加到你的 .bash_profile 或 .bashrc 文件中：

echo "source <(kubectl completion bash)" >> ~/.bash_profile

上述命令是针对于当前登入用户进行配置，切换至其他用户后，其他用户下无法使用命令补全，若要服务器中所有客户均具备该命令补全方法，则将配置写入到/etc/profile下，命令如下：

echo "source <(kubectl completion bash)" >> /etc/profile

运行以下命令以使更改生效：

source ~/.bash_profile

若修改的是“/etc/profile”文件，则执行如下命令：

source /etc/profile

4.18. 网络组件（Calico）部署

为更好的管理yaml文件，建议在系统中创建专属文件夹对yaml文件进行管理，本实例将所有yaml放置在/home/kube/yaml下；

#创建yaml文件管理路径
mkdir -p /home/kube/yaml

下载Calico配置文件“calico.yaml”，本次部署calico-3.26版本，请根据实际需求进行下载，（建议不低于v3.28这个版本）并在K8s管理的master主节点中执行

#下载calico的部署官方文件
cd /home/kube/yaml && wget  --no-check-certificate  https://projectcalico.docs.tigera.io/archive/v3.25/manifests/calico.yaml
#以下为执行结果显示内容
--2024-07-10 17:22:47--  https://projectcalico.docs.tigera.io/archive/v3.28/manifests/calico.yaml
Resolving projectcalico.docs.tigera.io (projectcalico.docs.tigera.io)... 46.137.195.11, 13.215.144.61, 2406:da18:880:3801::c8, ...
Connecting to projectcalico.docs.tigera.io (projectcalico.docs.tigera.io)|46.137.195.11|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 238089 (233K) [text/yaml]
Saving to: ‘calico.yaml’
100%[==============================================================================>] 238,089      438KB/s   in 0.5s   
2024-07-10 17:22:48 (438 KB/s) - ‘calico.yaml’ saved [238089/238089]

[238089/238089]为calico.yaml文件大小。

4.18.1. 修改calico.yaml如下内容

执行ip addr 查看k8s的master节点的服务网卡名称

#查看当前服务器的网卡信息 
ip a

![外链图片转存失败,源站可能在这里插入图片描述

vim calico.yaml

使用vim打开calico.yaml文件，找到如下内容，在其下方添加如下内容

原配置（大概在calico.yaml文件的第4567行）

- name: CLUSTER_TYPE
  value: "k8s,bgp"

新配置

# CLUSTER_TYPE 下方添加信息
- name: CLUSTER_TYPE
  value: "k8s,bgp" 
# 下方为新增内容 
- name: IP_AUTODETECTION_METHOD 
  value: "interface=ens33"

新增网卡绑定信息，本实验网卡名称为ens33

在这里插入图片描述

4.18.2. Calico部署必须加载的镜像

在部署Calico时，通常使用官方提供的yaml文件，该文件会指定拉取镜像的名称及版本，文件内包含成百上千行代码，如果一一查询加载镜像名称不但耗时还容易遗漏，那么如果快速简单的查看calico部署时需要那些镜像呢？

我们可以通过百度资源去查询“Calico部署需要加载那些镜像”或直接执行下列命令来获取加载镜像名称和版本。

#查看Calico部署需要那些镜像
cd /home/kube/yaml &&grep 'image:' calico.yaml
#以下为执行结果显示内容
  image: docker.io/calico/cni:v3.25.0
  image: docker.io/calico/cni:v3.25.0
  image: docker.io/calico/node:v3.25.0
  image: docker.io/calico/node:v3.25.0
  image: docker.io/calico/kube-controllers:v3.25.0

4.18.3. 部署Calico网络组件

网络环境稳定的情况下直接执行，自动拉取镜像

#开始部署calico网络服务
cd /home/kube/yaml && kubectl apply -f  calico.yaml

4.18.4. 检查Calico部署结果

查看pod创建情况(前三个为新建pod)

kubectl get pod -n kube-system
#以下为查询结果
NAME                                       READY   STATUS     RESTARTS      AGE
calico-kube-controllers-658d97c59c-rvcfp   0/1     Pending    0             12s
calico-node-9577m                          0/1     Init:0/3   0             12s
calico-node-98zc4                          0/1     Pending    0             12s
coredns-66f779496c-24r9l                   0/1     Pending    0             3d21h
coredns-66f779496c-mflkk                   0/1     Pending    0             3d21h
etcd-k8smaster                             1/1     Running    0             3d21h
kube-apiserver-k8smaster                   1/1     Running    0             3d21h
kube-controller-manager-k8smaster          1/1     Running    1 (52m ago)   3d21h
kube-proxy-w5ljz                           1/1     Running    0             3d21h
kube-proxy-wk9tw                           1/1     Running    0             3d21h
kube-scheduler-k8smaster                   1/1     Running    1 (52m ago)   3d21h

若查询结果如下图，则说明Calico部署完成，本次K8s基于Calico网络组件环境部署完成；

在这里插入图片描述

若查询结果如下图（Init:ImagePullBackOff），则说明Calico部署过程中存在异常，需进行一步处理，具体处理步骤请参考本文档《第5章节-Calico部署失败检查及处理方法》。

在这里插入图片描述

5. Calico部署失败检查及处理方法

5.1. 镜像拉取失败，导致无法部署

首先通过“kubectl describe”获取pod启动失败原因，若显示“Error: ImagePullBackOffBackoff”说明镜像拉取失败，可以手动重新拉取镜像后在重新进行部署pod。

以pod节点calico-node-9577m为列，示例如下：

5.1.1. 查看Pod无法启动原因

查看pod无法启动的详细信息

kubectl describe pod calico-node-9577m  -n kube-system

![外链在这里插入图片描述

通过节点描述检查pod（calico-node-9577m）执行失败的最终原因：

kubectl describe pod calico-node-9577m  -n kube-system

在这里插入图片描述

通过pod描述很清晰的看出镜像“docker.io/calico/cni:v3.25.0”不存在，无法下载。

5.1.2. containerd查询镜像拉取情况

通过containerd工具进一步确认镜像“docker.io/calico/cni:v3.25.0”是否下载部署完成。若只查看某个命令空间下的镜像情况则添加“-n”参数

ctr images ls | grep docker.io/calico/cni:v3.25.0

结果如图：说明当前并无任何镜像被下载

在这里插入图片描述

补充：若要查看containerd当前部署的所有镜像，可执行下列命令

ctr images ls
crictl images

到此那么有人会说，镜像都没的如何部署Calico呢，是不是就不能部署Calico作为K8s的网络管理组件呢，其实不然，回想一下我们之前部署了Docker环境，且在V1.24.0及以前版本时，Calico是完全可以使用的。那么Docker中是否存在对应的镜像呢？于是我便在Docker镜像仓库中收索关于Calico的镜像。

5.1.3. 使用docker手动拉取镜像

参考文档中第六部分进行手动拉取镜像

5.1.4. containerd 重新导入镜像

参考文档中第七部分进行手动加载镜像

5.1.5. 重新部署Calico网络组件

①查看命名空间kube-system内pod情况

kubectl get  pod -n kube-system 
#以下为执行结果显示内容
NAME                                       READY   STATUS                  RESTARTS         AGE
calico-kube-controllers-658d97c59c-rvcfp   0/1     ContainerCreating       0                22h
calico-node-9577m                          0/1     Init:CrashLoopBackOff   39 (2m32s ago)   22h
calico-node-98zc4                          0/1     Pending                 0                22h
coredns-66f779496c-24r9l                   0/1     ContainerCreating       0                4d20h
coredns-66f779496c-mflkk                   0/1     ContainerCreating       0                4d20h
etcd-k8smaster                             1/1     Running                 1 (3h45m ago)    4d20h
kube-apiserver-k8smaster                   1/1     Running                 1 (3h45m ago)    4d20h
kube-controller-manager-k8smaster          1/1     Running                 3 (179m ago)     4d20h
kube-proxy-w5ljz                           1/1     Running                 1 (3h45m ago)    4d20h
kube-proxy-wk9tw                           1/1     Running                 0                4d19h
kube-scheduler-k8smaster                   1/1     Running                 3 (179m ago)     4d20h

在这里插入图片描述

可以看到calico-node和calico-kube-controllers拉取失败，删除部署失败的pod。

②删除拉取失败pod

cd /home/kube/yaml && kubectl delete -f calico.yaml

在这里插入图片描述

③再次查看命名空间kube-system下的pod情况如下

kubectl get pod -n kube-system

在这里插入图片描述

从查询结果看：发现calico-kube-controllers的pod无法正常删除，但该pod又无法恢复，则使用如下命令强制删除

kubectl delete pod calico-kube-controllers-658d97c59c-rvcfp -n kube-system --force 
#以下为执行结果显示内容
Warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
pod "calico-kube-controllers-658d97c59c-rvcfp" force deleted

④重新部署calico

#开始部署calico网络服务
cd /home/kube/yaml && kubectl apply -f  calico.yaml

5.1.6. 验证calico部署状态。

Kubectl get pod -n kube-system -owide

5.2. mount-bpffs”挂载异常

5.2.1. 查看失败pod原因及情况

查看当前pod的描述排查问题，最终显示如下信息

kubectl describe pod calico-node-95vzs -n kube-system
#以下为显示结果
……
Events:
  Type     Reason     Age                 From               Message
  ----     ------     ----                ----               -------
  Normal   Scheduled  21m                 default-scheduler  Successfully assigned kube-system/calico-node-95vzs to k8smaster
  Normal   Pulled     21m                 kubelet            Container image "docker.io/calico/cni:v3.25.0" already present on machine
  Normal   Created    21m                 kubelet            Created container upgrade-ipam
  Normal   Started    21m                 kubelet            Started container upgrade-ipam
  Normal   Pulled     21m                 kubelet            Container image "docker.io/calico/cni:v3.25.0" already present on machine
  Normal   Created    21m                 kubelet            Created container install-cni
  Normal   Started    21m                 kubelet            Started container install-cni
  Normal   Pulled     20m (x4 over 21m)   kubelet            Container image "docker.io/calico/node:v3.25.0" already present on machine
  Normal   Created    20m (x4 over 21m)   kubelet            Created container mount-bpffs
  Normal   Started    20m (x4 over 21m)   kubelet            Started container mount-bpffs
  Warning  BackOff    99s (x93 over 21m)  kubelet            Back-off restarting failed container mount-bpffs in pod calico-node-95vzs_kube-system(ac8c642f-3102-45d9-8d0d-f5df2e00bd63)

“BackOff” 错误通常表明 Kubernetes 中的一个容器在尝试启动时不断失败，并且 kubelet 已经进入了退避重试（Back-off）状态。从显示信息发现对于 calico-node 容器， mount-bpffs”挂载出现问题。通常可能是配置问题或所需资源不可用导致的。以下是排查问题的过程和一些可能的解决方法：

5.2.2. 检查 Pod 日志

检查失败容器的日志，以获取更多关于错误的信息

kubectl logs -n kube-system calico-node-95vzs -c mount-bpffs
#以下为显示结果
flag provided but not defined: -best-effort
Usage of Calico:
  -allocate-tunnel-addrs
    	Configure tunnel addresses for this node
  -allocate-tunnel-addrs-run-once
    	Run allocate-tunnel-addrs in oneshot mode
……
  -upgrade-windows
    	Run Windows upgrade service.
  -v	Display version
flag provided but not defined: -best-effort

日志显示问题是因为容器mount-bpffs标签中没有“-best-effort”这个标签；需要对标签做处理。

5.2.3. 处理异常标签

针对容器mount-bpffs标签中没有“-best-effort”这个标签，直接删除“-best-effort”标签，清理pod，重新拉取pod容器，即可。具体步骤如下：

原配置（大概在calico.yaml文件的第4516行）

image: docker.io/calico/node:v3.25.0
          imagePullPolicy: IfNotPresent
          command: ["calico-node", "-init", "-best-effort"]

修改后配置

image: docker.io/calico/node:v3.25.0
          imagePullPolicy: IfNotPresent
          command: ["calico-node", "-init"]

! 在这里插入图片描述

5.2.4. 重建Pod

修改后重现拉取Pod，若发现pod可以正常拉取成功，显示为“Running”则部署成功，但若是显示无进程运行，如下图显示，部署失败，检查目前使用containerd导入docker镜像的实际版本。参考本文档附录（一）中Calico与K8s版本对照表，进行Calico版本适配升级。

在这里插入图片描述

5.2.5. calico-node镜像版本查询

通过运行的pod查看日志可以获取到当前使用的镜像版本，经查询，当前calico-node的版本为3.21，不满足k8s-v1.28。需结合“附录（一）Kubelet与Calico的兼容性对照表”，对使用的calico-node进行升级

kubectl logs  -f -n kube-system calico-node-rxwdr |grep version

在这里插入图片描述

5.2.6. Calico相关镜像导入

经过阿里源查询发现目前镜像仓库中最大版本为3.21，不满足k8s-v1.28版本，对于v1.28版本的K8s至少需要calico-node版本在3.26或以上，最终在docker hub中查询到该版本镜像，下面介绍下镜像的查找以及下载过程。

Docker-hub地址：https://hub.docker.com/

在收索框中输入要收索的镜像名称，示例：收索

示例：收索部署calico/cni:v3.25.0

打开官方网站在收索框中输入“calico/cni”

在这里插入图片描述

点击进入“calico/cni”镜像仓库，选择“tag”在弹出收索框中填入“3.26”即选择所有包含3.26的“calico/cni”镜像，拷贝下载命令到数据库中执行

在这里插入图片描述

docker pull calico/cni:v3.26.4-67-gbba0a8cb7f3b

在这里插入图片描述

error pulling image configuration: download failed after attempts=6: dial tcp 199.59.149.237:443: connect: connection refused

表明无法连接docker-hub，docker-hub属于国外资源，所以我们无法正常下载，那么我们就需要寻找国内可替代的docker镜像，给大家推荐一个国内比较优秀的镜像网站（https://docker.aityp.com/），若大家有其他好的开源镜像网站，希望共享出来：

在这里插入图片描述

示例：收索部署calico/cni:v3.25.0

在收索框中输入“calico/cni:v3.25.0”同样无法按版本直接收索，显示如下；

在这里插入图片描述

在上述页面中我们可以根据我们的需求，去完善收索条件

在这里插入图片描述

在收索结果中查找需要的镜像点击进入

在这里插入图片描述

若没有与我们需要版本相同的镜像，则考虑大版本相同小版本相近且大于我们所需版本的镜像的版本（或结合“附录（一）Kubelet与Calico的兼容性对照表”下载兼容版本，并下载对应的calico.yaml文件），点击进入，获取国内下载地址如图：

在这里插入图片描述

通过上述方法下载calico所需的所有docker镜像，并通过docker tag将下载镜像修改为calico.yaml文件中需要的镜像名称（镜像版本号都必须保持一致），修改完成后，重新通过ctr导入到containerd 中，再次部署Calico网路组件

确保获取了如下三个镜像：

  docker.io/calico/cni:v3.25.0+
  docker.io/calico/node:v3.25.0+
  docker.io/calico/kube-controllers:v3.25.0+

最终导入至containerd 中的镜像及版本如下

  docker.io/calico/cni:v3.25.0
  docker.io/calico/node:v3.25.0
  docker.io/calico/kube-controllers:v3.25.0

由于在国内无非直接使用dockers hub 进行下载镜像，我们可以下载对应的国内镜像，并使用tag进行镜像重命名来获取我们要使用的镜像信息。

#docker.io/calico/kube-controllers:v3.25.0镜像
docker tag swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/calico/kube-controllers:v3.25.0 docker.io/calico/kube-controllers:v3.25.0
#docker.io/calico/cni:v3.25.0镜像
docker tag swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/calico/cni:v3.25.0 docker.io/calico/cni:v3.25.0
#docker.io/calico/node:v3.25.0镜像
docker tag swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/calico/node:v3.25.0 docker.io/calico/node:v3.25.0

containerd 重新导入镜像

参考本文档第七章节重新进行镜像导入

5.2.7. 重新部署Calico网络组件

cd /home/kube/yaml && kubectl apply -f  calico.yaml

5.2.8. 验证calico部署状态。

Kubectl get pod -n kube-system -owide

6. Docke手动加载镜像

6.1. 查看镜像信息

Docker中收索Calico相关镜像信息（在部署docker服务的主机中执行且确保docker服务被启动）

docker search calico

在这里插入图片描述

通过查询结果可以看到Docker镜像中是存在对应的镜像的，那么是否存在“docker.io/calico/cni:v3.25.0”呢？结果显示并不存在该镜像，但是存在“docker.io/calico/cni”我们都知道docker中镜像可以通过tag修改名字，为了能够部署成功我们便可以通过下载docker镜像，并修改镜像命令来获取“docker.io/calico/cni:v3.25.0”

在这里插入图片描述

但是在V1.24.0版本以后K8s底层已不在使用docker进行管理，所有我们还需要将镜像保存到本地，然后在通过containerd工具导入，才能在V1.24.0版本之后使用该镜像。

6.2. 拉取镜像

在镜像拉取前，通过官方以及第三方资料查询发现在部署Calico时，需要部署如下几个镜像：

calico/node

− 用途：负责网络路由和网络策略的实现。

− 镜像名：calico/node

− 版本示例：v3.25.0

calico/cni

− 用途：Calico 的 CNI 插件，用于管理容器网络接口。

− 镜像名：calico/cni

− 版本示例：v3.25.0

calico/kube-controllers

− 用途：Calico 的 Kubernetes 控制器，用于管理网络策略、IPAM 和其他控制平面任务。

− 镜像名：calico/kube-controllers

− 版本示例：v3.25.0

calico/pod2daemon-flexvol(可选)

− 用途：用于在 Pod 和 Calico Daemon 之间共享网络信息。

− 镜像名：calico/pod2daemon-flexvol

− 版本示例：v3.25.0

calico/typha (可选)

− 用途：用于在大规模集群中提升 Calico 的性能和可扩展性。

− 镜像名：calico/typha

− 版本示例：v3.25.0

通过docker查询发现上述镜像均存在，但无对应版本则最终拉取镜像命令如下

docker pull calico/node
docker pull calico/cni
docker pull calico/kube-controllers
docker pull calico/pod2daemon-flexvol
docker pull calico/typha

在这里插入图片描述

查询镜像拉取最终结果

#查看镜像部署情况
docker images
#以下为执行结果显示内容
REPOSITORY                  TAG       IMAGE ID       CREATED       SIZE
calico/node                 latest    9b7965ed4504   2 years ago   214MB
calico/pod2daemon-flexvol   latest    0d3b19c2d4d5   2 years ago   21.3MB
calico/cni                  latest    2c8aa43a8d6d   2 years ago   239MB
calico/kube-controllers     latest    5235846386af   2 years ago   132MB
calico/typha                latest    cdfbea6501a9   3 years ago   52.8MB

6.3. Docker镜像重命名

使用tag对需要镜像重新命名，以确保符合k8s使用

#将下载镜像标签均改为v3.25版本
docker tag calico/node:latest calico/node:v3.25.0

docker tag calico/pod2daemon-flexvol:latest calico/pod2daemon-flexvol:v3.25.0 

docker tag calico/cni:latest calico/cni:v3.25.0

docker tag calico/kube-controllers:latest calico/kube-controllers:v3.25.0

docker tag calico/typha:latest calico/typha:v3.25.0
#列出镜像，验证新的标签
docker images
#以下为执行结果显示内容
REPOSITORY                  TAG       IMAGE ID       CREATED       SIZE
calico/node                 latest    9b7965ed4504   2 years ago   214MB
calico/node                 v3.25.0   9b7965ed4504   2 years ago   214MB
calico/pod2daemon-flexvol   latest    0d3b19c2d4d5   2 years ago   21.3MB
calico/pod2daemon-flexvol   v3.25.0   0d3b19c2d4d5   2 years ago   21.3MB
calico/cni                  latest    2c8aa43a8d6d   2 years ago   239MB
calico/cni                  v3.25.0   2c8aa43a8d6d   2 years ago   239MB
calico/kube-controllers     latest    5235846386af   2 years ago   132MB
calico/kube-controllers     v3.25.0   5235846386af   2 years ago   132MB
calico/typha                latest    cdfbea6501a9   3 years ago   52.8MB
calico/typha                v3.25.0   cdfbea6501a9   3 years ago   52.8MB

在这里插入图片描述

6.4. 将修改好的Docker镜像下载到本地

docker save -o calico-node-v3.25.0.tar calico/node:v3.25.0

docker save -o calico-pod2daemon-flexvol-v3.25.0.tar calico/pod2daemon-flexvol:v3.25.0

docker save -o calico-cni-v3.25.0.tar calico/cni:v3.25.0

docker save -o calico-kube-controllers-v3.25.0.tar calico/kube-controllers:v3.25.0

docker save -o calico-typha-v3.25.0.tar calico/typha:v3.25.0

上述是将每个镜像单独打包成独立镜像，也可将上述五个镜像打包成一个tar包，具体命令如下：

docker save -o calico-images.tar calico/node:v3.25.0 calico/pod2daemon-flexvol:v3.25.0 calico/cni:v3.25.0  calico/kube-controllers:v3.25.0  calico/typha:v3.25.0

7. containerd手动加载docker镜像

将下载好的calico镜像导入到containerd中。便于接下来在Kubernetes 集群中使用这个镜像

以calico：v3.25依赖版本为例

7.1. 镜像导入containerd

使用ctr将下载好的Docker镜像加载到containerd中

ctr -n k8s.io images import calico-cni-v3.25.0.tar
#以下为执行结果显示内容
unpacking docker.io/calico/cni:v3.25.0 (sha256:712c5525da3ba881705a811ad5b82a98fcfe21f401cfad9b0c629a0692ef2092)...done
ctr -n k8s.io images import calico-kube-controllers-v3.25.0.tar 
#以下为执行结果显示内容
unpacking docker.io/calico/kube-controllers:v3.25.0 (sha256:3c3b6ca8c6fe2d5564c51a8022747e062b5642282945885931c5cb912db2adfc)...done
ctr -n k8s.io images import calico-node-v3.25.0.tar 
#以下为执行结果显示内容
unpacking docker.io/calico/node:v3.25.0 (sha256:1091a76be0beb2335d290d5f50fd27bfb02884c959633ef2e08123373e0defd8)...done
ctr -n k8s.io images import calico-pod2daemon-flexvol-v3.25.0.tar
#以下为执行结果显示内容
unpacking docker.io/calico/pod2daemon-flexvol:v3.25.0 (sha256:e6399daf84bfd971f345906a8ecfb688bbf6003885870da40cceed0ade26dd07)...done
ctr -n k8s.io images import calico-typha-v3.25.0.tar 
#以下为执行结果显示内容
unpacking docker.io/calico/typha:v3.25.0 (sha256:9369871def51e3ce4bc2a30021eb23148b650a05dd2698a7004adc86055098dd)...done

若获取的本地镜像打包在一个tar包中，那么直接执行下列命令即可将镜像全部加载到containerd中

ctr -n k8s.io images import calico-images.tar 
#以下为执行结果显示内容
unpacking docker.io/calico/typha:v3.25.0 (sha256:9369871def51e3ce4bc2a30021eb23148b650a05dd2698a7004adc86055098dd)...done
unpacking docker.io/calico/node:v3.25.0 (sha256:1091a76be0beb2335d290d5f50fd27bfb02884c959633ef2e08123373e0defd8)...done
unpacking docker.io/calico/pod2daemon-flexvol:v3.25.0 (sha256:e6399daf84bfd971f345906a8ecfb688bbf6003885870da40cceed0ade26dd07)...done
unpacking docker.io/calico/cni:v3.25.0 (sha256:712c5525da3ba881705a811ad5b82a98fcfe21f401cfad9b0c629a0692ef2092)...done
unpacking docker.io/calico/kube-controllers:v3.25.0 (sha256:3c3b6ca8c6fe2d5564c51a8022747e062b5642282945885931c5cb912db2adfc)...done

7.2. 查看镜像加载情况

在containerd中查看docker镜像是否加载成功

ctr -n k8s.io images ls|grep v3.25.0
#以下为执行结果显示内容
docker.io/calico/cni:v3.25.0                                                                                                            application/vnd.oci.image.manifest.v1+json                sha256:712c5525da3ba881705a811ad5b82a98fcfe21f401cfad9b0c629a0692ef2092 228.6 MiB linux/amd64                                                                   io.cri-containerd.image=managed                                 
docker.io/calico/kube-controllers:v3.25.0                                                                                               application/vnd.oci.image.manifest.v1+json                sha256:3c3b6ca8c6fe2d5564c51a8022747e062b5642282945885931c5cb912db2adfc 126.9 MiB linux/amd64                                                                   io.cri-containerd.image=managed                                 
docker.io/calico/node:v3.25.0                                                                                                           application/vnd.oci.image.manifest.v1+json                sha256:1091a76be0beb2335d290d5f50fd27bfb02884c959633ef2e08123373e0defd8 208.2 MiB linux/amd64                                                                   io.cri-containerd.image=managed                                 
docker.io/calico/pod2daemon-flexvol:v3.25.0                                                                                             application/vnd.oci.image.manifest.v1+json                sha256:e6399daf84bfd971f345906a8ecfb688bbf6003885870da40cceed0ade26dd07 20.4 MiB  linux/amd64                                                                   io.cri-containerd.image=managed                                 
docker.io/calico/typha:v3.25.0                                                                                                          application/vnd.oci.image.manifest.v1+json                sha256:9369871def51e3ce4bc2a30021eb23148b650a05dd2698a7004adc86055098dd 50.4 MiB  linux/amd64                                                                   io.cri-containerd.image=managed

在这里插入图片描述

7.3. crictl命令使用异常

“ctr”命令仅作为containerd的管理命令，但是针对于k8s无法进行直接管理，在k8s中，需使用“crictl”命令，若使用“ctr”命令将镜像加载完成，通过“ctr”命令正常查询时，我们还需使用“crictl ps”进行查询，若遇到下面相似的问题那么请按如下方法重新进行crictl命令配置及优化。

#crictl ps
WARN[0000] runtime connect using default endpoints: [unix:///var/run/dockershim.sock 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. 
WARN[0000] image connect using default endpoints: [unix:///var/run/dockershim.sock 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. 
E0717 11:11:39.565237   18144 remote_runtime.go:390] "ListContainers with filter from runtime service failed" err="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial unix /var/run/dockershim.sock: connect: no such file or directory\"" filter="&ContainerFilter{Id:,State:&ContainerStateValue{State:CONTAINER_RUNNING,},PodSandboxId:,LabelSelector:map[string]string{},}"
FATA[0000] listing containers: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial unix /var/run/dockershim.sock: connect: no such file or directory"

在这里插入图片描述

①查看“crictl”命令是否安装

通过查询命令版本来验证，若查到版本则说明安装完成，若显示“bash: crictl: command not found…”则说明crictl命令未安装，请按安装步骤进行部署安装

crictl --version
#crictl version v1.26.0

②crictl命令配置及优化

# 创建配置文件
cat <<EOF | tee /etc/crictl.yaml
runtime-endpoint: unix:///run/containerd/containerd.sock
image-endpoint: unix:///run/containerd/containerd.sock
timeout: 10
debug: true
EOF
#查看crictl.yaml文件内容
cat  /etc/crictl.yaml

在这里插入图片描述

③再次验证crictl命令是否配置成功

crictl info

在这里插入图片描述

④使用 crictl ps 查看正在运行的容器

crictl ps

在这里插入图片描述

⑤使用 crictl images 查看镜像加载情况

crictl images

在这里插入图片描述

到此镜像手动加载完成。

8. 总结

本案例部署过程中，部署Calico时踩坑，主要在Calico相关镜像与部署K8s版本不兼容问题，在Calico拉取镜像时，由于阿里的docker镜像源并没有calico.yaml文件中需要的镜像版本，通过tag修改，并未考虑镜像的实际版本，最终导致部署失败，经过不懈努力，和多方资料查找，最终部署完成，完成后整理本文档，方便后续K8s爱好者和IT小白学习K8s提供学习资料。

kevin·zhao &&

关注

5
点赞
踩
13

收藏

觉得还不错? 一键收藏
打赏
0
评论
Kubernetes1.28+Calico3.25 基于Centos7部署保姆级详细步骤

本案例部署过程中，部署Calico时踩坑，主要在Calico相关镜像与部署K8s版本不兼容问题，在Calico拉取镜像时，由于阿里的docker镜像源并没有calico.yaml文件中需要的镜像版本，通过tag修改，并未考虑镜像的实际版本，最终导致部署失败，经过不懈努力，和多方资料查找，最终部署完成，完成后整理本文档，方便后续K8s爱好者和IT小白学习K8s提供学习资料。
复制链接

扫一扫