если у теюя миллион записей в секунду, будет дорого)

не миллион. Если кто смотрел как это повлияло на затраты с их кластером, то прошу поделиться

are you typing the code right?

Я включал, чтобы отследить кто использует старые API пути для deploy/daemon-set/etc на пару дней - разницы особо не заметил

в спеке manageFields смотри, там написано кто какое поле правил

уффф

ща гляну

спасибо 👍
нас безопасники заставили включить

Уважаемые Коллеги!

24 ноября приглашаем вас принять участие в вебинаре на русском языке, на котором коллеги из компании Tigera расскажут вам о наиболее распространенных вопросах, возникающих в процессе переноса и модернизации приложений в инфраструктуру Kubernetes.

После окончания вебинара его участникам будут направлены: презентация, запись вебинара, ссылки на дополнительные материалы, а также анкета участника, после заполнения которой, вы получите шанс выиграть приятные и полезные призы (ваучеры Amazon, а также креативные подарки от Tigera и Factor Group).

Вебинар рекомендован для ИТ-специалистов, DevOps, DevSecOps, сетевых инженеров и архитекторов, а также всех технических специалистов, работающих с Kubernetes (K8s), и интересующихся вопросами обеспечения безопасности и стабильности работы с точки зрения сетевой инфраструктуры K8s.

Подробнее о мероприятии и программе.
Подробнее о решениях Tigera.
Для того, чтобы принять участие в вебинаре, необходимо зарегистрироваться.

Какое самое норм решение заставить работать pod disruption budget для 1 реплики? Аналогично rolling upgrade (катим второй под, ждем пока поднялся, вырубаем первый)

указать в роллингапдейте что максимальнонедоступно 0?

не не
я про то что если тупо сделать так

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
 name: api
spec:
 minAvailable: 1
 selector:
   matchLabels:
     app: api

и деплоймент api в 1 реплике, то drain никогда не завершится, потому что у PDB будет ALLOWED DISRUPTIONS == 0

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

вот вопрос в том как бы воткнуть костыль, потому что очень надо, скейлить все в 2 не хочу, а zero downtime upgrade хочу

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

это ты про то если yaml обновился, это так
а я про drain нод, либо их недоступность по какой то причине

если прибить поду, то пода прибъется))

Нужно сорсы смотреть поведения пдп - насколько я понимаю он всетаки "запрещает" а не "вносит логику переноса"

недоступность решается толерейшнами, пдб* не причем

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

И вообщем то - тебе сказали верно - нужно заставить контроллер зашедулить еще одну копию

deployment это сделает создав новый replicaset