Приветствую! Есть люди, кто запускал ceph хранилище внутри kubernetes? Напишите, пожалуйста, в лс

Приветствую! Есть люди, кто запускал ceph хранилище внутри kubernetes? Напишите, пожалуйста, в лс

рук?

rook.io?

Не слышал о таком Я пытался использовать их helm чарты http://docs.ceph.com/docs/master/start/kube-helm/ Спасибо, сейчас почитаю

это поддержка удаленного хранилища имеджей - это и правда не реализовано. PV будут работать как обычно

Тоесть ceph с динамическим выделением блобов и pv спокойно работают?

Тоесть ceph с динамическим выделением блобов и pv спокойно работают?

yep, это вообще не часть за которую CRI твечает

Эт понятно Просто уточняю

Вот-вот. Рассказывайте. А то как буд-то в лужу перднули...

вот это понимаю профессиональная дискуссия

вот это понимаю профессиональная дискуссия

Вот именно

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

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

господа, а кто-то пробовал стартовать etcd как статик под в кублете?

Так и надо, на мастерах

при смерти кубелета мастера, умирает и etcd рядом

Присмерти kubelet контейнеры запущенные им остаются работать

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

я все таки не поняю, я сейчас про tcp уровень так, вот я инициализирую etcd клиента передаю ему на вход 3 ноды etcd он при иниицализации их все опросит и узнает какой мастер? а дальше будет "слать на него"?

для меня в моей практике - считаю, что кубер по крайней мере должен быть в трех ДЦ, чтобы еще и под CDN

Обновления идут через лидера etcd, а он один.я так не запускал, но мне кажется аписерверу не очень понравится если он далеко. Да и самому кластеру etcd может быть сложно жить с пингами до других серверов кластера по 50-200мс да еще и нестабильными - частые перевыборы, таймауты еще какая нибудь хрень точно повылазит

Они все начнут в состоянии candidate, спустя какое-то время у одного произойдет election timeout, после которого он начнет голосование за лидера в term 1, оставив голос за самого себя и попросив у соседей. На первой же или какой-нибудь там итерации кто-нибудь изберется, после чего начнет слать команду appendEntries всем фолловерам. Фолловеры за счет этого знают, кто сейчас мастер и куда роутить приходящий запрос.

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

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

Если это не соцопрос, то лучше сразу вопрос писать :)

Подскажите а поды могут общатся друг с другом по ClusterIP?

Если это не соцопрос, то лучше сразу вопрос писать :)

😁👍 к делу: хочется узнать столкнулись ли с какими то проблемами, потому что в режиме 'чисто заценить' штука кажется удобной. Но вот различные его прослойки в виде cattle как то не внушают доверия. Документация очень бедная, если говорить о 2.0 версии. Вот и хочется мини отзыв о возможных граблях, первые из которых его настройка с SSL

etcd очень чувствителен к латенси - думаю что в разные ДЦ не разнести ноды одного кластера

Подскажите а поды могут общатся друг с другом по ClusterIP?

хмм ClusterIP это тип сервиса, причем тут общение подов?

Подскажите а поды могут общатся друг с другом по ClusterIP?

Да

Подскажите а поды могут общатся друг с другом по ClusterIP?

Вам в сторону ENV переменных и внутреннего DNS

Вам в сторону ENV переменных и внутреннего DNS

понял спасибо

Подскажите а поды могут общатся друг с другом по ClusterIP?

это уже общение “через сервис” получается

это уже общение “через сервис” получается

собственно да. Про это и имел в виду.

просто за одним сервисом может сидеть несколько реплик одного пода - поэтому это не общение подов

просто за одним сервисом может сидеть несколько реплик одного пода - поэтому это не общение подов

👍

просто за одним сервисом может сидеть несколько реплик одного пода - поэтому это не общение подов

Да не правильно выразился. Интересно стало могут ли сервисы общатся друг с другом

Да не правильно выразился. Интересно стало могут ли сервисы общатся друг с другом

Общение сервисов, если речь идёт о ресурсе Service - не есть общение подов

Общение сервисов, если речь идёт о ресурсе Service - не есть общение подов

Да я уже выше написал что не правильно выразился.

Общение сервисов, если речь идёт о ресурсе Service - не есть общение подов

я понял

👍

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

kubedns вообще все должен решать

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

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

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

Вы серьезно?

человек не может ходить - это трение между обувью и объектами на земной поверхности

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

хмм ну ок, сервисы могут общаться также как и две днс записи

мы про сервисы в кубе или какие-то абстрактные?

Сервисы в кубе как минимум могут общаться через ingress

они могут и без ингреса )

ингрес для внешних пользователей

Вы серьезно?

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

Да кто ж спорит?

это тоже самое, что “в гите нет веток”.

они могут и без ингреса )

Env, dns?

технически веток нет, но все подразумевают, что есть

Env, dns?

нуда, через внутренний днс-сервис

точнее, “получая маршруты из внутреннего днс-сервиса”

думаю, что выбрана неверная аналогия. Аналогия сервисов это домены, никто же не говорит что домены общаются

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

Под сервисом не поды, а эндпоинты🤫

общаются сервера куда указывают домены

kubedns вообще все должен решать

о чем и речь

Првет! Кто нибудь юзает Crunchy PostgreSQL for Kubernetes ?

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

точнее на локалхост мне надо

гайз, я хочу странного. мне нужен автоматический способ понимать, что current state == desired state для некоторого множества кубернетесовых артефактов - деплойментов, сервисов, ингрессов и т.п. покажите, куда копать, пожалуйста.

по стетйам ansible хорошо) описал стейт и в крон его

у меня docker не может спулить имаджи для etcd и flannel с quay.io, у вас все ок?

Прикрыли много ркн

гайз, я хочу странного. мне нужен автоматический способ понимать, что current state == desired state для некоторого множества кубернетесовых артефактов - деплойментов, сервисов, ингрессов и т.п. покажите, куда копать, пожалуйста.

я бы терраформ посоветовал, сириусли

он впринципе для этого и разрабатывался

я бы терраформ посоветовал, сириусли

вообще про другое.

поясните вашу проблематику

ты разворачиваешь тестовый стенд со всей инфраструктурой в k8s. развёртывание занимает существенное время, причем сложнопредсказываемое. потом надо стартовать интеграционные тесты. нужно определять момент, когда "всё закончилось, можно стартовать тесты".

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

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

ээ, а нельзя опираться на readiness check который отдает каждый под и просто дожидаться RUNNING?

воот.

для подов - можно.

а для деплойментов (если он накатился инкрементально и там поехал процесс) - уже нельзя. нельзя быть уверенным что Service аллоцировался и взлетел.

ну или если можно - то расскажите как. об этом собственно и вопрос.

другими словами, вопрос состоит в том, как определить что deployment ready, если его обновили инкрементально?

deployment

например да.

возможно проблема не технического плана. я знаю что большие дяди для такого рода задач на Ынтырпрайзе делают cannary upgrade и через метрики сервисов понимают что деплоймент/апгрейд деплоймента прошел успешо.

но это вряд ли стоит делать в вашем случае.

речь о тестовом стенде.

то есть костыльное решение - это sleep 60, обычно за это время всё успевает взлететь.