поэтому фронты пока отдельно

когда весь сервис упакуем в кластер, можно будет и фронты туда же

а пока приходится извращаться немношк

А как тогда доступен куб-днс снаружи?

всмысле?

откуда "снаружи?"

Видимо я не так прочитал первое сообщение, нгинкс не видит днс кубернетиса?

видит

я не понимаю, где проблема? ;)

kube-proxy на хосте надежно решает эту проблему посредством iptables

# iptables-save | grep -i dns -A KUBE-SEP-AGF24HBSCHVRB2IM -s 192.168.0.4/32 -m comment --comment "kube-system/kube-dns:dns" -j KUBE-MARK-MASQ -A KUBE-SEP-AGF24HBSCHVRB2IM -p udp -m comment --comment "kube-system/kube-dns:dns" -m udp -j DNAT --to-destination 192.168.0.4:53 -A KUBE-SEP-CF3CVUYBRRNMUR2I -s 192.168.0.4/32 -m comment --comment "kube-system/kube-dns:dns-tcp" -j KUBE-MARK-MASQ -A KUBE-SEP-CF3CVUYBRRNMUR2I -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp" -m tcp -j DNAT --to-destination 192.168.0.4:53 -A KUBE-SERVICES -d 10.222.222.222/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-SVC-TCOU7JCQXEZGVUNU -A KUBE-SERVICES -d 10.222.222.222/32 -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp cluster IP" -m tcp --dport 53 -j KUBE-SVC-ERIFXISQEP7F7OF4 -A KUBE-SVC-ERIFXISQEP7F7OF4 -m comment --comment "kube-system/kube-dns:dns-tcp" -j KUBE-SEP-CF3CVUYBRRNMUR2I -A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment "kube-system/kube-dns:dns" -j KUBE-SEP-AGF24HBSCHVRB2IM

и так на каждом хосте

не руками, естественно

все эти правила динамически формирует kube-proxy

который запущен на всех хостах

таким образом я могу прямо на bare-metal машине использовать кластерный днс (ну и любые другие endpoint'ы)

Я через nodeport обычно прокидывал сервисы

а зачем?

приходится прокси перенастраивать

чтобы он другой рейнж портов мог юзать

Ну это меня и смущало

А как у тебя описание сервиса выглядит?

https://gist.github.com/Bregor/5d27a6d0cb722d743bb7f17da132edfd

это тыптыщеконфиг

а сервисы как обычно

ща

Я что то не понял про то как указать cluster ip на bare

а зачем?

ты же имя в сервисе пишешь

и по имени к нему и обращаешься

разрешение имени в адрес делает kube-dns

А доступен он также на всех нодах?

Как нодпорт?

ну на всех, где kube-proxy есть

или руками iptables настроен ;)

добавил сервис в гист: https://gist.github.com/Bregor/5d27a6d0cb722d743bb7f17da132edfd

Ясно, видимо меня смутила фраза в доке, что cluster ip предоставляется сервис провайдером

Спасибо за экскурс)

это когда у тебя type: LoadBalancer

и над тобой GCE или LBE

тогда айпи тебе выдает провайдер

а на bare metal тебе сам черт не брат :D

:)

собственно адреса для сервисов выдаются аписервером

ориентируется он при этом на --service-cluster-ip-range=10.222.0.0/16

ну в смысле это у меня там 10.222.0.0/16

не помню, что там по-умолчанию

Хм, так это дополнительный адрес? Или что это за range?

хехе

об это я бился головой дня три

(ну я там выше говорил уже, что я не очень умный)

короче

адреса для сервисов и адреса для подов - это два никак не пересекающихся множества

адреса для сервисов абсолютно не имеют никакого "физического" представления

они нигде не терминируются

и нужны только для роутинга до нижележащих ресурсов (подов)

а вот адреса подов имеют под собой некоторое "физическое" отображение

и должны кем-то выдаваться

это может быть CNI, docker-networking, etc

А мы про адреса сервисов

Да , про них я знаю)

Я думал мы продолжаем тему внешних

нене

Думаю какой там еще ренж вроде все только прояснилось)

мы про то, что внутри кластера, да

Когда я открыл для себя флажок iptables у куб прокси все стало гораздо понятнее с кластерными и прочими айпишниками)

ммм?

оно ж по-дефолту iptables

или ты о чем?

Да вроде нет как раз :)

--proxy-mode=: Which proxy mode to use: 'userspace' (older) or 'iptables' (faster). If blank, look at the Node object on the Kubernetes API and respect the 'net.experimental.kubernetes.io/proxy-mode' annotation if provided. Otherwise use the best-available proxy (currently iptables). If the iptables proxy is selected, regardless of how, but the system's kernel or iptables versions are insufficient, this always falls back to the userspace proxy.

а, хотя у меня явно указано, да

может по-дефолту и не оно

command: - /hyperkube - proxy - --proxy-mode=iptables - --kubeconfig=/etc/kubernetes/kubeconfig.yaml

вот так запускаю

Вот вот :)

ок-ок, был неправ

Сейчас уже по дефолту иптаблес, я когда ставил был по дефолту юзерспейс

Приём) Есть кто бодрствующий?

Есть вопрос) Допустим, имеем такой расклад: kubectl get svc --namespace kube-system NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE elasticsearch-logging 10.100.0.80 <none> 9200/TCP 1d heapster 10.100.0.10 <none> 80/TCP 4d kibana-logging 10.100.0.146 <none> 5601/TCP 1d kube-dns 10.100.0.100 <none> 53/UDP,53/TCP 13d kubernetes-dashboard 10.100.0.107 <none> 80/TCP 6d monitoring-grafana 10.100.0.77 <none> 80/TCP 4d monitoring-influxdb 10.100.0.188 <none> 8083/TCP,8086/TCP 4d Интересует такой момент - если у нас во время нагрузки одной ноды какой-то из этих подов будет перенесён на другую ноду - IP адрес сохранится или тоже поменяется?