Как и почему Reddit «упал» и «лежал» 314 минут?
14 марта, в День числа пи, сайт Reddit перестал работать. Даунтайм продлился больше 5 часов, а точнее 314 минут. Михаил Петров, руководитель проекта «Платформа» в VK, прочитал статью о происшествии и подготовил для нас краткую выжимку с причинами и подробностями.
🔹 О том, что что-то не так, команда узнала через 2 минуты по RPS на сайте. Попробовали обновить кубер с 1.23 до 1.24 и потеряли все метрики внутри кубера. График был выше с внешних LB, DNS не работал (не резолвил записи в Consul, но резолвил внешние хосты).
План A был все откатить, но у кубера нет процедуры даунгрейда. Да, была процедура снятия бэкапа перед апгрейдом кубера и его рестора, но она была написана несколько лет назад и никогда не тестировалась на продакшен-кластерах. Восстановление из бэкапа заняло бы часы, поэтому решили расследовать инцидент дальше. Прошел час…
🔹 Попробовали рестартовать компоненты. В процессе расследования заметили следующее:
🔸 поды поднимались и опускались очень долго,
🔸 образы грузились очень долго,
🔸 логи контролплейна писали много всего, но не было очевидной ошибки.
🔹 Затем выяснили, что Calico работает так себе.
1. Calico-kube-controllers замерло в ContainerCreating-статусе.
2. У CRI-O есть баг, который появляется при обновлении CRI-O (а его тоже апгрейдили до поддерживаемой версии). Поды, которые были на предыдущей версии, плохо стартуют. Быстрофикс — удалить под. Но это не помогло.
3. Попробовали рестартануть Calico-typha и CP, но не помогло.
🔹 Заметили в логах CP тайм-ауты на операции записи. А точнее, операции вызова адмишен-контроллера. Был только один OPA. Удалили его — тайм-ауты исчезли, но ситуацию это не исправило. Прошел еще час…
🔹 Решили восстанавливаться из бэкапа, хотя никто из присутствующих этого никогда не делал. Процедура была следующая:
🔸 погасить все CP-инстансы, кроме одного,
🔸 выполнить даунгрейд компонентов на оставшейся,
🔸 восстановить данные из бэкапа,
🔸 запустить остальные CP-ноды и засинкать их.
Сразу же заметили несколько проблем. Процедура рестора была написана для другой версии кубера и учитывала, что на хосте докер, а не CRI-O. То есть многие команды, описанные в процедуре, были с другим синтаксисом или вообще не подходили.
🔹 Процедура восстановления прошла успешно, воркер-ноды стали заезжать в кластер. Стартанули другие ноды CP, но они не могли зайти в кластер. Выяснилось, что бэкап делался на любой ноде, поэтому восстанавливаться надо было на той же ноде, с которой делался бэкап. Но этого не учли. Поломали голову, но решили проблему. Все заработало, но до сих пор было неясно, что произошло…
🔹 К счастью, проблема не затронула логи. У Reddit Calico работает в меш. То есть каждая нода соединяется с другими. В больших кластерах это вызывает проблемы, а для их решения есть роут-рефлекторы, когда каждая нода соединяется с ними, а не со всеми нодами в кластере. Проблема была в том, что все забыли, что роут-рефлекторы вообще есть, конфигов для них не было, а жили роут-рефлекторы на нодах с CP.
📍Итак, для самых терпеливых и любознательных. Конфиг, который вызвал проблему, в картинке к посту.
🔹 Вот тут зарыта собака https://github.com/kubernetes/…
🔹 Kubeadm applies a “node-role” label to its control plane Nodes. Currently this label key is node-role.kubernetes.io/master and it should be renamed to node-role.kubernetes.io/control-plane. Kubeadm also uses the same “node-role” as key for a taint it applies on control plane Nodes. This taint key should also be renamed to “node-role.kubernetes.io/control-plane”.
🔹 Лейбл ноды мастера в Kubeadm в 1.24 версии изменился с Master на Control-plane.
🔹 Calico не могла найти роут-рефлекторы.
Вот поэтому я и не люблю Kubeadm — за сокрытие реализации от админа кластера.
#за_минуту
14 марта, в День числа пи, сайт Reddit перестал работать. Даунтайм продлился больше 5 часов, а точнее 314 минут. Михаил Петров, руководитель проекта «Платформа» в VK, прочитал статью о происшествии и подготовил для нас краткую выжимку с причинами и подробностями.
🔹 О том, что что-то не так, команда узнала через 2 минуты по RPS на сайте. Попробовали обновить кубер с 1.23 до 1.24 и потеряли все метрики внутри кубера. График был выше с внешних LB, DNS не работал (не резолвил записи в Consul, но резолвил внешние хосты).
План A был все откатить, но у кубера нет процедуры даунгрейда. Да, была процедура снятия бэкапа перед апгрейдом кубера и его рестора, но она была написана несколько лет назад и никогда не тестировалась на продакшен-кластерах. Восстановление из бэкапа заняло бы часы, поэтому решили расследовать инцидент дальше. Прошел час…
🔹 Попробовали рестартовать компоненты. В процессе расследования заметили следующее:
🔸 поды поднимались и опускались очень долго,
🔸 образы грузились очень долго,
🔸 логи контролплейна писали много всего, но не было очевидной ошибки.
🔹 Затем выяснили, что Calico работает так себе.
1. Calico-kube-controllers замерло в ContainerCreating-статусе.
2. У CRI-O есть баг, который появляется при обновлении CRI-O (а его тоже апгрейдили до поддерживаемой версии). Поды, которые были на предыдущей версии, плохо стартуют. Быстрофикс — удалить под. Но это не помогло.
3. Попробовали рестартануть Calico-typha и CP, но не помогло.
🔹 Заметили в логах CP тайм-ауты на операции записи. А точнее, операции вызова адмишен-контроллера. Был только один OPA. Удалили его — тайм-ауты исчезли, но ситуацию это не исправило. Прошел еще час…
🔹 Решили восстанавливаться из бэкапа, хотя никто из присутствующих этого никогда не делал. Процедура была следующая:
🔸 погасить все CP-инстансы, кроме одного,
🔸 выполнить даунгрейд компонентов на оставшейся,
🔸 восстановить данные из бэкапа,
🔸 запустить остальные CP-ноды и засинкать их.
Сразу же заметили несколько проблем. Процедура рестора была написана для другой версии кубера и учитывала, что на хосте докер, а не CRI-O. То есть многие команды, описанные в процедуре, были с другим синтаксисом или вообще не подходили.
🔹 Процедура восстановления прошла успешно, воркер-ноды стали заезжать в кластер. Стартанули другие ноды CP, но они не могли зайти в кластер. Выяснилось, что бэкап делался на любой ноде, поэтому восстанавливаться надо было на той же ноде, с которой делался бэкап. Но этого не учли. Поломали голову, но решили проблему. Все заработало, но до сих пор было неясно, что произошло…
🔹 К счастью, проблема не затронула логи. У Reddit Calico работает в меш. То есть каждая нода соединяется с другими. В больших кластерах это вызывает проблемы, а для их решения есть роут-рефлекторы, когда каждая нода соединяется с ними, а не со всеми нодами в кластере. Проблема была в том, что все забыли, что роут-рефлекторы вообще есть, конфигов для них не было, а жили роут-рефлекторы на нодах с CP.
📍Итак, для самых терпеливых и любознательных. Конфиг, который вызвал проблему, в картинке к посту.
🔹 Вот тут зарыта собака https://github.com/kubernetes/…
🔹 Kubeadm applies a “node-role” label to its control plane Nodes. Currently this label key is node-role.kubernetes.io/master and it should be renamed to node-role.kubernetes.io/control-plane. Kubeadm also uses the same “node-role” as key for a taint it applies on control plane Nodes. This taint key should also be renamed to “node-role.kubernetes.io/control-plane”.
🔹 Лейбл ноды мастера в Kubeadm в 1.24 версии изменился с Master на Control-plane.
🔹 Calico не могла найти роут-рефлекторы.
Вот поэтому я и не люблю Kubeadm — за сокрытие реализации от админа кластера.
#за_минуту