Alexandr Kruchkov

Просто алерт. Просто Арго.

2026-03-17T09:27:02.097Z

Прилетает алёрт: HPA maxed out.

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

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

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

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

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

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

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

NAME REFERENCE TARGETS MIN MAX REPLICAS
keda-hpa-vmagent-scaler VMAgent/... 5694m/40 (avg), memory: 50%/40% 2 10 10

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

Один 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.

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

Классика.

Нули

2026-03-05T17:34:50.170Z

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

Ну, не совсем всё умерло - он включается, нагревается и троттлит 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 отрабатывает, но вывод странный. Где-то что-то парсится не так.

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

всё, что связано с обработкой JSON в CLI-инструментах, либо зависает, либо даёт неверный результат. awscli внутри гоняет Python и boto3, там свой парсер.
jq - отдельный бинарник.

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

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

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

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.

WSL2 на Windows ARM (в моём случае - Windows виртуалка на Mac с чипом Apple Silicon, WSL2 внутри неё) умеет запускать x86-64 бинарники через Microsoft Prism - встроенный эмулятор.
Запускает. Но нестабильно. Базовые операции типа jq '.field' или jq '.[]' работают.
А вот более сложные выражения, типа jq -e 'type == "array"' или даже jq --version - падают или зависают.

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

скрипт клонирования 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(), которая никогда не вызывается.

Нули.

Когда kubectl врёт

2026-02-11T18:07:58.287Z

Сегодня мне для нашего кубернетис оператора надо было поменять Namespaced scope на Cluster scope у одного CRD.

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

удалить старый 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.

Но ресурс-то у меня теперь cluster-scoped !!!!!!!

Для него 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

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

Кэш позволяет kubectl не дёргать API-сервер при каждом kubectl get po, а сразу знать, что po = pods.

Проверяю 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)

дефолтное значение TTL увеличили до 6 часов:

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 не существует и он выплёвывает

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

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

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

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

Для cluster-scoped ресурсов это некорректное поведение, но kubectl этого не знает, потому что кэш врёт.

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{})