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

а в kubernetes тут возникают проблемы

Какие? Куб не билдит? )

Да - особенно линковка между докерами

связи теряются

А docker-compose не помогает?

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

Сама технология такова что kuberbetes не поддерживает инфрастурктуру

Сама технология такова что kuberbetes не поддерживает инфрастурктуру

Насколько я успел понять, кубернетис поддерживает сервисы, а инфраструктура уже не особо важна

Ну да, но если постоянные CI/DI процессы то разворачивать проще руками докеры через чем kuberbets тратить время на линковку

тогда уж через гитлаб было бы проще, там в их ci всё легко делается

для запусков тестов

Ну я сейчас пробую развернуть все через kompose, у меня приложение из 13 контейнеров получается

Хотя я код вынес в отдельный volume

И туда его деплою

Гайз, кто подскажет... Можно ли вынести имейджи из куба при помощи kubectl или мб манифестов? А то как по мне не круто ходить по нодам, вручную вычищать

docker-gc?

Куб же сам gc запустит если места мало будет

Или можно сделать демонсет с DinD и там поудалять что нужно

Гайз, кто подскажет... Можно ли вынести имейджи из куба при помощи kubectl или мб манифестов? А то как по мне не круто ходить по нодам, вручную вычищать

Насрой gc кубелту

Коллеги, привет! Нуждаюсь в совете бывалых по теме Kubernetes + Jenkins. Имеется Kubernetes на GKE, туда поставили Jenkins из https://github.com/kubernetes/charts/tree/master/stable/jenkins Собственно хочется понять, на сколько это удобно и жизнеспособно? Может быть у кого-то уже есть достаточный опыт что бы отговорить от подобной затеи, или наоборот, посоветовать? В основном CI/CD нужна для multi-staged билдов контейнеров (сборка, тест, публикация образа без лишней шелухи) и в последствии деплой всего этого через Helm в K8S.

жизнеспособно, главное настроить JVM чтобы оно умело понимать лимиты

С каждым днём становлюсь ближе к осознанию, что k8s не лучший вариант для On-site инвайремента, слишком много головняков , а с учётом того что все должно быть по pcidss, то дальше тестов билдов это ни куда не пойдет. Но монструозные стеки VM для запуска одного приклада уже по горло. Вопрос вот в чем , может обратить внимание на тот же oshift или ранчера , там хоть в ядре тот же кубер но призрачно возможна дальнейшая сертификация.??? Кончено понятно что k8s это только фрейм ворк для лепки , но это далеко ещё не глина или пластилин.

а что в k8s противоречит сертификации?

Думаю не то, что бы он противоречил, сертифицировать можно все что угодно. Вопрос в том сколько это будет стоить.

pci dss же не ограничивает тебя вроде инструментами

Здрасти, коллеги! Я тут долго думал и искал решение такого кейса: а может ingress направлять трафик на поды statefullset через хедлес сервис? а то хочу доступ к некоторым ресурсам в виде site.com/statefulpod-0 , /statefulpod-1, /statefulpod-N А придумать ничего кроме кастомных костылей и китайских плагинов для nginx не могу

С каждым днём становлюсь ближе к осознанию, что k8s не лучший вариант для On-site инвайремента, слишком много головняков , а с учётом того что все должно быть по pcidss, то дальше тестов билдов это ни куда не пойдет. Но монструозные стеки VM для запуска одного приклада уже по горло. Вопрос вот в чем , может обратить внимание на тот же oshift или ранчера , там хоть в ядре тот же кубер но призрачно возможна дальнейшая сертификация.??? Кончено понятно что k8s это только фрейм ворк для лепки , но это далеко ещё не глина или пластилин.

Про PKS не слышали? Там stateful firewall в комплекте, должно быть ок для pci dss

жизнеспособно, главное настроить JVM чтобы оно умело понимать лимиты

Ага, спасибо! Я правильно понимаю, что бы на слейвах docker image собирать, нужно что бы у образа с которого слейв поды поднимаются должен быть docker cli? То есть мне стандартный jnlp-slave нужно поменять на https://hub.docker.com/r/ninech/jnlp-slave-with-docker/ Или я что-то делаю не так?

образы для докера можно собирать не только докером

Ага, спасибо! Я правильно понимаю, что бы на слейвах docker image собирать, нужно что бы у образа с которого слейв поды поднимаются должен быть docker cli? То есть мне стандартный jnlp-slave нужно поменять на https://hub.docker.com/r/ninech/jnlp-slave-with-docker/ Или я что-то делаю не так?

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

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

А чем?

buildah требует только CAP_ADMIN емнип

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

То есть всё же слейвов (для сборки докеримаджей) лучше держать вне K8S, что бы они были обычными VM-ками?

(напомню - прокинутый докер сокет в под - это рут на самой ноде)

То есть всё же слейвов (для сборки докеримаджей) лучше держать вне K8S, что бы они были обычными VM-ками?

я не стану советовать что вам делать с секьюрити, я же не в курсе что у вас твориться вообще

в опеншифте это всё давно решено отдельным объектом Build, который работает в RBAC, жду уже когда полноценно допилят бэкэнд с buildah, чтобы наконец-то выкинуть этот дырявый докер

Ну и в чем проблема? Даже тут уже неоднократно писали, не нужно прокидывать сокет в контнейнер, просто юзать tcp к докеру

Сети 😖 Поды не видят друг друга, куда смотреть? apiVersion: apps/v1 kind: Deployment metadata: labels: app: pg1 name: pg1 spec: replicas: 1 strategy: {} selector: matchLabels: app: pg1 template: metadata: labels: app: pg1 spec: containers: - name: pg1 image: postgres:9.5 ports: - containerPort: 5432

Ну и в чем проблема? Даже тут уже неоднократно писали, не нужно прокидывать сокет в контнейнер, просто юзать tcp к докеру

это конечно лучше, но даже с сертификатами весь RBAC уходит лесом

А кто нибудь MetalLB использует?

я одному клиенту поставил. Клиент пока не жаловался. Но там совсем не highload

зачем делать отступы в 4 пробела в ямле?

vim так настроил, так то и 2-х достаточно)

вообще даже 1 достаточно, но принято 2 ставить

ямль гибкий

Все стерпит

Я вообще должен с пода видеть другие поды? Пинговать их там незнаю, на порты ломится...

Кто чем собирает images ? Docker in docker внутри k8s я так понял это совсем не вариант

это конечно лучше, но даже с сертификатами весь RBAC уходит лесом

Ну а зачем RBAC для сборки? Docker на отдельной машинке, только для билда. Мне кажется, все не так драматично :)

Кто чем собирает images ? Docker in docker внутри k8s я так понял это совсем не вариант

я сейчас пытаюсь идти по этому пути

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

Ну а зачем RBAC для сборки? Docker на отдельной машинке, только для билда. Мне кажется, все не так драматично :)

а как регулировать доступ к этой машине?

пытаюсь поставить под с docker:dind + persistent volume для /var/lib/docker, сгенерить сертификаты и дергать демона через API из других подов

норм идея же?

норм

можно ещё kubevirt и вмку сделать

зачем делать отступы в 4 пробела в ямле?

http://www.yaml.org/spec/1.2/spec.html#id2777534

можно ещё kubevirt и вмку сделать

я про такое не слышал, сейчас разберусь, спасибо

http://www.yaml.org/spec/1.2/spec.html#id2777534

это к чему?

это к чему?

ммм, ни к месту, я просто не так понял )

Блин, все-равно ничего не вижу с пода

Только шлюз пингуется и все. На kube-dns ни пингом ни телнетом

Как и на все остальное

Куда смотреть?

походу ваша оверлей сеть не работает

Спасибо, пойду погуглю по новым ключевикам

Ну да, но если постоянные CI/DI процессы то разворачивать проще руками докеры через чем kuberbets тратить время на линковку

Что такое линковка?

Связь между докерами. Как на уровне API в микросервисах так и в целом по инфраструктуре

кажется в контексте кубера речь про поды

Кто чем собирает images ? Docker in docker внутри k8s я так понял это совсем не вариант

Ходим в DIND по сети. Можно еще buildah + VFS storage driver, тогда контейнеру только CAP_SYS_ADMIN нужен, что получше чем —privileged. Но в buildah кеширования нет :(

'тратить время на линковку' предлагаю в топик нашего чаннела

Спасибо, пойду погуглю по новым ключевикам

для Kube-dns выставить реплика=1 и запинать его на ту же ноду где неработающий под - если заработает, то дело в оверлее

А у меня всего одна нода, там все

пытаюсь поставить под с docker:dind + persistent volume для /var/lib/docker, сгенерить сертификаты и дергать демона через API из других подов

+ плагином к докеру ограничить что можно только build команды пускать , но не RUN. (сам еще не сделал так, но в планах)

Связь между докерами. Как на уровне API в микросервисах так и в целом по инфраструктуре

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

+ плагином к докеру ограничить что можно только build команды пускать , но не RUN. (сам еще не сделал так, но в планах)

Это применимо к небольшим проектам. А если ландшафт переносится целый ? Вот тут неудобно

В AWS канале тишена. Тут вопрос такой.У AWS за последнее время ни чего не появилось нового для PPTP или L2TP что-бы можно было секьюрно попадать на инстансы у которых нет доступа наружу ? S-t-S это хорошо и для соединения удаленных подсетей, но если надо одному , двум людям попасть с не рабочего места на иснтансы, как то не хочется для этого пилить отдельный инстанс с pptpd. А изнутри конторы через VPN лезть в AWS подсети это потери скорости итд. Сорри за оффтоп но может кто знает.

В AWS канале тишена. Тут вопрос такой.У AWS за последнее время ни чего не появилось нового для PPTP или L2TP что-бы можно было секьюрно попадать на инстансы у которых нет доступа наружу ? S-t-S это хорошо и для соединения удаленных подсетей, но если надо одному , двум людям попасть с не рабочего места на иснтансы, как то не хочется для этого пилить отдельный инстанс с pptpd. А изнутри конторы через VPN лезть в AWS подсети это потери скорости итд. Сорри за оффтоп но может кто знает.

Поднимите инстанс который будет смотреть и наружу, и в нужную сеть и через него подключайтнсь. Хоть ssh, хоть l2tp, хоть shadowsocks.

Поднимите инстанс который будет смотреть и наружу, и в нужную сеть и через него подключайтнсь. Хоть ssh, хоть l2tp, хоть shadowsocks.

Ну для этого я могу плднять OpenVPN или PPTP сервак на t2.micro, меня интересуют именно встроенные фичи AWS , возможно что-то появилось уже. Опять же , не охото создавать дополнительную точку отказа/обслуживания так как ее придется обслуживать, документировать и сертифицировать. Нужно что-то надежное быстрое и изящное.

Все-равно с сетью фигня( Не видят поды ничего кроме шлюза