vault?

И его тоже

Не держим секреты в кубер секретах

vault - это вот это? https://www.vaultproject.io/

а как у вас сервисы коннектятся друг к другу?

у меня вот сервисы для staging/prod каждый в своем неймспейсе тип /api-staging /api-prod у каждого сервиса есть набор connection strings до редисов и монг которые лежат в /staging /prod сервисы получают стринги к ним из env сейчас я их пробрасываю через секреты

а что еще есть интересного для менеджмента секретсов?

Энвы в манифестах, манифесты шаблонезированы

Я в git-crypt крипчу, и храню прямо в git

Я в git-crypt крипчу, и храню прямо в git

Оно

спасибо, сегодня вместо сна у меня знакомство с продукцией hashicorp -_-

спасибо, сегодня вместо сна у меня знакомство с продукцией hashicorp -_-

Я в git-crypt крипчу, и храню прямо в git

ты уже любишь hcl?

ты уже любишь hcl?

точнее проблема, что через год забываешь что где

а что небезопасного хранить конфиги в секретах? вы тип их храните в шифрованном виде и в рантайме декриптите?

в гите не разместишь =/

Шифруй etcd @ закрывай доступ к гиту с секретами

Это есть в опеншифт?

Это есть в опеншифт?

вроде даже kubeadm по дефолту везде юзает сертификаты

Я так понимаю это про хранение

Ну у ваулта все секреты в зашифрованном виде хранятся, в etcd плейнтекстом, но в base64 насколько я понимаю

https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/

https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/

в волте ещё и разграничение прав получше будет имхо

Прикольно, но встает вопрос, где хранить decryption key?

Насколько я понял оно юзается для легаси + еще моднейшие облака. А если все в кубере, то RBAC хватит

И так. Смотри. Виртуализация нужна для более эффективного использования ресурсов. Куб создан плюс минус для того же. Отбросим в сторону вопросы сесурити. Потому что к ним большие вопросы после всех этих интел гейтов. Теперь что касается кейса. Мы берем железо, ставим на него куб и радостно юзаем ресурсы железки на полную. Мы берем железо и ставим на него виртуализацию, юзаем ресурсы железки на полную. Тут вопросов нет. Вопрос зачем запихивать оркестратор в оркестратор и туда еще стейт?

А подскажите пожалуйста про кейсы работы и потенциальные риски в следующем случае. К примеру у меня есть таже postgres или какая то иная база, которую мы держим single node (без репликаций и всего такого) И мы заводим её в куб как deployment + pvc (ReadWriteOnce) + в deployment stattegy говорим replica 1 \ maxSurge 1 \ maxUnavailable 1. Я ожидаю что в случае падения ноды. репликейшн контроллер зашедулит под на другую ноду и примонтирует том туда. И никаких сайд эффектов не случится (кроме потенциальных проблем со стейтом базы после падения, и невозможности стартануть новому поду) Есть ли тут ошибки \ подводные камни ?

А подскажите пожалуйста про кейсы работы и потенциальные риски в следующем случае. К примеру у меня есть таже postgres или какая то иная база, которую мы держим single node (без репликаций и всего такого) И мы заводим её в куб как deployment + pvc (ReadWriteOnce) + в deployment stattegy говорим replica 1 \ maxSurge 1 \ maxUnavailable 1. Я ожидаю что в случае падения ноды. репликейшн контроллер зашедулит под на другую ноду и примонтирует том туда. И никаких сайд эффектов не случится (кроме потенциальных проблем со стейтом базы после падения, и невозможности стартануть новому поду) Есть ли тут ошибки \ подводные камни ?

https://youtu.be/7CR5eH6a8Fo

Он говорил об этом

Базы как StatefulSet заводить надо, если заводить их как deployment то есть шанс при перезапуске потерять данные. Так как сначала будет создаваться новый под, затем будет удаляться старый. Вторая проблема что при смерте ноды - под сам не переедет, а пометится как Unknown и будет висеть. Чтобы под переехал нужно чтобы был cloud-provider или fencing который в случае чего гарантированно снесет ноду и удалит ее из кластера.

https://youtu.be/7CR5eH6a8Fo

А там есть ответ на этот вопрос?

Там вроде просто объяснение кейс с бд в ваккуме

Спасибо. Совсем забыл про порядок старта. А под клауд провайдером что подразумевается ? И обязателен ли фенсинг если pvc перемонтируется ?

Есть ещё вариант понимать базы оператором, каждая база - это кластер из трёх реплик например, тогда в случае падения ноды ничего перезапускать не потребуется. База продолжит работу с оставшимися двумя репликами.

Ну если у вас куб работает в облаке или в "какой-нибудь openstack'е", то можно к нему cloud-provider прикрутить, чтобы куб самостоятельно занимался созданием нод и томов, а так же их аттачем, фенсинг там как правило из коробки. > обязателен ли фенсинг если pvc перемонтируется ? Дело в том, что без него pvc тоже не перемонтируется.

https://youtu.be/7CR5eH6a8Fo

Да, про это я знаю, но там кейс не требующий прям высокого ha и простой в пару тройку минут допустим.