☰

在 ubuntu 上使用 containerd 的獨立 kubelet 上沒有連線和 cgroup 錯誤

tag-icon • tag-icon ubuntu-20.04 cgroup containerd
在 ubuntu 上使用 containerd 的獨立 kubelet 上沒有連線和 cgroup 錯誤

我正在嘗試將 kubelet 元件設定為 kubernetes 頁面中的獨立服務，儘管我似乎遺漏了一些東西。

我已經配置了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

對於版本，我正在使用：

  • 容器 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 \

目前這是一個更好的解決方案。仍在調查中。

相關內容