Оооочень интересный дебаг
Коллеги, всем привет! =)
После небольшое затишься, очередной, надеюсь интересный пост про то как мы дебажили историю “а почему поды не разворачиваются”
Вводная: k8s 1.31, cilium, Istio, 30-03-2025 авария в я.облаке
Все началось с классического запроса от разработчика “сервисы не деплоятся, обновления не катятся”. Хммм, подумал я и пошел дебажить.
helm upgrade - отваливается по таймауту. Последствия воскресного инцидент я.облака и возможно какая то часть инфры находится в залипшем состоянии, а мы и не вкурсе. Проверил раннеры, обновил версию helm`а (чисто на всякий случай, текущая была не сильно новой) - проблема сохраняется. Хмм подумал я второй раз и решил попробовать развернуть сервис “начисто”. У сервиса в чарте сабчартом подключен redis.
Ииии redis разворачивается, а подов сервиса нет 0_о
В events совершенно ничего интересно. Посмотрел всякое, посмотрел телеметрию - ничего сильно страшного не видно. Иииии потом я вспоминаю, что deployment сервиса, на самом деле “внтури” replicaset (вы же знаете, что весь k8s - это абстракция на абстракции). Посмотрел, что там с replicaset и увидел следующее:

Warning FailedCreate 26s replicaset-controller Error creating: Internal error occurred: failed calling webhook "object.sidecar-injector.istio.io": failed to call webhook: Post "https://istiod.istio-system.svc:443/inject?timeout=10s": dial tcp ${istio-pod-ip}:15017: connect: connection timed out

Опппа, контроллер не может отправить вебхук в истио, что бы он добавил сайдкар в наш под. Становится интересно.
Из неймспейса проверяю связность при помощи nc, curl - все хорошо. Replicaset все еще не может отправить вебхук в истио.
Перезапускаю istio контроллер (просто делаю роллаут) и на всякий случай “пинаю” mutatingwebhook istio. Результата нет. На всякий случай “собираю” отдельный деплоймент и тестирую его в отдельном неймспейсе, что бы исключить сетевые политики, после тестирую размещение на разных нодах - результат тот же.
Ооооокай, что там у нас с cilium?
Проверяю ns kube-system и вижу что там, после “воскресных приключений”, ооочень много подов istio-operator висят в статусе containerstatusunknown. Подчищаю контейнеры и делаю роллаут подов cilium. Результат все тот же. Все кому нужно “хукануть” истио, что бы произошел инжект сайдкара не могут этого сделать.
Штош, тут мои полномочия все, оформляю критикал тикет в саппорт.
Саппорт отвечает быстро, и предлагает выполнить команду

k get ciliumnodes.cilium.io

На выходе мы получаем список нод нашего кластера, которые “входят в сеть cillium”
И видим мы там ооочень интересные вещи, а именно:

NAME CILIUMINTERNALIP 
master-a 1.1.1.1
master-c 1.1.1.2
master-d 1.1.1.2
k8s-master-a 1.1.1.1
k8s-master-b 1.1.1.3
k8s-master-c 1.1.1.2
k8s-master-d 1.1.1.2
#адреса конечно же не такие, следите за последним октетом

И первый же мой вопрос: “Чегооооо? Откуда у меня мастера в зоне С которую мы разорабрали 2 квартала назад? И почему мастеров так много если их должно быть 3?”
Естественно я уточнил, а какой мастер актуален для кластера на данный момент. Саппорт уточнил актуального мастера и рекомендовал, удалить старые. Старые мастера удалены, вебхуки работают, приложения деплоятся/обновляются, все счастливы.
Произойти такое могло, скорее всего из-за той мега аварии в я.облаке 30-03-2025 (но это не точно, так как старые мастера у меня были достаточно давно)
Мораль сего приключения такова - не забывайте, что в k8s много абстракций =)
Фан факт - коллеги с соседних бизнес доменом с таким сталкивались ранее и ответили мне быстрее чем саппорт =)
ЗЫ1 - как это можно обнаружить заранее - логи управляющих компонентов, там по идеи все должно быть видно =)
ЗЫ2 - весь пост написан от моего лица, но на самом деле нас было двое, Серег, спасибо большое ^_^
ЗЫ3 - коллеги, из соседнего домена, Дим, Макс, Лех, спасибо за помощь в дебаге ^_^