Ломаем и чиним etcd-кластер

[rotabor]

«etcd — это быстрая, надёжная и устойчивая к сбоям key-value база данных. Она лежит в основе Kubernetes и является неотъемлемой частью его control-plane. Именно поэтому критически важно уметь бэкапить и восстанавливать работоспособность как отдельных нод, так и всего etcd-кластера.» просто поражает своей логикой. База настолько надёжна и устойчива к сбоям, что критически важно уметь её восстанавливать вручную!

[kvaps]

Имелось ввиду скорее второе утверждение чем первое, что etcd лежит в основе Kubernetes.
Исправил пунктуацию, спасибо :)

[darthslider]

Что-то в итоге ничего и не сломали.
Думал будет про failed proposals, частые re-elect, потерю кворума (и влияние на кубер в таком случае).
Кстати, а что произойдет с кластером, если мы восстановим бекап etcd?
Он резко постарается привести себя в то состояние, в котором был и начнет шедулить 100500 недостающих подов?

[kvaps]

Дельное замечание, про потерю кворума дополнил.

Кстати, а что произойдет с кластером, если мы восстановим бекап etcd?

Ничего не произойдёт. Kube-apiserver спроектирован так, чтобы по возможности не хранить никакого состояния, поэтому он просто подхватит изменения в etcd. Это работает даже без перезапуска apiserver.

Он резко постарается привести себя в то состояние, в котором был и начнет шедулить 100500 недостающих подов?

Это зависит не от apiserver, а скорее от controller-manager и scheduler. После того как вы востановите бэкап, все ваши ноды будут находиться в том же состоянии на момент которого был сделан бэкап. То есть если они были в Ready, то такими они и останутся до поры до времени. И только спустя 30 секунд (таймаут по умолчанию), если кубелеты не сообщили о своём состоянии аписерверу, controller-manager начнёт переводить их в NotReady и триггерить создание новых подов.
Старые поды при этом останутся работать без изменений, то есть кубелеты самостоятельно не предпринимают никаких действий по удалению подов в случае невозможности связаться с apiserver.

про failed proposals, частые re-elect

Про это мне сказать пока что нечего, если кому есть чем дополнить статью, милости прошу в комментарии :)

[gecube]

kube-api-server не совсем стейтлесс. Я уже неоднократно слышал инфу, что в нем есть кэш. И это подтверждается исходными кодами https://github.com/kubernetes/kubernetes/pull/7559

[Worldpunk]

Круто пишет автор.
Немного вскипел мозг при прочтении, пришлось вернутся к прошлой статье. Непонимаю зачем так мудрено делать. Народ кто не шарит просто не поймёт, мне надо было мозг жёстко перевернуть, я не говорю что это не рабочий способ, и не говорю что долго. За статью спасибо, она врятле поможет, хотя было бы время как говорится.
Помню лет 5 назад поднимал, где то уткнулся. Спасибо понял ошибку.