Не мог не вставить эту глупую картинку peka face, потому что дебажить пятисотки в кубере в облаках на самом деле не так просто, как многим кажется, а заголовок статьи конечно же же наполнен жиром сарказма и иронии.

Итак - начнём.

Четыре недели с 502: как мы гасили ошибки в бот-сервисе одну за другой

Расскажу историю о том, как суммарно около четырёх недель мы последовательно находили и устраняли причины 502-ошибок в одном из наших сервисов.

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

Одна из тех историй, когда, починив что-то одно, видишь следующее - и так несколько итераций подряд.

Кто такой бот-сервис

У нас есть сервис, который занимается обработкой входящих вебхуков от внешнего корпоративного чат-инструмента - назовём его просто бот-сервис.

Он крутится в Kubernetes, за ним AWS ALB, трафик идёт от ботового фреймворка вендора.

Написан на Node.js + Express. Ничего экзотического.

Схема выглядит так:

  Vendor Bot Framework
          |
          | HTTPS, keep-alive
          v
  +------------------+
  |       DNS        |   Route53 / Cloudflare
  +--------+---------+
           |
           v
  +------------------+   +----------------------------------+
  |     AWS ALB      |<--| AWS Load Balancer Controller     |
  +--------+---------+   | - следит за K8s Endpoints        |
           |             | - регистрирует/дерегистрирует    |
           |             |   поды в target group ALB        |
    +------+------+      +----------------------------------+
    v             v
+----------+ +----------+
|  Pod 1   | |  Pod 2   |   (Pod N ...)
|  Node.js | |  Node.js |
|  :3000   | |  :3000   |
+----------+ +----------+

Именно в этой цепочке и живут все проблемы, о которых пойдёт речь.

Как сервис стал боевым

Долгое время бот-сервис жил в относительно тихом режиме: небольшая нагрузка, в основном внутреннее использование. Мониторинг был минимальный - сервис работает, и ладно.

Потом сервис начал получать реальный трафик от живых пользователей. Стали потихоньку поглядывать на метрики - рестартов нет, CPU и память в пределах нормы, всё выглядело спокойно.

И вот однажды прилетел вопрос: "а почему у нас 502 ошибки?"

Первые 502: клиент жалуется, мы в темноте

На тот момент не было почти никакой зацепки. Метрики приложения есть, Prometheus есть, Grafana есть. Но конкретно по ALB - тишина. ALB стоял давно, логирование для него никто не включал: всё работало, зачем.

Понятно было только одно: где-то есть 502. Откуда, от кого, когда именно, что в это время делал бэкенд - непонятно совсем.

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

Первая гипотеза: keepAlive таймауты

Погуглили "node.js alb 502" - нашли сразу две статьи, которые объясняли одну и ту же механику. Ссылки будут в конце статьи.

Суть такая: у Node.js http.Server дефолтный keepAliveTimeout равен 5 секундам.

У AWS ALB дефолтный idle timeout - 60 секунд.

То есть ALB держит соединение открытым 60 секунд, а Node.js закрывает его уже через 5.

Когда ALB пытается отправить новый запрос по уже закрытому соединению - получаем 502 и ECONNRESET на стороне приложения.

Исправляется просто: выставить keepAliveTimeout на сервере чуть больше, чем таймаут ALB, чтобы Node.js никогда не закрывал соединение раньше балансера.

server.keepAliveTimeout = 65000;
server.headersTimeout = 66000;

(headersTimeout должен быть чуть больше keepAliveTimeout - иначе Node.js может отбросить запрос, который пришёл в самый последний момент перед закрытием соединения)

Добавили это в server.ts, задеплоили. Стало заметно лучше - часть 502 пропала. Казалось, нашли причину и дальше заживём.

Но нет.

Ошибок стало меньше, но они не исчезли. Значит, была ещё какая-то другая причина - или несколько. И без нормальных данных двигаться дальше было некуда.

Шаг 0. Включаем логи ALB

Зашли в настройки load balancer в AWS Console - Attributes - Access logs - Enable.

Указали S3-бакет, включили все доступные на тот момент поля.

Настроили сбор из S3 в OpenSearch через существующий pipeline.

После этого у нас появился полноценный лог каждого запроса через балансер, включая:

• elb_status_code - что ответил сам ALB клиенту
• target_status_code - что ответил под балансеру (или "-", если не ответил вообще)
• target_processing_time - сколько под думал
• request - метод, URL, протокол
• user_agent - кто стучится

С этого момента стало можно нормально разбираться.

Причина #1 - Rolling deploy без preStop hook

Полез в OpenSearch - там теперь лежат ALB access-логи.

Запрос простой: ищем elb_status_code: 502 по нашему домену за последнюю неделю.

Картина такая: несколько одиночных 502 в разное время суток, и один раз сразу 10 штук подряд. Примеры из лога:

• 1 запрос, target_processing_time 0.084s, ответа от пода нет
• 1 запрос, 0.476s, ответа нет
• 1 запрос, 2.069s, ответа нет
• 1 запрос, 1.284s, ответа нет
• 10 запросов подряд, ответа нет ни от одного

target_status_code: null и target_processing_time меньше нескольких секунд - ALB до пода достучался, а вот HTTP-ответа так и не получил.

Это не таймаут приложения, это обрыв соединения на уровне TCP.

Первый же вопрос: что происходило в это время с подами?

Иду в Prometheus, смотрю kube_pod_container_status_restarts_total - рестартов нет.

Смотрю kube_pod_info - количество подов менялось.

А значит что? Правильно - роллинг-деплой.

Алгоритм роллинг-деплоя в Kubernetes примерно такой:

1. Kubernetes посылает SIGTERM умирающему поду
2. Одновременно убирает его из Endpoints
3. ALB обновляет свой список целей - но не мгновенно, это занимает несколько секунд

В этот зазор ALB ещё продолжает гнать трафик на уже умирающий под.

Под получает SIGTERM, начинает завершаться - и новый запрос от ALB уже некому обработать. Отсюда 502.

Решение классическое - preStop хук: заставляем контейнер немного подождать перед завершением, чтобы ALB успел дерегистрировать цель.

lifecycle:
  preStop:
    exec:
      command: ["sleep", "15"]

Небольшое отступление для тех, кто на свежих версиях Kubernetes.

Начиная с версии 1.29 появилась фича PodLifecycleSleepAction - нативный sleep прямо в preStop без костыля через exec и системную команду. В 1.30 она включена по умолчанию, в 1.34 вышла в GA(beta?).

Если у вас k8s >= 1.30, можно писать так:

lifecycle:
  preStop:
    sleep:
      seconds: 15

Чище, без зависимости от наличия sleep в образе, сразу понятно что происходит.

У нас на тот момент была более старая версия кластера, поэтому пошли через exec.

Добавили в деплоймент, задеплоили. Это был PR #1.

Вместе с ним отключили автоскейлинг воркер-компонента - он создавал лишний шум деплоев без реальной надобности (PR #2).

После этого единичные 502 при деплоях пропали. Казалось, всё.

Причина #2 - OOMKill

Вскоре прилетело сразу 10 штук 502 за один раз.

Снова OpenSearch - время совпадает, снова target_status_code: null.

Иду смотреть что было с подами в это время.

В Prometheus смотрю

kube_pod_container_status_last_terminated_reason{reason="OOMKilled"}.

Один из подов получил OOMKill - память стрельнула до ~800 MiB при лимите 800 Mi.

Под умер, ALB не успел дерегистрировать - 10 одновременных запросов получили 502.

Смотрю лимиты в деплойменте - да, 800 Mi, и это явно было на грани.

Откуда такой спайк - скорее всего, транзиентный пик нагрузки, в Node.js такое бывает при обработке нескольких тяжёлых запросов одновременно.

Подняли лимит памяти до 1536 Mi (PR #3). После этого OOMKill больше не повторялся.

Причина #3 - CPU throttling -> liveness probe перезапускает контейнеры

Спустя несколько дней - новый инцидент, уже серьёзнее. Пять 502, target_processing_time от 13 до 24 секунд. Три пода.

Это уже не про деплой и не про память.

Лезу в Prometheus, смотрю container_cpu_cfs_throttled_seconds_total.

Картина неприятная:

• 35.7% throttling
• 34.4%
• 35.5%

Треть всего CPU-времени поды просто не получают из-за лимита.

Node.js - однопоточный event loop. Когда CFS-шедулер Linux троттлит процесс, event loop стоит.

Стоит event loop - не отвечают HTTP-эндпоинты.

Не отвечают эндпоинты - liveness probe падает.

Смотрю конфигурацию проб через kubectl:

livenessProbe:
  periodSeconds: 10
  failureThreshold: 6
  timeoutSeconds: 10

То есть нужно 6 подряд неудачных проб с периодом 10 секунд - 60 секунд при жёстком троттлинге.

CPU-лимит в 200m - это 0.2 ядра. При нагрузке это катастрофически мало для Node.js с event loop.

Поднимаем CPU limit с 200m до 500m (PR #4).

После деплоя картина в Prometheus:

• 4.3% throttling
• 8.6%
• 9.6%

С 35% упало до 4-10%. Лайвнес-килы прекратились.

Причина #4 - Graceful shutdown: Node.js и SIGTERM

Казалось бы, всё починили. Но нет.

После деплоя PR #4 начали появляться два новых паттерна в OpenSearch:

502-ошибки:

• target_processing_time: 0.078s, target_status_code: null
• target_processing_time: 3.924s, target_status_code: null

460-ошибки (client closed connection):

• день 1 - 32
• день 2 - 12
• день 3 - 2
• день 4 - 1
• день 5 - 2

Всё это - только от user-agent вендора, только во время деплоев.

preStop: sleep 15 у нас есть, это проверено через kubectl describe rs.

Тогда почему?

Пауза на подумать.

preStop hook даёт поду 15 секунд до того, как Kubernetes пошлёт SIGTERM.

Но что происходит после SIGTERM?

По умолчанию Node.js http.Server на SIGTERM не делает ничего специального.

Процесс завершается, все open TCP-соединения - сброшены. Мгновенно.

А бот-фреймворк вендора держит keep-alive соединения с сервером.

Одно соединение - много запросов. Когда соединение рвётся прямо во время обработки запроса - ALB получает 502. Когда клиент пробует переиспользовать соединение, которого уже нет - 460.

Значит нам нужен явный обработчик SIGTERM, который:

1. Перестаёт принимать новые соединения (server.close())

2. Ждёт пока завершатся активные запросы

3. Только тогда выходит

server.keepAliveTimeout = 65000;
server.headersTimeout = 66000;

process.on('SIGTERM', () => {
  logger.info('SIGTERM received, closing HTTP server');
  server.close(() => {
    logger.info('HTTP server closed');
    process.exit(0);
  });

  // backstop: если активный запрос завис и server.close() никогда не вызовет колбэк -
  // выходим принудительно за 2 секунды до SIGKILL, чтобы завершение было контролируемым
  setTimeout(() => {
    logger.warn('Forced exit after timeout');
    process.exit(1);
  }, 25000).unref();
});

Добавили в src/server.ts, открыли PR #5. Ревью прошло без замечаний.

Но после деплоя ожидаемых строк в логах не появилось.

Ни "SIGTERM received", ни "HTTP server closed" - ничего.

Обработчик как будто не существовал.

Причина #5 - Node.js не получает SIGTERM: yarn как PID 1

Полезли смотреть Dockerfile.

CMD ["yarn", "start"]

А start в package.json:

"start": "NODE_ENV=production node -r newrelic --enable-source-maps build/src/server.js"

Вот и проблема. Когда контейнер стартует через CMD ["yarn", "start"], процесс yarn становится PID 1 в контейнере. Yarn Classic (1.x) не пробрасывает сигналы дочерним процессам. Kubernetes посылает SIGTERM yarn, yarn его просто игнорирует, node - дочерний процесс - не получает ничего.

Вся цепочка:

PID 1: yarn
  -> sh -c "NODE_ENV=production node ..."
       -> node build/src/server.js   <- SIGTERM сюда не доходит

Решение простое - убрать yarn из цепочки и запустить node напрямую как PID 1.

ENV NODE_ENV=production
CMD ["node", "-r", "newrelic", "--enable-source-maps", "build/src/server.js"]

NODE_ENV=production был захардкожен в yarn start - просто перенесли в ENV в Dockerfile.

Теперь:

PID 1: node build/src/server.js   <- получает SIGTERM напрямую от Kubernetes

Это PR #6.

Причина #6 - server.close() не закрывает idle-соединения

После деплоя PR #6 shutdown-логи наконец появились. "SIGTERM received" - есть. "HTTP server closed" - есть. Но несколько 460 всё равно проскакивали.

Смотрю тайминг: 460 появляются в самом конце жизни пода, уже после того как server.close() отработал.

Тонкость в том, что server.close() перестаёт принимать новые соединения и ждёт завершения активных запросов - но idle keep-alive соединения при этом не закрывает. Бот-фреймворк вендора держит пул таких соединений открытыми между запросами. Если соединение было idle в момент shutdown - server.close() его не трогает. Оно висит до истечения terminationGracePeriodSeconds, потом прилетает SIGKILL от Kubernetes - и в этот момент соединение рвётся без предупреждения. Клиент пытается использовать мёртвое соединение - получает 460.

Решение: явно закрыть все idle-соединения до вызова server.close().

server.closeIdleConnections();
server.close(() => {
  process.exit(0);
});

closeIdleConnections() немедленно завершает соединения, по которым нет активных запросов. Активные - продолжают обрабатываться до конца. Именно такой порядок нужен.

Важно: closeIdleConnections() появился в Node.js 18.2.0. На более старых версиях (16.x и ниже) метода нет - понадобится либо обновить Node.js, либо вручную отслеживать и закрывать idle-соединения.

Это PR #7.

Итоговая схема: все слои и настройки

  Настройки соединений:

  +-----------------------------------------------+
  | Слой          | Параметр          | Значение   |
  +-----------------------------------------------+
  | AWS ALB       | idle timeout      | 60s        |
  | Node.js       | keepAliveTimeout  | 65s (>60s) |
  | Node.js       | headersTimeout    | 66s (>65s) |
  | Pod           | CPU limit         | 500m       |
  | Pod           | memory limit      | 1536Mi     |
  +-----------------------------------------------+

  keepAliveTimeout должен быть больше ALB idle timeout,
  иначе Node.js закроет соединение раньше ALB -> 502.

  Завершение пода (rolling deploy / OOMKill / restart):

  t= 0s  K8s удаляет под из Endpoints
         K8s запускает preStop hook
         |
         +-- preStop: sleep 15s
         |   (ждём пока ALB дерегистрирует под,
         |    иначе запросы идут на умирающий под -> 502)
         |
  t=15s  preStop завершён
         K8s отправляет SIGTERM -> node (PID 1)
         |   (именно node, не yarn -- Yarn Classic сигналы не пробрасывает)
         |
         +-- server.closeIdleConnections()
         |   (закрываем idle keep-alive прямо сейчас,
         |    иначе доживут до SIGKILL и дадут 460)
         |
         +-- server.close()
         |   (перестаём принимать новые соединения,
         |    ждём завершения активных запросов)
         |
         +-- setTimeout(force exit, 25s)
             (страховка: если запрос завис и server.close()
              не вызвал колбэк -- выходим до SIGKILL)

  t=?s   активные запросы завершились -> process.exit(0)

  t=30s  K8s: SIGKILL  (terminationGracePeriodSeconds)

  Итого окно для активных запросов: 30 - 15 = 15s

Что добавляли по пути

Помимо параметров и кода, по ходу расследования добавляли и инструменты обсервабилити:

• Логирование - добавили явное логирование события получения SIGTERM и закрытия HTTP-сервера. Раньше это было чёрным ящиком - не было понятно, что происходило с сервером в момент завершения.
• Анализ ALB-логов - настроили регулярный разбор target_status_code, target_processing_time и elb_status_code в OpenSearch. Раньше смотрели только на наличие 5xx - теперь ещё и на то, ответил ли под вообще.
• Prometheus-запросы - добавили в регулярный осмотр метрики CFS-троттлинга (container_cpu_cfs_throttled_seconds_total) и количество терминированных контейнеров с причиной (kube_pod_container_status_last_terminated_reason). Без этого CPU-проблема выглядела бы просто как "иногда 502".

Итог

keepAlive fix - keepAliveTimeout 65s, headersTimeout 66s - убирает 502 от гонки таймаутов Node.js vs ALB

• PR #1 - preStop: sleep 15 - фиксит 502 при роллинг-деплоях
• PR #2 - отключение автоскейлинга воркера - убирает лишние деплои
• PR #3 - memory limit 800Mi -> 1536Mi - фиксит OOMKill при пиках нагрузки
• PR #4 - CPU limit 200m -> 500m - фиксит CPU throttle -> liveness probe перезапускает контейнеры
• PR #5 - graceful shutdown на SIGTERM - фиксит 502/460 при завершении подов
• PR #6 - node как PID 1 в Dockerfile - фиксит то что SIGTERM вообще не доходил до Node.js
• PR #7 - server.closeIdleConnections() перед server.close() - фиксит 460 от idle keep-alive соединений

Суммарно на весь дебаг ушло около четырёх недель. Не потому что фиксы сложные - большинство из них несложные. А потому что без логов и метрик каждый следующий шаг был невозможен: сначала нужно было включить ALB логи, потом накопить статистику, потом разобраться с первой причиной - и только тогда стала видна вторая. Каждый закрытый слой убирал шум и открывал следующий. На самом деле было 9 исправлений, но я смог вспомнить только 7 из них.

После всех фиксов ошибки 502/504/460 ушли полностью, клиенты рады, сервис работает на отлично.

Несколько выводов, которые оставлю здесь для себя и тех, кто столкнётся с похожим:

• Если первый фикс помог - не спешите радоваться. Несколько независимых причин могут маскировать друг друга. Смотрите на абсолютное количество ошибок, не только на тренд
• Включите ALB access logs сразу. target_status_code: null и target_processing_time вместе сразу говорят где именно рвётся цепочка - не тратьте время на угадывание
• preStop: sleep N - обязательный минимум для любого сервиса за ALB при роллинг-деплоях (на самом деле не всегда, но пусть будет обязательным для статьи)
• CPU-лимит в Kubernetes - это не просто "ограничение". Для однопоточных рантаймов (Node.js, Python GIL) троттлинг убивает не производительность, а живость сервиса целиком
• Дефолтный http.Server в Node.js не делает graceful shutdown - надо писать руками
• Написать SIGTERM-обработчик недостаточно - надо убедиться что процесс вообще получает сигнал. CMD ["yarn", "start"] в Dockerfile делает yarn PID 1, и Yarn Classic сигналы не пробрасывает. Запускайте node напрямую
• 460 от ALB - это не "клиент сам ушёл". Это часто симптом того, что сервер рвёт keep-alive соединения без предупреждения
• server.close() в Node.js не закрывает idle keep-alive соединения - без closeIdleConnections() они будут висеть до SIGKILL и давать 460 в самом конце

Ссылки

Tuning HTTP Keep-Alive in Node.js (про keepAliveTimeout, headersTimeout и откуда берутся 502 при Node.js за ALB)

• https://connectreport.com/blog/tuning-http-keep-alive-in-node-js

AWS ALB access logs - список всех полей и как включить

• https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html

AWS ALB - настройка idle timeout и других атрибутов балансера

• https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-attributes.html

Express.js - graceful shutdown и работа с http.Server

• https://expressjs.com/en/advanced/healthcheck-graceful-shutdown.html

Kubernetes - preStop hooks и жизненный цикл пода

• https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-hooks

Kubernetes KEP-3960 - нативный sleep в preStop (PodLifecycleSleepAction, GA в 1.34)

• https://kep.k8s.io/3960

HPA: keda-hpa-vmagent-scaler
Cluster: stg-**-uswest1
Current value: 10 (max)

Сперва я вообще задумался - а нахрена этот алерт? Что он мне дает? Ну уперлось в максимум, и что? Все остальное работает ок, никаких других алертов.

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

Ну ок, пошёл смотреть.

Проблема первая:

• vmagent жрёт памяти больше, чем ему отведено

Первым делом смотрю что там с HPA:

Два триггера.

• Один prometheus-based - 5.7/40, всё хорошо.
• Второй - memory: 50%/40%.
  Вот он виновник.

Смотрю дальше:

• Лимит на каждый pod: 256Mi
• Фактическое потребление: ~130 MiB на pod

130/256 = 50%. Цель триггера - 40%, то есть 102 MiB.

Это физически недостижимо - vmagent столько и держит в памяти просто чтобы работать, независимо от нагрузки. Горизонтальный скейлинг тут не поможет: добавишь реплик, каждая всё равно будет жрать те же 130 MiB.

Решение простое - поднять лимит. 384Mi > утилизация падает до 34%, HPA успокоится.

Правлю values в репозитории с ArgoCD-приложениями для кластера stg-*-uswest1:

resources:
  limits:
    memory: 384Mi
  requests:
    memory: 384Mi

Коммичу, засинкал ArgoCD.

И вот тут началось.

Проблема вторая:

• ArgoCD и KEDA устроили драку

После синка:

Operation cannot be fulfilled on scaledobjects.keda.sh "vmagent-scaler":
the object has been modified; please apply your changes to the latest version
and try again. Retrying attempt #1

Классический 409. ArgoCD читает объект, хочет запатчить - а за это время KEDA уже успел его обновить.
Проверяю как часто это происходит:

kubectl -n vm get scaledobject vmagent-scaler -o jsonpath='{.metadata.resourceVersion}'
sleep 5
kubectl -n vm get scaledobject vmagent-scaler -o jsonpath='{.metadata.resourceVersion}'

# 157227839 → 157227898 за 5 секунд

KEDA пишет в ScaledObject каждые 1-2 секунды. Статусы, условия, метрики - всё туда.
Ретрай через 10, 20, 40 секунд не помогал - KEDA всегда успевал раньше.

Попытка 1:

• ignoreDifferences

В конфиге ApplicationSet уже был блок:

ignoreDifferences:
  - group: keda.sh
    kind: ScaledObject
    managedFieldsManagers:
      - keda-operator
      - keda-metrics-adapter

Но не работает. Пошёл смотреть кто реально владеет полями в объекте:

kubectl -n vm get scaledobject vmagent-scaler --show-managed-fields -o json

manager: keda               | op: Update
manager: argocd-controller  | op: Apply

А я что написал? keda-operator. А реальное имя - просто keda.

Добавил keda в список.

Не помогло.

Дело в том, что ignoreDifferences влияет только на то, что ArgoCD показывает в дифе.
На сам apply - никак не влияет. ArgoCD всё равно патчит объект при синке.
Это я понял позже.

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

Почитал документацию, вроде красиво, ок.

Попытка 2:

• включить ServerSideApply

Логика была такая: с SSA ArgoCD перестаёт посылать resourceVersion в патче, значит 409 уйдёт.

Добавил ServerSideApply=true в syncOptions для vm-приложений.

Тут выяснился интересный нюанс. В ApplicationSet у нас базовый шаблон уже имел ServerSideApply=true:

syncPolicy:
  syncOptions:
    - ServerSideApply=true

Но в templatePatch для vm-секции был такой кусок:

syncPolicy:
  syncOptions:
    - RespectIgnoreDifferences=true

И он молча перезаписывал базовый список вместо того чтобы добавить к нему.
Итого vm-приложения жили без SSA всё это время, хотя казалось что SSA включён. 🤡

Добавил ServerSideApply=true явно в vm-секцию. Применил. Синканул.

Ошибка изменилась:

Please review the fields above--they currently have other managers.
Please re-run the apply command with the --force-conflicts flag.

Хм. Это уже не 409 от гонки - это SSA ownership conflict.
Стало хуже. 🙃

• До SSA: транзиентная 409, иногда сама проходила с третьей попытки.
• После SSA: постоянный конфликт владения полями, не проходит никогда.

Попытка 3:

• найти конкретные поля-конфликтеры

Смотрю что именно KEDA записывает в managedFields:

kubectl get <resource> --show-managed-fields -o json \
  | jq -r '.metadata.managedFields[].manager'

KEDA через CSA (client-side apply) владеет spec.advanced.scalingModifiers.
ArgoCD через SSA тоже хочет применить spec.advanced (оно есть в Helm-темплейте).

Конфликт.

Добавил jsonPointers для этого поля:

jsonPointers:
  - /metadata/resourceVersion
  - /metadata/finalizers
  - /spec/advanced/scalingModifiers
  - /status

Не помогло.

Потому что ignoreDifferences + RespectIgnoreDifferences=true - это "не синкай ресурс если разница ТОЛЬКО в этих полях". Но если ресурс синкается по другой причине (а он синкался, потому что менялись лимиты памяти в VMAgent) - ArgoCD применяет объект целиком.

Включая все поля.

Включая конфликтные. 🤡

Попытка 4:

• Force=true аннотация

Думаю, ну раз нужен --force-conflicts, может есть способ сказать ArgoCD "применяй этот ресурс с --force-conflicts"?

Добавил в Helm-темплейт ScaledObject:

annotations:
  argocd.argoproj.io/sync-options: Force=true

Тут я вовремя остановился и проверил что это вообще делает.
Force=true в ArgoCD - это delete + recreate ресурса при каждом синке.
Не --force-conflicts для SSA. Это вообще другое и довольно опасное.

Убрал, не применял.

Что реально сработало

Пока я всё это ковырял, читал документацию, смотрел менеджед поля и логи, понял в чём корень.

Проблема - смешанный ownership: KEDA пишет в ScaledObject через CSA (старый client-side apply), ArgoCD пытается применить через SSA. Когда два разных механизма клеймят одно поле - кубернетис говорит "разберитесь между собой".

И ignoreDifferences тут не поможет никак - он только про вычисление диффа, не про применение.

Самое простое решение - удалить ScaledObject и дать ArgoCD пересоздать его с нуля через SSA.

После пересоздания:

• ArgoCD - единственный SSA-owner всех полей в объекте
• KEDA потом пишет scalingModifiers через CSA - это его поле, арго его не трогает
• Поля не пересекаются > конфликта нет

Похер, это стейдж.

kubectl -n vm delete scaledobject vmagent-scaler

ArgoCD пересоздал. Синк прошёл с первого раза. Всё зелёное. 🎉

Следом HPA отскейлился обратно - vmagent с новым лимитом 384Mi держит ~34% утилизации, ниже порога 40%.

Через 10 минут (stabilizationWindowSeconds: 600 на scaleDown) реплики упали с 10 до 2.

Что поправили в итоге

В Terraform-модулях - ApplicationSet для всех mt-кластеров:

• Добавили ServerSideApply=true явно в vm-секцию templatePatch (чтобы он не терялся при override)
• Добавили keda в managedFieldsManagers (было только keda-operator и keda-metrics-adapter, реального имени менеджера не было)
• Добавили /spec/advanced/scalingModifiers и /metadata/finalizers в jsonPointers - теперь ArgoCD корректно игнорирует эти поля при диффе и не показывает ложные OutOfSync

В репозитории с ArgoCD-приложениями - values для stg-mt-uswest1:

• Лимит vmagent: 256Mi → 384Mi

Итоги

• ignoreDifferences - только про отображение диффа. Не про apply. Всегда.
• CSA + SSA на одном объекте = смешанный ownership = проблемы. Лечится пересозданием.
• Имена менеджеров надо проверять в реальном объекте, не угадывать:

kubectl get <resource> --show-managed-fields -o json \
  | jq -r '.metadata.managedFields[].manager'

• Force=true в ArgoCD != --force-conflicts в kubectl SSA.
• Первое - delete+recreate
• второе - принудительное взятие ownership поля.

Разные вещи.

• templatePatch в ApplicationSet переписывает поля целиком, а не мержит. Если в базовом шаблоне есть syncOptions: [ServerSideApply=true], а в templatePatch ты пишешь syncOptions: [RespectIgnoreDifferences=true] - SSA пропадает молча.
• Иногда самый быстрый путь - удалить объект и дать системе пересоздать его в правильном состоянии.

Несколько часов потратил на то, что решилось одной командой kubectl delete.

Просто алерт. Просто Арго. Просто пять минут.

Классика.

На планшете для работы умер кулер. Приплыли.

Ну, не совсем всё умерло - он включается, нагревается и троттлит 100% времени.
Windows-планшет, на котором жила вся моя рабочая среда: куб контексты, профили AWS и Azure, скрипты, IDEs. Да всё. Всё было там.

Надо быстро восстановить рабочее место.

Причём в изолированное окружение, чтобы ничего, связанного с работой не перемешалось с личным и не было лишних утечек.
Поднял виртуальную машину с Windows на Mac (да, я привык к Windows-среде, не осуждайте 🙃), начал по памяти восстанавливать инструменты.

Благо есть asdf с .tool-versions - всё задокументировано, стоишь раз за разом одни и те же версии. Скопировал файл, запустил инсталляцию.

Поставилось автоматически:

• kubectl, helm, helmfile, terragrunt, terraform
• awscli, azure-cli, kubelogin
• jq, yq, k9s, kubectx

Дохера всего, около 45 утилит.

Дальше надо запустить скрипты - клонировать весь GitLab компании разом, настроить контексты кластеров всех облаков и профили облаков. Всё это у меня было. Всё это я написал раньше. Надо просто запустить.

Запускаю скрипт клонирования GitLab.
Завис. Минута. Две. Пять.
Окей, Ctrl+C, думаю. Что-то с сетью? Или токен протух?

Иду в GitLab UI - токен живой. Проверяю вручную:

curl -s -H "PRIVATE-TOKEN: $TOKEN" "https://gl.company.com/api/v4/user"

Всё нормально, вернул мой профиль, HTTP 200. Хорошо.
Значит не токен.

Меняю токен на новый - на всякий случай. Запускаю скрипт. Снова завис.

Прошу нейронку помочь.
Та начинает советовать добавить таймаут в curl, добавить проверки пагинации, переписать функции...
Делаю всё это. Всё равно зависает или выдаёт нули:
Хотя вручную curl отдаёт нормальные данные.
Ни один совет нейронки не помог ни в чем.

Добавляю отладочный вывод.
Оборачиваю запрос в файл, читаю из файла, убираю BOM, убираю нулевые байты, убираю CR...
Нули.

Пишу отдельный дебаг-скрипт с пошаговыми запросами.
Каждый шаг - отдельный curl, каждый ответ - в переменную, потом проверяем
jq -e 'type == "array"'...

И тут вижу странное:
API error на /groups page=1:

[{"id":10,"web_url":"https://gl.company.com/groups/all","name":"All"...

Что.

Стоп. Там же чётко написано [{"id":10... - это массив.
Это валидный, сука, JSON. Ты чо, пёс.
Но проверка говорит "не массив".
Проверяю сам:

echo '[]' | jq -e 'type == "array"'; echo "exit: $?"
exit: 1

Чтоооо.

echo '[1,2,3]' | jq -e 'type == "array"'; echo "exit: $?"
exit: 1

ЧТО.

jq возвращает 1 для валидного массива. На вопрос "это массив?" jq отвечает "нет".

Ладно, решаю - пофиг на GitLab, пофиг на jq, склоню вручную потом.
Сначала сделаю рабочую среду.

Иду настраивать kubectl-контексты. Запускаю скрипт - не работает.
Иду в AWS, пробую aws eks update-kubeconfig - зависает.
Пробую вручную aws sts get-caller-identity - зависает на несколько секунд, потом отрабатывает.
Что-то медленное и странное.

Пробую aws s3 ls - работает, но медленно.
Иду в Azure - az account list отрабатывает, но вывод странный. Где-то что-то парсится не так.

Начинаю замечать паттерн:

Стоп. Какого лешего тут происходит.

Как мне может ВСЁ поломать всего-лишь одна утилита?????

Пойдём смотреть тебя.

which jq
/home/alexk/.asdf/shims/jq
file /home/alexk/.asdf/shims/jq
/home/alexk/.asdf/shims/jq: Bourne-Again shell script, 
ASCII text executable

Шим asdf. Смотрю куда он ведёт:

ls /home/alexk/.asdf/installs/jq/
1.8.1
file /home/alexk/.asdf/installs/jq/1.8.1/bin/jq
ELF 64-bit LSB executable, x86-64

От сука.

А теперь проверяем ещё раз для наглядности:

uname -m
aarch64

Вот оно.
Система - ARM64. Бинарник jq - x86-64.

Именно поэтому:

• скрипт клонирования GitLab зависал на первой же функции, которая проверяла тип ответа через jq
• echo '[]' | jq -e 'type == "array"' возвращал 1 вместо 0
• счётчики были нулями - jq тихо ломался при подсчёте длины массива
• всё, что просто парсило JSON вручную через awscli/azure-cli, работало через собственные парсеры

Короче все скрипты подготовки среды на новом рабочем железе.

Понятно что сломалось.
Непонятно почему asdf поставил неправильный бинарник.

Лезу в плагин:

cat ~/.asdf/plugins/jq/bin/download

Нахожу функцию определения архитектуры:

get_arch(){
  declare arch="$(uname -m)"
  if [ "$arch" == 'x86_64' ]; then
    echo '64'
  elif [ "$arch" == 'aarch64' ]; then
    echo '64'     # <--- вот оно
  elif [ "$arch" == 'arm64' ]; then
    echo '64'     # <--- и вот
  elif [ "$arch" == 'i386' ]; then
    echo '32'
  ...
}

И чуть ниже - как формируется имя файла для скачивания:

guessed_file="jq-linux$arch"

То есть: aarch64 -> get_arch() возвращает '64' -> скачивается jq-linux64 - это x86-64 бинарник.

Самое смешное - в том же файле есть функция guess_download_url(), которая это правильно обрабатывает:

guess_download_url() {
  ...
  if [ "$arch" == 'aarch64' ]; then
    arch="arm64"
  fi
  ...
}

Правильная логика есть. Но эта функция - мёртвый код.
Нигде не вызывается. Кто-то написал, не подключил и забыл.
А в download() используется старая get_arch(), которая для любой 64-битной архитектуры, включая ARM, выдаёт одинаковое '64'.

А на GitHub Releases у jq 1.7.1+ есть отдельный jq-linux-arm64.
Он существует.
Просто плагин про него не знает.

Правлю плагин (PR с фиксом позже сделаю в плагин):

было:

elif [ "$arch" == 'aarch64' ]; then
    echo '64'
elif [ "$arch" == 'arm64' ]; then
    echo '64'

стало:

elif [ "$arch" == 'aarch64' ]; then
    echo 'arm64'
elif [ "$arch" == 'arm64' ]; then
    echo 'arm64'

И имя файла:

было:

guessed_file="jq-linux$arch"

стало:

case "$arch" in
  64)    guessed_file="jq-linux64" ;;
  32)    guessed_file="jq-linux32" ;;
  arm64) guessed_file="jq-linux-arm64" ;;
  *)     guessed_file="jq-linux-$arch" ;;
esac

Переустанавливаю:

asdf uninstall jq 1.8.1
asdf install jq 1.7.1

file ~/.asdf/installs/jq/1.7.1/bin/jq
ELF 64-bit LSB executable, ARM aarch64 ✅

echo '[]' | jq -e 'type == "array"'; echo "exit: $?"
exit: 0 ✅

Запускаю скрипт клонирования и контексты всех куберентисов.
Всё работает. Красота.

Итоги
- планшет умер, виртуалка поднялась, среда восстановлена. Полдня потрачено.
- из них часа два - на отладку того, что казалось сломанным скриптом или токеном.
- причина: jq x86-64 на aarch64-системе работает через эмуляцию, частично. Простые операции - норм. Чуть сложнее - всё, привет нулям и зависаниям.
- баг в asdf-плагине для jq: get_arch() возвращает 64 для любой 64-битной архитектуры, ARM в том числе. В итоге всегда скачивается jq-linux64 (x86-64).
- правильная логика в том же файле есть - в мёртвой функции guess_download_url(), которая никогда не вызывается.

Нули.

Казалось бы рутинная задача:

• удалить старый CRD
• накатить новый с scope: Cluster (через ArgoCD сменой версии)
• обновить манифесты custom resources, чтобы не было namespace в метаданных.

Поднял локальный kind-кластер, протестировал всё летает.
Накатил на stage-кластер готово, CRD установился, статус Established.
Применяю тестовый манифест:

kubectl apply -f test.yaml

И тут...

Error from server (NotFound): error when creating "test.yaml": 
the server could not find the requested resource 
(post myresources.operator.example.com)

Поехали дебажить

CRD в кластере есть:

kubectl get crd myresources.operator.example.com
NAME                                 CREATED AT
myresources.operator.example.com     2026-02-11T15:23:50Z

Статус Established:

kubectl get crd myresources.operator.example.com -o 
jsonpath='{.status.conditions[?(@.type=="Established")]}'
{"lastTransitionTime":"2026-02-11T15:23:50Z",
"message":"the initial names have been accepted",
"reason":"InitialNamesAccepted",
"status":"True",
"type":"Established"}

Scope правильный:

kubectl get crd myresources.operator.example.com 
-o jsonpath='{.spec.scope}'
Cluster

List работает:

kubectl get --raw /apis/operator.example.com/v1alpha1/myresources
{"kind":"MyResourceList","apiVersion":"operator.example.com/v1alpha1",
"items":[]}

А apply нет. 404. Не найдено. Бред.

Начинаем копать

Первая мысль "может API ещё не зарегистрировался до конца?"
Жду минуту. Пять минут. Десять минут.
Та же херня.

Вторая мысль "может права? RBAC?"
Проверяю:

kubectl auth can-i create myresources.operator.example.com
yes

Права есть. API отвечает. CRD Established.

А apply возвращает 404. Бред.

Ладно, смотрим что kubectl вообще пытается сделать.
Включаю verbose режим:

kubectl create -f test.yaml -v=9 2>&1 | grep -E "POST |Request Body|namespaces/"

И вот тут я вижу ЭТО:

Request Body: {"apiVersion":"operator.example.com/v1alpha1","kind":"MyResource","metadata":{"name":"my-test-resource","namespace":"my-namespace"}, ...}

curl -v -XPOST ... 'https://.../apis/operator.example.com/v1alpha1/namespaces/my-namespace/myresources?...'

POST https://.../apis/operator.example.com/v1alpha1/namespaces/my-namespace/myresources 404 Not Found

Стоп.

kubectl пытается создать ресурс по namespaced URL:

.../namespaces/my-namespace/myresources.

Для него URL должен быть

.../apis/operator.example.com/v1alpha1/myresources (без /namespaces/).

Более того, kubectl сам подставляет namespace в тело запроса, хотя в моём манифесте его нет!

Откуда namespace в запросе?

Проверяю текущий контекст:

kubectl config get-contexts
CURRENT   NAME                           NAMESPACE
*         my-staging-cluster-context     my-namespace

Ага. У меня в контексте задан default namespace my-namespace.

kubectl видит:

• в контексте есть namespace
• в манифесте metadata.namespace не указан
• думает: "ресурс же namespaced, надо подставить namespace из контекста!"
• подставляет namespace и строит URL для namespaced ресурса

Но откуда kubectl взял, что ресурс namespaced?

Хер ли ты такой инициативный-то?

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

Discovery cache вот где собака зарыта

я уже дед, если так говорю? да?😢

kubectl делает discovery при первом запросе к новой API-группе запрашивает список всех ресурсов этой группы и их параметры:

• какие есть kinds
• какие shortNames (например, po для pods, svc для service)
• namespaced или cluster-scoped
• какие verbs доступны (create, get, list, etc.)

Эта информация сохраняется в кэше:

~/.kube/cache/discovery/<server-host>/v1/serverresources.json

Я даже не знал о его существовании.

Проверяю discovery для моего ресурса:

kubectl get --raw /apis/operator.example.com/v1alpha1

Вывод:

{
  "resources": [
    {
      "name": "myresources",
      "singularName": "myresource",
      "namespaced": false,
      "kind": "MyResource",
      "verbs": ["delete","deletecollection","get","list","patch","create","update","watch"]
    }
  ]
}

API-сервер правильно отвечает:

"namespaced": false.

Значит проблема в кэше kubectl.

Он закэшировал старую версию CRD (когда тот был namespaced), и теперь считает, что ресурс всё ещё namespaced!

TTL кэша discovery

До Kubernetes v1.22 (август 2021) TTL кэша discovery в kubectl составлял 10 минут.
Многие до сих пор думают, что достаточно подождать 10 минут, и кэш обновится сам. Хуй вам.

С этого коммита

• https://github.com/kubernetes/kubernetes/commit/94f7f922054d0aa4aa07d572a940ec0dda842646

(PR #107141, merged в августе 2021)

return diskcached.NewCachedDiscoveryClientForConfig(
    config, 
    discoveryCacheDir, 
    httpCacheDir, 
    time.Duration(6*time.Hour)  // было 10*time.Minute
)

Изменение вступило в силу:

• для kubectl с Kubernetes v1.22 (август 2021)
• для всех client-go клиентов с Kubernetes v1.25

Причина:

• на больших кластерах с сотнями CRD каждый discovery-запрос может включать сотни GET запросов для всех group-versions. Это вызывало client-side rate limiting и тормозило kubectl.

Увеличение TTL снизило частоту discovery, но создало новую проблему:
устаревший кэш может жить до 6 часов, и ждать не имеет смысла.

Решение 1: Применить с пустым cache-dir

Самый быстрый способ заставить kubectl не использовать старый кэш:

kubectl apply -f test.yaml --cache-dir=/tmp/kubectl-cache-fresh

kubectl создаст свежий кэш в /tmp/kubectl-cache-fresh, сделает discovery заново, увидит, что ресурс cluster-scoped, и применит манифест корректно:

myresource.operator.example.com/my-test-resource created

После первого успешного apply новый кэш уже содержит правильную информацию.
Дальше можно работать без --cache-dir.

Решение 2: Сбросить namespace в контексте

Если не хочется трогать кэш, можно убрать default namespace из контекста:

kubectl config set-context --current --namespace=""
kubectl apply -f test.yaml

Без namespace в контексте kubectl не будет подставлять его автоматически, и запрос пойдёт на cluster-scoped URL.

После применения можно вернуть namespace:

kubectl config set-context --current --namespace="my-namespace"

Решение 3: Очистить кэш вручную

Удалить старый кэш для данного API-сервера:

# Посмотреть, где кэш
ls ~/.kube/cache/discovery/

# Удалить кэш для нужного хоста (подставьте свой каталог, я вообще всё дропнул))
rm -rf ~/.kube/cache/discovery/<host-from-above>
rm -rf ~/.kube/cache/http/<same-host>

kubectl apply -f test.yaml

kubectl при следующем запросе сделает discovery заново.

Решение 4: Обновить discovery через api-resources

Официальный способ форсировать обновление discovery cache без удаления файлов:

kubectl api-resources --api-group=operator.example.com
kubectl apply -f test.yaml

Команда kubectl api-resources принудительно обновляет discovery cache для указанной API-группы.
Это безопаснее, чем удаление файлов кэша вручную, и работает для конкретной группы, не затрагивая остальные.

Как работает discovery cache **.

Материал со звёздочками для самых любознательных.

Разберём подробнее, чтобы понять, почему эта проблема вообще возникает.

Архитектура кэша

kubectl хранит кэш в двух местах:

• Discovery cache

~/.kube/cache/discovery/<server-host>/

• файлы serverresources.json для каждой group-version
• содержат информацию о ресурсах: kinds, shortNames, verbs, scope
• HTTP cache

 ~/.kube/cache/http/<server-host>/

• кэш HTTP-запросов к API-серверу

Процесс работы

• Пользователь запускает

kubectl apply -f test.yaml

• kubectl читает манифест, видит

kind: MyResource

• Проверяет локальный кэш:
• есть ли файл

~/.kube/cache/discovery/<host>/operator.example.com/v1alpha1/serverresources.json?

• валиден ли этот файл (не истёк ли TTL)?
• Если кэш валиден, kubectl использует закэшированную информацию
• Если кэш устарел или отсутствует, делает GET запрос к API-серверу:

   GET /apis/operator.example.com/v1alpha1

• Сохраняет результат в кэш с TTL = 6 часов

Проблема при смене scope

Когда CRD меняет scope с Namespaced на Cluster:

• Старый кэш содержит

 "namespaced": true

• Новый API отдаёт

"namespaced": false

• но kubectl использует старый кэш (TTL ещё не протух)
• kubectl строит URL для namespaced ресурса:

.../namespaces/<ns>/myresources

• Для cluster-scoped ресурса такой endpoint не существует и он выплёвывает

404

Почему kubectl подставляет namespace

Когда kubectl видит:

• ресурс namespaced (по кэшу)
• в манифесте нет metadata.namespace
• в текущем контексте задан default namespace

Он делает вывод: "пользователь забыл указать namespace, подставлю из контекста".

Discovery cache и масштабирование

Эта проблема часть более широкой темы: discovery cache как ограничение расширяемости Kubernetes.

Проблема с большим количеством CRD

На кластерах с сотнями CRD (например, с Crossplane, GCP Config Connector, Azure Service Operator) discovery превращается в бутылочное горлышко:

• kubectl запускает discovery для всех, сука, group-versions в кластере
• Если у вас 500 CRD, это 500+ GET-запросов
• Каждый kubectl get pods может инициировать discovery (если кэш устарел)
• Это вызывает client-side rate limiting:

   Waited for 1.140352693s due to client-side throttling, not priority and fairness

Увеличение TTL решило одну проблему (частые discovery-запросы), но создало другую (долгоживущий устаревший кэш).

Будущие улучшения

Обсуждаются следующие подходы:

• Инкрементальный discovery обновлять только изменившиеся group-versions
• server-side filtering позволить клиенту запрашивать discovery только для нужных kinds
• Configurable TTL сделать TTL настраиваемым через флаг

Подробнее:

• https://github.com/kubernetes/kubernetes/issues/107077

Выводы и практические советы

• При смене scope CRD сразу очищайте кэш, используйте --cache-dir или запустите kubectl api-resources
• На CI/CD не используйте общий кэш между пайплайнами или очищайте перед каждым запуском
• При траблшутинге kubectl первым делом включайте -v=9 и смотрите на URL запросов
• Если видите "client-side throttling" проблема в discovery, не в API-сервере
• Не ждите 10 минут, это устаревшая информация (до Kubernetes v1.22), сейчас TTL = 6 часов
• Официальный способ обновить кэш (форсирует re-discovery)

 kubectl api-resources --api-group=<ваша-группа> 

Альтернатива для операторов

Если пишете оператор, который программно работает с cluster-scoped ресурсами:

• используйте typed clients вместо dynamic clients
• если нужен dynamic client, явно указывайте scope через REST mapper
• не полагайтесь на автоматическую подстановку namespace

Пример:

import (
    "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured"
    "k8s.io/apimachinery/pkg/runtime/schema"
)

gvr := schema.GroupVersionResource{
    Group:    "operator.example.com",
    Version:  "v1alpha1",
    Resource: "myresources",
}

// Cluster-scoped resource  без namespace
obj, err := dynamicClient.Resource(gvr).Create(ctx, &unstructured.Unstructured{
    Object: map[string]interface{}{
        "apiVersion": "operator.example.com/v1alpha1",
        "kind":       "MyResource",
        "metadata": map[string]interface{}{
            "name": "my-instance",
            // НЕТ namespace!
        },
    },
}, metav1.CreateOptions{})

Ссылки

• https://serverfault.com/questions/1049006/what-does-kubectl-store-in-the-cache
• https://jonnylangefeld.com/blog/the-kubernetes-discovery-cache-blessing-and-curse
• https://github.com/kubernetes/kubernetes/pull/107141
• https://github.com/kubernetes/kubernetes/issues/107077
• https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/cli-runtime/pkg/genericclioptions/config_flags.go