В kubelet 1.36 была утечка памяти. В EKS её закрыли раньше релиза 1.36.3
В Kubernetes 1.36 нашли регрессию в kubelet: при синхронизации подов startPodSync создавал новый отменяемый Go-контекст, но мог перезаписать сохранённый cancelFn, не вызвав предыдущую функцию. Такие контексты оставались связанными с родительским и постепенно накапливались.[1]
Проблема затрагивает upstream kubelet 1.36.0–1.36.2.[1:1][2] Она не обязана быть видна в kubectl top pods: тот показывает потребление контейнеров, а kubelet — процесс на самой ноде.[1:2] Надёжнее смотреть метрику kubelet process_resident_memory_bytes на каждой ноде.[1:3]
В исходном инциденте профиль памяти показал почти миллион удерживаемых cancelable contexts после восьми дней работы; основной путь удержания проходил через podWorkers.UpdatePod.[1:4] Исправление было принято в Kubernetes и отдельно перенесено в ветку release-1.36 для патч-релиза.[2:1]
Что важно для EKS
Есть две разные даты исправления:
| EKS AMI | kubeletVersion | Статус исправления |
|---|---|---|
1.36.2-20260709 и последующие AMI с kubelet 1.36.2 |
v1.36.2 |
AWS cherry-pick’нул фикс #139823: версия осталась 1.36.2, но код уже исправлен.[3] |
1.36.3-20260827 и позднее |
v1.36.3 |
Фикс входит в официальный upstream-релиз Kubernetes 1.36.3.[4] |
Upstream-фикс означает, что исправление вышло в официальной версии Kubernetes.[2:2] Cherry-pick означает, что AWS забрал конкретный коммит с исправлением и добавил его в собственную сборку раньше официального патч-релиза.[3:1] С точки зрения этой утечки оба варианта рабочие.[2:3][3:2]
Поэтому утверждение «первый EKS AMI с исправлением — 1.36.3-20260827» неточно: ранняя граница — 1.36.2-20260709.[3:3] Но если критерий приёмки требует именно kubeletVersion = v1.36.3, выбор ami_release_version = "1.36.3-20260827" остаётся правильным.[4:1]
Как проверить ноды
После ротации нод проверьте установленную версию:
kubectl get nodes -o custom-columns=NAME:.metadata.name,KUBELET:.status.nodeInfo.kubeletVersion
Актуальное потребление памяти kubelet можно получить с метрик ноды:
NODE=<node-name>
kubectl get --raw "/api/v1/nodes/${NODE}/proxy/metrics" \
| grep '^process_resident_memory_bytes '
Для постоянного контроля полезен алерт на process_resident_memory_bytes{job="kubelet"} > 800e6. Это не специфический детектор именно этой ошибки, но он заметит опасный рост RSS процесса до того, как память ноды начнёт влиять на workload.
Вывод
Если EKS-ноды используют 1.36.2-20260709 или более новый 1.36.2 AMI, конкретно эта утечка уже должна быть устранена. Обновление до 1.36.3-20260827 оправдано, когда нужен официальный Kubernetes 1.36.3 и выполнение DoD по версии kubelet; для одной лишь утечки это не минимально необходимый апгрейд.
https://github.com/kubernetes/kubernetes/issues/139823 — Kubernetes issue #139823 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
https://github.com/kubernetes/kubernetes/pull/140066 — Backport to release-1.36 ↩︎ ↩︎ ↩︎ ↩︎
https://github.com/awslabs/amazon-eks-ami/releases/tag/v20260709 — Amazon EKS AMI v20260709 ↩︎ ↩︎ ↩︎ ↩︎
https://github.com/awslabs/amazon-eks-ami/releases/tag/v20260827 — Amazon EKS AMI v20260827 ↩︎ ↩︎