ещё нужно поднять микросервис, который генерит статичный мак на основе названия поды StatefulSet и прокидывает в контейнер

кто нибудь на GKE сидит? не ловили ошибку UnregisterNetDevice, после которой докер на ноде намертво зависает?

есть issue в апстриме докера https://github.com/moby/moby/issues/5618

Народ, а дайте совет из серии best practice пожалуйста. Если сервисы внутри кластера должны общаться между собой, то они(сервисы) должны делать доп. проверки на тему может ли тот или иной сервис к нему обращаться за той или иной задачей?

Народ, а дайте совет из серии best practice пожалуйста. Если сервисы внутри кластера должны общаться между собой, то они(сервисы) должны делать доп. проверки на тему может ли тот или иной сервис к нему обращаться за той или иной задачей?

Ммм нет. В Деплое у тебя прописаны liveness и readness пробы. Так что наблюдение за конечным подом осуществляет сам кубер

То что он его осуществляет это понятно. Я про то что сами приложения в контейнерах долждны делать проверку кто к ним обращается или нет? Или это и был на это ответ?

То что он его осуществляет это понятно. Я про то что сами приложения в контейнерах долждны делать проверку кто к ним обращается или нет? Или это и был на это ответ?

Это уже от уровня твоей паранои зависит.

Это уже от уровня твоей паранои зависит.

Вот я потому и спрашиваю "как принято". А то с уровнем моей паранойи оно просто не заработает)

То что он его осуществляет это понятно. Я про то что сами приложения в контейнерах долждны делать проверку кто к ним обращается или нет? Или это и был на это ответ?

Ну обычно у людей уровень параноии ниже, и они доверяют тем кто в их же namespace

У меня выходит ситуация что часть сервисов будут в другом namespace, и эти сервисы будут работать с финансами, вот и думаю насколько безопасно и как сотворить

Ты знаешь кто и как их туда поместил?

Здесь примерна та же схема, что и раньше..с виртуалками например

Я и поместил, точнее помещу. И конкретно финансовые сервисы будут делать проверку если клиент захочет получить деньги. А так в общем и "основном" namespace сервисы будут доверять тому что скажет JWT

Тогда в чём проблема?

JWT в любом случае либо кодировано либо подписано

JWT в любом случае либо кодировано либо подписано

Тому что JWT сможет расшифровать только один сервис, и делать он это будет либо по получении запроса с роутера, либо по запросу с фин. сервиса. В итоге для большинства обычных сервисов JWT будет по сути открытым

Котаны. Чот не могу въехать. Как мне подсовывать имейджпуллсекреты сервайс акку в создаваемые неймспейсы? Везде нужны одни и те же

Сервис акку ни как

imagePullSecrets это объек из описания деплоймента

его указывать нужно в деплое..

Сервис акку ни как

В смысле никак если даже очень как

В смысле никак если даже очень как

J rfr

о как

и как же

https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/

если кто-то разучился читать документацию )

Раньше ге было

Не знаю, я месяца 3 назад уже читал это

3 месяца назад, это слишком малый пробег, я тут часлюсь почти 2 года, и поверь кубер очень сильно изменился)

а так да добавили, на что им спасибо)

А сюда можно с глупыми вопросами? Поставил через kubeadm в Virtualbox Kubernetes. Две ноды. Соответственно мастер и одна нода. Просто поучиться и разобраться. Все выглядит хорошо но почему то Cluster-IP для сервиса прилетает какой-то совсем левый. Соответственно не могу получить доступ. Кто то сталкивался с такими проблемами в VirtualBox?

ребят, а кто как разделяет приложения по неймспейсам? Вот допустим у меня есть некоторое микросервисное приложение, но в каких случаях его имеет смысл дробить еще и по неймспейсам? Или оставить например 1 неймспейс на 1 приложение? И работать уже в этих рамках?

смотря что тебе надо

мне вот нужны вагоны неймспейсов. кому-то не надо

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

если нужна связность сервисов - держи в одном неймспейсе

не надо - не держи )

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

смотря что взломают

связность нужна, но ведь её можно сделать и через разные неймспейсы?

бывает вон уборщицы решают кому работать а кому нет

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

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

та часть что будет во втором неймспейсе будет содержать логику работы с финансами, она сама непосредственно наружу торчать не будет

крутой ты мужик. я бы так не смог

эм... всмысле?

"накидайте кто как и что делает, а я подумаю"

ну я не совсем про это) я еще попросил почему именно так)

но в свою очередь я тоже всегда стараюсь отвечать именно в таком варианте) очень помогает на самом деле )

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

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

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

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

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

я не думаю, что отдельный нэймспейс тебе что-то даст. Лучше подумай зачем ты об этом задумался)

сложность выноса куда-либо микросервисов/не микросервисов зависит от криворукости кода

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

ну по сути там просто сменить адрес в тех сервисах что с нми работают и установка ролей для обращения в другой неймспейс

и вроде всё, хотя может что-то упустил

у нас гораздо меньше сервисов и все они в одном нэймспейсе, условно. Выделено в отдельные по группам (например, логирование, мониторинг, балансирование)

а ведь можно еще задуматься что количество сервисов != количество подов

ахаха

АХАХА

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

какого места? о_о

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

когда-то читал такое

https://www.weave.works/blog/securing-microservices-kubernetes/

https://www.weave.works/blog/securing-microservices-kubernetes/

полезная ссыль. благодарствую

Вот и меня сил то цепляет тут. А что пока не могу понять. За ссылку спасибо, почитаю.

как я понимаю логику происходящего вообще в докерах куберах.

у вас есть ингресс - это первый оплот защиты и ограничения доступа

у вас есть ингресс - это первый оплот защиты и ограничения доступа

нууу нет

ну как нет

для начала пускать извне кого куда

а кто внутри только общается

потому что ингресс к безопасности отношения по логике своей не имеет. ингресс - нарушение периметра.

нет даже какой-то выработанной стратегии между разными ингрессами на акцесс-листы.

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

1 точка входа в приложене так сказать

метки совпали - пролезло