а можете рабочие how to посоветовать?

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

Я fluentd пересылаю эвенты и логи в спланк

тип не прописывается по умолчанию инстанс, с которого снимается метрика и нет различий в лейблах между несколькими кластерами, из-за чего прилетают либо дубликаты, либо ошибки out-of-order

CNI логи чисты, ошибок нет

Контора платит, почему быт нет :)

https://medium.com/@dominik.tornow/inside-kubernetes-rbac-9988b08a738a

Какой то формализм ненужный. Не пейпер хаскелистов же

Можно ли используя network policy ограничить трафик между неймспесами? или надо задать им сегменты сети напрямую и городить заборы между сегментами?

Можно и нужно

canary deployment, green/blue и тп техники в кубе.

Ребят, кто юзает prometheus-operator в кубере. Сколько оперативы он у вас жрет?

Ребят, кто юзает prometheus-operator в кубере. Сколько оперативы он у вас жрет?

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

иии... речь про сам оператор или в целом про весь его выводок? =)

иии... речь про сам оператор или в целом про весь его выводок? =)

в церкви метрик лучше спрашивать

Интересно еще узнать, сколько он потребляет на более менее нагруженных кластерах, где штук 500-1000 подов. Неужели так и продолжает расти?

Интересно еще узнать, сколько он потребляет на более менее нагруженных кластерах, где штук 500-1000 подов. Неужели так и продолжает расти?

а в секунду у тебя сколько сэмплов?

У меня с такой статой почти 3 гига потребляет на пике.

Интересно еще узнать, сколько он потребляет на более менее нагруженных кластерах, где штук 500-1000 подов. Неужели так и продолжает расти?

речь именно про поды прометея. У меня они жрут 1-2 гига оператвы и продолжают расти. Вот понять не могу, нормально ли это.

https://www.cncf.io/wp-content/uploads/2018/03/CNCF-Presentation-Template-K8s-Deployment.pdf

ну да. Если такое не нужно - есть recreate

ну да. Если такое не нужно - есть recreate

В смысле доку нужно читать. Меня по-умолчанию устраивает в 99% случаев.

Старая шутка заиграла по новому)

recreate это не стратегия по-умолчанию

recreate это не стратегия по-умолчанию

Я не понимаю о чем ты. Стратегия по умолчанию RollingUpdate. Если сделать readiness, то будет zerodowntime

а recreate == kubectl delete pod? а то вот я когда так делаю с подами, то как раз в таком случае появляется даунтайм

чуть сложнее. Он будет ждать, пока все помрут. kubectl delete pod не остановит возрождение.

Всем привет. Поделитесь опытом, пожалуйста. У меня в проекте примерно 40 микросервисов, сейчас у каждого в своей репе helm chart. Количество сервисов растет неуклонно, они все очень связаны, то есть чтобы протестировать один из сервисов надо запустить как минимум 2-3 зависимости. Есть qa, которые пишут стабы чтобы тестировать конкретные сервисы изолированно. У меня задача построить пайплайн, конечная точка в пайплайне установка в окружение stage. Пока мысли такие, по киммиту для конкретно модуля создаем namespase запускаем там стабы и автотесты, далее если ок ставим в перманентное окружение dev в нем опять тесты и шаг review, после которого уже по кнопке в stage если версия компонента релизная. И ещё нормально ли пошарить чарты между репами сервисов через git submudules, хочется видеть их в одном месте, так же по сути в этом отдельном репе определить env vars для конкретных окружений. Если у вас что-то похожее прошу поделиться опытом пожалуйста.

Всем привет. Поделитесь опытом, пожалуйста. У меня в проекте примерно 40 микросервисов, сейчас у каждого в своей репе helm chart. Количество сервисов растет неуклонно, они все очень связаны, то есть чтобы протестировать один из сервисов надо запустить как минимум 2-3 зависимости. Есть qa, которые пишут стабы чтобы тестировать конкретные сервисы изолированно. У меня задача построить пайплайн, конечная точка в пайплайне установка в окружение stage. Пока мысли такие, по киммиту для конкретно модуля создаем namespase запускаем там стабы и автотесты, далее если ок ставим в перманентное окружение dev в нем опять тесты и шаг review, после которого уже по кнопке в stage если версия компонента релизная. И ещё нормально ли пошарить чарты между репами сервисов через git submudules, хочется видеть их в одном месте, так же по сути в этом отдельном репе определить env vars для конкретных окружений. Если у вас что-то похожее прошу поделиться опытом пожалуйста.

Всем привет. Поделитесь опытом, пожалуйста. У меня в проекте примерно 40 микросервисов, сейчас у каждого в своей репе helm chart. Количество сервисов растет неуклонно, они все очень связаны, то есть чтобы протестировать один из сервисов надо запустить как минимум 2-3 зависимости. Есть qa, которые пишут стабы чтобы тестировать конкретные сервисы изолированно. У меня задача построить пайплайн, конечная точка в пайплайне установка в окружение stage. Пока мысли такие, по киммиту для конкретно модуля создаем namespase запускаем там стабы и автотесты, далее если ок ставим в перманентное окружение dev в нем опять тесты и шаг review, после которого уже по кнопке в stage если версия компонента релизная. И ещё нормально ли пошарить чарты между репами сервисов через git submudules, хочется видеть их в одном месте, так же по сути в этом отдельном репе определить env vars для конкретных окружений. Если у вас что-то похожее прошу поделиться опытом пожалуйста.

мы по MR создаем изолированные стенды в раздельных namespace. Тоже хелм-репы используем

То есть обновился сервис один какой-то, сработал триггер и пошло создание свежего неймспейс куда ставится вся система?

не совсем, у нас задача несколько проще. В основном для нужд разработки и qa - надо поднимать кучу стендов с продуктами параллельно, с разницей в ветке из которой собирались проекты. Для независимой разработки\тестирования новых фич. К примеру - создается новая ветка (master branch + feature) -> после MR в нее срабатывает триггер и либо создается копия инфраструктуры в новом namespace, либо он обновляется до новой версии

Понял, спасибо.

Самая большая проблема у прометея с потреблением памяти во время отрисовки графиков (раскушивался до 20гб), в этом случае хорошо помогает https://github.com/Comcast/trickster

народ, поделитесь опытом, пожалуйста а как вы собираете метрики в прометее с двух и более nginx-ingress контроллеров, при помощи nginx-exporter? есть такой аргумент у экспортера: -nginx.scrape-uri как я понял, он подходит только если у меня один ингресс будет есть такой вот daemonset и service: https://pastebin.com/VRj7VTR9 но не заводится из-за ошибки(stub-status локейшен если че есть в конфигах ingress-cintroller-ов и слушается на 8080 порту): Nginx Client: Failed to create NginxClient: failed to get http://127.0.0.1:8080/stub_status: Get http://127.0.0.1:8080/stub_status: dial tcp 127.0.0.1:8080: connect: connection refused