1、报错信息FoundmultipleCRIendpointsonthehost.Pleasedefinewhichonedoyouwishtousebysettingthe'criSocket'fieldinthekubeadmconfigurationfile:unix:///var/run/containerd/containerd.sock,unix:///var/run/cri-dockerd.sockToseethestacktraceofthiserrorexecutewith--v=5orhigher报错信息截图： 2、原因：没有整合kubelet和cri-dockerd3
问题：[root@master:~]kubeadminit--image-repositoryregistry.aliyuncs.com/google_containers--pod-network-cidr=10.244.0.0/16-[init]UsingKubernetesversion:v1.24.1[preflight]Runningpre-flightcheckserrorexecutionphasepreflight:[preflight]Somefatalerrorsoccurred: [ERRORCRI]:containerruntimeisnotrunning:out
K8s在创建pod时发现pod状态为ContainerCreating状态检查pod的日志发现提示Failedcreatepodsandbox:rpcerror:code=Unknowndesc=failedtosetupsandboxcontainer"fdd30141bf51b68d4f08a2405ea287508aa0d585d30c853a849d9d57cb7c1062"networkforpod"tiller-deploy-58565b5464-zhnml":NetworkPlugincnifailedtosetuppod"tiller-deploy-58565b5464-zhn
kubectl获取node节点，集群状态检测时，master、node一直处于NotReady状态[root@master~]#kubectlgetnodesNAME STATUS ROLES AGE VERSIONmaster NotReady control-plane 27m v1.26.3node NotReady 80s v1.26.3查看pod状态，发现coredns一直处于pending状态[root@master~]#kubectlgetpods--all-namespacesNAMESPACE NAME READY
kubelet在容器网络接口（CNI）的集成中发挥着重要的作用，它通过以下步骤来调用CNI插件：Pod创建：当Kubernetes接收到一个新的Pod创建请求时，kubelet负责创建和管理该Pod。网络配置：在Pod创建过程中，kubelet会从KubernetesAPIServer获取Pod的网络配置信息，包括网络插件的名称和相关参数。CNI插件调用：一旦kubelet获取到Pod的网络配置信息，它会调用CNI插件来配置Pod的网络。kubelet通过执行CNI插件的二进制文件，并将Pod的网络配置信息作为输入传递给插件。网络插件处理：CNI插件收到网络配置信息后，会根据配置信息来进行相应
前言：kubernetes的部署从1.24版本开始后，弃用docker-shim，也就是说部署1.24版本后的集群不能使用docker-ce了。比较清晰的解决方案有两个，一是使用containerd，这个是一个新的支持cri标准的shim，一个是使用cri-docker这样的中间插件形式，一头通过CRI跟kubelet交互，另一头跟dockerapi交互，从而间接的实现了kubernetes以docker作为容器运行时。但是这种架构缺点也很明显，调用链更长，效率更低。那么，cri-docker虽然有效率低下的缺点，但很明显这个更加符合原来的docker使用习惯。说人话就是部署简单，学习成本不会
基于Ubuntu22.04除非特别标注，其余步骤master和worker节点都需要操作准备工作修改Ubuntu镜像https://developer.aliyun.com/mirror/ubuntu?spm=a2c6h.13651102.0.0.2e611b11BvTeZL备份默认/etc/apt/sources.list修改/etc/apt/sources.list修改后更新sudoaptupdate&&sudoaptupgrade主机名解析主机名成解析编辑三台服务器的/etc/hosts文件，添加下面内容根据自己情况配置，这里我有一台master节点对应192.168.90.100，no
本文参考自：UsingtheCRI-OContainerEngineCRI-O是一个开源的、社区驱动的容器引擎。其主要目标是取代Docker服务作为Kubernetes实施的容器引擎。随着 Kubernetesv1.24对dockershim的弃用，CRI-O将成为Kubernetes容器引擎的不二之选。CRI-O容器引擎为运行与开放容器标准 (OCI)兼容的运行时提供了一个稳定、更安全和高性能的平台。使用CRI-O容器引擎可以借助使用符合OCI的运行时（如runc、默认OCI运行时或KataContainers）来启动容器和Pod。CRI-O的稳定性来自于它是与Kubernetes的主要和次
本文参考自：UsingtheCRI-OContainerEngineCRI-O是一个开源的、社区驱动的容器引擎。其主要目标是取代Docker服务作为Kubernetes实施的容器引擎。随着 Kubernetesv1.24对dockershim的弃用，CRI-O将成为Kubernetes容器引擎的不二之选。CRI-O容器引擎为运行与开放容器标准 (OCI)兼容的运行时提供了一个稳定、更安全和高性能的平台。使用CRI-O容器引擎可以借助使用符合OCI的运行时（如runc、默认OCI运行时或KataContainers）来启动容器和Pod。CRI-O的稳定性来自于它是与Kubernetes的主要和次
镜像下载、域名解析、时间同步请点击阿里云开源镜像站从kubernetes1.24开始，dockershim已经从kubelet中移除，但因为历史问题docker却不支持kubernetes主推的CRI（容器运行时接口）标准，所以docker不能再作为kubernetes的容器运行时了，即从kubernetesv1.24开始不再使用docker了。但是如果想继续使用docker的话，可以在kubelet和docker之间加上一个中间层cri-docker。cri-docker是一个支持CRI标准的shim（垫片）。一头通过CRI跟kubelet交互，另一头跟dockerapi交互，从而间接的实现
