Вообщем то drain пройдет если ты своему деплойменту после дрейна скажешь rollout restart

и он уедет с cordon ноды

(зашедулится на другую)

С учетом твоей стретегии обновления описанной в ямлике контроллера (деплоймента например)

вот такой бомж-сетап:
managed кубер DO
есть cluster autoscaler 1-2 ноды
есть деплойменты в 1 реплике
хочу избежать даунтайма при обновлении версии кубера (они сами триггерят его) или замене тачек (создаю второй пул, и когда создался удаляю первый) - щас все это с даунтаймом

делайте 2 реплики и не бебети мозги

в любом случае сервис с 1 репликой не может быть без даунтайма по определению

Как в хельме проверить ключ на существование?

может. rollingUpdate
вот нужно что то типа того, но на кейс обновления кубера, что если тачка недоступна (апдейт кубера), чтобы зашедулилась вторая реплика в pending, CA заказал новую тачку (потому что текущая Unshedule), туда все переехало, потом начала обновляться вторая тачка, поды переехали на первую (она уже обновилась), ну и потом продается одна тачка
вот такое можно относительно просто сделать? не считая платить х2 бабок заскейлив все в 2

не может

потому что когда нода упадет (или пода) сервис упадет

kubectl taint node poshlivsenah
kubectl rollout restart randomresources

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

Ну и вообще вот ищью https://github.com/kubernetes/kubernetes/issues/66811

Иди в общий чат с вопросом: "Какой м..."?😂

Тогда он подпишится что аудит лога нет, лучше с "Ну сам признаешься или начальству слить?"

Самый надежный способ)

мне на самом деле не стыдно признаться что аудиа нет) его же никто не заказывал и за мою карьеру я впервые сталкиваюсь с тем что нужно понять кто что-то сделал)
так что Какой м.. звучит вполне логично)

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

Всем привет. У кого нибудь есть опыт с kubeedge? где это можно применить.