всё понятно, фича добавлена 7 ноября https://github.com/sorintlab/stolon/commit/979c44c1bfabea176683eeb79a42c89f13e6c890 В релиз пока не вошла

в 0.13 нет, а в 0.12 есть типо?

в 0.13 нет, а в 0.12 есть типо?

нет, должна появиться позже 0.13

нет, должна появиться позже 0.13

блин))) а как тогда рестартиться?)) и почему у вас всё ок автоматом перезагружается?))

киперов чтоль килять?))

kubectl delete всё такое

блин))) а как тогда рестартиться?)) и почему у вас всё ок автоматом перезагружается?))

ручками, только надо соблюдать порядок рестарта мастера реплик. У меня собственноручная сборка)

ручками, только надо соблюдать порядок рестарта мастера реплик. У меня собственноручная сборка)

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

ручками, только надо соблюдать порядок рестарта мастера реплик. У меня собственноручная сборка)

и ручками имеется ввиду через kubectl delete pod или есть команда через stolonctl? в даном случае ничего такого не нашел

Google certified associate cloud engineer course is free on udemy for the first 5,000 folks using promo code GCPFREEACE https://www.udemy.com/google-certified-associate-cloud-engineer/

и ручками имеется ввиду через kubectl delete pod или есть команда через stolonctl? в даном случае ничего такого не нашел

первое, касательно порядка рестарта при смене shared_buffers это особо значения не имеет

первое, касательно порядка рестарта при смене shared_buffers это особо значения не имеет

понял, спасибо за ответы и как я понимаю при statefulset подах, он ведь не должен пересоздавать вольюм? а то попробовал удалить под который воркер и в амазоне нового вольюма не создалось, то есть по сути данные не должны затереться? бэкапы само собой сделал))) хочу просто понять как оно функционирует

понял, спасибо за ответы и как я понимаю при statefulset подах, он ведь не должен пересоздавать вольюм? а то попробовал удалить под который воркер и в амазоне нового вольюма не создалось, то есть по сути данные не должны затереться? бэкапы само собой сделал))) хочу просто понять как оно функционирует

тут я не знаю)

тут я не знаю)

ну вроде нормально всё правда именно мастер надо прям ощутимо долго рестартилась и висела в статуск СontainerCreating, ожидал когда полечится ошибка: Multi-Attach error for volume "pvc-b1cf0ebe-38da-11e9-9644-0252ffea31e4" Volume is already exclusively attached to one node and can't be attached to another слава богам полечилось и запустилось

ну вроде нормально всё правда именно мастер надо прям ощутимо долго рестартилась и висела в статуск СontainerCreating, ожидал когда полечится ошибка: Multi-Attach error for volume "pvc-b1cf0ebe-38da-11e9-9644-0252ffea31e4" Volume is already exclusively attached to one node and can't be attached to another слава богам полечилось и запустилось

а порядок рестарта надо соблюдать при смене max_connections, чтобы на репликах не было меньше, чем на мастере

а порядок рестарта надо соблюдать при смене max_connections, чтобы на репликах не было меньше, чем на мастере

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

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

тогда реплики не запустяться, будет фатальная ошибка

тогда реплики не запустяться, будет фатальная ошибка

О_О

вот же блин, стремно конечно

Смотрите какая прелесть https://www.cncf.io/the-childrens-illustrated-guide-to-kubernetes/

Смотрите какая прелесть https://www.cncf.io/the-childrens-illustrated-guide-to-kubernetes/

Это с капитаном куб? Или что то новое

его же уже спойлили на докладе в яндексе

Это с капитаном куб? Или что то новое

С капитаном видимо этот https://cloud.google.com/kubernetes-engine/kubernetes-comic/

https://web.archive.org/web/20171108051103im_/https://deis.com/images/blog-images/kubernetes-illustrated-guide-illustration-10.png

Покажу девушке через час. Посмотрим, поймёт ли она Kubernetes.

нет конечно. Написано же — для детей.

Покажу девушке через час. Посмотрим, поймёт ли она Kubernetes.

Как похвастаться что у тебя есть девушка 😂

https://www.operatorhub.io/

https://www.operatorhub.io/

А что такое Auto Pilot?

А что такое Auto Pilot?

где ты такое увидел?

Нашел https://github.com/operator-framework/operator-sdk/blob/master/doc/images/operator-maturity-model.png?raw=true

Как похвастаться что у тебя есть девушка 😂

https://www.youtube.com/watch?v=JWwuwr9ez0I

а, ну prometheus operator вполне себе автоматический пилот

а, ну prometheus operator вполне себе автоматический пилот

Хрен там https://www.operatorhub.io/operator/prometheusoperator-community.0.22.2

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

Как похвастаться что у тебя есть девушка 😂

Ну, это не редкость.

ну вроде нормально всё правда именно мастер надо прям ощутимо долго рестартилась и висела в статуск СontainerCreating, ожидал когда полечится ошибка: Multi-Attach error for volume "pvc-b1cf0ebe-38da-11e9-9644-0252ffea31e4" Volume is already exclusively attached to one node and can't be attached to another слава богам полечилось и запустилось

А как ты так рестартил что лок с волюма не снялся?

А как ты так рестартил что лок с волюма не снялся?

ну рестарт сделал по очереди сначала первый воркер kubectl delete pod keeper-0 потом второй оба быстренько обновились а вот когда сделал тоже самое для мастера, то вот такая хрень была выше

ну рестарт сделал по очереди сначала первый воркер kubectl delete pod keeper-0 потом второй оба быстренько обновились а вот когда сделал тоже самое для мастера, то вот такая хрень была выше

Оч странно, так как лок держит нода, если я не ошибаюсь, и при таком рестарте нода должна понять что лок снимается

Оч странно, так как лок держит нода, если я не ошибаюсь, и при таком рестарте нода должна понять что лок снимается

ну вот странно что с двумя всё четко прошло

Обычно лок зависает если падает нода. И раньше решали это удалением ноды из кластера :)

Обычно лок зависает если падает нода. И раньше решали это удалением ноды из кластера :)

чур чур😆

ну вот странно что с двумя всё четко прошло

Они может на тех же нодах остались

Они может на тех же нодах остались

а мастера перевел на другую, отличную от той, на которой он был ранее?

а мастера перевел на другую, отличную от той, на которой он был ранее?

А как было то? Ты же рестартил:)

А как было то? Ты же рестартил:)

ахах так я ж не смотрел на какой он ноде был до и на какой стал после)))

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

в следующий раз постараюсь не забыть и понаблюдать

в следующий раз постараюсь не забыть и понаблюдать

Как лучше от лока избавляться тебе расскажет @kvaps . Вроде у него в фенсинге это реализовано.

Как лучше от лока избавляться тебе расскажет @kvaps . Вроде у него в фенсинге это реализовано.

ну он сам избавился повисел контейнер минуты две в статусе ContainerCreating и всё кстати он свой вольюм отцепил в этот момент и потом обратно приатачил его

https://www.asykim.com/blog/deep-dive-into-kubernetes-external-traffic-policies

наглядное объяснение разницы между externalTrafficPolicy: Cluster и externalTrafficPolicy: Local

Правильно ли я понимаю, что для пода интерфейс выделяет pause? Есть может дока, где описано, как происходит при hostNetwork: true? Тогда ведь процесс происходит по другому. Хотелось бы в картинках это понять

https://www.asykim.com/blog/deep-dive-into-kubernetes-external-traffic-policies

А можно настроить metallb (например) в HA кластере на 3 ноды, чтобы при запросе на внешний ip кластера (который через haproxy кидает запрос на одну из нод) если под запущен на другой ноде запрос отправлялся на неё?

А можно настроить metallb (например) в HA кластере на 3 ноды, чтобы при запросе на внешний ip кластера (который через haproxy кидает запрос на одну из нод) если под запущен на другой ноде запрос отправлялся на неё?

под с чем, с haproxy?

под с чем, с haproxy?

Не, под просто через сервис и ингресс хочет наружу предоставить что-нибудь по http

Есть вариант ставить haproxy на каждую ноду, но тогда не очень понятно зачем нужен metallb

Правильно ли я понимаю, что для пода интерфейс выделяет pause? Есть может дока, где описано, как происходит при hostNetwork: true? Тогда ведь процесс происходит по другому. Хотелось бы в картинках это понять

Все просто, pause запускается всегда, хоть с hostNetwork: true, хоть нет, все остальные контейнеры в поде запускаются с --network-from

Не, под просто через сервис и ингресс хочет наружу предоставить что-нибудь по http

Ты сломал мой мозг

просто представь себе, что MetalLB - это что-то вроде keepalived, но IP на ноде появляется только тогда когда есть endpoint у сервиса

Ты сломал мой мозг

Ну типа есть под с nginx, есть сервис для него и ingress на этот сервис, я хочу, чтобы снаружи всё работало при 1 реплике в кластере с 3 нодами (ноды и мастера одновременно). Я ставлю metallb, настраиваю ingress при установке на использование load balancer, даю ему список ip из 3-х ip нод кластера (они в принципе внешние, но dns настроен на haproxy, который перекидывает запрос на один из них, наверное через round robin). Metallb выделяет для ingress один из внутренних ip, в итоге она нода отвечает на запросы и прекрасно работает, остальные две - нет. Хочется, чтобы остальные две тоже отвечали, но при этом не настраивать на них haproxy и т.п. штуки

> даю ему список ip из 3-х ip нод кластера IP-адреса которые ты выдешь MetalLB не должны существовать где либо

просто представь себе, что MetalLB - это что-то вроде keepalived, но IP на ноде появляется только тогда когда есть endpoint у сервиса

А, в этом контексте понятнее. То есть нужна ещё поддержка инфраструктуры для всяких vrrp и т.п.

А, в этом контексте понятнее. То есть нужна ещё поддержка инфраструктуры для всяких vrrp и т.п.

vrrp не нужен, но с антиспуфингом скорее всего не заработает

Либо в моем кейсе можно сделать через vlan с каким-нибудь локальным плавающим ip и пробрасывать на него трафик через haproxy на каждой из нод

vrrp не нужен, но с антиспуфингом скорее всего не заработает

У хецнера пробовал - только через их апи если только перекидывать (

Либо в моем кейсе можно сделать через vlan с каким-нибудь локальным плавающим ip и пробрасывать на него трафик через haproxy на каждой из нод

а зачем на плавающий IP, если через ha-proxy можно сразу на сервис роутить?

а зачем на плавающий IP, если через ha-proxy можно сразу на сервис роутить?

Хм, то есть у меня получится схема haproxy (внешний) - haproxy (на одной из нод) - ingress - service - pod?

внешний - это где?

если у тебя есть внешний haproxy и всего три ноды, то почему-бы тебе просто не вывесить твой сервис как nodePort?

внешний - это где?

Ну хост (потенциально несколько) где-то рядом, который не в кубере

если у тебя есть внешний haproxy и всего три ноды, то почему-бы тебе просто не вывесить твой сервис как nodePort?

Но тогда не будет же плюшек ингресс с роутами и сертификатами?

Но тогда не будет же плюшек ингресс с роутами и сертификатами?

ну ты же ingress-controller вывешиваешь, так что будет все работать прекрасно

ну ты же ingress-controller вывешиваешь, так что будет все работать прекрасно

Хм, спасибо, покопаю в эту сторону, звучит логично 👍

как-то так

с metallb можно было бы сделать вот так:

где 10.0.0.10 плавал бы за nginx-ingress

Что лучше -- KVM или гитлер-гэ ?

с metallb можно было бы сделать вот так:

Не в бете вроде