☰

keine Verbindung und Cgroup-Fehler bei eigenständigem Kubelet mit Containerd auf Ubuntu

tag-icon • tag-icon ubuntu-20.04 cgroup containerd
keine Verbindung und Cgroup-Fehler bei eigenständigem Kubelet mit Containerd auf Ubuntu

Ich versuche, die Kubelet-Komponente als eigenständigen Dienst von der Kubernetes-Seite aus einzurichten, aber es scheint, als ob mir etwas entgeht.

Ich habe containerd + runc konfiguriert (nach Schritten) mit:

$ mkdir -p /etc/containerd/
$ containerd config default | tee /etc/containerd/config.toml
$ sed 's/SystemdCgroup.*/SystemdCgroup = true/' -i /etc/containerd/config.toml

um runc zu aktivieren gemäß:

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
  ...
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
    SystemdCgroup = true

Allerdings scheint etwas zu fehlen, da ich immer wieder die folgende Fehlermeldung erhalte:

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"

Das zweite Problem ist, dass ich von Pod aus nicht auf das Internet zugreifen kann. Ich habe Kubelet mit folgendem Befehl gestartet:

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

Für die Versionen verwende ich:

  • containerd 1.6.19
  • runc 1.1.4
  • Kubelet 1.23.16
  • Ubuntu 20.04

Irgendwelche Tipps?

Danke

Antwort1

Nachdem ich mich eine Zeit lang davon entfernt hatte, konnte ich zurückkommen und das Problem noch etwas genauer untersuchen.

Der erste Gedanke war also, dass der Container kein Netzwerk hatte. Um das Problem zu beheben, können Sie Folgendes tun:

# ip netns
cni-f6078594-55bf-95d3-a2fd-33a5095b74c9 (id: 0)

Für jeden Pod, den Kubelet startet, wird ein Netzwerk-Namespace erstellt und virtuelle Schnittstellen angehängt. Dies ist ein Pod-Design.Schauen Sie sich das hier an.

Weiter mit der Fehlerbehebung:

# 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

Dies zeigt, dass der Schnittstelle im Netzwerk-Namespace tatsächlich eine IP zugewiesen wurde10.200.0.15/24

Versuchen wir eine Verbindung über den Namespace:

# 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

Dies stellt jedoch sicher, dass der Container über eine Verbindung verfügt, wenn Sie Folgendes versuchen:

# ip netns exec cni-f6078594-55bf-95d3-a2fd-33a5095b74c9 ping google.com
ping: google.com: Temporary failure in name resolution

Daraus lässt sich schließen, dass ein DNS-Problem und kein Verbindungsproblem vorliegt.

Um dieses Problem zu lösen, habe ich eine neue Datei /root/resolve.conf mit guten Servern erstellt:

nameserver 8.8.8.8
nameserver 8.8.4.4

Und den Befehl aktualisiert:

--resolv-conf=/etc/resolv.conf \

Um auf die neue Datei zu verweisen, wie:

--resolv-conf=/root/resolv.conf \

Außerdem wurde der Cluster-DNS entfernt:

--cluster-dns=127.0.0.53 \

Der Cluster-DNS muss noch repariert werden, für Validierungszwecke reicht es jedoch aus, wenn der DNS auf einen DNS außerhalb der Instanz verweist.

BEARBEITEN:

Im Nachhinein habe ich das verbessert. Ich habe die resolv.conf unverändert gelassen und den Cluster-DNS aktualisiert:

--cluster-dns=8.8.8.8 \

Das war für den Moment eine bessere Lösung. Wir untersuchen das noch.

verwandte Informationen