OpenEular23.09（欧拉）操作系统为企业搭建独立的K8S集群环境，详细流程+截图

win10，vmware16 pro，openeular23.09，linux内核 6.4.0-10.1.0.20.oe2309.x86_64，

docker-engine 2:18.09.0-328，kubernetes 1.25.3，containerd 1.6.22，calico v3.25

集群模式：一主二从

单机版operEuler安装及配置按下面链接逐步操作即可；

1.节点克隆；

搭建好主节点k8s-master01，先关机，再按照下图右键操作，克隆出两个工作节点k8s-worker02和k8s-worker03;（此时，三台虚拟机的账户，密码，IP，网络等信息都是一样的）

2.修改两个工作节点的主机名和IP；

修改k8s-woker02节点的IP；

定位到指定目录命令：

编辑命令：

k8s-woker02：192.168.91.101

k8s-worker03节点的操作与上面相同；

k8s-worker03：192.168.91.102

3.网络相关重要配置检查一遍，一般没啥问题，眼过一遍即可；

两个worker节点都看一遍；

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.91.100 k8s-master01
192.168.91.101 k8s-worker02
192.168.91.102 k8s-worker03

关闭防火墙：

禁止开机自启：

查看防火墙状态：

修改SELinux配置需要所有主机重启操作系统。

最小化安装系统需要安装ntpdate软件，此处安装的是服务器版本，带有update软件，直接使用即可；

安装命令：

编辑同步时间规则命令：

0 */1 * * * /usr/sbin/ntpdate time1.aliyun.com

开启内核路由转发命令：

（截图中命令显示两次，是我测试命令可用后，二次截图的操作）

配置内核参数，将桥接的IPv4流量传递到iptables的链的命令：（创建新文件+编辑内容）

执行该命令，如果不执行就会在应用k8s.conf时出现加载错误；

使用新添加配置文件生效；

或下面命令：

回车，安装过程如下；

配置ipvsadm模块加载方式，添加需要加载的模块；

授权、运行、检查是否加载；

方法一：

方法二：

本案例采用方法二；

1.查看是否存在docker软件；

2.安装docker；

3.设置docker开机启动并启动；

4.查看docker版本；

1.所有主机安装k8s依赖，连接跟踪；

2.k8s-master01节点安装；

3.k8s-worker02和k8s-worker03两个节点安装；

k8s-worker02

k8s-worker03

4.所有主机设置开机自启kubelet；

K8S通过kubeadm安装出来以后都是以Pod方式存在，即底层是以容器方式运行，所以kubelet必须设置开机自启。

5.所有主机现在启动kubelet.service；

6.所有主机查看kubelet运行状态;

所有主机重启kubelet；

排查 hostname、etc/hosts等均正常。

错误一：“crictl not found in system path”；

（重要提醒：此处只在master节点安装crictl，后面在k8s集群初始化完成后，执行worker节点加入master时，报错worker找不到crictl，所以全部主机都必须安装crictl。）

需要安装crictl工具；（建议所有主机都要安装crictl，后面都会用到）

错误二：“socat not found in system path”；

需要安装socat工具；

错误三：[ERROR CRI]: container runtime is not running: output: time="2023-12-29T08:16:11+08:00" level=fatal msg="unable to determine runtime API version: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial unix /var/run/cri-dockerd.sock: connect: no such file or directory""
, error: exit status 1

 （重点注意：此处只在master节点安装containerd，推荐在所有节点都安装containerd，因为worker节点加入master时，需要用到containerd。）

问题定位：

1.“container runtime is not running”，containerd服务未启动，查阅containerd运行状态；

2.提示未找到containerd.service，需要安装containerd.service；

3.yum安装containerd失败原因分析：

（1）k8s 1.24之后弃用了docker-shim。

dockershim 的作用是 Kubernetes 通过 CRI 来操作 Docker，所以Kubernetes 任何的功能变动或 Docker 有任何的功能特性变更，dockershim 代码必须加以改动保证能够支持相关的变更（维护特别不方便）。

        另外，Docker 的底层运行时是 containerd（大家装docker的时候应该也会发现有containerd这样几个东西），最终都是要调用 containerd且 containerd 自身也支持 CRI 。那为什么要先绕过一层 Docker 呢？是不是可以直接通过 CRI 跟 Containerd 进行交互呢？这也就造成了现在 Kubernetes 社区弃用 dockershim的原因。

（2）linux操作系统systemd的服务管理。

系统服务在/usr/lib/systemd/system目录下，名字为*.service之类的文件，systemctl可以通过文件名管理服务。这就是为什么有些systemctl 可以管理一些二进制启动的服务，linux的3.10的内核以后直接后台运行二进制程序显然不够优雅。

（3）主流的平台platform有x86(amd)，arm（aarch）等等，操作系统也是分linux/windows的。

参考cpu架构，如果不熟悉的话，还是不好记住的，特别是amd/arm这种容易混。特别注意的是，用ctr命令拉取、导入、导出镜像，是需要指定平台的，否则有时候会报相关错误，ctr也支持全平台，但是文件就比较大了。

（4）containerd的工具为ctr，k8s管理containerd的工具为crictl。

ctr是containerd的工具，它运行时，需要在ctr 紧后加入-n namespace。例如k8s的镜像是放在k8s.io的命名空间下的，你直接用ctr查看，是看不到镜像的，你需要这样才能看到：ctr -n k8s.io images list。但是可以用crictl直接查看到k8s运行的服务的镜像。

4.用二进制文件安装containerd；

（1）下载地址（本测试用的是1.6.22版本，其他版本自行选择下载）；

（2）上传，解压“cri-containerd-1.6.22-linux-amd64.tar.gz”；

上传containerd压缩包到k8s-master01节点，位置自选；

（3）解压containerd压缩包到“/usr/bin/”，或“/usr/local/bin/”；

因为这两个目录都具有系统的环境变量，可以直接运行。比如ssh命令其实就在/usr/bin/ssh

①本案例是解压到“/usr/local/bin/”，（因为该路径本来是空的，万一解压失败，回退也方便清理）；

-------------------由于参考资料不完整--------------走的一段弯路start------------------记录一下-------------

赋予它们可执行权限，4=读，2=写，1=可执行，加一起就是他的权限。

-----------------------------------------------------------弯路end---------------------------------------------------------

正确方法如下：

etc目录：主要为containerd服务管理配置文件及cni虚拟网卡配置文件；

opt目录：主要为gce环境中使用containerd配置文件及cni插件；

usr目录：主要为containerd运行时的二进制文件，包含runc；

②拷贝二进制可执行文件到中；

containerd 的安装包中一共有五个文件，通过上面的命令它们被安装到了 /usr/local/bin 目录中：

containerd：即容器的运行时，以 gRPC 协议的形式提供满足 OCI 标准的 API

containerd-release：containerd项目的发行版发布工具

containerd-stress：containerd压力测试工具

containerd-shim：这是每一个容器的运行时载体，我们在 docker 宿主机上看到的 shim 也正是代表着一个个通过调用 containerd 启动的 docker 容器。

ctr：它是一个简单的 CLI 接口，用作 containerd 本身的一些调试用途，投入生产使用时还是应该配合docker 或者 cri-containerd 部署。

赋予它们可执行权限，4=读，2=写，1=可执行，加一起就是他的权限。

正确命令如下：

③把上面解压的这个文件containerd.service，放到systemd的目录下："/usr/lib/systemd/system/"；

解压文件完整根路径如下：

"/usr/local/bin/etc/systemd/system/containerd.service"

④给containerd.service赋予权限；

如果你不想每次使用crictl都带一行类似下面这样的参数，

crictl --image-endpoint unix:///var/run/containerd/containerd.sock

那么你就执行下面的命令：

（4）master节点启动containerd；

a.查询containerd运行状态：

b.启动containerd命令：

但是切换到这个目录，发现目录是空的。（未截图）

1.查看kubelet启动日志；

报错现象：kubelet 日志报 ​​network plugin is not ready: cni config uninitialized​​

解决方法：网络插件（flannel 或者 calico）没有安装或者安装失败。

2.安装部署网络插件（master节点上）；

calico和flannel二选一（）

在此处下载 kube-flannel.yml；

直接apply： kubectl apply -f kube-flannel.yml
也可直接复制下面的命令：

flannel 的pod启动正常后，如果节点还是Notready，需要安装kubernetes-cni

3.检测主机环境是否达到集群的要求，可根据结果提示进行逐一排除故障；

下面的输出结果很重要，根据提示操作，应该就可以启动k8s集群了；

不然要执行生成token;

4.【kubectl get nodes】查看当前节点异常“The connection to the server 192.168.91.100:6443 was refused - did you specify the right host or port?”;

报错：The connection to the server 192.168.91.100:6443 was refused - did you specify the right host or port?

"/etc/containerd/config.toml"这个文件好像没啥用，还是删了。

Kubeadm初始化依然报错：

“[ERROR CRI]: container runtime is not running:”

正确操作如下：

（1）确保下面命令执行且生效，"admin.conf......"；

（2）所有主机重置k8s集群；

（3）所有主机删除$HOME/.kube；

（4）master节点执行 k8s初始化失败：The kubelet is not running；

不重置，会提示.yaml配置文件已经存在，无法初始化；

（5）重置后，k8s集群初始化提示超时，[kubelet-check] Initial timeout of 40s passed；

（6）修改/lib/systemd/system/kubelet.service；

this might take a minute or longer if the control plane images have to be pulled #1023(https://github.com/kubernetes/kubeadm/issues/1023), 尝试一下，没想到竟然成功了！方法就是修改/lib/systemd/system/kubelet.service，添加kubelet启动参数如下：
[Service]
ExecStart=/usr/bin/kubelet --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml
…
然后，重启计算机，所有主机执行sudo kubeadm reset 后重新执行下面初始化命令；

重启master节点后，k8s集群初始化仍然报错；

（7）所有主机修改镜像仓库和添加k8s阿里云YUM软件源；

（8）所有主机修改/etc/docker/daemon.json内容，重启 docker；

（9）主要错误信息跟踪：

Unfortunately, an error has occurred:
    timed out waiting for the condition

This error is likely caused by:
    - The kubelet is not running
    - The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)

If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
    - 'systemctl status kubelet'
    - 'journalctl -xeu kubelet'
 

日志文件中的错误主要有四种：

①找不到节点；

②获取不到节点信息；

③Unable to register node with API server；

④获取不到pause镜像；

（10）所有主机配置kubernetes源；

尝试网上的解决方案：添加pod-infra-container-image参数，但是添加该参数后仍然报错。

执行k8s集群初始化命令，还是一样的错误信息。

Container runtime network not ready错误通常是由于网络配置不正确或网络插件未正确安装等原因引起的。通过检查网络插件、网络配置、重启kubelet服务、检查网络状态以及重启节点等步骤，我们可以解决这个问题。在解决问题之前，确保备份数据和配置，并确保有其他节点可以接管工作负载，以防止服务中断。

所有主机执行下面命令：

重置后，初始化还是报一样的错误。

master节点执行下面命令：

所有主机重置后，master节点初始化k8s集群，还是一样的错误。

1.下面方法可以解决containerd运行状态报错的问题（仅master主节点）；

（1）master节点先删除“/etc/containerd/config.toml”文件；

（2）master节点执行下面命令，重新生成“/etc/containerd/config.toml 文件”；

 命令执行完之后，一定要检查一遍配置内容有没有改过来。

发现没改成功，手动修改：

（3）master节点重启containerd；

（4）master节点查看containerd状态；

（5）所有主机重置初始化；

（6）在master节点执行k8s集群初始化命令；

# 使用containerd作为容器，不再使用docker
kubeadm init --node-name=k8s-master01
--image-repository registry.aliyuncs.com/google_containers
--kubernetes-version v1.25.16
--apiserver-advertise-address=192.168.91.100
--pod-network-cidr=10.244.0.0/16
--service-cidr=10.96.0.0/12

k8s集群初始化终于成功了。

初始化过程说明：

• [preflight] kubeadm 执行初始化前的检查。
• [kubelet-start] 生成kubelet的配置文件”/var/lib/kubelet/config.yaml”
• [certificates] 生成相关的各种token和证书
• [kubeconfig] 生成 KubeConfig 文件，kubelet 需要这个文件与 Master 通信
• [control-plane] 安装 Master 组件，会从指定的 Registry 下载组件的 Docker 镜像。
• [bootstraptoken] 生成token记录下来，后边使用kubeadm join往集群中添加节点时会用到
• [addons] 安装附加组件 kube-proxy 和 kube-dns。 Kubernetes Master 初始化成功，提示如何配置常规用户使用kubectl访问集群。 提示如何安装 Pod 网络。 提示如何注册其他节点到 Cluster。

1.master节点必要的环境配置；

2.两个worker工作节点加入k8s集群；

worker02节点执行join到k8s集群的命令：

（1）所有woker节点（k8s-worker02和k8s-worker03）都要安装crictl；

k8s-worker02缺少crictl，执行安装命令：

（2）所有worker节点都安装containerd；

因为前面master节点安装过containerd，所以此处按照之前的方法，直接安装了。

①所有worker节点上传，解压“cri-containerd-1.6.22-linux-amd64.tar.gz”；

worker02和worker03要分别上传；

②两个worker节点都解压containerd压缩包到“/usr/local/bin/”；

③两个worker节点均拷贝二进制可执行文件到中；

etc目录：主要为containerd服务管理配置文件及cni虚拟网卡配置文件；

opt目录：主要为gce环境中使用containerd配置文件及cni插件；

usr目录：主要为containerd运行时的二进制文件，包含runc；

④两个worker节点均赋予关键文件可执行权限，4=读，2=写，1=可执行，加一起就是他的权限。

正确命令如下：

⑤两个worker节点，把上面解压的这个文件"/usr/local/bin/etc/systemd/system/containerd.service"，放到systemd的目录下："/usr/lib/systemd/system/"；

⑥两个worker节点均给containerd.service赋予权限；

⑦两个worker节点均给crictl配置参数；

如果你不想每次使用crictl都带一行类似下面这样的参数，

crictl --image-endpoint unix:///var/run/containerd/containerd.sock

那么你就执行下面的命令：

⑧两个worker节点均启动containerd；

a.启动containerd命令：

b.查询containerd运行状态：

（3）两个worker节点再次加入k8s集群；

（4）在master节点查看k8s集群中的所有节点工作状态；

3.在master节点使用k8s集群网络插件calico；

（1）master节点下载calico.yaml；

（2）master节点修改配置calico.yaml；

 ①.在xshell界面，“编辑”---->“查找”；

尝试后，发现在vim模式，这个搜索模式没法用。

②.在vim模式下，按下Esc键，确保处于正常模式，输入并加上要查找的关键字，然后按Enter键，比如":/CALICO_IPV4POOL_CIDR"；

Vim会自动将光标移到第一次出现该关键字的位置；

按n键向前导航或N键向后查找；

按i进入可编辑模式，方向键+修改内容；

若要退出查找模式，可以按下Esc键返回正常模式。

本案例需要修改下面两行配置；

原来是：

修改后：

（3）master节点执行命令：kubectl create -f calico.yaml

4.根据网上资料，应该是k8s不支持当前calico版本的原因；

可以在在官网查看版本是否兼容。

（1）master节点下载calico.yaml；（v3.26）（v3.27）均无法下载，不可用。

wget https://docs.projectcalico.org/v3.26/manifests/calico.yaml

wget https://docs.projectcalico.org/v3.27/manifests/calico.yaml

calico v3.25版本匹配，也可以下载，可使用；

（2）master节点修改配置calico.yaml；

（3）master节点执行命令：kubectl create -f calico.yaml

更新现有资源：如果你要更新已经存在的资源，可以使用  命令。确保将更新的配置保存到 YAML 文件中，并使用以下命令执行更新：

5.在master节点查看多个节点运行状态"kubectl get pods -n kube-system";

6.worker节点join到master节点；

7.worker节点"NotReady"的问题；

（1）在master节点执行"kubectl get nodes"；

参考calico官方安装文档；

（2）所有主机重置k8s；

（3）master节点重新初始化；

（4）master节点执行下面命令；

（5）两个worker节点join到master节点；

在master节点执行"kubectl get nodes"；

（6）master节点安装calico v3.25.2；

①执行下面命令，生成tigera-operator.yaml；

②重点注意下面命令，与calico官方文档执行有些不同；

③编辑custom-resources.yaml文件内容；

显示行号：进入vim模式，按"Esc"，再按":"，输入"set nu"，再点"Enter"。

点"i"进入可编辑模式，修改cidr值，再依次点"Esc"、":wq"，点击"Enter"保存退出。

④执行编辑后的custom-resources.yaml文件；

⑤删除已经存在的"custom-resources.yaml"，消除上面的错误；

重新执行命令：

 kubectl get ns

（7）kubernetes YUM源准备,所有集群主机均需操作；

此处使用阿里云，修改下边的"gpgcheck=0, repo_gpgcheck=0"跳过验证；

master节点执行“yum check-update  #清除yum缓存”报错；

（8）所有主机执行"vim /etc/sysconfig/kubelet"；

 所有主机的内容设置为：

 所有主机设置kubelet开机自启；

（9）三台主机的kubelet运行中报错；

（10）master节点删除calico v3.25.2，安装calico v3.24.6；

直接安装calico v3.24.6会提示一堆文件已经存在，所以必须先删除v3.25.2版本，再安装v3.24.6；

 如果删除失败，有可能是网络问题，重新删除即可。

安装calico v3.24.6；

（11）master节点执行  ，修改sandbox_iamge的行如下所示：

下图中只改了版本号；（感觉两个地址差不多）

改完之后，执行： 重启containerd；

（12）"kubectl get nodes"命令，所有节点状态为"NotReady"的解决方法;

 问题截图如下：

在NotReady的节点，执行下面命令，状态就可变为Ready；

（13）master节点重新安装calico v3.25；

先卸载上面用另一种方式安装的calico v3.24.6；

 

 

​​​​​​​