IP-адреса сервисов kubernetes недоступны

Итак, у меня есть кластер kubernets, запущенный и работающий с использованием Руководства по ручной установке Kubernetes on CoreOS.

$ kubectl get no
NAME              STATUS                     AGE
coreos-master-1   Ready,SchedulingDisabled   1h
coreos-worker-1   Ready                      54m

$ kubectl get cs
NAME                 STATUS    MESSAGE              ERROR
controller-manager   Healthy   ok
scheduler            Healthy   ok
etcd-0               Healthy   {"health": "true"}
etcd-2               Healthy   {"health": "true"}
etcd-1               Healthy   {"health": "true"}

$ kubectl get pods --all-namespaces -o wide
NAMESPACE     NAME                                      READY     STATUS    RESTARTS   AGE       IP               NODE
default       curl-2421989462-h0dr7                     1/1       Running   1          53m       10.2.26.4        coreos-worker-1
kube-system   busybox                                   1/1       Running   0          55m       10.2.26.3        coreos-worker-1
kube-system   kube-apiserver-coreos-master-1            1/1       Running   0          1h        192.168.0.200   coreos-master-1
kube-system   kube-controller-manager-coreos-master-1   1/1       Running   0          1h        192.168.0.200   coreos-master-1
kube-system   kube-proxy-coreos-master-1                1/1       Running   0          1h        192.168.0.200   coreos-master-1
kube-system   kube-proxy-coreos-worker-1                1/1       Running   0          58m       192.168.0.204   coreos-worker-1
kube-system   kube-scheduler-coreos-master-1            1/1       Running   0          1h        192.168.0.200   coreos-master-1

$ kubectl get svc --all-namespaces
NAMESPACE   NAME         CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
default     kubernetes   10.3.0.1     <none>        443/TCP   1h

Как и в руководстве, я настроил сервисную сеть 10.3.0.0/16 и под сеть 10.2.0.0/16, Сеть Pod выглядит нормально, так как контейнеры busybox и curl получают IP-адреса. Но у сервисной сети есть проблемы. Первоначально я сталкивался с этим при развертывании kube-dns: сервис IP 10.3.0.1 не удалось связаться, поэтому kube-dns не смог запустить все контейнеры, и DNS в конечном итоге не работал.

Изнутри я могу воспроизвести проблему:

[ root@curl-2421989462-h0dr7:/ ]$ curl https://10.3.0.1
curl: (7) Failed to connect to 10.3.0.1 port 443: No route to host

[ root@curl-2421989462-h0dr7:/ ]$ ip route
default via 10.2.26.1 dev eth0
10.2.0.0/16 via 10.2.26.1 dev eth0
10.2.26.0/24 dev eth0  src 10.2.26.4

Кажется нормальным, что в контейнере есть только маршрут по умолчанию. Как я понял, запрос (к маршруту по умолчанию) должен быть перехвачен kube-proxy на рабочем узле, перенаправляется на прокси на главном узле, где IP транслируется через iptables на общедоступный IP-адрес мастера.

Кажется, есть общая проблема с настройкой sysctl bridge / netfilter, но в моей установке это нормально:

core@coreos-worker-1 ~ $ sysctl net.bridge.bridge-nf-call-iptables
net.bridge.bridge-nf-call-iptables = 1

У меня действительно трудное время для устранения неполадок, так как мне не хватает понимания того, для чего используется сервисный IP, как сервисная сеть должна работать с точки зрения потока трафика и как лучше всего отладить это.

Итак, вот мои вопросы:

  • Для чего используется 1-й IP сервисной сети (в данном случае 10.3.0.1)?
  • Является ли приведенное выше описание потока трафика правильным? Если нет, какие шаги необходимо предпринять, чтобы контейнер достиг IP-адреса службы?
  • Каковы наилучшие способы отладки каждого шага в потоке трафика? (Я не могу понять, что не так из журналов)

Спасибо!

Источник

3 ответа

Решение

Сервисная сеть предоставляет фиксированные IP-адреса для Сервисов. Это не маршрутизируемая сеть (поэтому не ожидайте ip ro ничего не показывать и не будет работать ping), но набор правил iptables, управляемых kube-proxy на каждом узле (см. iptables -L; iptables -t nat -L на узлах, а не на стручках). Эти виртуальные IP-адреса (см. Фото!) Действуют как прокси-сервер балансировки нагрузки для конечных точек (kubectl get ep), которые обычно являются портами модулей (но не всегда) с определенным набором меток, как определено в Сервисе.

Первый IP-адрес в сети Сервиса предназначен для доступа к самому kube-apiserver. Слушает порт 443 (kubectl describe svc kubernetes).

Устранение неполадок отличается в каждой сети / конфигурации кластера. Я бы вообще проверил:

  • Работает ли kube-proxy на каждом узле? В некоторых установках он запускается через systemd, а в других есть DeamonSet, который планирует Pod на каждом узле. В вашей настройке он развертывается как статические блоки, созданные самими кубелетами из /etc/kubernetes/manifests/kube-proxy.yaml
  • Найдите логи для kube-proxy и найдите подсказки (можете ли вы опубликовать некоторые из них?)
  • Измените kube-прокси на userspace Режим. Опять же, детали зависят от вашей настройки. Для вас это в файле, который я упоминал выше. присоединять --proxy-mode=userspace в качестве параметра на каждом узле
  • Работает ли оверлейная (под) сеть?

Если вы оставите комментарии, я свяжусь с вами..

Источник

У меня была та же самая проблема, и окончательное решение, которое работало для меня, состояло в том, чтобы включить переадресацию IP на всех узлах в кластере, что я пренебрег.

$ sudo sysctl net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1

Сервисные IP-адреса и DNS начали работать сразу после этого.

Источник

У меня была та же проблема, которая оказалась проблемой конфигурации в kube-proxy.yaml Для параметра "master" у меня был IP-адрес, как в - --master=192.168.3.240, но на самом деле он должен был быть похож на URL - --master = https://192.168.3.240/

К вашему сведению, мой kube-прокси успешно использует --proxy-mode=iptables (v1.6.x)

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