![Ubuntu 上带有 containerd 的独立 kubelet 上无连接且出现 cgroup 错误](https://linux22.com/image/784361/Ubuntu%20%E4%B8%8A%E5%B8%A6%E6%9C%89%20containerd%20%E7%9A%84%E7%8B%AC%E7%AB%8B%20kubelet%20%E4%B8%8A%E6%97%A0%E8%BF%9E%E6%8E%A5%E4%B8%94%E5%87%BA%E7%8E%B0%20cgroup%20%E9%94%99%E8%AF%AF.png)
我正在尝试从 kubernetes 页面将 kubelet 组件设置为独立服务,但似乎缺少了一些东西。
我已经配置了containerd + runc(按步骤) 和:
$ mkdir -p /etc/containerd/
$ containerd config default | tee /etc/containerd/config.toml
$ sed 's/SystemdCgroup.*/SystemdCgroup = true/' -i /etc/containerd/config.toml
按照以下步骤启用 runc:
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
...
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = true
不过,似乎缺少了一些东西,因为我一直收到错误:
Feb 28 12:29:45 ip-200-115-0-5 kubelet[1854442]: E0228 12:29:45.986417 1854442 cri_stats_provider.go:455] "Failed to get the info of the filesystem with mountpoint" err="unable to find data in memory cache" mountpoint="/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs"
第二个问题是,我似乎无法从 pod 内部访问互联网。我使用以下命令启动了 kubelet:
ExecStart=/usr/local/bin/kubelet \
--config=/etc/kubernetes/kubelet-config.yaml \
--resolv-conf=/etc/resolv.conf \
--pod-cidr=10.88.0.0/16 \
--cluster-domain=cluster.local \
--cluster-dns=127.0.0.53 \
--cgroup-driver=systemd \
--fail-swap-on=false \
--pod-manifest-path=/etc/kubernetes/manifests \
--container-runtime=remote \
--container-runtime-endpoint=unix:///run/containerd/containerd.sock \
--runtime-request-timeout=10m \
--network-plugin=cni \
--cni-conf-dir=/etc/cni/ \
--cni-bin-dir=/opt/cni/bin
对于版本,我使用的是:
- containerd 1.6.19
- 运行 1.1.4
- kubelet 1.23.16
- Ubuntu 20.04
有小费吗?
谢谢
答案1
过了一段时间后,我能够回过头来再排除一些故障。
因此,最初的想法是容器没有网络。要解决此问题,您可以执行以下操作:
# ip netns
cni-f6078594-55bf-95d3-a2fd-33a5095b74c9 (id: 0)
因此,对于 Kubelet 旋转的每个 Pod,它都会创建一个网络命名空间并附加虚拟接口,这是一个 Pod 设计。点击这里。
继续进行故障排除:
# ip netns exec cni-f6078594-55bf-95d3-a2fd-33a5095b74c9 ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 56:ef:8e:da:f2:29 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.200.0.15/24 brd 10.200.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::54ef:8eff:feda:f229/64 scope link
valid_lft forever preferred_lft forever
这表明网络命名空间内的接口确实被分配了 IP10.200.0.15/24
让我们尝试通过命名空间进行连接:
# ip netns exec cni-f6078594-55bf-95d3-a2fd-33a5095b74c9 ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=0.975 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=1.24 ms
但是,在尝试以下操作时,这可以确保容器具有连接性:
# ip netns exec cni-f6078594-55bf-95d3-a2fd-33a5095b74c9 ping google.com
ping: google.com: Temporary failure in name resolution
这表明我们遇到了 DNS 问题,而不是连接问题。
因此,为了解决这个问题,我创建了一个带有良好服务器的新 /root/resolve.conf 文件:
nameserver 8.8.8.8
nameserver 8.8.4.4
并更新了命令:
--resolv-conf=/etc/resolv.conf \
指向新文件,例如:
--resolv-conf=/root/resolv.conf \
另外,删除了集群 DNS:
--cluster-dns=127.0.0.53 \
仍然需要修复 cluster-dns,但出于验证目的,将 DNS 指向实例外部的 DNS 就足够了。
编辑:
事后看来,我已经改进了这一点。我保持 resolv.conf 不变,并更新了 cluster-dns:
--cluster-dns=8.8.8.8 \
目前来说这是个更好的解决方案。仍在调查中。