коллеги, немного не профильный вопрос на ubuntu:16.04 хоств. докер 18.x утекают файловые дескрипторы на /var/run/docker.sock при интенисвном использовании dind никто не встречался?

мне не дали дешевую машину купить, типа небезопасно))

Смеюсь в голосину) Управление рисками, блин)

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

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

Здоровье то подпортили.

Можно еще и страховку жизни попросить

И страховку кода.

Смеюсь в голосину) Управление рисками, блин)

Кошерная компания.

несекурная тачка небось зубило

И страховку кода.

кстати, тема для стартапа "ваш bus factor = 1? купите страховку"

несекурная тачка небось зубило

Ее даже упоминать опасно не то что ездить :)))

кстати, тема для стартапа "ваш bus factor = 1? купите страховку"

Ну или раделить риски увеличив бас фактор до трех например

Ну или раделить риски увеличив бас фактор до трех например

что ты, это слишком сложно. это ж думать надо.

Ее даже упоминать опасно не то что ездить :)))

я на зубиле не ездил вообще, на пару дней взял бы) как и ниву и какой-то мерс из 90) e124 или вроде того

Почувствовать эпоху

Ребят. Кто-нибудь прикручивал к куберу Single-Sign-On? Идея состоит в том, чтобы логиниться в дашборд или консоль с помощью гуглового аккаунта, в котором будет разделение ролей для юзеров. В какую сторону лучше смотреть? Dex/keycloack/etc? Можно ли интегрировать это как-то без подобного посредника, или непосредственно крутить его в самом кубере?

Ребят. Кто-нибудь прикручивал к куберу Single-Sign-On? Идея состоит в том, чтобы логиниться в дашборд или консоль с помощью гуглового аккаунта, в котором будет разделение ролей для юзеров. В какую сторону лучше смотреть? Dex/keycloack/etc? Можно ли интегрировать это как-то без подобного посредника, или непосредственно крутить его в самом кубере?

мы используем okta

мы используем okta

Я правильно понял, что это саасная штука, которая позволяет не хостить у себя условный dex, при этом за это надо платить деньги? И если да, то как тарификация идет, за счет количества юзеров или fix-price?

Я правильно понял, что это саасная штука, которая позволяет не хостить у себя условный dex, при этом за это надо платить деньги? И если да, то как тарификация идет, за счет количества юзеров или fix-price?

да по юзерам

но она офигенна

Мы используем https://github.com/cloudposse/charts/tree/master/incubator/portal https://docs.cloudposse.com/kubernetes-platform-services/dashboard/cluster-portal/ Github как Single Sign On Правда нет разделения по группам - просто способ сделать аутентификацию для dashboards.

а сколько если не секрет за юзера выходит? я у них на сайте только contact sales нашел без прайсов

под капотом используем вот эту штуку https://github.com/bitly/oauth2_proxy

Мы используем https://github.com/cloudposse/charts/tree/master/incubator/portal https://docs.cloudposse.com/kubernetes-platform-services/dashboard/cluster-portal/ Github как Single Sign On Правда нет разделения по группам - просто способ сделать аутентификацию для dashboards.

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

Крутяк. Ещё должны быть кастомные oauth2 авторизаторы и будет то, что нужно. Давно такое искал.

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

oauth2_proxy поддерживает Google default Azure Facebook GitHub GitLab LinkedIn OpenID Connect Provider

из коробки

еще есть форки всякие которые добавляют другие провайдеры

Сейчас у меня просто https://nginx.ru/ru/docs/http/ngx_http_auth_request_module.html auth_request /path/to/auth/page; напрягает только то, что нет ролей и тп.

(это вдруг кому интересно самое простое решение)

oauth2_proxy так и работает но там можно ограничивать только участникам команды в github org

думаю можно через это реализовать роли

но подумать прийдется как это сделать

под капотом используем вот эту штуку https://github.com/bitly/oauth2_proxy

крутяк, спасибо за ссылку

тут нужно, чтобы прокси на каждый url спрашивал "а сюда можно?". У auth_request проблема, что это только 1 запрос первый раз.

Сейчас думаю может через это auth_request_set $переменная значение; передавать X-User-Role его из вне нельзя переопределить, а в самом приложении if (role !== 'admin') и тп. А вообще решал кто-то проблему авторизацию по микросервисам централизованно?

Есть https://nginx.ru/ru/docs/http/ngx_http_auth_jwt_module.html Но форму авторизации некому выдавать.

тут нужно, чтобы прокси на каждый url спрашивал "а сюда можно?". У auth_request проблема, что это только 1 запрос первый раз.

сомневаюсь что это так работает. На каждый запрос отправляется подзапрос по auth_request Там смотрят на cookie аутентификационную и прнимают решение. членство в группе прийдется запрашивать и\или кешировать

Сейчас думаю может через это auth_request_set $переменная значение; передавать X-User-Role его из вне нельзя переопределить, а в самом приложении if (role !== 'admin') и тп. А вообще решал кто-то проблему авторизацию по микросервисам централизованно?

У Яндекса был доклад про быструю межсервисную авторизацию

из документации aut_request The module may be combined with other access modules, such as ngx_http_access_module, ngx_http_auth_basic_module, and ngx_http_auth_jwt_module, via the satisfy directive.

Before version 1.7.3, responses to authorization subrequests could not be cached (using proxy_cache, proxy_store, etc.).

так что на каждый запрос отправляется подзапрос - сюда можно?

А как сертификатиками в кубере управлять, с учётом того что у нас nginx ingress ? Хочется подцепить letsencrypt и чтобы оно само всё двигалось

cert manager

kube-lego пишет что они unsupported

https://cert-manager.readthedocs.io/en/latest/

мы до сих пор на kube-lego

как нибуть на cert-manager переедем

есть эксперты helm? ? два вопроса: 1. Как вы чистите (и чистите ли вообще) конфигмапы релизов, если он разростается - хелм начинает подтормаживать. 2. Как деплоите большое кол-во подов разом, он сильно просаживается по производительности (особенно если имеется configmap-mount в деплойке) большое кол-во - от 100 и выше. все что до 100 он вроде как прожевывает более-менее.

есть эксперты helm? ? два вопроса: 1. Как вы чистите (и чистите ли вообще) конфигмапы релизов, если он разростается - хелм начинает подтормаживать. 2. Как деплоите большое кол-во подов разом, он сильно просаживается по производительности (особенно если имеется configmap-mount в деплойке) большое кол-во - от 100 и выше. все что до 100 он вроде как прожевывает более-менее.

helm init --history-max 5 Не было никаких проблем производительностью, столько и деплоим.

о, про историю не знал, спасибо!

Что с производительностью, собираете метрики с tiller пода? По CPU в лимит упирается или OOM летят постоянные? С какими параметрами запускаете helm?

Что с производительностью, собираете метрики с tiller пода? По CPU в лимит упирается или OOM летят постоянные? С какими параметрами запускаете helm?

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

стандартный helm upgrade --install ...

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

потому что когда прилетает не мало на 1 ноду - кубелет еле пережевывает все

и куча ошибок типа du ... в kubelet

Это да, kubelet не самый быстрый, если очень много подов на ноду.

Из практики лучше больше сотни подов не деплоить на одну машину.

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

Что с CPU лимитами, что по графикам соотношение container_cpu_cfs_throttled_periods_total к container_cpu_cfs_periods_total? Как себя чувствует etcd и apiserver?

задрали для кубелета ресурсы и пока живем

> Как себя чувствует etcd и apiserver etcd увеличивается на запись/чтение, на api cpu растет

Надо всё мониторить, тюнить, скейлить вертикально и т.д. У нас в самом Helm не было проблем с производительностью никогда. Только окружение лагало.

ERROR: S client not available

Надо всё мониторить, тюнить, скейлить вертикально и т.д. У нас в самом Helm не было проблем с производительностью никогда. Только окружение лагало.

???

>с производительностью А с самим Helm'ом проблем хоть отбавляй.

А какой распределённый fs проще всего стартануть и поддерживать? Исторически обхожу это давно через отдельные базы + s3/minio.

Longhorn от ранчер если автоматом Zfs если секса мало) GlusterFS - мы уже 6-7 лет в мелком продакшен используем

Господа, стоит ли смотреть на ALB-ingress-controller?

или забить и использовать нджинкс исключительно?

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

Железные тачки? Может тогда на них виртуалки? У меня двухпроцессорные железки - пока по 2 виртуалки на сервак сделал (и "прибил" каждую к совему процу). Очень удобно виртуалки через ovirt разрулить - быстро поднять все и надежный

Longhorn от ранчер если автоматом Zfs если секса мало) GlusterFS - мы уже 6-7 лет в мелком продакшен используем

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

Железные тачки? Может тогда на них виртуалки? У меня двухпроцессорные железки - пока по 2 виртуалки на сервак сделал (и "прибил" каждую к совему процу). Очень удобно виртуалки через ovirt разрулить - быстро поднять все и надежный

у нас разные окружения в зависимости от важности на разных виртуализациях) пока что самый ок - это железка

если нужна надежность

железку сложнее скопировать на соседний серв (у меня все на железе, это я так)

если нужна надежность

А были прецеденты с ненадежностью в виртуалках? Какие?

А были прецеденты с ненадежностью в виртуалках? Какие?

в основном на kvm

на днях наблюдал diskpressure на ноде, при этом места/инодов полно и ио почти на нуле.. через минут 15 статус поменялся на "все норм".. как такое подебажить?

в основном на kvm

Какие? Можно в личку, реально интересно. У меня нагрузка не очень высокая пока, может потому проблем не встречал

Мы ранее говорили про авторизацию на микросервисы, это же умеет https://konghq.com/kong-community-edition/ Тут пару раз проскакивало. Есть у кого опыт?

мне как-то не очень нравится, что мой сервис при билде выплевывает 2 артефакта - хелм чарт и контейнер

кто как с этим живет?

что значит выплевывает контейнер? docker push же

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

обновлённый

контейнер или image?

image, простите

и прям image в репу git? или вы про registry?

про реджистри, да

и хелм чарт тоже в реджистри должен пушиться

я бы не называл это артефактом. Это больше собрали коробку и отправили по почте. Чем коробка, которая стоит под боком и все берут оттуда что нужно (это артефакты в моём понимании).

грубо говоря у gitlab артефакты удаляются через месяц по-умолчанию. С image так нельзя совсем.

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

Я не про гластер внутри куба. Гластер снаружи, к нему по multi mount nfs можно подключаться. А внутри куба или стейтлесс или прямой МАП нфс по ключу из докеров. (Мы правда не из куба в проде. Виртуалки голые и докеры голые)

Мы ранее говорили про авторизацию на микросервисы, это же умеет https://konghq.com/kong-community-edition/ Тут пару раз проскакивало. Есть у кого опыт?

Тоже очень интересно

на днях наблюдал diskpressure на ноде, при этом места/инодов полно и ио почти на нуле.. через минут 15 статус поменялся на "все норм".. как такое подебажить?

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