keepalived использует VRRP, по другому и быть не может

Оператор его конфигурит

наткнулся на инструкцию по подняьтию кубика https://habr.com/post/358264/#introduction дошел до строки export K8SHA_IPVIRTUAL=172.26.133.20 не могу понять в той же мне ли подсети вставить адрес или в другой(оставить все как есть)

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

я тут попроще инструкцию писал, как раз с keepalived: https://habr.com/post/427941/

Коллеги, подскажите нормально ли flannel живет не с дефолтной сеткой, а если я свою /16 укажу?

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

Приветствую! Подскажите, можно ли как то реализовать следующую стратегию. Есть deployment Hello-World, который живет в k8s. Хочется иметь его высокую доступность в кластере, с помощью запуска нескольких его реплик. Приложение не масштабируется, и в настоящем времени только один pod может работать с запросами. Можно как то сделать к примеру: Deployment Hello-World имеет 2 реплики, но запросы принимает только pod Hello-World-95trf543853853, но в случае если он будет не доступен, то запросы будут адресованы Hello-World-583jd2171273 ?

Подправил. Он запустислчя. На всех нодах запущен. Сделал маршруты все как нвдо. Только вот если пытаться попасть с одной ноды на другую. То показывает болт

а какой режим используешь? я flannel не помню как работает, но с hostgw там все было очень просто как-то

https://habr.com/company/flant/blog/346304/

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

по умолчанию там vxlan

Да stateless. К примеру одна нода ушла в режим обслуживания и все поды с нее были выселены. Этот под с приложением будет перезапущен на другом воркере, но все это время будет даунтайм. А тут хочу что бы его не было.

Да stateless. К примеру одна нода ушла в режим обслуживания и все поды с нее были выселены. Этот под с приложением будет перезапущен на другом воркере, но все это время будет даунтайм. А тут хочу что бы его не было.

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

Это как пример привел даунтаймом, может просто воркер помрет к примеру или другие факторы. Я чекал про это доки, точнее как планировщик ведет себя при недоступности воркера, но это другая история. Я просто перед тем как городить костыли, думал есть какие-то уже наработаные кейсы у людей из сообщевства в этом плане) Куб может поддерживать сколько укажу подов, и они будет работать, но тогда если трафик будет гулять между этими подами в deployment, то ничего работать не будет.

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

Наработанный кейс - писать приложения так, чтобы они горизонтально масштабировались :)

Приветствую! Подскажите, можно ли как то реализовать следующую стратегию. Есть deployment Hello-World, который живет в k8s. Хочется иметь его высокую доступность в кластере, с помощью запуска нескольких его реплик. Приложение не масштабируется, и в настоящем времени только один pod может работать с запросами. Можно как то сделать к примеру: Deployment Hello-World имеет 2 реплики, но запросы принимает только pod Hello-World-95trf543853853, но в случае если он будет не доступен, то запросы будут адресованы Hello-World-583jd2171273 ?

Буду думать. Подобные штуки делали с помощью Corosync и Pacemaker в свое время

Можно. Например через nginx - все бекенды кроме одного должны быть помечены backup ,тогда на них ничего отправляться не будет. Как этого добиться думайте сами. Ещё вариант - поставить сайдкар рядом со всеми и он будет пересылать запросы на текущий "главный" под или передавать локальному приложению если он сам главный. "главность" определяется скажем сортировкой по IP адресу всех записей в headless service и выбору первого в списке

Приветствую! Подскажите, можно ли как то реализовать следующую стратегию. Есть deployment Hello-World, который живет в k8s. Хочется иметь его высокую доступность в кластере, с помощью запуска нескольких его реплик. Приложение не масштабируется, и в настоящем времени только один pod может работать с запросами. Можно как то сделать к примеру: Deployment Hello-World имеет 2 реплики, но запросы принимает только pod Hello-World-95trf543853853, но в случае если он будет не доступен, то запросы будут адресованы Hello-World-583jd2171273 ?

В какой неймспейс надо класть сервисомнитор для пром-оператора? в monitoring? или в тот, в котором вертится приложение?

В том который пром оператор мониторит

Вообщем как ни крути, без умного балансироващика при файловере сколько то запросов потеряются (если клиенты без встроенных ретраев), но кто будет фейловить умный балансировщик, даже если он найдется такой? :)

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

коллеги, как вы разделяете среды дев, тест... через отдельные нэймспэйсы?

У меня два разных кластера с общей авторизацией и одним kubeconfig

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

"так вы что, и есть за меня будете?"

допустим на одном стоит строго прод, а на втором дев, тест... как вы делите дальше?

допустим на одном стоит строго прод, а на втором дев, тест... как вы делите дальше?

Он не будет бегать, он выберет и отошлет на под

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

Ну и по неймспейсу на приложение

там где prometheus kubectl get servicemonitor --all-namespaces=true NAMESPACE NAME AGE ... monitoring kube-prometheus-prometheus 2d monitoring monitoring-external-ceph 2d monitoring monitoring-external-galera 2d ...

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

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

В той же

а почему тогда написано $ minikube start Starting local Kubernetes v1.7.5 cluster... Starting VM... SSH-ing files into VM... ?

Напишите о результатах потом

Они точно не совместимы с оператором? И только через сервисмонитр работать?

Вижу на многих подах в интернета аннотации annotations: prometheus.io/scrape: "true" prometheus.io/port: "16686"

не знаю на сколько вопрос тематический, но все же задам. Вот есть в кубере энное количество сервисов. Тот же rabbitmq/postgres и всякое разное что не содержит из коробки экспортера для прометея. Как мониторите?

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