Зоны ответственности kubelet

➡️ Kubelet получает манифесты подов (PodSpecs) в основном от API-сервера, но также берет их напрямую из файловой системы ноды (по умолчанию из каталога /etc/kubernetes/manifests). Это позволяет запускать control plane еще до того, как доступен API-сервер, решая проблему курицы и яйца при инициализации кластера.

➡️ После получения манифестов kubelet приводит в соответствие текущее состояние подов на ноде с желаемым состоянием, описанным в манифесте. Для запуска и управления контейнерами он взаимодействует с container runtime (containerd, CRI-O). Аргумент --container-runtime-endpoint сообщает kubelet, где находится этот container runtime.

➡️ Kubelet не только запускает поды, но и постоянно мониторит их состояние. Он реализует  liveness, readiness и startup пробы.

➡️ Kubelet регулярно отправляет информацию о статусе подов и самогй ноды в API-сервер, что позволяет control plane отслеживать состояние ноды и запущенных на ней подов.

➡️ Через kubelet реализуется доступ к exec, logs и другим операциям — все эти запросы идут через API-сервер, который в свою очередь обращается к kubelet для получения данных с нужной ноды (или нод).

➡️ Kubelet отвечает за контроль ресурсов узла: при возникновении нехватки ресурсов (например, памяти) инициирует вытеснение (eviction) подов с наименьшим приоритетом. При этом учитывается поле priorityClassName: поды с более низким приоритетом будут удалены первыми, чтобы освободить ресурсы для более важных сервисов (подробнее тут).

Почему неплохо всё это знать?

Бывают разные кейсы. Пример — этот тред на реддите, или почему важны лимиты. Под на ноде съедал всю память и из-за этого крешился kubelet, делая ноду недоступной. Упс.

Service mesh в K8s: костыль или must have?

➡️ прямой эфир в понедельник!

Специальный гость — Георг Гаал, Principal DevOps Engineer, Zodia Markets.

Эфир пройдет в формате интервью. Мы с Маркусом подготовили для Георга каверзные вопросы про стандартные и не очень способы применения service mesh. Попробуем выяснить: есть ли жизнь после сервис меша?

➡️ Встречаемся прямо здесь, на канале, 23 июня в 18:00 мск. Эфир бесплатный, предварительная регистрация не нужна.

Ждём вас!

Сбор ответов для State of DevOps Russia 2025 заканчивается

До завершения ежегодного исследования состояния DevOps осталось 2 дня.

Это исследование — единственное в своем роде в России. Оно позволяет получить полную картину того, как развивается DevOps в стране, какие инструменты и практики используют команды, с какими вызовами сталкиваются компании. Каждый новый голос делает исследование точнее и полнее, поэтому я прошу вас пройти его.

➡️ Результаты исследования будут доступны каждому участнику. А еще организаторы разыграют в лотерею мерч, промокоды и билеты на Highload++ и DevOps Conf.

20 минут вашего времени — возможность повлиять на будущее DevOps в России.

Пройти опрос — по ссылке.

Привет! Это Маркус.

Решил вздремнуть, чтобы набраться сил перед эфиром.

➡️ Напоминаю: сегодня в 18:00 мск мой человек встречается с Георгом Гаалом, Principal DevOps Engineer, Zodia Markets.

Будем задавать ему всякие каверзные вопросы про сервис мэш и кубернетисы ваши (если я не просплю, конечно).

Кто придёт — лапки вверх 😻

Overengineering, который медленно убивает ваш продукт

👉 Второй вебинар серии FinOps 25 июня в 17:00 мск

Overengineering замедляет разработку, тратит ресурсы и подрывает мораль команды в силу увеличения порога входа в продукт.

На вебинаре мы:

🔹 разберем разные кейсы: от раздутых пайплайнов до излишнего увлечения надежностью

🔹 расскажем о причинах overengineering – от карго культа до CV driven development.

После просмотра вы получите solid понимание, как не надо делать, и советы, как не усложнять себе жизнь без строгой необходимости.

Занять место в один клик — через бота.

Kubernetes — всё. Что вместо него?

Kubernetes стал стандартом де-факто в мире контейнеров и DevOps. Но может ли его что-то заменить?

Принес вам свежий выпуск подкаста {между скобок} — коллеги обсуждают, есть ли жизнь после k8s, куда движется индустрия и стоит ли разработчику вникать в k8s.

➡️ Внутри есть мини-интервью со мной, рассказываю про service mesh: что это, как устроено и кому нужно. А ещё делюсь промокодом на скидку 10% на интенсив по service mesh.

Но своим подписчикам готов отдать его прямо в посте: SM_SKOBKI

Смотреть интервью — по ссылке.

BARE METAL PROVISIONING

Вы, конечно, читали документацию Kubernetes. Следуйте инструкции, и получите кластер. Но есть одна маленькая деталь, когда дело касается автоматизации добавления воркер нод — нужно сначала установить ОС!

Как только у вас появилась ОС, её можно настраивать по сети. Ansible? Кастомные скрипты по SSH? Выбирайте свой любимый инструмент, который приносит меньше всего боли! В облаках, конечно, все проще. Создали AMI со всем необходимым, засунули kubeadm join в userdata, и готово! Хотя, конечно, проще взять EKS.

Бывают разные кейсы, и, например, здесь описано, как при помощи синей изоленты, AWS SSM, userdata и EC2 metadata API (169.254.169.254/latest/meta-data) автоматизировать добавление новых воркер нод, поднятых через terraform на EC2.

Но это все еще недостаточно интересно, мы же тут про настоящий bare metal говорим! Как автоматизировать процесс подключения новых воркер нод на bare metal?

🐈 Ответ: PXE (будьте здоровы!)
PXE — Preboot Execution Environment.

➡️ Что нам понадобится?

🟠 DHCP-сервер: будет выдавать машинам IP-адреса, а также сообщать, с какого TFTP-сервера нужно тянуть образ.

🟠 TFTP-сервер: TFTP (Trivial File Transfer Protocol) — это такой очень простой (до неприличия) протокол передачи файлов, который используется, чтобы отдать образ по сети на машину, у которой еще нет даже намека на операционную систему. TFTP-сервер раздаст загрузочные файлы, необходимые для старта установки.

➡️ Как это работает?

1. DHCP Discovery: PXE-клиент, вшитый в прошивку сетевой карты, отправляет DHCP DISCOVER.
2. DHCP Offer: DHCP-сервер отвечает с IP, TFTP сервером (option 66) и bootfile (option 67), используя MAC-адрес для кастомизации.
3. TFTP Download: клиент качает bootloader (например, pxelinux.0 или ipxe.efi) через TFTP (по UDP!, вот где UDP используется в реальном мире, не всем же по TCP ходить).
4. Bootloader Config: Bootloader ищет конфигурационный файл (например, MAC-адрес-специфичный, или default), определяющий kernel и initrd.
5. Kernel & Initrd: скачиваются kernel (vmlinuz) и initrd через TFTP.
6. OS Install: ядро загружается, initrd монтируется, и запускается установщик ОС. Здесь уже важно сделать образ, который «сам» поставится, вплоть до успешного kubeadm join.

➡️ Кастомизация?

Вся кастомизация может быть основана на MAC-адресе добавляемой ноды. DHCP-сервер может выдавать разные параметры в зависимости от MAC-адреса, а TFTP-сервер может отдавать разные файлы конфигурации PXELINUX. Это позволяет автоматизировать установку разных операционных систем и конфигураций на разные машины. Но все же лучше делать единообразно.

Почитать гайд можно, например, здесь. Ну и модный talos тоже позволяет так делать.

Отсылаю тут к недавнему посту, почему важно знать как работает сеть, даже под десятью слоями абстракций. Если в указанной цепочке что-то сломается, расчехляйте ваши tcpdump.

А что насчет медведя? Отсылаю к другому посту про музыку для работы. Slaughter to Prevail как раз недавно выпустили новый трек RUSSIAN GRIZZLY IN AMERICA.

Две взрывных шутки из комментариев:

You can't make typical animal noises in the breakdown
Alex : hold my BEAR

Режиссёр: Сколько отсылок к России вы хотите добавить?
Саня: Да

А как вы автоматизируете процесс поднятия воркер нод, если у вас bare metal?

Архитектурные диаграммы для вашего k8s

Разобраться в инфраструктуре проще, когда она нарисована. И в этом нам поможет kubediagrams.

➡️ Что это такое?

KubeDiagrams — это инструмент, который позволяет генерировать довольно наглядные архитектурные диаграммы на основе того, что задеплоено в кластере или лежит у вас в репозитории. Он использует манифесты, позволяя быстро визуализировать взаимосвязи между подами, сервисами, деплойментами и другими ресурсами.

➡️ Пример использования с проектом opentelemetry demo.

Этот проект был выбран, потому что для него нет готовой картинки в README на github (а там есть разные примеры, начиная от простых деплоев wordpress, заканчивая более сложными проектами типа cassandra).

Добавим репозиторий opentelemetry demo и поставим в кластер:

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm install my-otel-demo open-telemetry/opentelemetry-demo

Поставим kubediagrams прямо из github и запустим через python virtualenv:

git clone https://github.com/philippemerle/KubeDiagrams.git
python3 -m venv myenv; source myenv/bin/activate
pip install PyYAML diagrams

И получим ошибку 😟

Понадобилось доустановить graphviz для создания картинок. На macos ставится так:

brew install graphviz

Результат для opentelemetry demo:

kubectl get all -o yaml | ./KubeDiagrams/bin/kube-diagrams -o /tmp/otel.png -

Warning: картинка огромная, потому что компонентов много, и все они развернуты в одном namespace.

🐈 Дайджест материалов июня 🐈

Сегодня последний день месяца, а это значит, что пришло время подвести итоги и собрать в одном посте все полезные материалы.

➡️ Оптимизация запуска тяжелых образов для ML

➡️ Разгружаем etcd

➡️ Cloud native практики, которые постоянно нарушаются

➡️ Что почитать, чтобы отвлечься от кластеров

➡️ Атаки на инфраструктуру через забытые ресурсы

➡️ Заметки про публичные облака, или что можно узнать, если внимательно читать документацию

➡️ Неожиданные ошибки в k8s, или imagePullPolicy, который вас обманывал

➡️ Зоны ответственности kubelet

➡️ BARE METAL PROVISIONING

➡️ Архитектурные диаграммы для вашего k8s

Видеоматериалы:

🟣 Rancher в продакшен: вебинар с Вячеславом Федосеевым
→ YouTube
→ VK Видео
→ Rutube

🟣 Kubernetes — всё. Что вместо него? Свежий выпуск подкаста {между скобок}
→ YouTube

В комментариях под этим постом можно написать, какую тему вы хотели бы разобрать в июле ⬇️

Как DevOps-инженеру сэкономить часы работы и избежать ошибок с помощью AI-инструментов

👉 воркшоп с Виктором Чаплыгиным, Senior Engineer в международном GameDev холдинге.

Что будет на воркшопе:

Теория: кратко о том, как работают LLM в контексте разработки и эксплуатации. Обзор Cursor IDE — AI-интегрированная IDE с поддержкой кода и терминала.

Практика:

🔹 Настройка Cursor IDE — подготовка среды для продуктивной работы с AI;
🔹 Создание и отладка IaC (Kubernetes YAML, Ansible) с помощью AI-ассистентов: выявление и исправление ошибок;
🔹 Генерация понятной и структурированной документации к проектам с помощью AI;
🔹 Разбор реальных кейсов и работа с командной строкой: исправление, пояснение, улучшение команд и манифестов.

А ещё — личный опыт и лучшие практики применения GPT-ассистентов для повседневных DevOps-задач, от написания инфраструктуры до исправления ошибок и генерации документации.

Когда: в субботу, 5 июля

Узнать подробности и занять место на воркшопе — по ссылке.

Когда docker-compose подводит

Привет, это Маркус. Сегодня замещаю своего человека и хочу рассказать вам, почему переход на k8s стоит того.

Вы могли видеть такие проекты: один docker-compose отвечает за всю инфраструктуру сервиса:

🟣Контейнер с приложением
🟣БД
🟣Кеш

Таких сервисов может быть несколько, они еще будут взаимодействовать друг с другом путем открытия внешних портов на серверах (и хорошо, если это будет внутренняя сеть облака, а не машины с публичными IP без правильно настроенного файрвола). Каждому из них нужны зависимости в виде БД, кешей, очередей и т.д.

Все это деплоится по ssh (или через gitlab runner с executor=shell, где runner крутится на той же машине, что и сервис).

И работает до поры, до времени.

Что может пойти не так?

➡️ Падение ноды

Сервер с проектом падает. Что происходит с вашим сервисом, БД и кешем? Правильно, они все недоступны. docker-compose в этой ситуации бесполезен. Он не умеет автоматически перезапускать контейнеры на другой ноде, обеспечивая непрерывность работы.

Особо дотошные скажут, что есть же docker swarm, и да, он может закрыть часть потребностей с точки зрения отказоустойчивости, но есть один нюанс: продукт больше активно не поддерживается и иногда получает багфиксы. Если вы супер дотошны, то можно сказать, что он уже закрывает все потребности и просто работает, так что там нечего развивать. И в разрезе небольших проектов это может быть валидно.

➡️ Обновления без даунтайма

Пришло время обновить ваш сервис. Используя docker-compose, вам придется остановить контейнер, обновить образ и запустить его снова. Это приводит к неизбежному даунтайму, даже если он длится всего 5 секунд.

➡️ Управление секретами

API-ключи, токены, etc. в любом случае окажутся на сервере, например, в виде .env файла, который хорошие мальчики не коммитят в git, и хранят в защищенных переменных в gitlab. И здесь возникает другая проблема: сложно выполнить аудит, кто к чему имеет доступ (в отличие от хорошо подготовленного vault).

docker-compose не виноват. Нужна смена парадигмы. Переход от серверов вида pets к серверам вида cattle.

При чем тут животные, можно прочитать в статье.

docker-compose отлично справляется с задачей локального запуска, но совершенно не подходит для оркестрации (да и деплой через gitlab runner c executor=shell, прямо скажем, тоже костыль).

Какие проблемы закрывает k8s

➡️ Self-healing
Если нода выходит из строя, k8s автоматически перезапускает ваши контейнеры на живых нодах, обеспечивая доступность сервиса.

➡️ Обновления без даунтайма
k8s поддерживает стратегии деплоя, такие как rolling update, позволяющие обновлять приложения постепенно, без прерывания обслуживания трафика. Приложение должно правильно завершаться, в соответствии с The Twelve-Factor App, но это уже такое же базовое требование, как и то, что любой сервис должен корректно работать в docker.

➡️ Управление секретами
k8s предоставляет встроенные механизмы для безопасного хранения и управления секретами, но будем честны, по-настоящему безопасно процесс работы с секретами можно выстроить через vault, полностью обходя механизм секретов в k8s (если есть такая необходимость)

➡️ Масштабирование
k8s позволяет автоматически масштабировать ваши приложения в зависимости от нагрузки (если настроите).

🐈 Переход на k8s — это инвестиция в стабильность и надежность, которая окупается не сразу.

Порог вхождения может показаться высоким, но результаты часто стоят того. k8s позволит вам сосредоточиться на разработке и развитии продукта, не беспокоясь о рутинных задачах по управлению инфраструктурой:

🔷 Перенести сервис на другую ноду
🔷 Добавить больше реплик для обслуживания выросшей нагрузки (но БД он вам магическим образом не отскейлит)
🔷 Легко и непринужденно ставить мониторинг
🔷 Запрещать запускать небезопасные вещи
🔷 Выполнять аудит изменений в кластере
И многое. многое другое.

Можно встретить мнения, что k8s сделал для оркестрации то, что сделал в свое время linux для серверов. k8s — это новая ОС, но не в классическом понимании операционных систем.

Карго-культ в инфраструктуре, или когда «делай как Google» создает проблемы

Представьте: вы взяли огромный helm chart сервиса, который успешно работает, и практически без изменений применили к другому сервису.

Итог: постоянные потери коннектов, потому что был настроен HPA, который новому сервису как собаке пятая нога, потому что в нормальный graceful shutdown он не умеет, клиенты плохо умеют ретраить и все остальное, что мы так любим (нет) в плохо написанных проектах.

Другой пример: у нас есть SRE, они пусть и чинят.

Разработчик сломал прод, SRE починил, и так несколько раз. Разработчики не интересуются метриками и доступностью. Идея shared ownership умерла, не успев зародиться. SRE занимаются тушением пожаров, а не внедряют лучшие практики и не доносят до разработчиков, как надо делать.

SRE курильщика — это когда создается пожарная команда, а не культура отказоустойчивости с SLO, error budgets, capacity planning, postmortems и прочими умными словами.

➡️ Карго-культ — это не только про инженеров, копирующих без понимания конфигурации, решения, архитектуры. Это про любой уровень, где берут нечто без понимания, как оно работает.

Чем выше уровень ответственности, тем дороже обходятся ошибки. Архитектурные решения, принятые на веру, могут привести к инцидентам спустя месяцы после внедрения.

🐈 Хотите как у Google? Сначала разберитесь, действительно ли у SRE занимаются тем, что описано в книгах, а не играют роль спасательного круга для разработчиков.

🐈 Хотите как у Cloudflare? Окей, тогда и инциденты разбирайте, как у Cloudflare — публично, в деталях и с обозначением всех причин, приведших к даунтайму.

История одного факапа, или как kubectl edit deployment стоил компании много денег

🟠 Контекст: компания разрабатывает платформу для онлайн-платежей. Сервис Transaction Processor (TP) отвечает за обработку транзакций и напрямую влияет на выручку компании. Любые перебои в его работе приводят к ощутимым финансовым потерям.

🟠 Ситуация: обкатали новый релиз сервиса в проде. Все сделали по лучшим практикам: канарейки, авто откаты в случае ошибок на метриках, обратная совместимость между актуальной и предыдущей версией сервиса.

🟠 Инцидент: после деплоя новой версии сервиса на 100% трафика, постепенно, через несколько часов, стало понятно, что есть проблема с утечкой памяти.

Команда, решив временно исправить ситуацию, вручную отредактировала deployment TP в проде, используя kubectl edit deployment tp-deployment.

Отдельный вопрос, почему у разработчиков в проде есть такой уровень доступа в кластер, но это out of scope.

🟠 Все расслабились: пока разбирались с утечкой памяти и не выкатывали новые версии, пришла пятница. Старая версия сервиса уже день работала в проде без проблем, без утечек памяти и не создавала никаких причин что-то делать. По метрикам все было ровно.

🟠 Что было дальше: на выходных команда, отвечающая за обслуживание кластера, утром, во время минимального трафика решила начать обновление некоторых зависимостей с постепенной перевыкаткой сервисов, потому что в сайдкар контейнерах были обнаружены критические ошибки, из-за которых можно было провести атаку типа DoS (не путать с DDoS).

В качестве сайдкара был envoy или nginx, и весь входящий в под трафик проходил через него, а так же весь исходящий трафик. Все это в целях аудита, мониторинга, управления сетевой безопасностью внутри кластера и так далее. А сами сайдкары добавлялись через mutation admission webhook, так что команды разработки в это никогда не влезали и не думали о сайдкарах, пока все успешно работало.

🟠 Последствия: передеплой TP привел к выкатке новой версии (потому что в main ветке именно она), перезаписав версию во вручную отредактированном deployment.

Работы прошли беспроблемно и все ушли отдыхать.

По итогу через несколько часов все поды начали почти синхронно падать по out of memory, трафик начинал идти на оставшиеся поды, которые перестали справляться с нагрузкой. k8s любезно перезапускал упавшие поды, которые тут же начинали получать трафик, который они неспособны обработать, и по liveness пробе начинали рестартовать, и так в цикле.

➡️ Что пошло не так?

Основная причина инцидента — configuration drift. kubectl edit deployment создал разницу между задекларированным состоянием в git и реальным состоянием кластера.

Нарушение декларативного подхода: k8s спроектирован для работы с декларативным подходом. Мы описываем желаемое состояние системы в манифестах, и Kubernetes следит за тем, чтобы реальное состояние соответствовало задекларированному.

➡️ Какие выводы можно (и нужно) сделать?

🟠 Infrastructure as code: если состояние инфраструктуры отличается от сохраненного в git - оно может стрельнуть в любой момент.
🟠 GitOps: рассмотрите возможность использования инструментов GitOps (например, ArgoCD) для автоматической синхронизации конфигурации кластера с репозиторием. Это гарантирует, что кластер всегда находится в желаемом состоянии, задекларированном в Git. Даже если кто-то имеет права лезть в кластер и менять конфигурацию.
🟠 Обучение: убедитесь, что все члены команды понимают принципы работы k8s, декларативный подход и важность IaC.

Эта история — урок о том, что k8s требует понимания. Быстрое решение с помощью kubectl edit deployment может быть легким (при наличии прав в кластере), но последствия могут быть серьезными. Инвестируйте в автоматизацию, инфраструктуру как код и обучение команды. Это окупится с лихвой, предотвращая дорогостоящие инциденты и обеспечивая стабильную работу. Конечно же, если все это правильно приготовите 🙂