komehdaht/cursor-chat-archive
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
cursor-chat-archive/repos/lmru-replenishment-parameterization-api/agent-transcripts/91245a37-af57-4618-ad9e-6170dc7de42d/91245a37-af57-4618-ad9e-6170dc7de42d.jsonl
T
Ruslan PiatrovichandCursor 532ac723cb Add full Cursor chat archive for Documents/repos workspaces. 
Includes global state.vscdb, per-repo transcripts, workspace storage,
composer exports, and restore scripts for a new machine.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-04 11:53:07 +03:00

31 lines
29 KiB
JSON
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
{"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**"}]}}
Reference in New Issue View Git Blame Copy Permalink