нет

кстати про терраформ лучше в чят хашикорп

Можно линку?

https://t.me/ru_hashicorp

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

а можешь вкратце что с ним не так?

а можешь вкратце что с ним не так?

На бумаге все очень хорошо. На слайдах все очень хорошо. В подписанным контракте между Гуглом и Нетфликсом все очень хорошо. В Гугле деплоят спинакером в k8s очень хорошо Документации мало, качество кода оставляет желать лучшего. Нетфликс по факту кладет на комтюнити. Гуглу они заделиверили каннари апгрейды в начале года. Комьюнити месяц назад И такого очень много

ну то есть очень специфичная шняга вещь-в-себе

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

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

https://t.me/ru_hashicorp

Спасибо

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

спасибо за отзыв

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

несмотря на то что он говно, он уже мейнстрим

Но всеравно гавно

угу

А альтернатив походу нет

недавно в спиннакер завезли поддержку хелма на уровне, из очередного java куска делать os.exec("helm")

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

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

образовалась даже контора в которую влили 4kk$ (которые по моим подсчетам должны закончиться ровно через год) http://armory.io которая деливерит за невменяемые деньги spinnaker

20 работяг, из которых около 8 инженеров и хантят еще троих

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

Всем привет. Я только недавно начал изучать k8s. Есть поставленая задача, нужно предоставлять клиентам доступ к приложению. Приложение состоит с 4х контейнеров docker (бд, php приложение, прокси, редис). По описанию, кубер подходит очень таки. Каждому клиенту создавать нейспейс, и в нем разворачивать контейнеры, при выходе обнов, обновлять нужный контейнер. Мне бы совет, реально сделать так? Или лучше поискать варианты попроще? Просто есть следующие сложности: - диски предоставлять нужно только с текущей ноды, нету никаких файловых хранилищ (религиозное соображение свыше, пытаемся переубедить). Это вроде решается hostPath - из-за предыдущей проблемы, получаем что неймспейсы нужно привязывать только к 1й ноде и всегда запускать приложение на этой ноде, если нода упала, то запускать больше нигде не нужно

Буду очень благодарен за совет )

сделай

каждому свое окружение хотите сказать?

каждому свое окружение хотите сказать?

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

Типа как да, у каждого свое окружение.

Интересует просто насколько это реально? И реально ли вообще.

Интересует просто насколько это реально? И реально ли вообще.

у меня есть похожая архитектура, для каждого клиента свой namespace из 3 подов, наружу торчит только openresty (nginx) который проксирует на etcd и на etcd web ui

Интересует просто насколько это реально? И реально ли вообще.

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

Ну, почти. Я кубер хочу использовать как аркестратор со своей стороны. Грубо говоря, я буду клиентам создавать предустановленный и настроеный Wordpress и предоставлять линк по которому он будет заходить в его админку. К контейнерам клиент никакого отношения иметь не будет. Но судя по описанию, я понял что это реально.

Ну, почти. Я кубер хочу использовать как аркестратор со своей стороны. Грубо говоря, я буду клиентам создавать предустановленный и настроеный Wordpress и предоставлять линк по которому он будет заходить в его админку. К контейнерам клиент никакого отношения иметь не будет. Но судя по описанию, я понял что это реально.

да, это возможно, вам нужно решить только проблему с loadbalancer, вы не указали в своем описании важную деталь где будет хоститься k8s, baremetal, облако?

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

baremetal

С балансером да, пока не понятно.

baremetal

перед тем как планировать инфрастуктуру с k8s на baremetal подумайте как вы будете делать loadbalancer (что бы выставлять наружу клиенту сервисы)

в вашем случае, когда workload привязан к машине можно обойтись и nodePort, что впринципе не очень красиво, но если у вас перед k8s стоит какой-либо ingress, можно и через него сделать, только аккуратно.

ingress рулит

Если есть информация где почитать по этому, буду благодарен. Пока идея состояла в nodePort одного контейнера на каждой ноде, который бы являлся прокси к остальным приложениям, и по домену разруливал.

ingress рулит

Вроде как похоже на то что думал

Если есть информация где почитать по этому, буду благодарен. Пока идея состояла в nodePort одного контейнера на каждой ноде, который бы являлся прокси к остальным приложениям, и по домену разруливал.

зависит от вашей сетевой архитектуры в которую вы добавите ноды с k8s как вариант metallb https://github.com/google/metallb

С сетью тоже все не понятно. По сути, у нас есть ДЦ и мы можем сделать почти любую архитектуру, но я не до конца еще с сетями в кубере разобрался. Пока на стадии тестирования

как вариант можно использовать opencontrail, 3.2.х - нет поддержки k8s (вернее есть. но лучше не использовать от словам совсем) в 4.x.x жирные контейнеры - тоже не очень, соседней команде не удалось его завести 5.х релизнулся две недели назад, я его пробовал поставить у себя - скажем так, оно не заработало, т.к. заделиверли артефакты (докер образа, бинарный ядерный модуль, и прочее) для centos 7.4 специальной ревизии ядра 693 в виде mx'а поставить рядом bgp роутер

успеха я так и не обрел с opencontrail R5.0

зависит от вашей сетевой архитектуры в которую вы добавите ноды с k8s как вариант metallb https://github.com/google/metallb

Я nginx юзаю, доволен

Я nginx юзаю, доволен

да, для "не сложных" случаев он отлично подходит

да, для "не сложных" случаев он отлично подходит

А если упросить сложные случае до не сложных, то тоже норм)

Я nginx юзаю, доволен

Я еще думаю. nginx, или может попробовать traefik

Народ, может всетаки в курсе кто? Так и не решил проблему с Retain для PVC которые создаются динамически. Есть вообще такая возможность?

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

StorageClass - ceph rbd

от удаления кем

юзером?

Да

через хельм

чтобы разрабы тома не по*ерили?)

Именно

Защита от далпаебов короче

чтобы мне спалось лучше

для critical приложений

https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes

только если сюда

только если сюда

Как сюды я знаю :) но это не то

В общем сделал в лоб ❗️Прописал Retain Policy в сам StorageClass (((

есть у кого-нибудь опыт с istio? если да, то как от него впечатления?

плюсы-минусы

В общем сделал в лоб ❗️Прописал Retain Policy в сам StorageClass (((

есть такая замечательная штука, называется она DEV_ENV

не пробовали не пускать разрабов туда где они могут что то сломать?) пускай ломают у себя в песочнице)

если че, деплоите заново и все

Через CI могут сломать

prod тот же к примеру

CI/CD всетаки

а как так разрабы к проду доступ имеют три четыре среды, протестили, обкатали, ии деплоите

у них есть там стейдж максимум, пусть там ломают свои PVC и спите спокойно:)

Не все так просто)

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

Тут вопрос интеграции gitlab + k8s

Из коробки я могу настроить на один NS

там же лежит прод стейдж и ревью

не совсем удобно с точки зрения k8s

я предлагаю другой вариант

но удобно с точки зрения интеграции с гитлабом

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

вы типа раннерами чарты пускаете?

Вот я и говорю, не так все просто) в принципе Retain для StorageClass Решил мою проблему, главное чтобы мусор не плодился, pvc по сути только для прод стейдж, остальное живет в памяти

ну не знаю, у нас за проду отвечают тупо девопсы, у разрабов свои песочницы, пусть хоть засносятся там)

Теперь у меня вот так:

в крайнем случае пусть у себя подымают на миникубе те же чарты с минимальными репликами и все:)

в крайнем случае пусть у себя подымают на миникубе те же чарты с минимальными репликами и все:)

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

ну так пусть деплоят только в своей среде

деплой привязан к ci/cd через gitlab, в gitlab Интеграция идет из коробки толко один проект - один неймспейс

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

Можно, но не стоит того

Это значит минусы перевешивают плюсы

ну, если секурность и здоровые нервы не приоритет, то да?

я не вижу минусов разве что по железу

по интеграции, говорю же

и автоматизации