1.问题描述:
在服务器上安装完k8s之后,会出现kubectl有时候连得上,等之后再去连接的时候又断开,同时节点出现了NotReady的情况,


出现了这两种双重症状
2.解决问题
自己的思路:查看日志,检查报错地方,一共经历了下面几个阶段
1.先检查kubelet的日志,日志提示网络连接问题
systemctl status kubelet

2.根据日志找到是网络的问题,检查conf是否有问题,结果很正常
cat /etc/kubernetes/kubelet.conf
root@worker:~# cat /etc/kubernetes/kubelet.conf
apiVersion: v1
clusters:
- cluster:
certificate-authority-data:*****
server: https://10.3.4.4:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: system:node:master
name: system:node:master@kubernetes
current-context: system:node:master@kubernetes
kind: Config
preferences: {}
users:
- name: system:node:master
user:
client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
client-key: /var/lib/kubelet/pki/kubelet-client-current.pem
3.会不会是证书的原因,检查证书有没有过期,检查结果是没得,证书有效期甚至可以到明年
openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -text

4.这些都没问题,会不会是因为没有安装网络插件才导致的网络问题?又安装了flannel,结果
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml```

现在成功从两个问题变成三个问题了..........其实前面两个问题和flannel没有关系,它是另外的问题,我们一会再来解决。
现在我们的尝试不得行(还有很多个检查都显示没问题,这里就不再水字数了),去看看网络上是怎么解决的。
网络上的思路:
这里要感谢**OleksandrTimoshenko**老哥提供了我们解决方法

其中提到主要的问题是出在containerd上,在之前的检查中显示它是没有问题的,现在让我们回去看看,是否是漏了什么,
这里提到需要将SystemdCgroup设置为true,然后重启,成功!!!!!!!!
systemctl restart containerd

3.没有提到的地方
如果资源不足也会启动失败,我使用的服务器主要是2h4g,资源十分受限,我把之前一直运行在docker上的各种服务都关闭了,节约了不少,
同时我还以为是端口的问题,将ipv6-ipv4 tcp udp的6443全部开启,实际上只需要开启ipv4 tcp即可,不需要开放其他地方

4.为什么?
SystemdCgroup
设置控制containerd
如何使用 cgroup(控制组)。cgroup 是 Linux 内核提供的资源管理机制,用于限制、监控和隔离进程组使用的资源(如 CPU、内存等)。- 当
SystemdCgroup
设置为false
时,containerd
使用自己的方式来管理 cgroup。而当设置为true
时,containerd
会让systemd
来管理 cgroup,这与许多现代 Kubernetes 环境的配置一致,因为systemd
是大多数 Linux 系统的默认初始化系统。 - 使用
SystemdCgroup = true
可以确保容器运行时正确与systemd
配合,避免因为容器的资源管理配置问题而导致 Kubernetes 的稳定性问题。
为什么这样做能解决问题?
- Kubernetes 在运行时依赖容器运行时(如
containerd
)来启动和管理容器。如果containerd
的配置文件存在问题(比如 cgroup 配置不兼容),会导致容器无法正常启动,从而影响 Kubernetes 组件,最终可能导致kubectl
等命令出现连接问题或不断重启。 - 通过生成默认配置并调整 cgroup 设置,你保证了容器运行时和系统管理工具(如
systemd
)之间的兼容性,确保了资源管理的正确性,从而解决了kubectl
不断重启的问题。