Ограничение доступа на уровне ресурсов, и все?

что за группировка?

готовые helm charts можно найти тут: https://github.com/kubernetes/charts

Но теперь хочу задерлоить распределённый сервис. Кафку, зукипер. Наверняка уже есть howto с рекомендациями

я слоупок, но скажу всетаки, такие вещи, как кафка например, у которых реплики не равноправны, рекомендуется деплоить в statefullset. elasticsearch например тоже, на нодах хранения может легко быть разный набор шардов. тоесть если у приложения есть какое то состояние в рабочем режиме, статус (не знаю какие еще подобрать слова), которое отличается репилки - нужно использовать statefullset

kubespray на мастерах после себя оставляет /etc/kubernetes/admin.conf, который все нужное содержит. кладешь себе в ~/.kube/<clustername>.conf и перед использованием kubectl\helm: export KUBECONFIG=~/.kube/<clustername>.conf

а если надо создать еще один такой admin но с другими правами? что копать надо?

я слоупок, но скажу всетаки, такие вещи, как кафка например, у которых реплики не равноправны, рекомендуется деплоить в statefullset. elasticsearch например тоже, на нодах хранения может легко быть разный набор шардов. тоесть если у приложения есть какое то состояние в рабочем режиме, статус (не знаю какие еще подобрать слова), которое отличается репилки - нужно использовать statefullset

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

а если надо создать еще один такой admin но с другими правами? что копать надо?

его можно нагенерить вручную. там есть блок clusters & users & contexts, где сводятся user + clister

генеришь нового user, описываешь с ним context, профит, нет?

https://kubernetes.io/docs/admin/authentication/ тут подробнее, сам не пробовал юзеров создавать

его можно нагенерить вручную. там есть блок clusters & users & contexts, где сводятся user + clister

спасибо, проверю и попробую

https://github.com/kubernetes/kubernetes/pull/52569

теперь в 1.9 больше не будет боли с iptables forward default policy =)

Кто то юзал contiv?

я слоупок, но скажу всетаки, такие вещи, как кафка например, у которых реплики не равноправны, рекомендуется деплоить в statefullset. elasticsearch например тоже, на нодах хранения может легко быть разный набор шардов. тоесть если у приложения есть какое то состояние в рабочем режиме, статус (не знаю какие еще подобрать слова), которое отличается репилки - нужно использовать statefullset

Я может конечно счас холивар разведу, но помоему такие вещи как кафка и зукипер вообще не надо деплоить в кубер

ваше дело

прост многим не нравится иметь N инструментов деплоя. N инструментов для оркестрации и тд

Просто как оно будет работать в проде? Где данные хранить?

а где вы храните данные обычно?

Обычно я их не храню

Их хранит кафка/зукипер/постгрес/редис/etc

нет же, ты их хранишь на той ноде, где запущен сервис

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

Это значит что мне все равно если этих данных не станет

Мой сервис их не использует

я чет потерял нить. ты запускаешь постгрес и тебе всеравно что будет с данными на диске, потому что сервис (постгрес) их не использует?

Я не запускаю постгрес в кубере

Для этого есть rds

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

Ничем. Это оно и есть. Просто это вне кубера

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

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

в statefullset pvc под каждый под генерятся и привязываются к конкретному поду. как уж там инфраструктура будет выделять pv, отдельный вопрос. в aws можно динамически же генерить pv под запросы. и при скейлинге тоже

очень в общих чертах сложно это обсуждать

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

Кубер это не учитывает (раньше по крайней мере не учитывал). Да и сложность этого схематоза такова, что я их не сильно виню. Вообщем я пришел к выводу, что все stateful - нах из кластера и pv использовать только в случае крайней необходимости (если софт по-другому не умеет).

насчет порождения нод в других зонах, шедулинг подов позволяет ограничить где именно можно шедулить с помощью affinity

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

Тогда пропадает ha

ну лан, тебе не угодить =)

что с ha за пределами к8с? =)

В rds по дефолту :)

В кафке и кубере из коробки

Зукипере*

Ну то есть все нормальные базы/очереди это умеют сами по себе а если не умеют то и в кубере вряд ли заумеют :)

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

Я вот не пойму зачем тянуть данные со старого пода на новую ноду чего-то?

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

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

готовые helm charts можно найти тут: https://github.com/kubernetes/charts

Спасибо

Я вот не пойму зачем тянуть данные со старого пода на новую ноду чего-то?

Механизм репликации - средство достижения HA и масштабируемости, а не штатный механизм переноса данных. В случае с кубером пода может скакать по кластеру как захочет (если конечно ее не прибить гвоздями). Плюс к этому может случиться так, что все 3 ноды будут недоступны в течение достаточно сжатого периода времени. Такое часто случается, например, в случае kops rolling update с изменением ig - оно просто по очереди терминейтит все ноды (сейчас вроде хоть дрейнить научилось) и порождает новые на их место

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

Ansible/Chef?

Ansible/Chef?

Да, если бы то была одна система, но тут целая инфраструктура которую с некоторй верояинтостью нужно скейлить.

Механизм репликации - средство достижения HA и масштабируемости, а не штатный механизм переноса данных. В случае с кубером пода может скакать по кластеру как захочет (если конечно ее не прибить гвоздями). Плюс к этому может случиться так, что все 3 ноды будут недоступны в течение достаточно сжатого периода времени. Такое часто случается, например, в случае kops rolling update с изменением ig - оно просто по очереди терминейтит все ноды (сейчас вроде хоть дрейнить научилось) и порождает новые на их место

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

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

Я тут зеленый, поэтому интересна идеология кубера

товарищи, подскажите если какое-нибудь готовое решение для горизонтального мастабирования воркеров, но не в облаке, а on prem.

tectonic?

tectonic?

А причем тут танец? Или индусская разработка?

А причем тут танец? Или индусская разработка?

https://coreos.com/tectonic/

Понятно - юмор был не оценен ?

?

Ну игра слов - название созвучно с танцем. А спеснями и плясками у нас индусы что либо делают (в фильмах). Вот и пошутил про индусскую разработку

Понятно - юмор был не оценен ?

да потому что юмор скверный. Вот и не оценили его

про танец понятно, а про индусов уже сложно

Ну фильмы Болливуда - там постоянно поют и танцуют

Проехали

Кубер это не учитывает (раньше по крайней мере не учитывал). Да и сложность этого схематоза такова, что я их не сильно виню. Вообщем я пришел к выводу, что все stateful - нах из кластера и pv использовать только в случае крайней необходимости (если софт по-другому не умеет).

Сейчас учитывает.

ERROR: S client not available

Есть вопрос про неймспейсы, когда они становятся необходимы?

всегда

В плане "не default" неймспейс

всегда ) особенно если RBAC, а RBAC всегда )

ок, когда RBAC.

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

RBAC работает для управления доступом к управлению ресурсами или как-то затрагивает коммуникацию между подами?

можно dev, staging, prod организовать удобно, все разграничить network policy чтобы случайно не ходило не туда. конфиги приложений статичные. надо redis идет просто на redis:6379 и придет в тот, что нужно

в сравнении с AWS это больше как IAM нежели Security Groups?

можно dev, staging, prod организовать удобно, все разграничить network policy чтобы случайно не ходило не туда. конфиги приложений статичные. надо redis идет просто на redis:6379 и придет в тот, что нужно

Ок, то есть по неймспейсам нормально среды раскладывать.

еще как.

Как вообще принято всем этим управлять? в AWS Cloudformation/Terraform, запускаешь aws cloudformation create-stack, а тут? через kubectl create -f ./template.yml ? или через helm? или я тчо-то путаю в сравнении категорий?

мой вариант helm template | kubectl apply -f - для всякого Г из интерентов, голый kubectl apply для своего Г

helm ни на что, кроме как затемплейтить не годится

аа, helm + kubectl apply это типа как jinja2 + cloudformation. Пардон такие аналогии)

а приложения как принято хранить-деплоить? для aws (ECS/EB) держу все обвязки в коде, и там просто eb deploy куда надо...

@rossmohax Спасибо, уже начало проясняться. Доки о такой базе не особо говорят. В частности о практических проверенных подходах)

у каждого свой путь) тут баталии как правильно регулярно проходят

да это ясно, но практические шорткаты люблю у настоящих людей слышать)

а приложения как принято хранить-деплоить? для aws (ECS/EB) держу все обвязки в коде, и там просто eb deploy куда надо...

создаете директорию ./kube и там храните, потом из ci деплоите. если ci агента запустить в кубе, то ему можно права кастрировать так, чтобы ничего лишнего не задеплоил (и вот тут неймспейс на приложение очень удобно )

в .kube хранятся темплейты helm, я так понимаю. которые потом по текущей среде создают конфиг, да?

можно так. можно kubectl apply --recursive -f common -f environment1

оно подтянет специфичные вещи из отдельной директории

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

?

можно иметь отдельную коллекцию веток в репе, где чисто деплой ресурсы. там сделать common ветку, и для каждого окружения. мержить все изменения common в окружение при помощи CI как будто это релиз самого кода (что логично, ибо новые параметры деплоя могут сломать деплой точно так же как новый код)

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

Кто может подсказать, деплоимся через helm, тег в приложении остается старый (master) деплой проходит успешно, пишет что UPDATED (и ставит текущее время), но сами приложения не пересоздаются. Вроде как helm как раз избавляет от того, чтобы в деплойменте из деплоя в деплой что-то менялось? версия: helm 2.7.2

Кто может подсказать, деплоимся через helm, тег в приложении остается старый (master) деплой проходит успешно, пишет что UPDATED (и ставит текущее время), но сами приложения не пересоздаются. Вроде как helm как раз избавляет от того, чтобы в деплойменте из деплоя в деплой что-то менялось? версия: helm 2.7.2

предыдущий деплой был failed?

нет, тоже success

а изменения то делаете?

ну сам образ меняется (слои меняются)