Как один микрофикс в Kubernetes сэкономил 600 часов работы в год

Вот важная новость с фронта ИИ: kubelet 9 минут назад Как один микрофикс в Kubernetes сэкономил 600 часов работы в год Средний 5 мин 237 Блог компании Флант DevOps * Kubernetes * IT-инфраструктура * Системное администрирование * Кейс Перевод Автор оригинала: Брэкстон Шейфер (Braxton Schafer) Это перевод статьи системного инженера Cloudflare Брэкстона Шейфера: автор рассказывает о том, как его команда сумела выявить причину медленной работы Atlantis и устранить её маленьким изменением в конфиге Kubernetes. Каждый перезапуск Atlantis — нашего инструмента для работы с Terraform — оборачивался 30-минутным простоем. То есть никаких тебе plan, apply или изменений в инфраструктуре для любого репозитория, которым управлял Atlantis.

Мы перезапускали его по 100 раз в месяц — то для смены учётных данных, то для новых проектов. В итоге — минус 50 часов работы инженеров каждый месяц, да ещё и каждый раз дёргали дежурного инженера. Как оказалось, всё дело было в слишком «осторожной» настройке Kubernetes, заданной по умолчанию.

Технические детали

Она и стала проблемой, когда том Atlantis разросся до миллионов файлов. Рассказываем, как нашли корень зла и исправили всё одной строчкой. Таинственно медленные рестартыМы управляем десятками Terraform-проектов через Merge Request'ы в GitLab, а Atlantis помогает нам планировать и применять изменения.

Он также следит, чтобы два MR'а одновременно не могли менять один и тот же проект. Он запущен как StatefulSet с единственной репликой, а для хранения состояний на диске использует PersistentVolume (PV) Kubernetes. Когда нужно добавить (или убрать) Terraform-проект или обновить доступы, приходится перезапускать Atlantis, чтобы тот подхватил изменения.

Вот этот перезапуск как раз и занимает полчаса. Проблема стала очевидна, когда у нас закончились inodes на томе Atlantis, и нам пришлось его перезапустить, чтобы увеличить размер тома. Каждый файл и директория съедают один inode, а их общее число задаётся при создании диска.

Отраслевые последствия

Наша Kubernetes-платформа использует Ceph, который не позволяет прокинуть флаги в mkfs, так что нам приходится мириться с дефолтными значениями. Единственный выход — увеличивать размер всего диска, а для этого нужен перезапуск пода. Сначала была идея просто сделать алерты менее чувствительными, но это лишь замаскировало бы проблему и задержало бы нашу реакцию на реальные инциденты.

Вместо этого мы решили разобраться, почему так происходит. Плохое поведениеКогда нам нужно было обновить секреты, мы запускали скользящее обновление командой kubectl rollout restart statefulset atlantis. Старый под корректно завершался, а новый тут же поднимался.

Но его статус выглядел так:$ kubectl get pod atlantis-0 atlantis-0 0/1 Init:0/1 0 30mЧто за дела? Естественно, первая идея — проверить события для этого пода. Он ожидает запуска init-контейнера, так что, может быть, события пода прояснят ситуацию?

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.