Почему Kube-прокси не направляет трафик на другой рабочий узел? - PullRequest
Новая
       24

Почему Kube-прокси не направляет трафик на другой рабочий узел?

0 голосов
/ 11 марта 2019

Я развернул несколько разных служб и всегда получаю одну и ту же ошибку.

Служба доступна на порту узла с компьютера, на котором работает модуль.На двух других узлах я получаю тайм-ауты.

kube-proxy работает на всех рабочих узлах, и я могу видеть в лог-файлах от kube-proxy, что был добавлен сервисный порт и открыт порт узла.В этом случае я развернул демо-версию stars из ситца

Вывод журнала Kube-прокси: 

Mar 11 10:25:10 kuben1 kube-proxy[659]: I0311 10:25:10.229458     659 service.go:309] Adding new service port "management-ui/management-ui:" at 10.32.0.133:9001/TCP
Mar 11 10:25:10 kuben1 kube-proxy[659]: I0311 10:25:10.257483     659 proxier.go:1427] Opened local port "nodePort for management-ui/management-ui:" (:30002/tcp)

Kube-прокси прослушивает порт 30002 

root@kuben1:/tmp# netstat -lanp | grep 30002
tcp6       0      0 :::30002                :::*                    LISTEN      659/kube-proxy

Есть также некоторые определенные правила iptable: 

root@kuben1:/tmp# iptables -L -t nat | grep management-ui
KUBE-MARK-MASQ  tcp  --  anywhere             anywhere             /* management-ui/management-ui: */ tcp dpt:30002
KUBE-SVC-MIYW5L3VT4JVLCIZ  tcp  --  anywhere             anywhere             /* management-ui/management-ui: */ tcp dpt:30002
KUBE-MARK-MASQ  tcp  -- !10.200.0.0/16        10.32.0.133          /* management-ui/management-ui: cluster IP */ tcp dpt:9001
KUBE-SVC-MIYW5L3VT4JVLCIZ  tcp  --  anywhere             10.32.0.133          /* management-ui/management-ui: cluster IP */ tcp dpt:9001

Интересная часть заключается в том, что я могу получить IP-адрес службы с любого рабочего узла 

root@kubem1:/tmp# kubectl get svc -n management-ui
NAME            TYPE       CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
management-ui   NodePort   10.32.0.133   <none>        9001:30002/TCP   52m

IP-адрес службы / порт может бытьдоступ с любого рабочего узла, если я делаю "curl http://10.32.0.133:9001"

" Я не понимаю, почему kube-proxy не "правильно" маршрутизирует это ...
Есть кто-нибудь подсказка, где я могу найтиошибка?

Вот некоторые характеристики кластера:

Это кластер ручной сборки, вдохновленный руководством Келси Хайтауэра «kubernetes the hard way».

  • 6 узлов (3 основных: 3 рабочих) локальных vms
  • ОС: Ubuntu 18.04
  • K8s: v1.13.0
  • Докер: 18.9.3
  • Cni: calico

Состояние компонента на главных узлах выглядит нормально 

root@kubem1:/tmp# kubectl get componentstatus
NAME                 STATUS    MESSAGE             ERROR
controller-manager   Healthy   ok                  
scheduler            Healthy   ok                  
etcd-0               Healthy   {"health":"true"}   
etcd-1               Healthy   {"health":"true"}   
etcd-2               Healthy   {"health":"true"}

Рабочие узлы выглядят нормально, если я доверяю kubectl 

root@kubem1:/tmp# kubectl get nodes -o wide
NAME     STATUS   ROLES    AGE   VERSION   INTERNAL-IP      EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
kuben1   Ready    <none>   39d   v1.13.0   192.168.178.77   <none>        Ubuntu 18.04.2 LTS   4.15.0-46-generic   docker://18.9.3
kuben2   Ready    <none>   39d   v1.13.0   192.168.178.78   <none>        Ubuntu 18.04.2 LTS   4.15.0-46-generic   docker://18.9.3
kuben3   Ready    <none>   39d   v1.13.0   192.168.178.79   <none>        Ubuntu 18.04.2 LTS   4.15.0-46-generic   docker://18.9.3

По просьбе П. Экамбарама: 

root@kubem1:/tmp# kubectl get po -n kube-system
NAME                                   READY   STATUS    RESTARTS   AGE
calico-node-bgjdg                      1/1     Running   5          40d
calico-node-nwkqw                      1/1     Running   5          40d
calico-node-vrwn4                      1/1     Running   5          40d
coredns-69cbb76ff8-fpssw               1/1     Running   5          40d
coredns-69cbb76ff8-tm6r8               1/1     Running   5          40d
kubernetes-dashboard-57df4db6b-2xrmb   1/1     Running   5          40d

1 Ответ

1 голос
/ 11 марта 2019

Я нашел решение для моей "Проблемы".
Такое поведение было вызвано изменением в Docker v1.13.x, и проблема была исправлена ​​в kubernetes с версией 1.8.

Простое решение состояло в том, чтобы изменить правила пересылки через iptables.
Запустить следующий cmd на всех рабочих узлах: «iptables -A FORWARD -j ACCEPT»

Чтобы исправить это правильно, мне пришлось сообщить кубу-Прокси CIDR для стручков.Теоретически это можно решить двумя способами:

  • Добавить «--cluster-cidr = 10.0.0.0 / 16» в качестве аргумента в командную строку kube-proxy (в моем случае в служебном файле systemd)
  • Добавьте 'clusterCIDR: "10.0.0.0/16" в файл kubeconfig для kube-proxy

В моем случае аргумент строки cmd не оказал никакого влияния.
Когда я добавил строку в мой файл kubeconfig и перезапустил kube-proxy на всех рабочих узлах, все работает хорошо.

Вот запрос github о слиянии для этой проблемы "FORWARD": ссылка

...