Поды на узле k8s недоступны, произошел сбой kube-proxy или CNI.

Я добавил новый узел в свой кластер k8s, но обнаружил, что некоторые выделенные этому узлу не могут отображать такие журналы:

      $ kubectl logs -n xxxx xxxxx-6d5bdd7d6f-5ps6k

Unable to connect to the server: EOF

Использование Lens дает такие журналы ошибок:

      Failed to load logs: request to http://127.0.0.1:49271/api-kube/api/v1/namespaces/xxxxxxx/pods/xxxx34-27736483--1-hxjpv/log?tailLines=500&timestamps=true&container=xxxxxx&previous=false failed, reason: socket hang up
Reason: undefined (ECONNRESET)

Я считаю, что в этом узле есть какая-то проблема, когда я использую переадресацию портов:

      $ kubectl port-forward -n argocd svc/argocd-notifications-controller-metrics 9001:9001
error: error upgrading connection: error dialing backend: dial tcp 10.0.6.20:10250: i/o timeout

Я думаю, что внутренний IP 10.0.6.20 неправильный.

Все модули kube-proxy работают из kubectl.

      -> % kgp -o wide -n kube-system | grep kube-proxy
kube-proxy-7pg9d                                  1/1     Running     1 (2d20h ago)   29d     10.0.6.20        worker4     
kube-proxy-cqh2c                                  1/1     Running     1 (15d ago)     29d     10.0.6.3         worker3           
kube-proxy-lp4cd                                  1/1     Running     0               29d     10.0.6.1         worker1           
kube-proxy-r6bgw                                  1/1     Running     0               29d     10.0.6.2         worker2

Но используяcrictl podsна каждом узле ищем эти модули

      # crictl pods | grep kube-proxy
ceef94b060e56       2 days ago          Ready               kube-proxy-7pg9d                                   kube-system         1                   (default)
418bd5b46c2b9       4 weeks ago         NotReady            kube-proxy-7pg9d                                   kube-system         0                   (default)

Показывает «Готово» или «Неготово». Я использую Calico для CNI в режиме ip_vs. Как я могу это исправить?

Источник

1 ответ

Я решил эту проблему, выполнив следующую процедуру:

Рабочий4

Убедитесь, что kubelet прослушивает порт по умолчанию:

      # lsof -i:10250
COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
kubelet 819 root   26u  IPv4  13966      0t0  TCP worker4.cluster.local:10250 (LISTEN)

Рабочий1 curl https://10.0.6.20:10250Получает тайм-аут, но найденcurl https://10.0.6.1:10250 # worker1от работника 4 ответил быстро.

Так что это могут быть пакеты, отброшенные внутри worker4,

Этот пакет журналов в работнике 4:https://www.thegeekstuff.com/2012/08/iptables-log-packets/

      iptables -N LOGGING
iptables -A INPUT -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A LOGGING -j DROP

Сохраню логи в/var/log/syslog

Использование команды для фильтрации из журналов:

      tail -200 /var/log/syslog | grep IPTables-Dropped | grep 10.0.6.1
Oct 10 13:49:37 compute kernel: [637626.880648] IPTables-Dropped: IN=eth1 OUT= MAC=00:16:ce:d4:b7:01:00:16:b2:77:89:01:08:00 SRC=10.0.6.1 DST=10.0.6.20 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=29087 DF PROTO=TCP SPT=58838 DPT=10250 WINDOW=64240 RES=0x00 SYN URGP=0

Поэтому я убежден, что пакет отброшен.

Добавляем правила:

      iptables -I INPUT -s 10.0.0.0/8 -p tcp --dport 10250 -j ACCEPT

Затем я могу подключить оболочку или получить логи из модулей на узле. Я ценю дискуссии с @SYN

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