{"role":"user","message":{"content":[{"type":"text","text":"<user_query>\nвопрос не по репозиторию\nя админ в клстере\nмогу сходить с имеющейся cluster role для проверки возможности чтения секретов?\n</user_query>"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"Да, можно — и лучше проверять **без фактического чтения секрета** через RBAC-проверки.\n\nСамый удобный способ:\n\n- Проверка конкретного субъекта:\n  - `kubectl auth can-i get secrets -n <namespace> --as=system:serviceaccount:<ns>:<sa>`\n  - `kubectl auth can-i list secrets -n <namespace> --as=system:serviceaccount:<ns>:<sa>`\n- Проверка конкретного секрета:\n  - `kubectl auth can-i get secret/<secret-name> -n <namespace> --as=...`\n\nВажно:\n\n- Если ты проверяешь **своим админским юзером** (cluster-admin), результат почти всегда будет `yes` и это не покажет права именно нужной `ClusterRole`.\n- Чтобы проверить именно роль, смотри:\n  1) есть ли в ней `resources: [\"secrets\"]`  \n  2) есть ли нужные `verbs` (`get`, `list`, `watch`)  \n  3) как она привязана (`RoleBinding/ClusterRoleBinding`) к нужному `SA/User/Group`.\n\nБыстрая проверка самой роли:\n- `kubectl get clusterrole <role-name> -o yaml`\n\nЕсли хочешь, могу скинуть короткий чек-лист команд для полного аудита “кто реально может читать secrets” по всему кластеру.\n\n**Explaining checking secret access**"}]}}
{"role":"user","message":{"content":[{"type":"text","text":"<user_query>\nвот права ro-user\nrules:\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - ''\n    resources:\n      - pods\n      - pods/log\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - ''\n      - events.k8s.io\n    resources:\n      - events\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - ''\n    resources:\n      - configmaps\n      - endpoints\n      - persistentvolumeclaims\n      - services\n      - serviceaccounts\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - ''\n    resources:\n      - namespaces\n      - limitranges\n      - resourcequotas\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - apps\n      - extensions\n    resources:\n      - replicasets\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - apps\n    resources:\n      - statefulsets\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - apps\n      - extensions\n    resources:\n      - deployments\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - batch\n    resources:\n      - cronjobs\n      - jobs\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - extensions\n      - networking.k8s.io\n    resources:\n      - ingresses\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - networking.k8s.io\n    resources:\n      - networkpolicies\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - rbac.authorization.k8s.io\n    resources:\n      - roles\n      - rolebindings\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - policy\n    resources:\n      - poddisruptionbudgets\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - metrics.k8s.io\n    resources:\n      - pods\n      - nodes\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - autoscaling\n    resources:\n      - horizontalpodautoscalers\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - autoscaling.k8s.io\n    resources:\n      - verticalpodautoscalers\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - storage.k8s.io\n    resources:\n      - storageclasses\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - apiextensions.k8s.io\n    resources:\n      - customresourcedefinitions\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - ''\n    resources:\n      - nodes\n      - persistentvolumes\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - apps\n      - extensions\n    resources:\n      - daemonsets\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - ''\n      - extensions\n    resources:\n      - replicationcontrollers\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - discovery.k8s.io\n    resources:\n      - endpointslices\n\n</user_query>"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"По этому набору правил — **нет, читать `secrets` нельзя**.\n\nПочему:\n\n- В `resources` нигде нет `secrets`.\n- Значит нет ни `get`, ни `list`, ни `watch` для секретов.\n- Также нет опасных прав типа `create/update/patch` на `pods`, `deployments`, `daemonsets` и т.д., через которые иногда эскалируют доступ до секретов.\n\nЧто этот `ro-user` всё же увидит:\n\n- Имена секретов в ссылках (например, в `pod.spec`, `serviceaccount.imagePullSecrets`, `envFrom.secretRef`) —  \n  но **не содержимое** (`data`/`stringData`).\n\nПроверить в кластере лучше так:\n\n- `kubectl auth can-i get secrets -n <ns> --as=<user-or-sa>`\n- `kubectl auth can-i list secrets -n <ns> --as=<user-or-sa>`\n- `kubectl auth can-i --list -n <ns> --as=<user-or-sa>`\n\nЕсли где-то получаешь `yes`, значит у субъекта есть **дополнительный** `RoleBinding/ClusterRoleBinding` помимо этой роли.\n\n**Summarizing permission limitations**"}]}}
{"role":"user","message":{"content":[{"type":"text","text":"<user_query>\nrules:\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - ''\n    resources:\n      - pods\n      - pods/log\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - ''\n      - events.k8s.io\n    resources:\n      - events\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - ''\n    resources:\n      - configmaps\n      - endpoints\n      - persistentvolumeclaims\n      - services\n      - serviceaccounts\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - ''\n    resources:\n      - namespaces\n      - limitranges\n      - resourcequotas\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - apps\n      - extensions\n    resources:\n      - replicasets\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - apps\n    resources:\n      - statefulsets\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - apps\n      - extensions\n    resources:\n      - deployments\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - batch\n    resources:\n      - cronjobs\n      - jobs\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - extensions\n      - networking.k8s.io\n    resources:\n      - ingresses\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - networking.k8s.io\n    resources:\n      - networkpolicies\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - rbac.authorization.k8s.io\n    resources:\n      - roles\n      - rolebindings\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - policy\n    resources:\n      - poddisruptionbudgets\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - metrics.k8s.io\n    resources:\n      - pods\n      - nodes\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - autoscaling\n    resources:\n      - horizontalpodautoscalers\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - autoscaling.k8s.io\n    resources:\n      - verticalpodautoscalers\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - storage.k8s.io\n    resources:\n      - storageclasses\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - apiextensions.k8s.io\n    resources:\n      - customresourcedefinitions\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - ''\n    resources:\n      - nodes\n      - persistentvolumes\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - apps\n      - extensions\n    resources:\n      - daemonsets\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - ''\n      - extensions\n    resources:\n      - replicationcontrollers\n  - verbs:\n      - get\n      - list\n      - watch\n    apiGroups:\n      - discovery.k8s.io\n    resources:\n      - endpointslices\n\n</user_query>"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"С этим `rules` результат тот же: **доступа к чтению Secret нет**.\n\n- В списке `resources` отсутствует `secrets`.\n- Значит нет прав `get/list/watch` на `secrets`.\n- По этим правилам можно читать много объектов, но не содержимое секретов.\n\nПрактическая проверка от имени нужного субъекта:\n\n- `kubectl auth can-i get secrets -n <ns> --as=<user-or-sa>`\n- `kubectl auth can-i list secrets -n <ns> --as=<user-or-sa>`\n- `kubectl auth can-i get secret/<name> -n <ns> --as=<user-or-sa>`\n\nЕсли где-то выйдет `yes`, значит права пришли из другой привязки (`RoleBinding/ClusterRoleBinding`), а не из этого фрагмента.\n\n**Confirming YAML validity and secrets absence**"}]}}
{"role":"user","message":{"content":[{"type":"text","text":"<user_query>\nkubectl auth can-i list secrets -n <ns> --as=<user-or-sa>\n<user-or-sa> - тут какую сущность надо указывать?\n</user_query>"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"Нужно указывать **того же субъекта, под кем реально идут запросы к API**.\n\n- Если это **ServiceAccount**:\n  - `--as=system:serviceaccount:<namespace-sa>:<sa-name>`\n  - пример: `--as=system:serviceaccount:payments:reader-sa`\n- Если это обычный **User** (из OIDC/сертификата):\n  - `--as=<username>` (ровно в том виде, как приходит в Kubernetes, напр. `ivan@company.com`)\n- Если важно проверить через **группу**:\n  - добавь `--as-group=<group-name>` (можно несколько раз)\n\nПримеры:\n\n- `kubectl auth can-i list secrets -n dev --as=system:serviceaccount:dev:ro-user`\n- `kubectl auth can-i list secrets -n dev --as=ivan@company.com --as-group=dev-readers`\n\nЕсли не уверен, кто ты сейчас:\n- `kubectl auth whoami` (если поддерживается версией kubectl/API)\n- или посмотреть, каким SA пользуется Pod: `spec.serviceAccountName` у workload’а."}]}}
{"role":"user","message":{"content":[{"type":"text","text":"<user_query>\n ✘ ruslanpi@ruslan-hpprobook450  ~  kubectl auth can-i list secrets -n cash-office-ru-prod --as-group=crowd-charon-admin\nerror: requesting uid, groups or user-extra for USERNAME without impersonating a user\n ✘ ruslanpi@ruslan-hpprobook450  ~  kubectl auth can-i list secrets -n cash-office-ru-prod --as-group=crowd-charon-ro\nerror: requesting uid, groups or user-extra for USERNAME without impersonating a user\n ✘ ruslanpi@ruslan-hpprobook450  ~  kubectl auth can-i list secrets -n cash-office-ru-prod --as-group=crowd-charon-rw\nerror: requesting uid, groups or user-extra for USERNAME without impersonating a user\n ✘ ruslanpi@ruslan-hpprobook450  ~ \n</user_query>"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"Ошибка из-за формата команды: `--as-group` нельзя использовать без `--as`.\n\nНужно так:\n\n- `kubectl auth can-i list secrets -n cash-office-ru-prod --as=<какой-то-пользователь> --as-group=crowd-charon-ro`\n- `kubectl auth can-i list secrets -n cash-office-ru-prod --as=<какой-то-пользователь> --as-group=crowd-charon-rw`\n- `kubectl auth can-i list secrets -n cash-office-ru-prod --as=<какой-то-пользователь> --as-group=crowd-charon-admin`\n\nНапример:\n\n- `kubectl auth can-i list secrets -n cash-office-ru-prod --as=test-user --as-group=crowd-charon-ro`\n\nВажно:\n\n- Для проверки **group-based RBAC** обычно достаточно любого `--as=test-user` + нужная группа.\n- Если у тебя нет права impersonate, получишь уже другую ошибку: `forbidden: User ... cannot impersonate ...`.\n- Если хочешь проверить именно сервис-аккаунт, используй без group:\n  - `--as=system:serviceaccount:<ns>:<sa-name>`\n\n**Explaining impersonation error with examples**"}]}}
{"role":"user","message":{"content":[{"type":"text","text":"<user_query>\nнайди причину, ничего не меняй и не деплой, это прод, в нужный контекст я уже переключился\nNikita, [24.02.2026 10:58]\nРебят, у нас что-то странное в yc-techno произошло с подами oncall.\nПо какой-то причине у части подов выставился лимит по памяти в 200Mi.\nПри этом у deployment стоит 4Gi\n\nNikita, [24.02.2026 10:59]\nТам еще есть VPA, но это сильно не похоже на его рук дело т.к. он обычно в байтах выставляет что-то в духе: 2047091944\n\nNikita, [24.02.2026 11:06]\nИ из-за этого там начались падения по OOM\n\nAndrey Klimentyev, [24.02.2026 11:07]\nЭто VPA делает. Тебе повезло с 200 Mi, в других там 2351218868 выставилось, например.\n\nNikita, [24.02.2026 11:08]\nНе, 200Mi это не поведение VPA. Это что-то другое, VPA всегда выставляет в байтах\n\nAleksey, [24.02.2026 11:09]\nтак это нормальное значение около 2.5 гигов\n\nAndrey Klimentyev, [24.02.2026 11:10]\nХорошо, с каким подом 200Mi?\n\nAndrey Klimentyev, [24.02.2026 11:10]\nНашёл 3, сорри. Ща гляну.\n\nNikita, [24.02.2026 11:11]\nЯ их рестарчу чтоб восстановить прод, такчто возможно сейчас поведение пропадет...\n\nNikita, [24.02.2026 11:12]\nНо это прям очень подозрительная херня...\n\nAndrey Klimentyev, [24.02.2026 11:13]\ndeckhouse релизнулся, VPA перекатился. В этот же момент странности начались. Смотрю changelog.\n\nNikita, [24.02.2026 11:15]\nСтранности начались сегодня после пересоздания подов\n\nAndrey Klimentyev, [24.02.2026 11:18]\nТы сейчас пересоздал все поды, там нет больше аннотации, что под VPA \"потрогал\". До этого были почти на всех, включая 200Mi поды.\n\nОчень и очень мутно всё. Как вообще там VPA побывал, если custom resource VPA нет?\n\nNikita, [24.02.2026 11:18]\nЯ перед рестартом сдампил yaml всех подов и всех deploy\n\nAndrey Klimentyev, [24.02.2026 11:18]\nСкинь, плз.\n\nNikita, [24.02.2026 11:18]\nЯ VPA выпилил сейчас\n\nNikita, [24.02.2026 11:20]\nСостояние VPA тоже задампил\n\nNikita, [24.02.2026 11:23]\nДамп деплоя grafana\n\nNikita, [24.02.2026 11:23]\n\nNikita, [24.02.2026 11:24]\nА нет ли у нас какой-то системы которая ставит некий дефолтный лимит если его нет?\n\nIgor Yurev, [24.02.2026 11:32]\nнативно в кубах такое может делать ресурс - LimitRange , но мы его не используем и в yc-techno  нету таких\n\nNikita, [24.02.2026 11:33]\nСамое странное что не на всех подах было такое поведение, а только на части\n\nNikita, [24.02.2026 11:42]\nТ.е. такое было всего на 14 подах из более 500\n\nAndrey Klimentyev, [24.02.2026 11:43]\nТам Флант какое-то вредительство выкатил.\n\n{{- if semverCompare \"<=1.32\" .kubernetesVersion }}\n  InPlacePodVerticalScaling: true\n{{- end }}\n\nAndrey Klimentyev, [24.02.2026 11:43]\nПытаюсь понять, что точно теперь происходит.\n\nNikita, [24.02.2026 11:45]\nЭто куда это они такую хрень закинули?\n\nAndrey Klimentyev, [24.02.2026 11:47]\nВ kubelet'ы. Там какое-то массовое вредительство вокруг VPA произошло. Я смотрю коммиты за последние 2.5 месяца. Похоже, какой-то большой VPA/InPlacePodUpdate труд до нас доехал вчера в yc-techno.\n\nNikita, [24.02.2026 11:48]\nА вставитьим за внесение подобной херни в выходной день возможно?\n\nNikita, [24.02.2026 11:49]\nПри том что они даже объявление делали \"мы 23 работать не будем\"\n\nAleksey, [24.02.2026 11:50]\nи релизнотсах ни слова\n\nAndrey Klimentyev, [24.02.2026 11:50]\nВозможно, это нам вставить надо. Праздники в РФ мы, похоже, не учитываем в расписаниях.\n\nNikita, [24.02.2026 11:51]\nLol\n\nArtem Gryaznov, [24.02.2026 11:51]\nОно ночью автоматом накатилось, фланты как таковые на наши настроенные окна обновлений не влияют)\n\nNikita, [24.02.2026 11:52]\nЭту херню можно как-то отключить?)\n\nArtem Gryaznov, [24.02.2026 11:53]\nпредлагаешь нам 120 кластеров руками обновлять?\n\nAndrey Klimentyev, [24.02.2026 11:54]\nОбсудим на мите.\n\nNikita, [24.02.2026 11:54]\nМне только один важен)\n\nAndrey Klimentyev, [24.02.2026 11:55]\nОтмена, это в 1.75 всё поедет. Надо учесть будет.\nНо 1.74 приехал реально за несколько часов до проблемы.\n</user_query>"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"Понял задачу: проведу только read-only расследование в текущем prod-контексте, без любых изменений. Сначала проверю текущее состояние терминала и соберу факты по `oncall`/VPA/событиям, чтобы подтвердить источник `200Mi`.\n\n**Planning initial investigation steps**"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"**Running multiple kubectl commands**"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"Уже подтвердил контекст `yc-techno` и наличие VPA в кластере. Сейчас вытащу точные данные по namespace `vedun-oncall`: какие лимиты на подах сейчас, какие события и есть ли следы VPA-мутаций/аннотаций.\n\n**Adjusting output reading approach**"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"**Investigating oncall pods across namespaces**"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"**Switching to ripgrep for large file search**"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"Нашёл целевой неймспейс: проблема с `oncall` относится к `obs-grafana`, а не `vedun-oncall`. Сейчас сравню ресурсы у `Deployment/StatefulSet` vs реально запущенные `grafana-oncall-*` поды и подниму события по OOM/resize/VPA.\n\n**Planning detailed resource inspection**"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"**Investigating memory limit anomaly**"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"**Planning VPA annotation inspection**"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"Есть важная зацепка: сейчас `grafana-oncall-engine-4` реально без memory limit в шаблоне (`requests: 1Gi`, `limits` отсутствует), тогда как остальные `engine-*` имеют `4Gi`. Дальше проверяю историю ReplicaSet и логи `vpa-updater` в `kube-system`, чтобы подтвердить, кто и когда выставил `200Mi` на части подов.\n\n**Planning pod and RS memory inspection**"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"**Investigating log file contents**"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"**Refining search patterns for logs**"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"**Narrowing namespace search**"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"Нашёл живой артефакт инцидента: у pod `grafana-oncall-celery-35-b47c8486d-hvdgb` сейчас лимит памяти `178956970` (~171Mi), при этом новые поды того же deployment уже `1Gi`. Сейчас проверяю YAML этого pod и его ReplicaSet на аннотации VPA/resize — это должно дать прямое подтверждение причины.\n\n**Investigating replica set resource mutation**"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"**Investigating pod annotations and memory limits**"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"**Investigating VPA in-place pod updates**"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"**Investigating missing VPA managed fields**"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"**Searching for uppercase VPA mentions**"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"Причина найдена, ничего не менял.\n\n- **Корень проблемы — VPA реально менял ресурсы pod’ов oncall в рантайме (in-place)**, а не Deployment-шаблоны.\n- На проблемном pod `grafana-oncall-celery-35-b47c8486d-hvdgb` есть прямое доказательство:\n  - аннотация `vpaUpdates: Pod resources updated by grafana-oncall-celery-35 ... memory request, memory limit`\n  - фактические ресурсы pod: `requests.memory=52428800` (~50Mi), `limits.memory=178956970` (~171Mi)\n  - при этом его `ReplicaSet`/`Deployment` для этого же workload имеют `requests.memory=300Mi`, `limits.memory=1Gi`\n- В `status.containerStatuses` этого же pod есть `Last State: OOMKilled (137)` — то есть падения коррелируют именно с заниженным лимитом после VPA-апдейта.\n\nПочему это выглядело “странно”:\n\n- VPA может писать значения как в байтах (`178956970`), так и в “Mi” в других случаях; это зависит от сериализации/источника, но это всё равно VPA-изменения.\n- Почему затронуло не все pod’ы: updater проходит не одномоментно, трогает часть pod’ов; после ручных рестартов большая часть уже пересоздалась с template-значениями, поэтому “следы” остались только на части/единицах.\n\nДополнительно заметил (отдельный риск):\n\n- `Deployment grafana-oncall-engine-4` сейчас в шаблоне **без memory limit** (`requests=1Gi`, `limits=<none>`), тогда как соседние `engine-*` имеют `4Gi`.  \n  Это не объясняет `200Mi`, но это отдельная конфигурационная аномалия в том же namespace.\n\nЕсли нужно, соберу короткий “postmortem evidence pack” (5-7 команд + ожидаемые поля), чтобы можно было приложить в инцидент/чат платформы.\n\n**Summarizing VPA in-place update cause**"}]}}
{"role":"user","message":{"content":[{"type":"text","text":"<user_query>\nArtem Gryaznov, [24.02.2026 11:56]\nне думаю если бы обновили руками, что то изменилось)\n\nAndrey Klimentyev, [24.02.2026 11:56]\n@Geniy_X \nА можешь VPA вернуть? Давай логи посмотрим актуальные и эвенты. Будет ли повторяться.\n\nNikita, [24.02.2026 11:58]\nЯ  там подготовил исправления, но можем перед этим попробовать снова все сломать)\n\nAndrey Klimentyev, [24.02.2026 11:58]\nДа. Давай я буду смотреть на поды, которые перекатываются не так. Интересно.\n\nNikita, [24.02.2026 12:00]\nУ меня есть теория что где-то есть система которая вкатывает \"дефолтный\" лимит при отсутствии значения\n\nNikita, [24.02.2026 12:00]\nСейчас попробую для начала кого-то ручками \"убрать\"\n\nNikita, [24.02.2026 12:05]\nДернул CI/CD на мастере, где-то минут через 20 начнет деплоить\nhttps://jenkins.lmru.tech/job/obs/job/github-automated-jobs/job/lmru--obs--grafana/job/master/\n</user_query>"}]}}
{"role":"assistant","message":{"content":[{"type":"text","text":"Да, это логичный эксперимент, и он как раз подтвердит гипотезу “это VPA/in-place, а не какой-то дефолтер”.\n\nЧто смотреть во время деплоя (первые 20–40 минут):\n\n- Поды в `obs-grafana`, у которых внезапно меняется memory на числа в байтах:\n  - `kubectl get pods -n obs-grafana -o custom-columns='NAME:.metadata.name,LIMIT:.spec.containers[*].resources.limits.memory,REQ:.spec.containers[*].resources.requests.memory' --no-headers | rg 'grafana-oncall-(engine|celery)'`\n- Следы VPA прямо на pod:\n  - `kubectl get pod -n obs-grafana <pod> -o jsonpath='{.metadata.annotations.vpaUpdates}{\"\\n\"}{.metadata.annotations.vpaObservedContainers}{\"\\n\"}'`\n- OOM/kill события:\n  - `kubectl get events -n obs-grafana --sort-by=.lastTimestamp | rg -i 'oom|killing|FailedKillPod|evict'`\n- Живые логи updater:\n  - `kubectl logs -n kube-system deploy/vpa-updater -f | rg -i 'obs-grafana|oncall|inplace|update|recommend|resize'`\n\nКритерий подтверждения причины:\n\n- Если у “битых” pod появляется `vpaUpdates` + лимит у pod расходится с `Deployment/ReplicaSet` (как уже было с `178956970`) — это VPA mutation.\n- Если `vpaUpdates` нет, а лимит всё равно подставляется, тогда копаем admission/LimitRange/другой mutating webhook.\n\nОтдельно держите в уме: `grafana-oncall-engine-4` уже сейчас с `limits.memory=<none>` в шаблоне — это может усиливать нестабильность при повторном тесте.\n\n**Providing concise risk advice**"}]}}