А какой контроллер?

nginx

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

А заимпортировать pvc в новый и чтобы стейтфулсет из того же хелмчарта их подхватил - у меня не выходило

А что происходило?

Возможно helm каждый раз генерит новые имена для StatefulSet'а / volume, потому и не подхватывал в моём случае - они вполне подхватываются, даже через helm (редерю чарт на стороне клиента)

новый PVC и PV генерировались

а canary 1-6

там все айпишники, бэкапится он норм, но как восстанавливать?

теоретически они бы не могли генериться, т.к. PersistentVolumeClaimTemplate всегда генерит PVC вида: %volumename%-%statefulsetname%-%replicaid%

я так навскидку не вспомню, это было 2 года назад но так и так пробовал - не заводилось, только через редактирование новых PV и подстановку туда старых EBS volume id

Я с кенери игрался, у меня вме ингрессы в однос нс были.

как бы логика вроде работает, но проблемы при удаление деплоя старого релиза, и там ОГРОМЕННЫЙ helm, который создает namespace, секреты для приложения,

Балансер работает с Target Group AWS. Если Кубер "вспомнит" ее id и добавит туда хостов после восстановления, то все должно срастить.

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

Хмм, а вместе с деплоем ингрессс заодно не удаляется случайно ?

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

Хмм, а вместе с деплоем ингрессс заодно не удаляется случайно ?

Если она описана в metadata или spec то вспомнит, если в status - то нет

Ну ручкам прописать нужный id как крайний вариант )

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

Всем привет! Подскажите, при использовании prometheus-operator через helm, можно добавлять сервисмониторы, не прописывая их в customs.yaml?

Ну ведь сервис мониторы это просто объект, вы можете его создавать как угодно и через что угодно. Или вас интересует только через helm и шаблон оператора?

А, не, у меня helm template, а сервис мониторы отдельно для проектов добавляются.

через helm template?

Ну беру и делаю шаблоны, потом apply

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

https://youtu.be/yGKI5JoKMUY

муншоты живы ? офигеть.

В смысле?)

https://youtu.be/hoqsUCw6bmM

https://youtu.be/hoqsUCw6bmM

https://youtu.be/hoqsUCw6bmM

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

Масло само по себе плохой расстворитель, собственно это основная причина почему не спирт/дистиллированная вода/что-то ещё

https://youtu.be/yGKI5JoKMUY

??

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

никак, resourceName нужно полное имя. Наиболее разумное предложение пока только в https://github.com/kubernetes/kubernetes/issues/44703

Я наверное уже всех достал. Но я снова пишу о pod security policy. Вдруг кто-то тоже с этой проблемой боертся. Если вкратце: проблема в том, что после включения PodSecurityPolicy (который прописывается в параметрах kube-apiserver) под kube-apiserver не поднимается, точнее сам под поднимается и запускается успешно в докере, но как под kubernetes'а не регистрируется в системе и его не видно в выводе kubectl. Так вот, оказалось что оно работает только если привязывать к системной группе system:authenticated. А именно вместо сервисаккаунта нужно роль забиндить к группе: apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: psp-allow-all roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: psp-allow-all subjects: - kind: Group apiGroup: rbac.authorization.k8s.io name: system:authenticated Статический под kube-apiserver поднялся. Победа. Работает только с этой группой, с system:serviceaccounts тоже не работало. Резюмируя. Если хотим включить PodSecurutyPolicy, то для статических подов плоскости управления (которые запускаются из /etc/kubernetes/manifests) да и вообще для всех подов из неймспейса kube-system надо создавать политики PodSecurityPolicy (которые им разрашают делать то что они делают, например hostnetwork, hostPorts, priveleged и т.д.), создавать кластерную роль и биндить ее на уровне неймспейса kube-system на группу system:authenticated. И наверное правильно это делать еще до включения плагина PodSecurutyPolicy, иначе при перезапуске любого важного пода плоскости управления он может просто не подняться из-за политик. Вроде логично это, но я чет не сразу допер.

добрый вечер кто-нибудь использует трефик как daemonset с открытыми на хосте портами мимо кубера? есть проблемы с этим?

Привет. В кубе подам можно как-то задать приоритет? Я имею ввиду не QoS класс / limits / requests, а именно приоритет, равно как если бы я сделал renice

https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/ ?

типа nice?

да-да

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

Привет. В кубе подам можно как-то задать приоритет? Я имею ввиду не QoS класс / limits / requests, а именно приоритет, равно как если бы я сделал renice