Не вздумайте базу в кластер запихивать

В кластер-то почему нет? Local Persistent Volumes + репликация СУБД (если нужна) - вполне вариант

Реплика будет привязана к ноде, умрёт нода, данные потерялись

А вне кластера ноды не умирают?

А вообще Кубер on-premise не нужен!

Привет, ребята помогите разобрать, чет запутался. Есть локальный кластер мастер и два воркера. Я использую metalLB как loadbalancer. Приложение на .net core. Все работает хорошо metal отдает ip сайт доступен. Но мне надо прикрутить еще ssl, добавил nginx ingress с правилами для ssl а вот дальше начинаю путаться. Ingress сделал как loadbalancer, ему metal дал ip, как теперь достучаться до сайта с помощью ip nginx ingress или ip metal который получил вначале? или я все напутал)?

layer2

идете по IP ингресс, который metallb выдал

а само приложение стоит ли тогда делать loadbalancer чтобы оно также получало ip ip от metal или хватит ingress?

Ребят, если есть внешний балансировщик, внутри кластера для доступа к сервисам необходимо создать только ingress?

В какую сторону копать?

А кто может подсказать как в prometheus установленный через helm запушить свои рулы и алерты?

Service достаточно, ингресс нужен для доступа из мира

Ребят, если есть внешний балансировщик, внутри кластера для доступа к сервисам необходимо создать только ingress?

Мне и нужен доступ из мира) Может я конечно не до конца что то понимаю, только изучаю. У меня есть балансировщик нагрузки от Digital Ocean к которому привязано доменное имя, есть кластер с 2 нодами и 1 мастер нодой. Т.е тогда получается, что бы достучаться из внешнего мира должна быть следующая схема Load Balancer (external) -> [ Load Balancer (internal) -> Ingress -> Services -> ...] ?

Мне и нужен доступ из мира) Может я конечно не до конца что то понимаю, только изучаю. У меня есть балансировщик нагрузки от Digital Ocean к которому привязано доменное имя, есть кластер с 2 нодами и 1 мастер нодой. Т.е тогда получается, что бы достучаться из внешнего мира должна быть следующая схема Load Balancer (external) -> [ Load Balancer (internal) -> Ingress -> Services -> ...] ?

Мне и нужен доступ из мира) Может я конечно не до конца что то понимаю, только изучаю. У меня есть балансировщик нагрузки от Digital Ocean к которому привязано доменное имя, есть кластер с 2 нодами и 1 мастер нодой. Т.е тогда получается, что бы достучаться из внешнего мира должна быть следующая схема Load Balancer (external) -> [ Load Balancer (internal) -> Ingress -> Services -> ...] ?

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

Спасибо большое всем за ответы! Есть еще один вопрос, нормальная ли практика разворачивать несколько проектов на одном кластере? Допустим у нас есть 2 команды, каждая работает над своим проектом, разумно будет их поместить на один кластер с различными namespace?

ребутнул ноду и контейнеры друг друга увидели. Что было - хрен его знает

Спасибо большое всем за ответы! Есть еще один вопрос, нормальная ли практика разворачивать несколько проектов на одном кластере? Допустим у нас есть 2 команды, каждая работает над своим проектом, разумно будет их поместить на один кластер с различными namespace?

из-за этой петрушки слез с Helm, слишком геморойно копировать и патчить это барахло, прощё своё написать.

Спасибо! А если необходимо для двух этих команд предоставить разные домены для доступа к их сервисам. Необходимо в каждом namespace создать свой ingress?

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

Подскажите я правильно понимаю что мне нужно сделать? В документации написано serverFiles.rules Prometheus server rules configuration {} Значит мне надо сделать rules.yaml который будет выглядеть как : serverFiles: rules: |- - все правила И сделать helm upgrade prometheus -f rules.yaml ?

Подскажите, возможно ли использовать в command/args переменные? Все что нагуглил это всякие echo. Пробовал на их примере - gunicorn не вставляет вместо $(VAR_NAME) нужную переменную

Да, только не забудь reuse values, а то потеряешь настройки с которыми ставил

Странно что правило я создал, алерт тоже, перезапустил alertmanager и ничего не произошло :\

А у тебя оператор?

У меня с оператором. Но они в принципе похожи. 100 пудов правила идут в ConfigMap и оттуда монтируются. Возможно в чарте бага. Найди этот CM и пересоздай с новым файлом

Ну и там релоадер должен пинать когда CM меняется. А ты даже перезапустил.

типа command: ["/bin/bash"] args: - -cex - exec gunicorn ${VAR_NAME}

спасибо. А насколько это вообще правильно? Просто в таком случае pid 1 в контейнере получает же не gunicorn, а bash?

Может я что-то неправильно делаю?

Всем привет! Пытаемся разобраться что же лучше: Helm, Helmfile, Kustomize, Qbec, etc. Сейчас в основном используем Helm + Helmfile. Но есть сомнения, которые и заставляют смотреть в сторону других решений. Основные сомнения: связка Helm + Helmfile только добавляет багов в процесс, также иногда приходится выполнять одну и ту же команду delete, чтоб всё-таки helm удалил все ресурсы, которые создал. Интересен Qbec. Выглядит свежо и более функционально по сравнению с Kustomize. Но есть маленькое НО. Как, например, завести такого монстра как стэк ELK или Prometheus, Grafana, Alertmanager, exporters, и т.д. без Helm? Кто-то пробовал подобное?