Kubernetes — мощный и сложный инструмент, работа с которым неизбежно порождает… инциденты. У каждого, кто всерьёз имел дело с оркестратором, найдётся в запасе история о бессонной ночи, потраченной на поиски причин загадочного сбоя. Часто виновником выступает DNS (на этот счёт даже существует поговорка: «It’s always DNS»). Впрочем, как выясняется, DNS виновата далеко не всегда. Иногда корень зла прячется в совершенно неожиданных местах: от слишком длинного названия деплоймента до коварного физического сбоя сетевой карты на master-узле.

Reddit — настоящий кладезь таких невероятных и в то же время поучительных историй. Мы взяли одну из веток, в которой инженеры делились своими «боевыми шрамами», и выборочно перевели самые любопытные и уникальные случаи. Чтобы было проще ориентироваться, все инциденты разделили на шесть категорий:

1. Проблемы с сетью и DNS

2. Ошибки в конфигурации и человеческий фактор

3. Масштабирование и управление ресурсами

4. Коварные зависимости и окружение

5. Баги и неожиданное поведение систем

6. Аппаратные сбои

Проблемы с сетью и DNS

bentripin:

«Один из самых запоминающихся случаев в моей практике произошёл в крупной компании по производству чипов. Вопреки моим советам, они решили использовать в качестве узлов кластера огромные, монструозные bare-metal-серверы: по 256 ядер и несколько терабайт оперативной памяти. Цель — добиться максимальной утилизации ресурсов. Для этого пожертвовали всеми настройками по умолчанию, чтобы на каждом узле запускать абсурдное количество подов.

Разумеется, это привело к проблемам. Возможности iptables оказались небезграничны — система просто не справлялась с более чем полумиллионом правил маршрутизации трафика. Пришлось на живом production-кластере в авральном режиме переключать CNI-плагин Calico в режим IPVS. Но этим дело не ограничилось: отказ даже одного такого узла приводил к коллапсу. Необходимость перезапустить сотни подов одновременно нагружала kube-apiserver до такой степени, чтотот «падал». Восстановление кластера занимало вечность. Это был тот ещё бардак, созданный исключительно своими руками».

withdraw-landmass:

«У нас была похожая, но ещё более безумная история, связанная с conntrack и постоянным пересозданием подов. Корень проблемы был в „гениальной“ идее наших разработчиков: они настроили фоновую задачу, которая по расписанию обращалась к API для каждого варианта товара из всех, что продавались в нашем онлайн‑магазине одежды за последние десять лет. Можете представить, сколько там было вариантов!

Думаю, делали по несколько миллионов запросов в день. Это был настоящий кошмар: таблицы conntrack переполнялись, а поды постоянно падали и пересоздавались.

Чтобы понять масштаб бедствия, сняли 30-секундный дамп трафика с 10 узлов (в кластере в среднем было 50–70 узлов). Один только график типов пакетов в Wireshark рендерился около часа, притом это были банальные DNS‑ и HTTP‑запросы.

Вишенка на торте: мы попытались внедрить Istio на этот кластер. Разумеется, он просто отказался работать — для него в сети было слишком много «шума»».

fdfzcq:

«Несколько недель мы ломали голову над странными, плавающими проблемами с DNS. Сервисы то работали, то нет, и никакой логики в этом не прослеживалось. Отладка была затруднена тем, что проблема проявлялась нерегулярно и затрагивала разные части системы, которая состояла из смешанных окружений: часть приложений работала в Kubernetes, часть — на виртуальных машинах.

Оказалось, что в нашей версии kube-dns использовался старый dnsmasq, в котором было жёстко прописано ограничение всего на 20 одновременных TCP-подключений! В моменты пиковой нагрузки этот лимит мгновенно исчерпывался, а новые запросы просто отваливались. Мораль? Иногда самый хитрый баг прячется за простым, но напрочь забытым числом в конфиге древнего софта».

miran248:

«В нашем сравнительно небольшом кластере GKE из 9 узлов наблюдались периодические тайм-ауты в работе kube-dns, проявлявшиеся во время пиковых нагрузок. Эти сбои приводили к каскадным отказам в работе приложений: все экземпляры Redis одновременно переставали отвечать на liveness-пробы, что вызывало их перезапуск и, как следствие, нестабильную работу зависимых сервисов.

Анализ показал, что производительности двух реплик kube-dns не хватало для обработки DNS-запросов от всех узлов кластера. Решили проблему, отмасштабировав kube-dns. В ConfigMap kube-dns-autoscaler’а прописали nodesPerReplica = 1. В результате число реплик DNS выросло с двух до девяти — по одной на каждый узел, — и ситуация стабилизировалась».

Xelopheris:

«Sticky-сессии — та ещё штука, могут подкинуть кучу странных проблем. Сам сталкивался с этим дважды.

В первом случае один из подов превратился в настоящую “чёрную дыру”. У него был криво настроен health check, поэтому Kubernetes думал, что с подом всё в порядке, хотя на деле тот не работал. Из-за sticky-сессий весь трафик от пользователей, которым “посчастливилось” на него попасть, просто уходил в никуда.

Второй случай был ещё интереснее. Упал основной канал связи с кластером, и трафик пошёл через резервный. Проблема была в том, что этот резервный канал работал через NAT. В итоге для кластера все пользователи внезапно стали приходить с одного и того же IP-адреса. И что сделали sticky-сессии? Правильно, они “приклеили” всех к одному-единственному поду!»

Copy1533:

«Не то чтобы прямо невероятная история, но попотеть пришлось. У нас был HA-кластер Redis Sentinel в Kubernetes — три пода, в каждом из которых работали и Sentinel, и Redis. Сентинелы, казалось бы, совершенно случайным образом переходили в tilt mode. Суть в том, что они постоянно выполняют проверки, и если одна из них занимает слишком много времени, то на какое-то время сентинелы просто отказываются работать. Иногда это случалось почти со всеми сентинелами в кластере, что приводило к даунтайму, а иногда — только с некоторыми.

В сети много информации об этой ошибке, но я никак не мог понять, в чём же причина в нашем случае. В приложениях ошибок не было, с вводом-выводом тоже всё было в порядке. Одна и та же конфигурация использовалась в нескольких кластерах, но предугадать, где и когда сентинелы выйдут из строя, было решительно невозможно.

После многих часов перебора разных конфигураций и злобного разглядывания логов я в итоге запустил strace, чтобы понять, что же на самом деле делает приложение. Ничего особенного там не было, просто сентинел выполнял свою работу. Ровно до того момента, когда я заметил, что иногда после открытия сокета к CoreDNS на 53-м порту ничего не происходило до самого тайм-аута.

Запустил tcpdump на узлах, увидел потерю пакетов (запрос ушёл, ответ пришёл, ответ ушёл — и тишина) и подтвердил наличие проблем с помощью iperf.

Одна из проблем (хотя и не первопричина) была в том, что тайм-аут DNS был выше, чем время, которое занимал цикл проверки Sentinel. Окей, установил тайм-аут DNS (через dnsconfig.options) где-то на 200 мс (этого должно было хватать с головой), чтобы был шанс повторно отправить запрос при потере пакета до того, как Sentinel начнёт жаловаться (почему-то вечно дело в DNS…).

До сих пор уверен, что где-то в инфраструктуре проблемы с сетью. У всех системы работают, по их словам, “идеально”, но при этом все согласны, что такой высокий процент потерь — это ненормально. Увы, я не смог сузить причину до конкретных хостов. Ну а пока проблема явно не проявляется… никто не шевелится — сами знаете».

benhemp:

«У нас был кластер, в котором, на первый взгляд, совершенно случайным образом отваливались соединения. Владельцы приложений перезапускали поды, на какое-то время это помогало, но потом всё повторялось снова. Кластер работал под управлением Kubernetes, развёрнутого в VMware.

После долгих поисков обнаружили, что проблема в случайных тайм-аутах DNS-запросов. Копнули в сторону nodelocaldns и CoreDNS, но там всё было в порядке. Начали грешить на сеть, когда заметили, что etcd-узлы периодически не могут подключиться к лидеру кворума. Но ничего не нашли — пакеты буквально растворялись в воздухе.

Спустя уйму времени мы, наконец, смогли сузить проблему до ARP: время от времени виртуальные машины просто не могли “достучаться” до своих соседей. Начали смотреть в сторону ACI, но и там не было зацепок. В конце концов обнаружили настройку в VMware, которая отвечала за то, как ESX-хосты получают ARP-таблицы. Её значение отличалось от других наших VMware ESX-кластеров. Как только её поправили, всё заработало!

Почему так долго искали причину: проблема с ARP проявлялась только при большом потоке трафика на множество разных эндпойнтов. Особенно плохо всё становилось, когда запускались рабочие нагрузки с тяжёлыми ETL-процессами (Extract, Transform, Load)».

Ethos2525:

«Каждый день в одно и то же время группа EKS-узлов переходила в NotReady. Перепроверили всё, что только можно: мониторинг, CoreDNS, все cron-задачи, зависшие поды, логи — ну вот вообще всё.

На самих узлах было видно, что kubelet на короткое время просто теряет связь с API-сервером (был тайм-аут при ожидании заголовков). Потом всё само возвращалось в норму. Мы так и не смогли понять, что происходит. Даже техподдержка облачного провайдера ничем не смогла помочь. Загадка так и осталась неразрёшенной».

Ошибки в конфигурации и человеческий фактор

soundtom:

«Мы случайно добавили 62 ВМ в группу API-серверов кластера вместо пула узлов, ошибившись при редактировании значения в Terraform. В результате число членов etcd подскочило с 3 до 65, что вызвало полную остановку его работы. На этом этапе кворум был уже потерян, поэтому простое удаление новых членов не решало проблему.

В тот день я узнал, что etcd можно “скормить” его собственную директорию с данными в качестве “резервного снапшота”. Он повторно импортирует все данные о состоянии, исключая при этом данные о членстве. То есть можно восстановить кластер etcd, используя существующие данные кластера Kubernetes, заново активировать управляющий слой (control plane) и возобновить работу с минимальными побочками.

Более того, выяснилось, что даже при неработающем управляющем слое кластер продолжает функционировать по инерции. Хотя аварийно завершённые рабочие нагрузки не перезапускаются, а запланированные задачи не выполняются, кластер вполне способен обслуживать production-трафик».

rrohloff:

«У меня был случай, когда Argo CD управлял сам собой, и я по глупости запустил синхронизацию его чарта для обновления, не проверив как следует diff. Это привело к удалению и пересозданию Application CRD.

В итоге Argo CD снёс вообще все приложения, которые этим CRD управлялись, — а это около 280 сервисов в разных кластерах.

Но был и плюс: как только Argo CD пересинхронизировался и применил CRD обратно, все сервисы поднялись буквально за минуты. Так что, как минимум, получился хороший тест на аварийное восстановление ?».

wrapcaesar:

«У меня была похожая история, только сервисов было поменьше. Экспериментировал с приложениями Argo CD прямо на проде — удалил одно, чтобы запустить другое. А он в итоге прибил всё, даже пространство имён.

После этого я всё пересинхронизировал, но пришлось ждать целый час, пока заработают управляемые сертификаты от Google. Час даунтайма :')».

bitbug42:

«Не скажу, что история невероятная, но точно дурацкая.

У нас был простенький однопоточный сервис, не умевший в асинхронность. Он обрабатывал запросы строго по одному, при этом выполняя кучу IO-операций для каждого из них. Постепенно он стал узким местом и начал обходиться слишком дорого. Чтобы сократить расходы, провели рефакторинг: сделали сервис производительным, многопоточным и асинхронным, чтобы он мог обрабатывать несколько запросов параллельно.

После развёртывания новой версии нас ждало разочарование: сервис по-прежнему использовал то же количество подов и ресурсов, что и раньше. Неужели мы несколько месяцев убили впустую?

Перебрали кучу теорий, выпустили несколько фиксов, которые ничего не изменили, и уже было отчаялись. Оказалось, всё дело было в неправильной настройке скейлера KEDA. В нём было установлено соотношение «поды/запросы» на уровне 1.2. Это значение подходило для старой версии, но для новой означало, что насколько производительным ни был бы наш сервер, в среднем один под никогда не сталкивался с несколькими запросами сразу (тут бы и сыграла многопоточность).

Решение было до смешного простым: поменять соотношение. И вот он — долгожданный прирост производительности (и экономия средств)!»

Smashing-baby:

«Историю рассказал знакомый: в их кластере майнили криптовалюту. Причиной стала ошибка в конфигурации публичного балансировщика нагрузки, из-за которой злоумышленники получили доступ к кластеру. Нагрузка на CPU резко возросла, но сервисы продолжали работать, пока инженеры не обнаружили проблему. Не знаю, сколько голов посекли по итогу».

sleepybrett:

«У нас был похожий инцидент. Один из сотрудников развернул для тестирования SOCKS-прокси и оставил его полностью открытым на публичном балансировщике нагрузки AWS. Менее чем через 20 минут его обнаружили и подключили к некоему VPN-сервису. Не прошло и часа, как через него пошёл огромный объём трафика. После этого случая мы отозвали у инженеров, не входящих в платформенную команду, права на управление внешними балансировщиками».

u_manshahid:

«Переводили кластеры EKS на Bottlerocket, используя для этого Karpenter. Когда уже заканчивали миграцию на последнем, самом крупном кластере, внезапно у критичных сервисов на новых узлах подскочили задержки. Со временем это произошло и на других кластерах.

В итоге пришлось всё откатывать назад. Только потом мы разобрались, в чём было дело: из-за кривого шаблона новые узлы обращались к главному CoreDNS, а не к локальному DNS-кэшу. Типичный фейспалм-момент».

benhemp:

«История из прошлого: а вы знали, что CA-сертификат для связи между компонентами кластера, созданный через kubeadm, живёт всего 5 лет? Что ж, мы это выяснили на собственном горьком опыте. К счастью, удалось собрать процесс, который позволял сгенерировать новый CA и заменить его в работающем кластере — без простоя. Но это работает, только если спохватиться до того, как сертификат протухнет. А вот если он уже истёк — придётся всё останавливать и уходить в даунтайм для замены».

sujalkokh:

«Обновлял версию Kubernetes после того, как “закордонил” все узлы. После удаления одного из узлов попытался удалить остальные, предварительно выполнив drain. Но ничего не произошло. Автоскейлер молчал, узлы не удалялись.

Оказалось, что на том самом первом удалённом мною узле, работал под Karpenter’а (это наш автоскейлер). А поскольку все остальные узлы были cordoned, переехать ему было попросту некуда.

Я, конечно, снял с них изоляцию, но было поздно — на оставшихся узлах не было ресурсов CPU и памяти для запуска Karpenter’а. Пришлось вручную добавить в кластер десять новых узлов, чтобы под Karpenter’а наконец-то смог запуститься и вернуть всё в норму».

Масштабирование и управление ресурсами

chrisredfield306:

«Ох, я уже много лет работаю с K8s в самых разных проектах — от крупных до совсем небольших.

Самым крутым был случай, когда один из моих проектов “выстрелил”, и мы получили нагрузку в 30 тысяч запросов в секунду. Кластер выдержал этот удар как ни в чём не бывало. Это было просто крышесносно и доказало, что мы всё спроектировали правильно.

А вот что касается самого невероятного случая… Сейчас, наверное, это прописная истина, но для меня в то время было открытием, что избыточное выделение ресурсов подам (overprovisioning) — плохая затея. Если выставлять запросы и лимиты на одно и то же значение, планировщику проще определить, что поместится на узел, и гарантировать, что вы не “забьёте” хост под завязку. Мы же для большинства наших бэкенд-подов ресурсы выделяли с небольшим запасом. Не с огромным, а так, чисто символическим.

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

Виновником оказалось как раз избыточное выделение ресурсов CPU. На хостах заканчивались вычислительные мощности, и процессор начинал работать в режиме time-slicing: выделяя такт одному поду, затем такт другому, и так по кругу. В итоге все поды просто выстраивались в очередь и ждали своего “хода”, чтобы что-то сделать. Было очень круто в этом разобраться, и больше я не пытаюсь мудрить с запросами и лимитами ?».

Коварные зависимости и окружение

International-Tap122:

«Люблю задавать вопрос про самые невероятные случаи на собеседованиях — отлично помогает понять ход мыслей инженера.

Пару месяцев назад понадобилось смигрировать и упаковать в контейнер для Kubernetes одно немолодое уже приложение на Java 11. В Kubernetes оно наотрез отказывалось работать, хотя на Docker Desktop всё было в порядке. На отладку ушла куча времени: проверили разные теории и настройки, выяснили, что приложение падает в containerd, но работает в Docker, даже пытались обновлять пакеты. Уже готовы были биться головой о стену, не понимая, в чём смысл контейнеризации, если она не гарантирует запуск на другой платформе.

А оказалось, что базовый образ, который разработчики прописали в Dockerfile’ах, — openjdk11 — уже много лет как устарел и заброшен. Я просто поменял его на более свежий и активно поддерживаемый, вроде amazoncorretto, — и вуаля, в Kubernetes всё завелось как по мановению волшебной палочки ?.

Иногда полезно сделать шаг в сторону и посмотреть на проблему с другой стороны — так она решается намного быстрее. Мы же зациклились на самом приложении ?».

lokewish:

«В одной крупной финтех-компании возникла проблема с сервисами для онлайн-трейдинга — они работали некорректно. Все компоненты кластера были в полном порядке, но разработчики утверждали, что есть проблемы со связью между двумя подами.

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

Проблема была не в Kubernetes, хотя все сначала подумали именно на него».

Баги и неожиданное поведение систем

cube8021:

«Мой любимый случай — история про зомби-поды. Мы столкнулись с этим в Rancher Kubernetes Engine. Суть проблемы в том, что процесс runc входил в какое-то странное, рассинхронизированное состояние с Docker’ом. В результате процессы пода продолжали работать на узле, хотя их нигде не было видно.

К примеру, в поде работает Java-приложение. Узел входит в это странное состояние, Kubernetes рано или поздно убивает под, и тот пропадает из вывода kubectl get pods. Команда docker ps тоже ничего не показывает. Но если зайти на узел и выполнить ps aux, то можно увидеть, что Java-процесс работает как ни в чём не бывало, продолжая общаться с базой данных и внешними API.

Как оказалось, причиной был кастомный пакет Docker от Red Hat. Они встроили в него сервис, который блокировал загрузку образов Red Hat в Docker Hub, но побочным эффектом его работы стала поломка среды исполнения для контейнеров».

mikaelld:

«Один забавный инцидент произошёл, когда мы настраивали мониторинг для инстанса Dex. Частота проверок составляла примерно три запроса в десять секунд. Спустя день или два заметили, что в etcd начало стремительно заканчиваться место на дисках. Выяснилось, что на тот момент Dex создавал сессию для каждого нового запроса (насколько я знаю, сейчас это исправлено), а сессии сохранялись в etcd.

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

Tall_Tradition_8918:

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

Из-за этого под даже не догадывался, что получил SIGTERM. А по истечении периода ожидания (grace period) его просто принудительно убивало по SIGKILL. Разобраться в ситуации помогли логи управляющего слоя. Финальным решением стал preStop-хук, который гарантировал, что под готов к корректной обработке сигналов завершения».

HamraCodes:

«У нас было Java-приложение на WildFly, развёрнутое в Kubernetes. Огромная такая штука — основа всего бизнеса компании, оно использовалось для проведения транзакций и выплат.

Проблема была в том, что часть подов запускалась нормально, а другие постоянно падали. Мы потратили уйму времени на поиск причины, пока не нашли в логах одну-единственную запись о том, что имя пода слишком длинное — буквально на один символ больше, чем допустимо. Сравнил его с именами тех подов, которые работали: действительно, всё дело в этом!

В итоге просто переименовали деплоймент, укоротив его название, и всё заработало!»

Dergyitheron:

«Однажды после патча я перезагрузил один из master-узлов. Проблема была в том, что etcd не понял, что узел ушёл в офлайн, и не вывел его из кворума. В итоге, когда узел снова поднялся, он не смог вернуться в кворум, ведь etcd считал, что тот и так работает. Пришлось лезть в etcd и удалять узел оттуда руками. К счастью, это помогло».

External-Hunter-7009:

«Однажды мы столкнулись с багом то ли в EKS, то ли в апстримном Kubernetes: развёртывание новой версии Deployment’а просто зависало. Судя по всему, где-то по пути терялось внутреннее событие, которое должно было двигать процесс дальше. Обычные способы, вроде kubectl rollout restart, не помогали. Пришлось вручную править поле status. Это было давно, так что могу ошибаться в деталях.

Ещё был случай, когда мы упёрлись в лимит на DNS-эндпойнте в VPC. Проблему решили, выкатив node-local-dns. Честно говоря, это должно быть настроено по умолчанию в любом управляемом кластере.

Ну и вишенка на торте — упёрлись в лимиты пропускной способности EC2 ENA. Эту проблему мы до сих пор не решили до конца, а только нашли обходной путь. Лимиты у AWS до смешного низкие, и они не раскрывают свои алгоритмы, так что настроить рабочие нагрузки, не теряя при этом кучу мощностей, невозможно. А из-за отсутствия политик QoS служебный трафик (вроде DNS или SYN-пакетов) становится ненадёжным, как только основной трафик приближается к лимиту. В теории можно настроить QoS на самом узле, но готовых решений нет, а до самописного у нас руки пока не дошли. Да и утилиты Linux тут не очень удобны: приходится зеркалировать интерфейс локально, поскольку средства контроля не умеют работать с ингресс-трафиком».

archmate:

«Время от времени у нашего облачного провайдера падал DNS, из-за чего нарушалась вся внутренняя коммуникация в кластере. Ситуация неприятная, но после письма в техподдержку всё всегда чинили довольно быстро.

Но не в этот раз. Им понадобилось три дня. Когда сервис наконец вернули к жизни, ничего не работало. Все запросы с kubectl отваливались по тайм-ауту, а kube-apiserver ушёл в вечный рестарт.

Оказалось, что в Longhorn (версии 2.1, если не ошибаюсь) был баг: каждый раз, когда пропадала связь, он начинал создавать реплики томов… столько, сколько мог. В итоге насоздавал их 57 тысяч, и kube-apiserver просто не справлялся с таким количеством запросов. Разгрести этот бардак было бы непросто, но в итоге всё спас однострочный скрипт, который я написал».

Аппаратные сбои

clvx:

«Однажды посреди рабочего дня у нас случился очень коварный сбой. На одном из master-узлов начала умирать сетевая карта, но умирать хитро: все UDP-соединения проходили как ни в чём не бывало, а вот TCP-пакеты просто отбрасывались. Можете представить, насколько тяжело было разобраться, что происходит. 

Мне повезло: я уже сталкивался с похожей проблемой в 2013 году на сервере HP Proliant, так что сразу подумал, что причина может быть в железе. Коллеги сначала отнеслись к этой идее скептически. Короче говоря, эта история — отличное напоминание: всегда решайте проблемы послойно, начиная с самого нижнего уровня».

Заключение

Kubernetes — не просто оркестратор, а целая вселенная со своими законами, где баги могут быть неотличимы от фич, а минутная невнимательность способна обрушить production. После прочтения этих историй становится очевидно: самый мощный инструмент отладки — это не tcpdump или strace, а опыт, которым делятся коллеги.

А с какими «монстрами» в своих кластерах приходилось сражаться вам? Делитесь в комментариях!