Прод не падает

Kubernetes 1.34 доживает до 27 октября

На странице релизов Kubernetes у 1.34 стоит дата End of Life: 27 октября 2026. Последний патч 1.34.12 вышел 15 сентября, после 27-го апстрим перестанет выпускать для неё исправления. Поддерживаются только три последние минорные версии: 1.37, 1.36 и 1.35.

Проверить, что у вас крутится, можно за минуту:
kubectl version
kubectl get nodes -o custom-columns=NAME:.metadata.name,KUBELET:.status.nodeInfo.kubeletVersion
Kubelet на нодах смотрю отдельно, потому что после апгрейда control plane старые ноды часто забывают.

Если всё равно планируете апгрейд, в 1.37 есть причина прыгнуть подальше. HPA scale-to-zero перешёл в beta и включён по умолчанию: с minReplicas: 0 и object или external метриками HPA гасит ворклоад до нуля подов в простое и поднимает, когда приходит нагрузка. Раньше для этого ставили KEDA. Для очередей и ночных воркеров это прямая экономия нод.

У managed-кластеров свои сроки и платная расширенная поддержка, так что даты лучше сверить у провайдера.

Источник: https://kubernetes.io/releases/

#Kubernetes #SRE #апгрейд

Express в Lambda без адаптеров

AWS выкатила Lambda Web Functions. Это обычный HTTP-сервер, который слушает порт, без переписывания в event handler. Подходит любой Node.js-фреймворк: Express, Hono, Fastify, Next.js. Одно окружение держит до 128 запросов одновременно, а платите за активное CPU, так что ожидание ответа базы почти ничего не стоит. Память при этом считается всё время жизни окружения.

Единственное отличие от локального запуска — слушать адрес из переменной AWS_LAMBDA_HTTP_ENDPOINT. Деплой одной командой, и сразу в три региона с роутингом по задержке:
aws lambda-web deploy --name my-web-app --code ./my-app \
--regions us-east-1,eu-west-1,ap-northeast-1
Больше всего мне понравилась канарейка из коробки: update-web-function-endpoint с --revision-weights делит трафик между ревизиями, например 90/10.

Ограничения на старте: только Node.js 24 на Arm64 и пять регионов, включая Ирландию. Я бы попробовал на мелком внутреннем API, которому под нужен ради пары запросов в минуту.

Источник: https://aws.amazon.com/blogs/aws/announcing-aws-lambda-web-functions-for-fast-consistent-web-app-performance-anywhere/

#AWS #serverless #Nodejs

cgroup v1 на нодах? Kubelet просто не стартует

Хорошая памятка в блоге Kubernetes про переход на cgroup v2. Главное: с v1.35 failCgroupV1 по умолчанию true, и kubelet на ноде с cgroup v1 не запустится. kubeadm в 1.35 ловит это ещё раньше, ошибкой на init, join и upgrade. Временный выход — failCgroupV1: false, но fallback собираются убрать в v1.38.

Проверить ноду можно одной командой, ответ должен быть cgroup2fs:
stat -fc %T /sys/fs/cgroup/
Требования: ядро 5.8+ (для Memory QoS лучше 5.9+), containerd 1.4+ или CRI-O 1.20+. Ещё одна деталь, которую я бы не пропустил: на cgroup v2 OOM по умолчанию убивает все процессы контейнера разом, а не по одному. Если у вас многопроцессные контейнеры, поведение поменяется.

И обновите всё, что читает cgroupfs напрямую: cAdvisor нужен v0.43.0+, плюс свежие Java, Node.js и automaxprocs. Прогоните stat по всем нодам до апгрейда, а не после.

Источник: https://kubernetes.io/blog/2026/10/06/kubernetes-cgroups-v2-shift/

#Kubernetes #Linux #cgroups

Swap в Kubernetes — уже не ересь

В блоге Kubernetes вышел разбор, как swap на локальном NVMe поднимает плотность подов. Swap на нодах в GA с v1.34, а раньше его отключали по двум причинам: в cgroup v1 память и swap шли одним лимитом, а диски были медленными. cgroup v2 и NVMe закрывают обе.

Цифры из теста. Python-песочницы под gVisor: 80 подов без swap, 240 со swap. Headless Chrome под gVisor — 80 и 160. Сборка ядра уложилась в лимит 300 МБ вместо 600 без замедления. А вот на 200 МБ рабочий набор ушёл в swap, и сборка стала дольше на 40%+. Swap — страховка для пиков, а не замена RAM.

Включается в kubelet:
failSwapOn: false
memorySwap:
swapBehavior: LimitedSwap
Работает только для Burstable: limit по памяти должен быть выше request. Я бы начал с нод под CI-раннеры, там память простаивает больше всего.

Источник: https://kubernetes.io/blog/2026/10/05/scaling-kubernetes-workloads-with-node-swap/

#Kubernetes #SRE #swap

curl на arm64 и баг компилятора, которого, похоже, нет

Команда curl переносила CI на arm64-раннеры, и тесты 2500–2503 начали падать под valgrind. Только в release. OpenSSL, собранный gcc 15/16 с -O3, — падает, с -O2 или clang — нет. quiche (Rust) — падает с opt-level от 1.

Обошли так: OpenSSL собирают clang'ом, quiche на aarch64 — с CARGO_PROFILE_RELEASE_OPT_LEVEL=0. Сначала это громко назвали двумя багами компиляторов. На HN и Lobsters быстро возразили: баг-репортов в компиляторы нет, ничего не подтверждено, и очень похоже, что valgrind ругается на вполне законную оптимизацию.

Мне эта история нравится как напоминание. «Баг компилятора» — почти всегда последняя версия, а не первая.

Если вы сейчас переезжаете на Graviton или свои arm-ноды, гоняйте тесты на той же архитектуре и с теми же флагами, что в проде. Плавает только в release? Сначала бисектите флаги. А временный костыль подпишите ссылкой на issue, иначе он проживёт дольше вас.

Источник: https://github.com/curl/curl/issues/23237

#ARM64 #CI_CD #DevOps