кто-то уже рекомендовал варианты?

https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

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

не понял в чем проблема. стучаться надо в myapp.svs.cluster.local , где myapp это имя сервиса

я не хочу хардкодить DNS рекорды в конфигах, вот в чем

разве при использовании любого service discovery тебе не нужно хардкодить имена в конфигах? типа webapp.service.consul если юзать Consul

ну ты по сути должен просто хранить некие keys и креды для подключения к service discovery, чтобы пойти туда и получить values

допустим, на основании labels. в таком случае ты сможешь похендлить изменение хостнейма в поде, а в случае хардкода DNS имени - нет

какая тебе разница как под называется? ты ходишь в днс по имени сервиса https://kubernetes.io/docs/concepts/services-networking/service/

> Assume a Service named foo in the Kubernetes namespace bar. A Pod running in namespace bar can look up this service by simply doing a DNS query for foo. A Pod running in namespace quux can look up this service by doing a DNS query for foo.bar.

Из днс вернётся кластер ип, который пробрасывается автоматически на поды, так что он не меняется

по сути это как внутри проксмокса днс...

но я не хочу хардкодить все это в конфигах, а хочу делать запрос в апишку такого типа ?labelSelector=environment%3Dproduction,tier%3Dfrontend и получить DNS

я бред могу писать, думаю. ну, потому что могу, ибо не разорбрался еще в вопросе навигации по аппам динамической

короче, проще всего написать небольшой враппер свой какой-то)

а очень хочу понять как это сделать красиво (ранее использовали самопальные решения везде: внуково - из админки список, далее обновление дхцп -> днс, в биллингах - днс+ca внутри контура + такой же днс на опорном домене снаружи, а внутри разруливалось все не по именам, а, таки, по ip которые редко менялись)

но я не хочу хардкодить все это в конфигах, а хочу делать запрос в апишку такого типа ?labelSelector=environment%3Dproduction,tier%3Dfrontend и получить DNS

пункт выше про внуково, ага. нормально работало на 800, что ли гаджетах в двух локациях (в каждой центральный сервак)

ну, проще всего сделать так, как выше вон предлагают, рассчитывая, что имя сервиса и DNS на его основании будет как single source of truth, что для меня очень деревянным методом выглядит

но я не хочу хардкодить все это в конфигах, а хочу делать запрос в апишку такого типа ?labelSelector=environment%3Dproduction,tier%3Dfrontend и получить DNS

ну вы вот этот selector= хотите хардкодить, а результат селектора хардкодить не хотите почемуто

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

да ниче не гибко. никакой гибкости не надо. везде прибиваете myservice как конечная точка контакта и всё. оно будет брать myservice из того же namespace где и клиент

тогда если у вас есть 2 неймспейса: prod и staging, то конфиги приложений внутри одинаковы и ничего запрашивать/темплейтить не надо

и там и там приложения ходят в myservice

service это и есть набор селекторных ключей. Если хочется ещё гибче можно смотреть на сервис-брокеры

Посоны, а кто flannel настраивал, скажите, вы apiserver запускаете в контейнере flannel сети, или снаружи? А то у меня проблема

Провайдер дропает пакеты, которые имеют srcip отличный от хоста. Когда я, например, внутри пода обращаюсь к kubernetes.default то от минорной ноды улетает пакет в сторону мастера c srcip пода (провайдер такое дропает)

попробовал в kubeproxy добавить опцию --masquerade-all но чет она не работает походу.. пакеты не маскардятся =(

Есть вариант сам apiserver запускать в контейнере, тогда весь трафик до него будет ходить по оверлейной сети.. вот думаю, кошер ли это или зашквар?

Провайдер дропает пакеты, которые имеют srcip отличный от хоста. Когда я, например, внутри пода обращаюсь к kubernetes.default то от минорной ноды улетает пакет в сторону мастера c srcip пода (провайдер такое дропает)

flannel же оборачивает пакеты в свои, как src ip там не хостовый может быть?

В смысле оборачивает? он жеж просто предоставляет сеть для IP подов. Никаким маскардингом он не занимается

IP подов совпадают с flannel subnet и c докер --bip

Вот только когда запрос уйдет на внешние endpoints, то пакет покидает ноду и srcip у него остается фланеловский

по логике, тут kube-proxy должен маскардить их

FLANNEL_IPMASQ=true

фланел умеет

коллеги у кого кореос последний и 1.6.1?

заметил, что при запуске rkt gc кубелет начинает вести себя неадекватно до перезапуска

не может получить статус контейнеров и рестартит их, а также ломится в старую директорию удаленного rkt pod а

кто-то​ сталкивался?

альфа кореос?

в том то и дело что стейбл

ip-masq норм. Спасибо =)

gc нормально отрабатывает, но кубелету об этом никак не сообщает и он видимо теряется)

gc нормально отрабатывает, но кубелету об этом никак не сообщает и он видимо теряется)

у вас кублет поды в докере пускает или в rkt?

поды в докере

рокетом кореос запускает фланнел

да, и сам кюблет тоже рокетом. но причем тут rkt gc и кублет тогда?

нет, сам кубелет у меня бинарником, когда gc перемещает старый контейнер фланнела в другую директорию, кубелет перестает видеть эту директорию на своем месте и почему то теряет статус докер подов

kubelet[5869]: W0417 09:55:34.508259 5869 raw.go:87] Error while processing event ("/var/lib/rkt/pods/run/3338e455

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

почему kubelet вообще видит контейнер flannel?

запускайте kubelet через kubelet-wrapper , у нас так работает и вроде бы проблем нет

я думал попробовать перейти с бинарника на kubelet-wrapper в рокете, у кого то есть такой конфиг с последними версиями?

у вас 1.6.1 и последний стейбл?

у нас 1.6.1 и beta

ок, попробую враппер

а ноды у вас ребутятся?

https://github.com/kubernetes-incubator/kube-aws/blob/e6de3dc6e45f8083013f23e24fade18305567cf5/core/controlplane/config/templates/cloud-config-worker#L137-L209

вот наша пускалка, подпилите напильником по вкусу :)

а ноды у вас ребутятся?

нет, оно несовместимо с кубом

просто просто новый контейнер фланнел создается только после ребута

если gc ничего не перемещает в мусор у меня проблем тоже нет

хорошая пускалка спасибо за линк

что-то не так если kubelet вообще заботит rkt контейнеры. все что он должен видеть - контейнеры в докере

ну видимо бинарник видит и то и то

надо попробовать его в rkt и не дать ему монтировать var/lib/rkt

хотя в вашем скрипте он примонтирован

-volume var-lib-rkt,kind=host,source=/var/lib/rkt \

если есть тестовая нода попробуйте убить контейнер с фланнел и подождать/запустить rkt gc

если есть тестовая нода попробуйте убить контейнер с фланнел и подождать/запустить rkt gc

ОК, я на ноде :) убить фланел, rkt gc, затем что?

смотреть лог)

если gc перенесет папку с убитым подом начнется активность кубелета

там просто политика gc не сразу переносить а через сколько то часов

может он просто отработает и не перенесет, по дефолту вроде через 12 часов он переносит в одну папку а еще через 12 удаляет

тишина

rkt list

что говорит?

https://coreos.com/rkt/docs/latest/subcommands/gc.html

UUID APP IMAGE NAME STATE CREATED STARTED NETWORKS 00091d0e hyperkube quay.io/coreos/hyperkube:v1.6.1_coreos.0 running 1 day ago 1 day ago 8182c0c8 flannel quay.io/coreos/flannel:v0.7.0 running 2 minutes ago 2 minutes ago list: 2 error(s) encountered when listing pods: list: ---------------------------------------- list: Unable to read pod 4c1c0eb7-ff8a-4ed7-8b08-0028b44d07c3 manifest: error reading pod manifest list: ---------------------------------------- list: Unable to read pod 657337f6-705f-4b57-9ae8-79e265af2476 manifest: error reading pod manifest list: ---------------------------------------- list: misc: list: rkt's appc version: 0.8.10 list:

похоже он их не может gc :) там был баг в рокете связаный со stage1 про это

хм