я подумал оно все в одной сети по сути

неужели может быть в этом затык?

ну сомневаюсь

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

как в анекдоте про маккинзи

))

а насчет ссд что скажете?

это не особо важно?

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

nginx к примеру смотрит на /var/www/html

я вот эту папку смонтировал как отдельный волюм

и дал ему класс pd-ssd

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

а лимиты у вас есть ?

в смысле квота?

или по ресурсам?

квота это на неймспейсах, на ресурсах реквесты и лимиты

limits: cpu: 200m memory: 512Mi requests: cpu: 200m memory: 256Mi

наращивал cpu до 1 ядра даже

не помогало особо

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

у вас хоть метрики есть?

в панели самого gcloud есть

там потребление ресурсов в рамках

этой квоты хватает

Посмотрите что у вас код делает в момент затупа. А то так можно все что угодно перебирать

это не квоты...

да, в смысле лимитов

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

по cpu - нет

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

да, это понятно, буду изучать

спасибо за помощь

Использует кто kustomize? Не могу понять как сделать что-то вроде labelPrefix, чтобы разделять production/staging сервисы.

А, просто namePrefix: app-production- commonLabels: app: app-production Круто, что в base не нужно писать labels/selector/template по ним. Сам цепляет.

Парни prometheus operator юзали? Я не могу понять с prometheus server всё сходу понял, там всё из коробки работает. А в чём его прикол?

те кто деплоят приложение могут создавать свои правила аггрегации и алертинга

не надо ходить и вписывать их в конфиге прометея

А как?

и так же с эндпоинтами которые прометей скрейпит

Алерты тоже?

да

у них в доке расписано, лучше там посмотри

я так до сих пор не добрался

Там свой kind

?

угу

Если я задеплою экспортер для мускула он пропишется в Конфигмап?

сам по себе - нет

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

серьёзно, глянь доку

Там свой kind

Там есть такая штука как сервис монитор. Выглядит примерно так: apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: container-monitor spec: jobLabel: containers selector: labels: - role: metrics namespaceSelector: matchNames: - kube-public endpoints: - port: metrics path: /metrics interval: 10s prometheus-operator исходя из такого конфига правит конфиг прометея для того чтобы он бегал по подам сервисов с ролью metrics и дергал их за /metrics

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

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

да, чот я не остановил поток фантазии вовремя. Ща поправлю

разве что порты превращает в чиселки

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

Меня вот больше интересует, нафига деплоится 2 прометея. Я это не осилил и оставил одного

Но я маленько слоупочил и делал по статье фланта с хабра 😄

а зачем не два?

your monitoring deserve reliability too

но конечно от твоего кейса зависит

Но я маленько слоупочил и делал по статье фланта с хабра 😄

она устарела же

А киньте ссылку на фланта

А киньте ссылку на фланта

https://habr.com/company/flant/blog/340728/

она устарела же

Ага, но отталкивался от нее

ставьте kube-prometheus через jsonnet, путь от разработков, остальное все чревато устареванием.

Я читал доку в хельме, немного не вкурил, а сейчас уже заходит :)

Спс парни, как всегда выручили :)

https://www.projectcalico.org/security-bulletins/

хорошо прям

https://www.projectcalico.org/security-bulletins/

спасибо!

https://www.projectcalico.org/security-bulletins/

🤦‍♂️🤦‍♂️

Всем привет! У меня есть вопрос, есть ли возможность заставить helm запускать сервисы поочереди или сначала опускать их а затем поднимать? Просто у нас жесткое ограничение по ресурсам в кластере стоит, а при использовании helm получается нужно 2x ресурсов, тк он сначала поднимает новое приложение затем опускает старое( Или может быть ктото боролся с этой проблемой другими путями?

Мне прост надо было решить проблему 1 единственную. А главное решить ее не подняв ради этого ceph + istio и еще кучу всего вокруг что будет по ресурсам жрать больше самого приложения

Для истио разве нужен сеф?

Всем привет! У меня есть вопрос, есть ли возможность заставить helm запускать сервисы поочереди или сначала опускать их а затем поднимать? Просто у нас жесткое ограничение по ресурсам в кластере стоит, а при использовании helm получается нужно 2x ресурсов, тк он сначала поднимает новое приложение затем опускает старое( Или может быть ктото боролся с этой проблемой другими путями?

Так куб делает в принципе, даже не в хельме дело

Всем привет! У меня есть вопрос, есть ли возможность заставить helm запускать сервисы поочереди или сначала опускать их а затем поднимать? Просто у нас жесткое ограничение по ресурсам в кластере стоит, а при использовании helm получается нужно 2x ресурсов, тк он сначала поднимает новое приложение затем опускает старое( Или может быть ктото боролся с этой проблемой другими путями?

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-surge

на проде кто-то уже использовал? https://rook.io

Для истио разве нужен сеф?

Цеф мне советовали когда я рассказывал про то что у меня статика лежит в проекте с php кодом и ее надо сервить с nginx.

Цеф мне советовали когда я рассказывал про то что у меня статика лежит в проекте с php кодом и ее надо сервить с nginx.

Ceph тяжёл и если у вас не кучи терабайт то он избыточен

Глустер легче цеф