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

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

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

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

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

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

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

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

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