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

Т.е. никто не мешает держать 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 идёт пересоздание подов, хотя фактически они часто не меняются 😬 Пока всем пофиг, руки не дойдут пофиксить.

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

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

всетаки если commit sha уехал, это уже совсем не тоже самое, что было раньше. так что все правильно

hi all! посоветуйте, пожалуйста, как увеличить размер pv и привязанного к нему pvc, если provisioner в их storageclass является host-path ?

мб есть какая-то конкретная литература на эту тему?

шо за провижионер с hostpath? =)

я, мб, нублю (: - дело для меня новое, мб, неправильно вопрос задал.

apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{},"name":"gitlab-storage-config","namespace":""},"provisioner":"kubernetes.io/host-path","reclaimPolicy":"Retain"} creationTimestamp: 2018-08-17T05:16:04Z name: gitlab-storage-config resourceVersion: "5859522" selfLink: /apis/storage.k8s.io/v1/storageclasses/gitlab-storage-config uid: a3b87c04-a1dc-11e8-ae43-1c6f6581d4b0 provisioner: kubernetes.io/host-path reclaimPolicy: Retain volumeBindingMode: Immediate

вот такой у меня storageclass, делал тестовое все, для gitlab-a

к нему привязан pv к pv обращается pvc. Все это на локальном сервере устроено. Хочется без лишних страданий научиться изменять размер pv и pvc.

https://kubernetes.io/blog/2018/07/12/resizing-persistent-volumes-using-kubernetes/

читал. там, как мне кажется, ключевое - Although the feature is enabled by default, a cluster admin must opt-in to allow users to resize their volumes. Kubernetes v1.11 ships with volume expansion support for the following in-tree volume plugins: AWS-EBS, GCE-PD, Azure Disk, Azure File, Glusterfs, Cinder, Portworx, and Ceph RBD.

попробовал у себя, на тестовом pvc, получил - error: persistentvolumeclaims "local-claim-1" could not be patched: persistentvolumeclaims "local-claim-1" is forbidden: volume plugin does not support resize

мне кажется, для host-path цифры в pvc не особо важны

вот я примерно о том же думаю - там же каталог, и все.

но хочется уверенности (:

проверь. выдели 8G, зайди в контейнер, посмотри, сколько доступно

скорее всего будет доступно всё, а не 8G

а, интересно, как выражается переполнение ресурса? это где-то видно?

ок, попробую, спасибо за совет.

еще уточнение - то есть выделить именно в pv? а в pvc должен остаться больший размер, который был изначально?

Доброе утро, господа. Кто-нибудь юзал pharos?

pharos.sh

нормальный у них такой в прайсе свитч usd <—> eur просто значок валюты около цифры меняется 😂

Зачем такое вообще нужно

Затем же зачем и kubeadm

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

Храните сессии юзеров в общем хранилище уже

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

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

нормальный у них такой в прайсе свитч usd <—> eur просто значок валюты около цифры меняется 😂

много у кого так.

бэкэнд - сторонне приложение. если в севрисе один под все ок, если больше - беда..

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

спс пошел читать

спс пошел читать

https://kubernetes.github.io/ingress-nginx/examples/affinity/cookie/README/ предположу что ingress-nginx используешь

угу

тут есть нюансы как всегда, если куки нет, я так понимаю ingress ее воткнет

тоесть клиент не по куке бэкэнда прилипнет, его прилипят к бэкенду и там он получит уже куку от бэка и начнет работу

какраз по куке прилаги и отваливается.. т.е. через nginx.ingress.kubernetes.io/affinity + nginx.ingress.kubernetes.io/session-cookie-name пробросится кука в сервис, а описании сервиса sessionAffinity: по той же куке?

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

https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md#custom-nginx-upstream-hashing

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

+1

какраз по куке прилаги и отваливается.. т.е. через nginx.ingress.kubernetes.io/affinity + nginx.ingress.kubernetes.io/session-cookie-name пробросится кука в сервис, а описании сервиса sessionAffinity: по той же куке?

не понял вопроса

Всем привет, в доках написано что кубер 1.8\1.9 поддерживает версию 17.03.х. Это последняя актуальная версия или документация просто не обновлялась?

это последняя, что прошла валидацию

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

работает и на 18.06, сам запускал, проблема пока не ловил

т.е если какие-то косяки обнаружатся, нас просто отошлют к последней валидированной версии)) понятно

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

всетаки если commit sha уехал, это уже совсем не тоже самое, что было раньше. так что все правильно

Я readme поменял, он перезапускает deployment. Там docker build мгновенно проходит, потому что кэш, но tag меняется и deployment отрабатывает. Думаю потом сделать проверку, что docker image отличается хоть чем-то кроме tag

Я readme поменял, он перезапускает deployment. Там docker build мгновенно проходит, потому что кэш, но tag меняется и deployment отрабатывает. Думаю потом сделать проверку, что docker image отличается хоть чем-то кроме tag

Что поделать, readme часть кода же

подскажите как лучше оформить зависимости между helm-чартами. Есть 10 чартов, из них 4 это базы, они долго поднимаются, надо чтобы чарты с приложениями начинали подниматься только после того, как поды с базами станут ready.