За что вы так хейтите рук? У нас уже год

почти работает стабильно тьфу тьфу

У многих кубер год работает, а потом тыква

Постоянно боюсь что etcd развалится

От чего ?

Я бы больше за бекапирование манифестов переживал чем за etcd

Их не нужно бекапить

почему не бэкапить просто etcd?

Чтоб потом кластер офигел ?

что бы потом ты не офигел когда etcd в один момент has gone away

- Я постоянно боюсь что etcd развалится, подскажите как с этим жить? - Сходите в церковь, свечку поставьте.

Я не испугаюсь

Точно! А ещё лучше - прими ислам

О, вы бэкапите манифесты? Расскажите как

Шта

Мирор в битбакет? )))

Не выйдет, Аллах-то давно в кубере ;)

А чо - норм

Ладно, это вы ещё не видели как кубу сносит бошку когда у etcd случается сплит-брейн ;)

У етсд не бывает сплит брейн

Гитом

бывает, если вдруг забыл --initial-cluster-state=new на existing переключить, человеческий фактор :)

Эм, это типикал мисконфигурейшен

Хорошо что есть бэкап!

в целом да, но если интересно, то расскажу. По всем канонам 12factor app, kube-apiserver totally stateless application, по этому когда это происходит не нужно даже дожидаться перезапуска kube-apiserver. Симптомы начнут себя проявлять мгновенно. Разберём две ситуации: Ситуация первая, когда у нас явный сплитбрейн. Когда все эндпоинты etcd работают в обычном режиме, но по какой-то причиен ничего не знают друг о друге. kube-apiserver настроен на общение со всеми из них. Первым делом вы обнаружите что каждый n'ый запрос возвращает no resources found, потому что kube-apiserver попадает в пустой etcd инстанс. Как показала практика куб продолжает работать в таком режиме и может существовать до того момента пока слегка прифигевший от происходящего админ не выпилит неисправную ноду из кластера. Ситуация вторая, когда у вас по каким-то причинам kube-apiserver начали ломиться в пустой etcd-кластер (бывало и такое), на самом деле это крайне неприятный факап, потому что все кубелеты обнаружат что их нодах не только ничего не запущенно, но и вообще ноды такой не существует и начнут один за другим прибивать ваш workload. При восстановлении бэкапа etcd, они конечно поднимут его снова, но даунтайм конечно будет нехилый.

В пустой они не начнут ломиться, потому что сертификаты пира етсдклиента не подойдут

Это если у тебя kubeadm)

А если нет? Если не можешь руками поднять - не поднимай

у меня cert-manager выписывает сертификаты к etcd, так что в 99% случаев они всегда валидные

Т.е. ты это куб в кубе ловил?

Да, с тех пор юзаю --initial-cluster=existing для всего и вся

Неее. С чего бы кублету убивать, если он получил ответ, что ноды такой нет в кластере ??? Вот если бы нода былааа, но в том етсд было написано, что на узле нету подов... тогда да, привел бы состояние к полученному. Ну и флапал бы туда сюда. Тут страшнее csi драйверы. Эти могут pv по удалять

соглашусь

там мог быть автоджойн нод...

На счёт кубелетов соглашусь это было бы логичным поведением, однако как показала практика последнего случая именно это и произошло. Не имею ни малейшего представления почему. Возможно кубелеты перезапустили свой реконсайлинг луп не удостоверившись что нода существует. Либо они получили утвердительный ответ с одного etcd и пустой список подов с другого или разные моменты времени.

На счёт CSI как раз бояться нечего, если нет ресурсов, то соответственно и в реконсайлинг луп csi-контроллера ничего не попадёт, удалять отсутствующие волумы он не будут. Проверял много раз.

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