将节点添加到 kubernetes 集群会导致无法加载 Kubelet 配置文件 /var/lib/kubelet/config.yaml 并且在 /etc/cni/net.d 中找不到网络答案

【问题标题】：Adding node to kubernetes cluster gives failed to load Kubelet config file /var/lib/kubelet/config.yaml and no networks found in /etc/cni/net.d将节点添加到 kubernetes 集群会导致无法加载 Kubelet 配置文件 /var/lib/kubelet/config.yaml 并且在 /etc/cni/net.d 中找不到网络
【发布时间】：2020-12-17 14:05:29
【问题描述】：

我有一个两个节点的 k8s 集群正在工作。我向集群中添加了另一个节点，sudo kubeadm join ... 命令报告该节点已加入集群。新节点卡在 NotReady 状态：

kubectl get nodes
NAME               STATUS     ROLES    AGE    VERSION
msi-ubuntu18       NotReady   <none>   29m    v1.19.0
tv                 Ready      master   131d   v1.18.6
ubuntu-18-extssd   Ready      <none>   131d   v1.17.4

journalctl -u kubelet 显示此错误：

Started kubelet: The Kubernetes Node Agent.
  22039 server.go:198] failed to load Kubelet config file /var/lib/kubelet/config.yaml, error failed to read kubelet config file "/var/l...

但是文件 /var/lib/kubelet/config.yaml 存在并且看起来没问题。

sudo systemctl status kubelet 显示不同的错误：

kubelet.go:2103] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plu
cni.go:239] Unable to update cni config: no networks found in /etc/cni/net.d

并且新节点上没有/etc/cni/目录。（现有节点有 /etc/cni/net.d/ 里面有印花布文件。）如果我运行

kubectl apply -f https://docs.projectcalico.org/v3.11/manifests/calico.yaml

再次在master上它并没有解决问题。新节点上仍然没有 /etc/cni/ 目录。

我在创建新节点时一定错过了一步。如何获取新节点上的 /etc/cni/ 目录？同样令人费解的是kubeadm join ...命令在新节点卡在NotReady时表示成功。

【问题讨论】：

您在初始化集群时是否添加了pod CIDR？您能否尝试安装最新的 calico 版本，即 3.16，并检查它是否有效？您能否将kubectl get pods --all-namespaces 的输出添加到您的问题中？
是：sudo kubeadm init --pod-network-cidr=192.168.0.0/16

标签： kubernetes kubeadm

【解决方案1】：

对于遇到这个问题的其他人，我终于能够通过这样做来解决这个问题

kubectl delete -f https://docs.projectcalico.org/v3.11/manifests/calico.yaml

紧随其后

kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

我几个月前安装的 3.11 版本与新节点之间肯定存在版本不兼容问题。

【讨论】：

【解决方案2】：

我在使用 pod cidr #kubeadm init --pod-network-cidr=10.10.0.0/16 初始化集群时也遇到了同样的情况

但是，#kubectl get pods --all-namespaces 命令帮助解决了这个问题。

【讨论】：

【解决方案3】：

我刚刚遇到过类似的情况，但近因更高。

基本上，我将一些 Gatekeeper 安全策略应用于 kube-system 命名空间，但没有意识到我必须为 kube-proxy 和 aws-node 设置例外（这是在 EKS 中）。

来自 kube 事件日志的几个示例：

[denied by psp-pods-allowed-user-ranges] Container kube-proxy is attempting to run without a required securityContext/runAsGroup. Allowed runAsGroup: {"ranges": [{"max": 65535, "min": 1}], "rule": "MustRunAs"}
[denied by caps-constraints] container <kube-proxy> is not dropping all required capabilities. Container must drop all of ["ALL"]
[denied by psp-hostfs-constraints] HostPath volume {"name": "xtables-lock", "hostPath": {"path": "/run/xtables.lock", "type": "FileOrCreate"}} is not allowed, pod: kube-proxy-j5h2d. Allowed path: [{"pathPrefix": "/tmp", "readOnly": true}]

在应用更改后的整整一个月里，我都没有注意到这一点；它仅在我的一个 EKS 节点由于某种原因重新启动后才出现。

在这里发帖，希望它可以在我失去的那一天拯救其他人。

【讨论】：