тада особого смысла ставить не вижу

Я юзаю. Мне понравилась интеграция с AD

Я юзаю. Мне понравилась интеграция с AD

О.о че прям так умеет?

О.о че прям так умеет?

ну это одна из фич ldap/ad

скорее одна из фич харбора

Ну я про него и написал

Ни у кого не было проблемы с daemonset? node-exporter не хочет заходить на все ноды, поднялся только на 5 нодах из 14( Кластер 1.9.6 (kops AWS)

1. ресурсов не хватает 2. taint какие нибуть но вообще то не сталкивался

Ни у кого не было проблемы с daemonset? node-exporter не хочет заходить на все ноды, поднялся только на 5 нодах из 14( Кластер 1.9.6 (kops AWS)

Рестарт controller-manager иногда может помочь. Но в пятницу вечером делайте на ваше усмотрение:)

Рестарт controller-manager иногда может помочь. Но в пятницу вечером делайте на ваше усмотрение:)

нужно попробовать, но не сейчас)

у меня недавно не стартовали даемонсеты на одной ноде. версия 1.9.7 ноду я создал в кластере заранее, а кубелет включил только спустя несколько часов. Поды стартовать на ноде после включения кубелет как раз не хотели. Я вникать не стал - рестарт controller-manager сразу помог.

1. ресурсов не хватает 2. taint какие нибуть но вообще то не сталкивался

Все проверил, должно взлетать. Причем пробовал daemonset пересоздавать, каждый раз по 5 подов апает из 14 и каждый раз на новых нодах.

Я все жду копс 1.11 там и с nvme pvc проблем не будет. на метале уже 1.11 кубспреем вкатил, нравится)

Короче я нашел корень зла в других неймспейсах, когда только сетапали кластер тестово деплоили хельмом kube-prometheus и как оказалось helm delete --purge оставил после себя мусор в виде daemonset node-exporter в другом неймспейсе. Вот они и поделили ноды между собой

Кто юзает stolon в кубере?

Кто юзает stolon в кубере?

Рассчитаться?

Есть парочка глупых вопросов, у меня stolon не в кубере, хочу перенести

Каждый день говорят - пишите сразу вопрос, сразу к делу.

Обязательно ли keeper задавать как StatefulSet? или можно как DaemonSet

Есть подозрение что Stolon привязывается к ID машины, в данном случае виртуальной, и демон сет может не сработать, так id после пересоздания может менятся

С другой стороны, если StatefulSet - изза ReadWriteOnce он не сможет развернуть две реплики на одной ноде

С другой стороны, если StatefulSet - изза ReadWriteOnce он не сможет развернуть две реплики на одной ноде

А зачем две реплики на одной ноде?

Наоборот я хочу DaemonSet

И похоже StatefulSet с Once будет его подобием

если количество реплик совпадет с количеством нод

/leave

Всем привет, кто то сталкивался с низкой пропускной способностью в flannel, запущен он на hetzner cloud версия kubernetes 1.11.2 ------------------------------------------------------------ Client connecting to 10.244.10.173, TCP port 5001 TCP window size: 0.04 MByte (default) ------------------------------------------------------------ [ 3] local 10.244.11.151 port 55312 connected with 10.244.10.173 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-67.0 sec 11.8 MBytes 1.47 Mbits/sec Ставил flannel так: kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

В версии 1.10.1 на железе таких проблем нет

В версии 1.10.1 на железе таких проблем нет

На хецнер деплоил кубик, но 1.10.х, и kubespray, как бэкенд - калико, всё норм живёт

На хецнер деплоил кубик, но 1.10.х, и kubespray, как бэкенд - калико, всё норм живёт

Не нарушая NDA, расскажите что вы там гоняете без клаудного pvc и lb? Сплошной stateless?

Ребят, а в helm реально при ( .Files.Glob ).AsSecrets подставить переменные в подтягиваемом файле?

Не нарушая NDA, расскажите что вы там гоняете без клаудного pvc и lb? Сплошной stateless?

Без pvc грустно, не спорю, но выжить можно. Насчет lb: keepalived + nginx ingress

Без pvc грустно, не спорю, но выжить можно. Насчет lb: keepalived + nginx ingress

Это понятно. Интересно что на таких k8s гоняется

База отдельно + proxysql, кластер CH на local-volumes, куча stateless...

Можно рядом так то и ceph развернуть для pvc

База отдельно + proxysql, кластер CH на local-volumes, куча stateless...

Спасибо, принято

Не нарушая NDA, расскажите что вы там гоняете без клаудного pvc и lb? Сплошной stateless?

База отдельно, stateless web & api, ML training на GPU и ceph для хранилища файлов

Ребят, а в helm реально при ( .Files.Glob ).AsSecrets подставить переменные в подтягиваемом файле?

Как всегда, отвечу сам: {{ tpl (.Files.Get "configs/proxysql.cnf") . | b64enc }}

Не нарушая NDA, расскажите что вы там гоняете без клаудного pvc и lb? Сплошной stateless?

Вместо lb DNS round robin и external-dns pod. Не айс но такие требования были

Спасибо

На хецнер деплоил кубик, но 1.10.х, и kubespray, как бэкенд - калико, всё норм живёт

на Hetzner Cloud?

на Hetzner Cloud?

Чистое жалезо

Чистое жалезо

Так у меня тоже работает но с flannel, а вот в cloud тормозит

на Hetzner Cloud?

У меня в cloud только мастера в разных локациях, сами по себе виртуалки там то еще гавно

Но есть в планах юзать их облако для автоскейлинга stateless приложений, которые любят проц

У меня в cloud только мастера в разных локациях, сами по себе виртуалки там то еще гавно

Та сам Hetzner не але, но так заказчик хочет

В сравнении да, а так живем там лет 5 и не все прям ужасно)

Да, для stateless hetzner прямо то что нужно. Дёшево и сердито. И если поменяют как всегда не тот диск в рейде, не страшно.

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

Не нарушая NDA, расскажите что вы там гоняете без клаудного pvc и lb? Сплошной stateless?

Только stateless в кубере)

на Hetzner Cloud?

Железо

вообщем с Calico полет нормальный, прийдется отказаться от flannel ------------------------------------------------------------ Client connecting to 192.168.153.193, TCP port 5001 TCP window size: 0.04 MByte (default) ------------------------------------------------------------ [ 3] local 192.168.218.1 port 57530 connected with 192.168.153.193 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-30.0 sec 4473 MBytes 1251 Mbits/sec

вообщем с Calico полет нормальный, прийдется отказаться от flannel ------------------------------------------------------------ Client connecting to 192.168.153.193, TCP port 5001 TCP window size: 0.04 MByte (default) ------------------------------------------------------------ [ 3] local 192.168.218.1 port 57530 connected with 192.168.153.193 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-30.0 sec 4473 MBytes 1251 Mbits/sec

Угу, крайне рекомендую без честного L2 жить на калико

Есть возможность чтобы у демонсетов суфукс был не случайный набор а имя ноды?

Гитлаб на множестве kubernetes кластеров : раннер в каждом и стучится в общий gitlab или раннер в общем гитлабе и стучится в множество kubernetes серверов?

Гитлаб на множестве kubernetes кластеров : раннер в каждом и стучится в общий gitlab или раннер в общем гитлабе и стучится в множество kubernetes серверов?

второе

Я бы сказал, что пофиг, как удобней. Хоть микс.

Т.е. никто не мешает держать runner и в общем и в личном. Если нужно и это не бесполезное дублирование.

второе

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

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

ну вы так и пиши в вопросе, что "права очень ограничены"

ну вы так и пиши в вопросе, что "права очень ограничены"

Ну это самоограничение :)

второе

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

в первом случае: вы должны научиться деплоить раннеров в ваших k8s, поддерживать коннективити между раннерами в k8s и вашим gitlab, и как-то в целом следить что-бы они были онлайн во втором случае: вы деплоите gitlab, внутри запускаете pod'ы которым пропихиваете kubeconfig/api tokens, которые удаленно работают с k8s. второй случай более простой и безотказный

в первом случае: вы должны научиться деплоить раннеров в ваших k8s, поддерживать коннективити между раннерами в k8s и вашим gitlab, и как-то в целом следить что-бы они были онлайн во втором случае: вы деплоите gitlab, внутри запускаете pod'ы которым пропихиваете kubeconfig/api tokens, которые удаленно работают с k8s. второй случай более простой и безотказный

Ну за раннерами следить везде проще. Во втором: надо не бояться выставлять аписервер попой наружу, проблемно во всяких огороженных подсетях, деплой раннеров на самом деле сложнее: надо создавать ресурсы в двух кластерах: сервис аккаунты, роли, биндинги в месте назначения и токены от сервисаккаунта в кластере раннера. Есть ещё на самом деле третий вариант: раннеры рядом с гитлабом, но вот экзекьюторы он запускает в кластере назначения :)

ясно понятно, какие есть еще нюансы?

например что у кластеров коннективити с gitlab'ом есть только по понедельникам с 8am-10am PST+4?

Я сделал первый вариант пока, но сильно не думал , а вот сейчас задумался :) второй вариант кажется правильнее. собираю мнения если кто как рашал прежде чем переделывать :) (думать о том что делаешь ДО не вариант как водится :) )

всем привет заранее извиняюсь за нубский вопрос, но где можно почитать по тому, как разные типы конфигурации отдаются контейнеру в кубернете? То есть у меня три среды: dev, qa, prod под каждую свой конфиг, скажем в dev.env, qa.env, prod.env. Как правильно в кубернете отдавать конфигурацию в зависимости от окружения и как вообще правильно вести разработку если есть окружение для dev, qa, prod? Пока смотрю на ConfigMap и вроде то, что нужно или есть другие варианты?

всем привет заранее извиняюсь за нубский вопрос, но где можно почитать по тому, как разные типы конфигурации отдаются контейнеру в кубернете? То есть у меня три среды: dev, qa, prod под каждую свой конфиг, скажем в dev.env, qa.env, prod.env. Как правильно в кубернете отдавать конфигурацию в зависимости от окружения и как вообще правильно вести разработку если есть окружение для dev, qa, prod? Пока смотрю на ConfigMap и вроде то, что нужно или есть другие варианты?

Конфиги это файлы?

Новые приложения конфигурировать только через ENV А для старых, которые хотят разные файлики и перепиливать лень - просто делаю cat conf | base64 и в одну ENV, обычно это уже легаси.

@alexesDev да, конфиги это разные файлы.

Как я выше написал, у меня рецепт крайне простой ? закатать в base64 и распаковывать при старте.

@alexesDev а где изначально конфиг хранится?

всем привет заранее извиняюсь за нубский вопрос, но где можно почитать по тому, как разные типы конфигурации отдаются контейнеру в кубернете? То есть у меня три среды: dev, qa, prod под каждую свой конфиг, скажем в dev.env, qa.env, prod.env. Как правильно в кубернете отдавать конфигурацию в зависимости от окружения и как вообще правильно вести разработку если есть окружение для dev, qa, prod? Пока смотрю на ConfigMap и вроде то, что нужно или есть другие варианты?

в helm деплоить с нужным -f values-qa.yaml ?

@alexesDev а где изначально конфиг хранится?

gitlab

раньше лежал в fs, потом base64 и в gitlab. gitlab через env прокидывает в кубер.

Распаковать, поменять, запаковать - редкая операция, не напрягает.

@wowsel то есть по сути такая структура: у меня доккер образ, который зависит от конфига и три конфига: dev.env, qa.env, prod.env я могу просто отдавать их helm типа -f qa.env так? Не работал в хелмом, поэтому вопрос. он для разных окружений свой образ сделает или будет один образ а потом при старте контейнера ему надо отдавать конфиг нужный?

@alexesDev а каким образом прокинуть какое окружение в кубер? Это для меня как раз сложный вопрос, как кубернету, который поднимает контейнер сказать с каким конфигом поднимать и в какой момент конфиг отдается и кем.

@wowsel то есть по сути такая структура: у меня доккер образ, который зависит от конфига и три конфига: dev.env, qa.env, prod.env я могу просто отдавать их helm типа -f qa.env так? Не работал в хелмом, поэтому вопрос. он для разных окружений свой образ сделает или будет один образ а потом при старте контейнера ему надо отдавать конфиг нужный?

helm просто будет подменять нужные данные или в env деплоймента, или в configmap, как у вас сделано, при деплое

@wowsel то есть по сути такая структура: у меня доккер образ, который зависит от конфига и три конфига: dev.env, qa.env, prod.env я могу просто отдавать их helm типа -f qa.env так? Не работал в хелмом, поэтому вопрос. он для разных окружений свой образ сделает или будет один образ а потом при старте контейнера ему надо отдавать конфиг нужный?

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

спасибо за ответы @wowsel @alexesDev , буду разбираться!

Новые приложения конфигурировать только через ENV А для старых, которые хотят разные файлики и перепиливать лень - просто делаю cat conf | base64 и в одну ENV, обычно это уже легаси.

А почему так? Ведь с файлами есть возможность менять конфиги на лету. А ENV вроде уже не сменишь когда процесс запущен.

это какое-то необоснованное предубеждение, ENV не универсальный вариант, да и не самый секурный

у энва-то принципиально секурность отличается от всего остального

А почему так? Ведь с файлами есть возможность менять конфиги на лету. А ENV вроде уже не сменишь когда процесс запущен.

так то git patch можно на лету делать, но никто не делает. Все перезапускают контейнеры.

У меня сейчас в большенстве мест тег равен CI_COMMIT_SHA и при kubectl apply идёт пересоздание подов, хотя фактически они часто не меняются ? Пока всем пофиг, руки не дойдут пофиксить.

Т.е. это не супер страшно. Страшно если так не получается делать из-за каких-то проблем (значит, что решение плохо работает в случае крэша пода).