На выходных щупал кубера. Задеплоил кластер из 2х нод, все поднято и вроде даже работает. Теперь вопрос такой, какой самый простой способ аутентифицировать мой локальный kubectl?

Поднимал через Ansible/Kubespray

На выходных щупал кубера. Задеплоил кластер из 2х нод, все поднято и вроде даже работает. Теперь вопрос такой, какой самый простой способ аутентифицировать мой локальный kubectl?

https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#accessing-kubernetes-api

но скорее всего у тебя был kubeconfig_localhost: = false и папка artifacts не создалась. можешь взять сертификаты с мастеров (/etc/kubernetes/ssl) или если была авторизация по токену: авторизоваться по любому из токенов в namespace: kube-system (kubectl get secrets -n kube-system)

Читаю, походу юзеры создаются в kubespray/credentials

You must be logged in to the server (Unauthorized) Как авторизоваться с тем, что у меня в контексте?

Я походу не догоняю какой-то базовый момент

Кто-то сталкивался с сетевыми задержками в подах на AWS?

@arslanbekov Какие стандартные способы аутентификации? Только Oauth?

@arslanbekov Какие стандартные способы аутентификации? Только Oauth?

нет, их много, по умолчанию kubespray прокидывает две политики авторизации (node и RBAC) в credentials у вас лежит пароль для юзера kube

https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/

Да, спасибо, прочел в линке который дали, потом нашел пароль. Поставил юзера в контексте, но как инициализировать авторизацию?

в kubectl config вижу свой конекст, он выбран.

а.. ща сменю юзера назначенного на контекст

https://www.mirantis.com/blog/a-comparison-of-different-containers-as-a-service-products/ вот рассылка пришла от мирантиса. Сравнение для холиваров чей кубер лучше

@arslanbekov kubectl get nodes все еще You must be logged in to the server (Unauthorized). Как мне сказать "Попробуй залогиниться с тем что в контексте?

Или это как раз прокси делает? А клиент тупо без аутентификации. Надо проверить

Видимо и гуй так же будет авторизоваться.

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

@kvendingoldo я бы сказал, что ни в каких случаях не нормально. если меняешь только чарт, что, бампать версию приложения?

Чего-то явно не хватает... Unauthorized... Куда копать?

...Пойду еще раз копну в сторону включенных способов аутентификации.

Заработало. node и token auth были выключены, прлюс удостоверился что и там и там одинаковые пароли.

Заработало. node и token auth были выключены, прлюс удостоверился что и там и там одинаковые пароли.

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

Норм. Спасибо. Из доков это не ясно как-то.

Гуй тоже заработал. Хорошо смотрится.

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

Тут, я так понимаю будет 2 сервиса, 2 пода со скейлом 3x?

Хочу логически сгруппировать, на сколько вообще это важно? Что на практике даёт группировка?

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

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

готовые 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?

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