![当 kubelet 使用 container-runtime remote 运行时,为什么我的 Kubernetes 工作节点会尝试拉取 infra-pod 映像?](https://linux22.com/image/757587/%E5%BD%93%20kubelet%20%E4%BD%BF%E7%94%A8%20container-runtime%20remote%20%E8%BF%90%E8%A1%8C%E6%97%B6%EF%BC%8C%E4%B8%BA%E4%BB%80%E4%B9%88%E6%88%91%E7%9A%84%20Kubernetes%20%E5%B7%A5%E4%BD%9C%E8%8A%82%E7%82%B9%E4%BC%9A%E5%B0%9D%E8%AF%95%E6%8B%89%E5%8F%96%20infra-pod%20%E6%98%A0%E5%83%8F%EF%BC%9F.png)
我有一组工作节点成功加入我的 K8s 集群,但由于无法从互联网上拉取 infrapod 映像,它们无法调度任何 pod。我们的集群是裸机,使用 Kubernetes 1.18,使用 CRI-O 作为其运行时(以及 podman)。
其中一个节点的 kubelet 日志输出如下:
Sep 17 18:56:02 node1.data.worker kubelet[112861]: E0917 18:56:02.188261 112861 kuberuntime_sandbox.go:69] CreatePodSandbox for pod "kube-proxy-hf5q2_kube-system(3f66419d-d676-4d17-af30-be79425a779c)" failed: rpc error: code = Unknown desc = error creating pod sandbox with name "k8s_kube-proxy-hf5q2_kube-system_3f66419d-d676-4d17-af30-be79425a779c_0": Error initializing source docker://k8s.gcr.io/pause:3.2: error pinging docker registry k8s.gcr.io: Get https://k8s.gcr.io/v2/: dial tcp [2607:f8b0:4003:c13::52]:443: connect: network is unreachable
这个特定的错误显然是因为工作节点没有连接到互联网,所以这是合理的。
然而,不是合理的是,节点正在尝试拉取 puase 映像,因为“PodSandboxImage”应该只在 kubelet 使用 Docker 作为其容器运行时才重要,而它并未配置为这样做。
我通过查看产生上述错误的工作节点上的 kubelet 命令行确认了这一点:
[sysmaint@node1 ~]$ systemctl status kubelet -l
● kubelet.service - kubelet: The Kubernetes Node Agent
Loaded: loaded (/usr/lib/systemd/system/kubelet.service; enabled; vendor preset: disabled)
Drop-In: /usr/lib/systemd/system/kubelet.service.d
└─10-kubeadm.conf
Active: active (running) since Wed 2020-09-16 21:08:55 GMT; 21h ago
Docs: https://kubernetes.io/docs/
Main PID: 112861 (kubelet)
Tasks: 58
CGroup: /system.slice/kubelet.service
└─112861 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --container-runtime=remote --container-runtime-endpoint=/var/run/crio/crio.sock --cgroup-driver=systemd
从上图可以看出,该节点配置为使用 cri-o 而不是 Docker 作为其运行时。
现在,我确信我可以通过更改 kubelet 配置中的 infra-pod-image 以指向我们的本地 docker 注册表来解决这个问题,但根据 Kubernetes 文档,如果系统不使用 Docker 作为运行时,它甚至不需要该映像。
文档和预期行为之间的不匹配让我认为我遗漏了一些东西。
我的问题是:
即使使用远程容器运行时,系统(即 kubelet 和 cri-o)是否仍需要暂停映像?
如果不是,我接下来应该做什么来确定这里的问题?具体来说,我假设工作节点上的某些配置有误
PS-顺便说一句,我是如果我解除污染,就能够在主节点上成功调度 pod,但我认为这是因为主节点确实有暂停映像并且能够连接到互联网。