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 не был привязан к какой-то конкретной ноде, а был привязан к конкретному сервису

ну тебе впринцепе пофиг где и какой ip весит

верно

главное, что бы все были routeable

все routable, т.к. находятся в одном L2-сегменте

ты боишься что нода с externalIP загнётся под напором трафика?

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

ты хочешь что бы на нодах запускался только один под с IP ?

ERROR: S client not available

ты боишься что нода с externalIP загнётся под напором трафика?

ну да, и в случае если откажет, минимизировать downtime для остальных сервисов тоже

ты хочешь что бы на нодах запускался только один под с IP ?

в идеале да, но теоретически podов с IP может быть больше чем нод

на самом деле я уже нашел решение

Копать здесь Node Affinity/Anti-Affinity

-)

ага, это как раз и есть podAntiAffinity с preferredDuringSchedulingIgnoredDuringExecution

чуть попозже попробую и приведу готовый yaml, если интересно

ну в общем да, таким образом все внешние IP прекрассно размазываются по всему кластеру: https://gist.github.com/kvaps/889fe2b9eeab9f205c818ab1d1af56a9

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

Взял потестить новый ovn/ovs плагтн, вроде все собралось, но вот возник вопрос в поднятии кластера, чтобы указать верный cni

В документации ничего актуального найти не удалось

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

на одном компьютере? если да, то minikube нужен

environment следующий, 3 x ubuntu 16.04.2 каждая virtualbox vm, master/node/node, cni ovs/ovn 2.7.2

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

я с помощью kubeadm подымал, полет нормальный, но я пока в тестовом режиме гоняю

через ansible не завелось

Не нашёл, как kubeadm сказать использовать cni ovs

На сайте нет этого

Цель завести плагин ovn-kubernetes

ток там нюанс один, пока конфиг в /etc/cni/net.d не положишь, ноды будут NotReady

#whois извините не представился, Максим, где работаю есть в linkedin, профиль сети и виртуализация, посоветовали в ru_devops, текущий проект k8s+ovs

ток там нюанс один, пока конфиг в /etc/cni/net.d не положишь, ноды будут NotReady

Что за конфиг?

Где вообще подробнее познакомится с этим, документация на сайте становится неактуальной на стадии написания по ходу

Не нашёл, как kubeadm сказать использовать cni ovs

Дя начала скажу что я kubernetes только начинаю изучать, и хоть у меня конфигурация похожа на твою, учти мои советы не претендуют на правильность.

Для начала установи на ноды kubeadm

потом сделай кластер с помощью kubeadm init и kubeadm join

Такая же фигня, я тыкал его раньше, но что-то там так сильно все изменилось, специфика работы основная не очень связана с этим просто

потом когда ты сделаешь кластер ноды у тебя будут NotReady

А как быть с тем что kubeadm бета и не рекомендовано для прода?

потом тебе нужно будет установить твой network плагин

С фланелью он у меня завелся, через kubeadm