Факапы, история 3
Очередная история про гугл и k8s. Как вы помните, у гугла существуют maintaince window, во времена которых он без предупреждения может ради обновления версии куба просто положить весь ваш кластер. Да, чтобы вы понимали, не реже раза в месяц ваши ноды будут падать. Может быть все сразу, а может по очереди. Может сегодня одна, а завтра другая. Может она поднимется за 2 минуты, а может за 25. Вы можете заплатить чуть больше денег и разнести ноды по разным регионам, но в любом случае что-то когда-то будет падать. Поэтому делать решение без репликации никак не получится, всегда должна быть реплика, которая обслужит клиента.
Эта история будет про etcd кластер. В кубе etcd можно запускать при помощи etcd-operator. И довольно-таки ошибочно думать про такой кластер, как про кубовское решение с этими всеми его шедулерами. Т.е. чтобы вы понимали, когда устанавливается оператор - он делается по всем канонам куба. Вы выкатываете helm, создается deployment, куб будет следить сам за тем чтобы оператор работал. На этом всё. Вы спросите, а откуда же тогда берется кластер? Так вот, после выкатки оператора мы должны принести в кластер один или несколько объектов под названием EtcdCluster. В котором описывается название, размер и версия etcd кластера. Оператор перехватывает событие создания такого объекта, считывает параметры и создает поды нашего кластера в указанном количестве. Что здесь кажется странным? С точки зрения k8s поды без deployment\replicaset это просто некоторый висящий в воздухе контейнер, который можно убить и никто не заплачет. Вот и получается, что всю заботу о том чтобы контейнеры кластера работали берет на себя etcd-operator.
Теперь скрестим ситуацию из первого абзаца со вторым. Если гугл кладет все ноды, то у нас падают все поды кластера. И тут самый интересный момент. Их никто не переподнимет после того как ноды рестартанут. Почему? потому что в etcd-operator заложена такая логика. Нет персистенса - нет переподнятия. В итоге, для того чтобы избежать этой попоболи в CRD нужно добавлять примерно такие строки:
kind: "EtcdCluster"
spec:
pod:
persistentVolumeClaimSpec:
storageClassName: XXXXXX
accessModes:
- ReadWriteOnce
resources:
requests:
storage: YYYYYYY
Тогда для каждого пода в кластере будут созданы свои тома, и после падения все будет переподниматься. С точки зрения кластера звучит довольно логично. Ибо если упало все, кворум хрен соберешь, данные эфемерны, кто теперь реально владеет актуальной информацией - непонятно. Так что если упал один под - переподнять его логично. Если весь кластер - то только с персистенсом.
#fuckup
