☰

sin conexión y error de cgroup en kubelet independiente con contenedor en ubuntu

tag-icon • tag-icon ubuntu-20.04 cgroup containerd
sin conexión y error de cgroup en kubelet independiente con contenedor en ubuntu

Estoy intentando configurar el componente Kubelet como servicio independiente desde la página de Kubernetes, aunque parece que me falta algo.

He configurado el contenedord + runc (según pasos) con:

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

para habilitar runc de acuerdo con:

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

Sin embargo, parece que falta algo porque sigo recibiendo el error:

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"

El segundo problema es que parece que no puedo acceder a Internet desde el módulo. Comencé kubelet con el comando:

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

Para las versiones, estoy usando:

  • en contenedor 1.6.19
  • runc 1.1.4
  • kubelet 1.23.16
  • Ubuntu 20.04

¿Algun consejo?

Gracias

Respuesta1

Después de un tiempo alejado de esto, pude regresar y solucionar el problema un poco más.

Entonces, el pensamiento inicial fue que el contenedor no tenía red. Para solucionar este problema, puede hacer lo siguiente:

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

Entonces, para cada Pod que haga girar Kubelet, creará un espacio de nombres de red y conectará interfaces virtuales; este es un diseño de Pod.Compruébalo aquí.

Continuando con la solución de problemas:

# 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

Esto resalta que a la interfaz dentro del espacio de nombres de la red se le había asignado una dirección IP.10.200.0.15/24

Intentemos la conexión a través del espacio de nombres:

# 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

Sin embargo, lo que garantiza que el contenedor tiene conectividad al intentar:

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

Esto concluye que estamos teniendo un problema de DNS y no de conectividad.

Entonces, para resolver eso, creé un nuevo archivo /root/resolve.conf con buenos servidores:

nameserver 8.8.8.8
nameserver 8.8.4.4

Y actualizó el comando:

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

Para apuntar al nuevo archivo, como:

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

Y también, eliminó el DNS del clúster:

--cluster-dns=127.0.0.53 \

Todavía es necesario arreglar el cluster-dns, aunque para fines de validación, tener el dns apuntando a DNS fuera de la instancia es suficiente.

EDITAR:

En retrospectiva, he mejorado esto. Dejé resolv.conf sin cambios y actualicé cluster-dns:

--cluster-dns=8.8.8.8 \

Esa era una mejor solución por ahora. Aún investigando.

información relacionada