Инцидент и реакция на API Kapsule FR-PAR

24 января в 23:48 по центральноевропейскому времени (CET) компания Scaleway столкнулась с инцидентом в регионе FR-PAR, который затронул клиентов, использующих управляемые сервисы Kubernetes Kapsule, Kosmos, как с взаимными, так и с выделенными средами, а также некоторые продукты, такие как Cockpit.

Проблема была решена к 01:03 той же ночи. Вот обзор того, что произошло.

Хронология инцидента
23:48: В Scaleway Kubernetes API возникла ситуация нехватки памяти (OOM). Инцидент начался, затронув API-интерфейс региона Kubernetes FR-PAR, что привело к тому, что узлы не смогли пройти аутентификацию в своей плоскости управления, в результате чего некоторые узлы стали NotReady.
23:48: На API-шлюзе обнаружена повышенная нагрузка, при этом количество запросов значительно возросло.
00:00:10: Инцидент передан на внутреннюю эскалацию и обработан дежурными инженерами Scaleway.
00:00–00:30: Продолжается диагностика: ситуация с OOM определена как основная причина сбоя.
00:35 — 00:40: Приняты меры по увеличению оперативной памяти API Kubernetes и запуску дополнительных реплик.
00:43: Исправление сработало, количество запросов к API-шлюзу быстро сокращается.
00:54: Узлы Kubernetes восстанавливали работу, большая очередь действий на отслеживаемых экземплярах
01:03: Все кластеры FR-PAR начали стабилизироваться после реализации дальнейших мер, таких как очистка кеша реестра и мониторинг любых дальнейших проблем.
01:13: Показатели в Cockpit начали появляться снова, указывая на полное восстановление.
После инцидента: для обеспечения стабильности были внесены непрерывный мониторинг и корректировки, включая корректировки конфигураций сервисов.

Влияние

• Увеличение времени ответа шлюза API, приводящее к некоторой недоступности (достижение тайм-аутов)
• Узлы Kubernetes не могут пройти аутентификацию и поэтому временно переходят в состояние «Неготов», что приводит к сбою в обслуживании.
• При необходимости активация процесса автоматического восстановления кластера, генерирующая автоматическую замену узла.

Основная причина и решение проблемы
На стороне Кубернетеса
Инцидент возник из-за сценария нехватки памяти (OOM) в API Scaleway Kubernetes, вызванного одновременным развертыванием в FR-PAR. Ситуация еще более усложнялась, поскольку этот API в настоящее время обрабатывал аутентификацию, не позволяя Kubelet обновлять свои аренды, что приводило к тому, что узлы переходили в состояние NotReady и повторяли попытки на неопределенный срок.
Решение:
Для исправления были предприняты следующие корректирующие действия:

• Технические изменения: немедленное увеличение лимита памяти и порогов сбора мусора для управляемых сервисов Kubernetes.
• Масштабирование: развертывание дополнительных реплик для ключевых служб для обработки возросшей нагрузки.

Долгосрочные решения:
Мы планируем реализовать следующие меры безопасности:

• Реализация локального кэша аутентификации
• Дальнейшие разработки по аутентификации узлов.

На стороне API-шлюза
На API-шлюз значительно возросла нагрузка, в первую очередь из-за подавляющего количества запросов, исходящих от неисправных компонентов на стороне Kubernetes.

Несмотря на возросшую нагрузку, API Gateway удалось работать без полного отключения. Изменения, уже внесенные в связи с прошлым инцидентом, позволили нам лучше справляться с внезапными скачками количества запросов.

Заключение
Этот инцидент подчеркивает важность надежного мониторинга и механизмов быстрого реагирования при управлении непредвиденным поведением системы. Мы стремимся извлечь уроки из этого инцидента и уже внедрили несколько улучшений, чтобы предотвратить подобные случаи в будущем.

Эти меры включают расширение наших возможностей мониторинга, корректировку наших стратегий ограничения скорости и улучшение наших протоколов реагирования на инциденты. Приносим извинения за причиненные неудобства и благодарим вас за понимание и поддержку, поскольку мы продолжаем совершенствовать наши системы, чтобы лучше обслуживать вас.