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

Kubelet для меня это часть контрол плейна - какая то хеоня сбоку нужная для запуска приложений , необходимое зло

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

Один сервис можно и статично задать

то есть не через servicemonitor?

Kubelet для меня это часть контрол плейна - какая то хеоня сбоку нужная для запуска приложений , необходимое зло

по сути это супервизор и на нем много что завязано, запуск и удаление подов, подкладывание волумов, метрики и т.п., так что я бы не назвал его “какой то Go процесс на каждой ноде”

по сути это супервизор и на нем много что завязано, запуск и удаление подов, подкладывание волумов, метрики и т.п., так что я бы не назвал его “какой то Go процесс на каждой ноде”

Я не говорю что он не нужен, я говорю что он приложению не нужен, а приложение первично. Куб не ради куба же

Я не говорю что он не нужен, я говорю что он приложению не нужен, а приложение первично. Куб не ради куба же

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

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

Если это не так,то надо стараться к этому приблизиться

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

Честно говоря я не могу сказать, что с моей стороны все было правильно 🙂 Но точно натыкался на issue, с подобным кейсом - апи сервер недоступен, через некоторое время ingress-controller все ednpoint-ы обнуляет. Но это было еще на версиях 0.9.x

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

как то у меня изза oom и сильного повышения нагрузки на тачках обращение к api стало занимать слишком много времени. я таймауты до этого низкие поставил для kubelet, чтобы детектить быстро исчезновение машины, тут я сам облажался конечно. все kubeletы не смогли о статусе отчитаться пару раз, а один какого то хрена залип и не смог более ни разу отчитаться успешно. нода notReady, мало того что итак нагрузка, этот пёс начал эвиктить всех с одной из машин. тогда я таймауты задрал пожирнее. вот про ингресс и его конфиг не думал, что будет когда апи недоступен

Вообщем пока есть живой ip пода надо стараться использовать его и не верить никому.

В том то и дело, что CRD ресурсы неймспейснуты и нет никакой причины давать разрешения на чтение секретов и руление sts в тех неймспейсах, откуда читают ServiceMonitor. Закину патч, посмотрим что скажут

https://github.com/coreos/prometheus-operator/pull/2197

И https://github.com/coreos/prometheus-operator/pull/2202

Вместе позволяют уменьшить RBAC права для Prometheus operator в неймспейсах откуда ServiceMonitor и PrometheusRule берутся, в частности не надо уметь читать/создавать/удалять все sts,secrets, pods

💪🏽, несмотря на карканье всяких скептиков типа меня

Ну там только код, я ещё не запускал :)))

я не настоящий сварщик, но в #2022 тогда придется ручками перезапускать пром, если секрет поменялся, он же теперь за ними не следит?

я не настоящий сварщик, но в #2022 тогда придется ручками перезапускать пром, если секрет поменялся, он же теперь за ними не следит?

Оно и раньше не очень то следило судя по коду - только секреты в том же неймспейсе что и Prometheus CR триггерили пересоздания конфигов

Оно и раньше не очень то следило судя по коду - только секреты в том же неймспейсе что и Prometheus CR триггерили пересоздания конфигов

ну да, он его напрямую монтировал, переделывал конфиг и посылал HUP - секрет перечитывался

впрочем, это довольно редкий случай

Всем привет. Смотрел на network policies, много думал: у нас есть и веб-сервисы, кафка, эластик, кибана, графана, которые публикуются через ingress. есть ещё jupyterhub для саентистов, который ходит вообще фиг знает куда. Что-мне подсказывает, формализовать такой зоопарк будет непросто, чтобы оформить правила в стиле dmz. Есть ли смысл пытаться делать dmz в кубе? Можете поделиться опытом?

Оно и раньше не очень то следило судя по коду - только секреты в том же неймспейсе что и Prometheus CR триггерили пересоздания конфигов

А нет, в enqueuForNamespace (который из handlesecretupdate) действительно триггерят пересоздание конфигов. Ну и фиг с ним, под флаг спрячу если не придумаю, мне эти Basic Auth секреты вообще не нужны :)

Коллеги подскажите по сбору метрик, не могут считываться метрики с controller-manager, etcd, scheduler. Они же запущены на мастер ноде как демоны, и поэтому в эндпоинтах сервисов фигурирует фактический ип физической ноды, и Прометей ругается на refused и эти таргеты в дауне. И на самом деле пробовал с хоста мастер ноды, по фактическому ип не даёт, а по 127.0.0.1 даёт, смотрел в конфиги этих подов, и там прописан адрес как раз 127.0.0.1, поэтому и ходит только на него, как быть в такой ситуации.

Коллеги подскажите по сбору метрик, не могут считываться метрики с controller-manager, etcd, scheduler. Они же запущены на мастер ноде как демоны, и поэтому в эндпоинтах сервисов фигурирует фактический ип физической ноды, и Прометей ругается на refused и эти таргеты в дауне. И на самом деле пробовал с хоста мастер ноды, по фактическому ип не даёт, а по 127.0.0.1 даёт, смотрел в конфиги этих подов, и там прописан адрес как раз 127.0.0.1, поэтому и ходит только на него, как быть в такой ситуации.

0.0.0.0 прописать.

То есть надо патчить эти ядерные поды? У меня кластер не навернется?

То есть надо патчить эти ядерные поды? У меня кластер не навернется?

Как разворачивал? kubeadm 0.0.0.0 по-дефолту ставит.

Как разворачивал? kubeadm 0.0.0.0 по-дефолту ставит.

не ставит, только свежий глянул

kubeadm ставил, но использовал apiserver-advertise-address, были какие-то траблы

не ставит, только свежий глянул

Действительно. Похоже, артефакт после обновлений остался.

advertiseAddress: корректный в серую сеть поставить и всё окей будет.

я не настоящий сварщик, но в #2022 тогда придется ручками перезапускать пром, если секрет поменялся, он же теперь за ними не следит?

Комменты к ПР велкомэ

advertiseAddress: корректный в серую сеть поставить и всё окей будет.

Что имеете в виду?

У меня там стоит ип ноды с мастером

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

Хочу запускать ansible-playbook сайдкаром к сервису, какой раннер взять?

Я не говорю что он не нужен, я говорю что он приложению не нужен, а приложение первично. Куб не ради куба же

> куб не ради куба Изыди, еретик!

Хочу запускать ansible-playbook сайдкаром к сервису, какой раннер взять?

Омг

Омг

думаешь плохая идея?

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

расскажи :)

Хочу запускать ansible-playbook сайдкаром к сервису, какой раннер взять?

https://hub.docker.com/r/ansible/awx_task/

Ну есть штука, которую нужно конфигурить. Есть playbook который хорошо это делает. Есть инвентори со всей конфигурацией котоая должна быть применена. Идея в том что бы вместе со штукой стартовал gitlab-runner который при изменении конфигурации в репе запускал бы playbook который применял бы изменения в сервисе

Ну есть штука, которую нужно конфигурить. Есть playbook который хорошо это делает. Есть инвентори со всей конфигурацией котоая должна быть применена. Идея в том что бы вместе со штукой стартовал gitlab-runner который при изменении конфигурации в репе запускал бы playbook который применял бы изменения в сервисе

ну так это ж https://github.com/water-hole/ansible-operator

ох

advertiseAddress: корректный в серую сеть поставить и всё окей будет.

Он же у меня и стоит такой, ип внутренней сети, по нему и пром бьётся, но безуспешно, в этом и трабл...

ну так это ж https://github.com/water-hole/ansible-operator

не совсем понимаю что конкретно он делает и какие задачи решает

не совсем понимаю что конкретно он делает и какие задачи решает

делаешь имадж из кода хранишь конфигурацию в CRD (всю inventory и vars + указатель на имадж с кодом) оператор следит за изменениями CRD и запускает плейбук

делаешь имадж из кода хранишь конфигурацию в CRD (всю inventory и vars + указатель на имадж с кодом) оператор следит за изменениями CRD и запускает плейбук

ага, теперь понял, спасиб за наводку!

так тебе и сайдкар не нужен, если дать права оператору делать exec в нужном поде

да интересный замут, но все же я сейчас больше склоняюсь к тому что-бы собрать отдельный контейнер с ansible, моим плейбуком и gitlab-runner'ом, т.к. весь процесс деплоймента в ci будет виден

Какой у кого вообще advertise-address в apiserver?

0.0.0.0?

Ребят, у меня GKE кластер с версией v1.11.3-gke.18, в ней есть фикс последней уязвимости?

а то в changelog'e только в 1.11.5

загугли баг

там есть тулза для тестирования

я видел, она вроде только для опенстека

Ребят, у меня GKE кластер с версией v1.11.3-gke.18, в ней есть фикс последней уязвимости?

Я сомневаюсь что гугл станет бекпортить фикс в свой gke, 99% что нет там его. Тч дорога вам в 1.11.5

srsly?)

вы хотите сказать у всех кластеров GKE сейчас такая уязвимость?

Я погуглил за вас

https://cloud.google.com/kubernetes-engine/docs/security-bulletins

У вас пропатченная версия, живите спокойно

У вас пропатченная версия, живите спокойно

Благодарю

Кто-нибудь использует GKE в проде с более-менее нагруженными сервисами?

Хочу переехать туда с bare-metal со всеми нашими сервисами

но пугают цены на трафик

учитывая что у нас SPA, в месяц набегает +/-25-30тб

учитывая что у нас SPA, в месяц набегает +/-25-30тб

будет очень дорого, если не начать отдавать статику и все статические объекты API через cdn

я смотрел презентацию

на kubernetes конфе

будет очень дорого, если не начать отдавать статику и все статические объекты API через cdn

у нас все что можно закэшировано в cloudflare cdn

без него было бы в 15 раз больше трафика

у нас тупо websockets сжирает 20-25-30тб

в месяц

Ну есть штука, которую нужно конфигурить. Есть playbook который хорошо это делает. Есть инвентори со всей конфигурацией котоая должна быть применена. Идея в том что бы вместе со штукой стартовал gitlab-runner который при изменении конфигурации в репе запускал бы playbook который применял бы изменения в сервисе

Если штука больше чем в одном экземпляре, то только один gitlab-runner запустит жобу с ансиблом

надоело bare-metal opsить

https://cloud.google.com/network-tiers/pricing c 1 января новые цены однако

Если штука больше чем в одном экземпляре, то только один gitlab-runner запустит жобу с ансиблом

да в целом мне подходит, штука в одном экземпляре, все изменения через нее записываются в бд