☰

우분투에서 컨테이너가 있는 독립형 kubelet에 연결이 없고 cgroup 오류가 발생함

tag-icon • tag-icon ubuntu-20.04 cgroup containerd
우분투에서 컨테이너가 있는 독립형 kubelet에 연결이 없고 cgroup 오류가 발생함

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"

두 번째 문제는 포드 내에서 인터넷에 액세스할 수 없다는 것입니다. 다음 명령으로 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 \

여전히 Cluster-DNS를 수정해야 합니다. 하지만 검증 목적으로 인스턴스 외부의 DNS를 가리키는 DNS를 사용하는 것만으로도 충분합니다.

편집하다:

돌이켜보면 나는 이것을 개선했다. resolv.conf를 변경하지 않고 클러스터-dns를 업데이트했습니다.

--cluster-dns=8.8.8.8 \

지금으로서는 그게 더 나은 해결책이었습니다. 아직 조사 중입니다.

관련 정보