нет соединения и ошибка cgroup на автономном kubelet с контейнером в Ubuntu

Я пытаюсь настроить компонент kubelet как автономный сервис со страницы kubernetes, хотя, похоже, я что-то упускаю.

Я настроил контейнер + 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"

Вторая проблема заключается в том, что я не могу получить доступ к Интернету из модуля. Я запустил 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
  • кубелет 1.23.16
  • убунту 20.04

Какие-нибудь советы?

Спасибо

Источник

1 ответ

Через некоторое время вдали от этого, я смог вернуться и еще немного устранить неполадку.

Итак, первоначальная мысль заключалась в том, что у контейнера нет сети. Чтобы устранить эту неполадку, вы можете сделать следующее:

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

Итак, для каждого пода, который вращает Kubelet, он создаст сетевое пространство имен и подключит виртуальные интерфейсы — это дизайн пода. Проверьте это здесь .

Продолжаем устранение неполадок:

      # 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

Это подчеркивает, что интерфейсу внутри сетевого пространства имен действительно был назначен IP-адрес 10.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 \

Все еще необходимо исправить DNS-кластер, хотя для целей проверки достаточно, чтобы DNS указывал на DNS за пределами экземпляра.

РЕДАКТИРОВАТЬ:

Оглядываясь назад, я улучшил это. Я оставил файл resolv.conf без изменений и обновил кластер-dns:

      --cluster-dns=8.8.8.8 \

На данный момент это было лучшее решение. Все еще расследуем.

Источник
Другие вопросы по тегам