Механизм репликации - средство достижения HA и масштабируемости, а не штатный механизм переноса данных. В случае с кубером пода может скакать по кластеру как захочет (если конечно ее не прибить гвоздями). Плюс к этому может случиться так, что все 3 ноды будут недоступны в течение достаточно сжатого периода времени. Такое часто случается, например, в случае kops rolling update с изменением ig - оно просто по очереди терминейтит все ноды (сейчас вроде хоть дрейнить научилось) и порождает новые на их место
Ну а прибивать гвоздями по идеологии кубера не правильно, или почему?
Dmitry
Dmitry
Почему бы для гомогенности не сделать 3 связки хост-под и задеплоить туда 3 ноды распределенных приложений
Dmitry
Я тут зеленый, поэтому интересна идеология кубера
Ilya
товарищи, подскажите если какое-нибудь готовое решение для горизонтального мастабирования воркеров, но не в облаке, а on prem.
Ivan
tectonic?
ShadoWalkeR
Понятно - юмор был не оценен 😃
Ivan
🤔
ShadoWalkeR
Ну игра слов - название созвучно с танцем. А спеснями и плясками у нас индусы что либо делают (в фильмах). Вот и пошутил про индусскую разработку
Logan
Ivan
про танец понятно, а про индусов уже сложно
ShadoWalkeR
Ну фильмы Болливуда - там постоянно поют и танцуют
ShadoWalkeR
Проехали
Dmitry
Есть вопрос про неймспейсы, когда они становятся необходимы?
G72K
всегда
Dmitry
В плане "не default" неймспейс
G72K
всегда ) особенно если RBAC, а RBAC всегда )
Dmitry
ок, когда RBAC.
Dmitry
то есть для управлением доступа, ок. А кроме этого есть практическое применение?
Dmitry
RBAC работает для управления доступом к управлению ресурсами или как-то затрагивает коммуникацию между подами?
G72K
можно dev, staging, prod организовать удобно, все разграничить network policy чтобы случайно не ходило не туда. конфиги приложений статичные. надо redis идет просто на redis:6379 и придет в тот, что нужно
Dmitry
в сравнении с AWS это больше как IAM нежели Security Groups?
Dmitry
можно dev, staging, prod организовать удобно, все разграничить network policy чтобы случайно не ходило не туда. конфиги приложений статичные. надо redis идет просто на redis:6379 и придет в тот, что нужно
Ок, то есть по неймспейсам нормально среды раскладывать.
G72K
еще как.
Dmitry
Как вообще принято всем этим управлять? в AWS Cloudformation/Terraform, запускаешь aws cloudformation create-stack, а тут? через kubectl create -f ./template.yml ? или через helm? или я тчо-то путаю в сравнении категорий?
G72K
мой вариант helm template | kubectl apply -f - для всякого Г из интерентов, голый kubectl apply для своего Г
G72K
helm ни на что, кроме как затемплейтить не годится
Dmitry
аа, helm + kubectl apply это типа как jinja2 + cloudformation. Пардон такие аналогии)
Dmitry
а приложения как принято хранить-деплоить? для aws (ECS/EB) держу все обвязки в коде, и там просто eb deploy куда надо...
Dmitry
@rossmohax Спасибо, уже начало проясняться. Доки о такой базе не особо говорят. В частности о практических проверенных подходах)
G72K
у каждого свой путь) тут баталии как правильно регулярно проходят
Dmitry
да это ясно, но практические шорткаты люблю у настоящих людей слышать)
G72K
а приложения как принято хранить-деплоить? для aws (ECS/EB) держу все обвязки в коде, и там просто eb deploy куда надо...
создаете директорию ./kube и там храните, потом из ci деплоите. если ci агента запустить в кубе, то ему можно права кастрировать так, чтобы ничего лишнего не задеплоил (и вот тут неймспейс на приложение очень удобно )
Dmitry
в .kube хранятся темплейты helm, я так понимаю. которые потом по текущей среде создают конфиг, да?
G72K
можно так. можно kubectl apply --recursive -f common -f environment1
G72K
оно подтянет специфичные вещи из отдельной директории
Dmitry
ну тогда хранить параметры для каждой среды в репе предется хранить. ок. Спасибо, встал на путь истиный.
Dmitry
😄
G72K
можно иметь отдельную коллекцию веток в репе, где чисто деплой ресурсы. там сделать common ветку, и для каждого окружения. мержить все изменения common в окружение при помощи CI как будто это релиз самого кода (что логично, ибо новые параметры деплоя могут сломать деплой точно так же как новый код)
G72K
если вы по колено в амазоне, подождите, они свой куб выкатывают и обвязки к нему тоже наверняка. может не придется привычные инструменты менять
Denis
Кто может подсказать, деплоимся через helm, тег в приложении остается старый (master) деплой проходит успешно, пишет что UPDATED (и ставит текущее время), но сами приложения не пересоздаются.
Вроде как helm как раз избавляет от того, чтобы в деплойменте из деплоя в деплой что-то менялось?
версия: helm 2.7.2
G72K
Denis
нет, тоже success
G72K
а изменения то делаете?
Denis
ну сам образ меняется (слои меняются)
G72K
неее так не годится
Denis
вообще он ревизию инкрементит (100, 101, 102 и тд), статус всегда DEPLOYED
G72K
надо образ чтобы поменялся
Denis
ну, тег ты имеешь ввиду?
Denis
образ то меняется конечно
G72K
поле image, как текст, изменения
Denis
тег перепушивается с другими сорцами 🙂 меняются слои, для докера это потенциально уже разные образа должны быть
G72K
хотел бы сказать хелм Г, но тут он не виноват.
Denis
поле image, как текст, изменения
так вроде при деплое через kubectl? там мы корячили timestamp поле, которое всегда менялось)
потом перешли на хелм и забыли об этом костыле
CrusaderX
Документацию ж не читаем
G72K
можете закостылить: делать Release.Version в annotation , и imagePullPolicy:always
Denis
можете закостылить: делать Release.Version в annotation , и imagePullPolicy:always
Спасибо добрый человек, пойду пробовать 🙂
Dmitry
если вы по колено в амазоне, подождите, они свой куб выкатывают и обвязки к нему тоже наверняка. может не придется привычные инструменты менять
Они вроде уже выкатили. Но я хочу для себя изучить.
Dmitry
Preview можно делать https://aws.amazon.com/eks/
Dmitry
можно иметь отдельную коллекцию веток в репе, где чисто деплой ресурсы. там сделать common ветку, и для каждого окружения. мержить все изменения common в окружение при помощи CI как будто это релиз самого кода (что логично, ибо новые параметры деплоя могут сломать деплой точно так же как новый код)
звучит логично. т.е. common хранит общие конфиги а сами ветки dev/prod хранят только переменные? Как в таком случае секретами управлять?
Sergey
звучит логично. т.е. common хранит общие конфиги а сами ветки dev/prod хранят только переменные? Как в таком случае секретами управлять?
зависит от того, на чет написано. например на node.js есть отличная тема - config, позволяет определять конфиги самому разрабу и говорить какие значения в конфигах будут соответствовать каким переменным. в итоге разраб может сам наколхозить конфиги (именно значащие значения) для всех сред, а секреты приедут в ENV-переменные
Dmitry
зависит от того, на чет написано. например на node.js есть отличная тема - config, позволяет определять конфиги самому разрабу и говорить какие значения в конфигах будут соответствовать каким переменным. в итоге разраб может сам наколхозить конфиги (именно значащие значения) для всех сред, а секреты приедут в ENV-переменные
Ну env можно в любое приложение пробросить. Но вопрос в том, как они управляются в мире кубера? где они хранятся и как разворачиваются
Sergey
отдельно заводятся секреты, потом подключаются к деплойменту в виде ENV-переменных
Dmitry
Отдельно где? Не могу понять, как их хранить. Например, для Amazon я храню многое в Ansible Vault
Sergey
как управлять секретами - дело личное, я знаю людей которые держат секреты в репо (с закрытым доступом) и тоже по CI-пайплайну их катают
Dmitry
Ок. Ну, по крайней мере я понял что env можно отдельно / параллельно накатывать на поды, так?
Sergey
не, внутри кубера есть такая абстракция как секрет, а уж откуда она возьмется - это как удобнее
Sergey
потом этот секрет можно замапить на env в поде
Dmitry
Ну мне напрашивается все равно ansible vault из которого создается секрет кубера... Или какие стандартные варианты хранения? Или часто как-раз кубер и хранит эти секреты изначально? (а люди их вручную задают в кубер?)
Alex
Ребята кто fluent-bit пользуется для доставки логов?
Alex
Есть пара вопросов
Anton
очень рекомендую https://www.youtube.com/watch?v=vTgQLzeBfRU
кое каких опций для kubelet \ kube-apiserver не хватает в инсталяции из kubespray.
плюс видео убедило начать использовать network policy =))
Dmitrii
А кто как сайты в k8s прогревает? Мне пока это видится как readiness probe которая проходится по списку страниц при первом запуске, а при следующих сразу выдает exit code 0.
Anton
не совсем уж вырубать его, хотя бы что то проверять на readiness нужно обязательно
G72K
звучит логично. т.е. common хранит общие конфиги а сами ветки dev/prod хранят только переменные? Как в таком случае секретами управлять?
Мы не храним, при деплое проверяется есть ли секрет, если нет - сгенерировать и создать. Секрет потом используется самим приложением и другими, кому оно надо (скажем пароль от базы данных). Но это работает только если у вас все в кубе
G72K
G72K
кое каких опций для kubelet \ kube-apiserver не хватает в инсталяции из kubespray.
плюс видео убедило начать использовать network policy =))
Там еще есть видео от rackn, которое имеет ненулевой шанс убедить не использовать kubespray :) узнал из него о digital rebar, буду смотреть как заменить им свой наколеночный pxe + dhcp