Не понял, что ты хочешьсделать?

смотри, есть 10 нод, - я создаю deployment, в котором описано приложение ABC и 3 реплики для него - я создаю сервис с ExternalIP который редиректит весь трафик на эти три контейнера, так? - теперь я хочу создать еще один deployment ABC-IP, который запустится на одной из тех нод, на который работает приложение ABC

пишишт лабел на три ноды kubectl lavbel no <имя ноды> ABC=true

и пишишь в деплой nodeSelector: abc: "true"

Ты просто мало курил)

возможно, но с каждым разом все интересней и интересней, мне кажется я уже крепко подсел на эту дурь :)

тогда шелдулер будет запускать поды только на нода с лейблом abc: true

http://blog.kubernetes.io/2017/03/advanced-scheduling-in-kubernetes.html

ок, а возможно label'ы назначать динамически? - мол запустилось приложение ABC, и ноде присвоился label run-app-ABC ?

после этого использовать его для деплоя следующего приложения

Делай запрос в API через serviceaccount

или грубо говоря сказать: "запустись там же, где и ABC"

То есть под запускается, получает данные о ноде на которой запущен и делает запрос в api сервер с постановкой лейбла.

Самое главное отрабоать логику, что бы эти лейблы чистить

-)

чем вы проводите нагрузочное тестирование на ваш кластер?

хайлоада нить иди

ab, wrk, jmeter, gatling, blazemeter taurus, yandex.tank

да, чет не нравится мне это решение, ес честно

почитай статейку выше) Должна помочь. У тебя как раз нужная задачка

locust.io

ab, wrk, jmeter, gatling, blazemeter taurus, yandex.tank

а ещё есть yandex.cocain )

ок, сча займусь

так вот сначала yandex.cocain потом yandex.tank -)

реально из вышеописанного только ab и jmeter постоянно пользую. гатлинг очень хорош, но не хватает декларативного описания сценариев

И никак иначе

https://artillery.io/ вот еще нашел

смотри, есть 10 нод, - я создаю deployment, в котором описано приложение ABC и 3 реплики для него - я создаю сервис с ExternalIP который редиректит весь трафик на эти три контейнера, так? - теперь я хочу создать еще один deployment ABC-IP, который запустится на одной из тех нод, на который работает приложение ABC

вам нужен podAffinity, лейблами пропишите для пода ABC-IP : запускаться там, где уже есть ABC под

он самый, спасибо

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

а вот это плохо. Но что если ABC и ABC-IP будет описан в одном yaml и будут апдейтиться одновременно?

или это не имеет значения?

поможет, но не гарантирует

в теории ABC-IP может прилететь к поду ABC, который вот вот будет убит :)

а kubernetes сам двигает podы, если нода не умерла?

может вам ABC-IP запустить, как еще один контейнер в ABC?

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

если вы гарантируете , что сначала полностью деплоите ABC , потом когда оно все устоялось, запускаете ABC-IP, то ОК. но ведь тогда будет период, где ABC работает без ABC-ip

незнаю насколько вам это важно

может вам ABC-IP запустить, как еще один контейнер в ABC?

это был бы идеальный вариант, но он должен быть запушен с hostNetwork: true

ну и что

а нет

если вы гарантируете , что сначала полностью деплоите ABC , потом когда оно все устоялось, запускаете ABC-IP, то ОК. но ведь тогда будет период, где ABC работает без ABC-ip

это не страшно, т.к. все что делает ABC-IP - это вешает внешний IP на ноду

ха, тогда вам все равно

пускайте его где угодно

хоть отдельно от ABC

этот ExternalIP он как NodePort , трафик отправится в поды, даже если они на других нодах

там не ExternalIP

да, потому я и думаю что podAffinity хорошо здесь подойдет

не, там как раз ExternalIP

ты же его через ip addr вешаешь на интерфейс) Это уже не extrnalIP

это вариант совсем из другой оперы

ты же его через ip addr вешаешь на интерфейс) Это уже не extrnalIP

externlIP это просто правило в iptables, все нормально

ну у сервис создается с ExternalIP, а контейнер этот ExternalIP на интерфейс одной из нод ассигнит

ну у сервис создается с ExternalIP, а контейнер этот ExternalIP на интерфейс одной из нод ассигнит

да. вам и podAffinity не нужен тогда

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

или kubernetes умеет еще net load учитывать?

и опять же, даже если и умеет, он никак не сможет связать что внешний трафик из-за этого dummy контейнера возникает

лучше гарантировать что все точки входа будут размазаны вместе с основными pod (которые делают основную работу)

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

а не, там preferredDuringSchedulingIgnoredDuringExecution есть, где можно веса выставлять, ух ты

мне прсто да же любопытно, сколько ты хочешь пустит трафика, что бы iptables загнулось

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

сделайте несколько externalIP

externalIP у меня будет тоже много

их то и хочу размазать по нодам

немного нубский вопрос http://blog.lwolf.org/post/going-open-source-in-monitoring-part-i-deploying-prometheus-and-grafana-to-kubernetes/ у меня прометей крутится как внутренний сервис и могу к нему подключаться напрямую через внутренний адрес, но я бы хотел, чтобы https://prometheus.example.com редиректил меня на внутренний сервис, если я подключен через впн и на 403, если стучусь просто из инета такое возможно вообще?

их то и хочу размазать по нодам

а смысл писать отдельный под с поднятием нужного ip если у нод и так есть ip и его можно назначить как externalIP?

у нод есть свой IP, который в случае если нода упадет потеряется тоже

дык у тебя же ряд IP будет работать

в случае если IP назначается контейнером, он передет на другую ноду

или все твои 2-3-5 ip должным быть 100% uptime

,,

??

ага, в том то и фишка

и внешний балансер получается не нужен

А где вообще балансировка идёт?

если у тебя ряд ip смотрит наружу, то где-то должна быть балансировка, или ты хочешь это решать чисто управленчиским ресурсом? (типо отдел А работает по ip А, отдел Б по ip Б)??

как то же мир доллжен узнать, что сервис работает по нескольких ip

Ну допустим есть 20 нод, у каждой есть два интерфейса, внешний (смотрит сразу наружу) и внутренний, на внутреннем у каждой ноды свой ip-адрес: 192.168.100.{1..20} Я хочу создавать сервис в этом кластере и вешать на внешний IP.

много сервисов

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