Local Kubernetes Dev — Part 3: Tooling overview — who does what

Два подхода: локальный кластер vs подключение к удалённому

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

Подход 1: весь Kubernetes у вас на машине. Вы поднимаете полноценный (пусть и маленький) кластер локально — через k3d, kind, minikube, Docker Desktop или Rancher Desktop — и деплоите в него свой сервис теми же манифестами, что поедут в прод. Всё локально, ничего не зависит от сети и общих стейджингов. Это путь нашей статьи.

Подход 2: локальный код подключается к удалённому кластеру. Здесь кластер живёт где-то на стейджинге, а вы «вставляете» свой локально запущенный процесс в него — так, будто он работает прямо внутри пода. Так не нужно держать весь кластер на ноутбуке, и сервис видит настоящие соседние сервисы стейджинга. Для этого есть отдельный класс инструментов: Telepresence, mirrord, Gefyra.

Коротко про них, потому что вы наверняка о них услышите:

• Telepresence строит VPN/туннель до кластера, ставит в него Traffic Manager и sidecar, умеет перехватывать (intercept) трафик сервиса на ваш локальный процесс. Требует root-прав на локальной машине (поднимает системный демон) и модифицирует кластер.
• mirrord работает иначе: он внедряется в ваш локальный процесс через механизмы вроде LD_PRELOAD/DYLD_INSERT_LIBRARIES и перехватывает libc-вызовы (сеть, файлы, переменные окружения), подменяя их на «как будто я внутри пода». Ему не нужен ни root, ни контейнеризация вашего кода — достаточно kubeconfig. По умолчанию работает в режиме mirror (зеркалирует трафик, безопасно для общего стейджинга), но умеет и steal.
• Gefyra использует VPN, работает без root, но только для кода, упакованного в Docker-контейнер, и не подменяет файлы/переменные окружения.

Различия удобно свести по каноническому разбору в блоге kubernetes.io: root нужен только Telepresence; подмену файлов и env поддерживают Telepresence и mirrord (Gefyra — нет); несколько локальных процессов одновременно умеет только mirrord. Подробности про сам mirrord — на официальном сайте MetalBear (заметьте: старый адрес mirrord.dev теперь редиректит туда).

1# Подход 2 на практике (для общего понимания, в статье не используем):
2telepresence connect
3telepresence intercept myapp --port 8080      # нужен root
4# или без root:
5mirrord exec --target pod/myapp -- uvicorn app:app --port 8080

Этот второй подход прекрасен, но у него своя цена: нужен живой удалённый кластер, его обслуживание, сетевая доступность, и для новичка это лишний слой магии. Поэтому дальше мы фокусируемся на подходе 1 — всё локально.

Docker и kubectl — фундамент

Два инструмента лежат в основании всего остального, и без них стек просто не заведётся.

Docker — это движок контейнеров. Тут важный момент, который многих удивляет: локальные кластеры запускают узлы (nodes) Kubernetes не на «голом железе» и не в облаке, а как обычные Docker-контейнеры на вашей машине. Так устроены k3d, kind, minikube с docker-драйвером и Docker Desktop. То есть нода Kubernetes — это контейнер, внутри которого крутится Kubernetes, а уже внутри него — ваши поды. Нет Docker (или совместимого рантайма) — нет кластера.

kubectl — официальный CLI Kubernetes и ваш основной канал общения с кластером. Через него вы применяете манифесты, смотрите состояние, читаете логи, пробрасываете порты и заходите внутрь подов:

1kubectl apply -f deployment.yaml          # применить манифест
2kubectl get pods -n myapp                  # посмотреть поды в namespace myapp
3kubectl logs -f deploy/myapp -n myapp      # логи в реальном времени
4kubectl port-forward svc/myapp 8080:8080 -n myapp   # проброс порта на localhost
5kubectl exec -it deploy/myapp -n myapp -- sh        # шелл внутри пода

Ещё одна важная деталь: в kubectl встроен Kustomize (о нём ниже) — его можно вызвать флагом -k:

1kubectl apply -k ./overlays/dev

Поверх kubectl работают все ускорители (Tilt, Skaffold) и визуальные утилиты вроде k9s — они под капотом дёргают тот же Kubernetes API. Так что kubectl стоит знать, даже если в повседневной работе вы будете жить в Tilt.

Локальные кластеры: k3d, kind, minikube, Docker Desktop, Rancher Desktop

Это та самая «коробка», в которую поедет myapp. Все варианты дают настоящий Kubernetes API — разница в скорости старта, прожорливости и наборе фич.

• k3d — обёртка, запускающая k3s (минималистичный, сертифицированный дистрибутив Kubernetes от Rancher/SUSE) внутри Docker. Самый быстрый старт и минимум потребляемой памяти, удобный встроенный registry. Идеален для ежедневной разработки. Важная оговорка: k3d — community- проект, а не официальный продукт Rancher/SUSE (об этом прямо сказано в его документации).
• kind (Kubernetes IN Docker) — запускает upstream-Kubernetes, узлы тоже как Docker-контейнеры, бутстрап через kubeadm. Сертифицирован CNCF, умеет multi-node и HA, может собирать Kubernetes из исходников. Создавался в первую очередь для тестирования самого Kubernetes и для CI/conformance.
• minikube — Kubernetes в виртуальной машине или с docker-драйвером, с большим набором аддонов. Классический выбор для обучения и экспериментов.
• Docker Desktop — содержит встроенный одно-нодовый Kubernetes, который включается одной галочкой. Удобно, если Docker Desktop уже стоит, но с оговоркой о «limited configuration options»: гибкости (multi-node, тонкая настройка) меньше, чем у k3d/kind.
• Rancher Desktop — GUI-приложение на базе k3s, нацеленное на нативную локальную разработку и тестирование в Kubernetes, в том числе чартов Helm.

1# Так создаётся кластер в разных инструментах (детали — в главе 5):
2k3d cluster create dev                              # k3s в Docker, наш выбор
3kind create cluster --config kind-config.yaml      # multi-node для CI/conformance
4minikube start                                       # K8s в VM/докере, для обучения

Какой выбрать? Консенсус материалов 2025–2026 (например, обзор oneuptime) сводится к тому, что kind или k3d дают лучший баланс скорости и возможностей для разработки. Конкретные цифры старта и потребления RAM по инструментам гуляют от бенчмарка к бенчмарку, поэтому относитесь к ним как к ориентиру: k3d обычно стартует очень быстро и ест мало памяти — именно поэтому он приятен для постоянного пересоздания кластера.

Helm и Kustomize — формат прод-манифестов

Помните главную идею главы 2: локальный кластер ценен тем, что принимает те же манифесты, что и прод, — в отличие от docker-compose, который структурно с ними не совпадает. А в каком виде эти прод-манифесты обычно живут? Чаще всего — в Helm или Kustomize.

Helm — это пакетный менеджер Kubernetes. Ваше приложение упаковывается в чарт (chart): каталог с Chart.yaml, values.yaml и папкой templates/. Манифесты в templates/ — это Go-шаблоны (с библиотекой функций Sprig), куда подставляются значения из .Values. Helm даёт версионирование по SemVer, понятие release (установленный экземпляр чарта), откаты (rollback), управление зависимостями и репозитории чартов. По данным CNCF, Helm используют около 75% организаций, а в ноябре 2025 вышел Helm 4 — с нативным server-side apply. Структура чарта подробно описана в официальной документации Helm.

1helm install myapp ./chart -f values.yaml -n myapp   # установить чарт как release
2helm upgrade myapp ./chart -n myapp                  # обновить
3helm rollback myapp 1 -n myapp                       # откатить на ревизию 1

Kustomize — другой подход, без шаблонов. Вы пишете базовые манифесты (base) и накладываете на них overlays — патчи под конкретное окружение (dev/staging/prod) через strategic merge или JSON 6902. Есть генераторы ConfigMap/Secret. Kustomize, как мы уже видели, встроен в kubectl (apply -k). Но у него нет пакетирования, версионирования и rollback — для GitOps и откатов поверх Kustomize обычно ставят ArgoCD или Flux.

1kubectl apply -k ./overlays/dev    # применить overlay для dev

На практике Helm и Kustomize не конкурируют насмерть, а часто дополняют друг друга: Helm — чтобы упаковать и распространять приложение, Kustomize — чтобы аккуратно править манифесты под окружение. Для myapp мы подробно поработаем с манифестами в главе 7.

Ускорители inner loop: Tilt, Skaffold, DevSpace (и где Okteto/Garden)

Голый цикл «правлю код → собираю образ → пушу → деплою → смотрю» в Kubernetes мучительно медленный. Эту боль решают ускорители inner loop — они автоматизируют сборку, обновление и наблюдение за изменениями.

• Tilt (OSS, Apache-2.0) автоматизирует цикл watch → build → update. Главная фишка — Live Update: синхронизация изменённых файлов прямо в работающий контейнер без полной пересборки образа. Конфигурация описывается в Tiltfile (по сути код на Starlark, Python-подобном языке), есть наглядный web-UI — большой плюс для новичка. Подробности — в документации Tilt.
• Skaffold (от Google, OSS) — пайплайн build/push/deploy с file sync, командой skaffold debug (деплой с подключённым отладчиком) и профилями. Умеет деплоить через kubectl, Helm, Kustomize и даже Cloud Run. Работает client-side. См. документацию Skaffold.
• DevSpace (OSS CLI) делает упор на двунаправленную синхронизацию файлов, hot reload и dev-контейнеры прямо в кластере; конфиг — devspace.yaml. Тоже client-side. См. документацию DevSpace.

Как устроена та самая Live Update в Tilt — три кирпичика (reference):

1# Фрагмент Tiltfile для myapp (подробно — в главе 8):
2docker_build(
3    'k3d-registry.localhost:5000/myapp',
4    '.',
5    live_update=[
6        sync('./app', '/code/app'),                                   # копируем файлы в контейнер
7        run('pip install -r requirements.txt',                       # ставим зависимости...
8            trigger='requirements.txt'),                             # ...только если менялся этот файл
9        fall_back_on('Dockerfile'),                                  # меняется Dockerfile -> полный rebuild
10    ],
11)

Идея: вместо «минут» на пересборку образа вы получаете «секунды» на синхронизацию файлов в живой контейнер. У FastAPI это особенно приятно сочетается с uvicorn --reload, который сам подхватывает изменённые .py-файлы. Важно помнить: Live Update не пересобирает образ — это инструмент для быстрого цикла; финальный прод-образ всё равно собирается полностью (для того и нужен fall_back_on на Dockerfile/зависимости).

Отдельно — про два инструмента, которые часто упоминают в одном ряду, хотя они про другое:

• Okteto — это про cloud dev environments: синхронизация локального кода в под удалённого/управляемого кластера. По духу это ближе к удалённому подходу из раздела 3.1, чем к чисто локальному ускорителю.
• Garden — graph-based автоматизация: build/deploy/test описываются как граф зависимостей. Полезен для сложных multi-service монорепо, для одного myapp это перебор.

Из локальных ускорителей нам ближе всего Tilt, Skaffold и DevSpace; Okteto и Garden решают соседние задачи. Tilt мы разберём детально в главе 8.

k9s и вспомогательные утилиты

Когда подов становится больше одного, постоянно набирать kubectl get/logs/describe утомляет. Тут выручают вспомогательные утилиты.

k9s — terminal-based UI для Kubernetes, по сути «визуальный kubectl». Это полноэкранный интерфейс в терминале с vim-навигацией, где видно поды, ноды и деплойменты в реальном времени, а нажатиями клавиш делаются типовые операции. Из частых горячих клавиш (официальный сайт): l — логи, s — shell внутрь пода, d — describe, Ctrl-d — удалить, плюс port-forward, scale, просмотр RBAC и :xray — древовидный обзор связанных ресурсов. Очень удобно, что k9s подсвечивает контексты цветом — продовый кластер можно покрасить в красный, чтобы случайно не натворить дел.

1k9s        # запустить; дальше навигация клавишами, :pods, :svc, :xray deploy и т.д.

Что ещё стоит знать (поставим, но углубляться не будем):

• kubectx / kubens — быстрое переключение контекстов и namespace.
• stern — стрим логов сразу с нескольких подов по селектору.
• krew — менеджер плагинов для kubectl.

Эти мелочи экономят рутину; настройку рабочего места разберём в главе 4.

Почему в статье выбрана связка k3d + Tilt

Сведём всё вместе. У локальной разработки в Kubernetes две главные боли: (1) нужен реалистичный кластер, принимающий настоящие прод-манифесты, и (2) нужен быстрый цикл правка→результат. Наш выбор закрывает обе.

k3d даёт настоящий Kubernetes API (через k3s) с очень быстрым стартом и небольшим потреблением памяти. Значит, мы получаем паритет с прод-манифестами (Helm/Kustomize), а не docker-compose-суррогат, и при этом не превращаем ноутбук в обогреватель. Кластер дёшево пересоздавать — а это бесценно, когда учишься и регулярно всё ломаешь.

Tilt с Live Update сжимает inner loop с минут до секунд, кодифицирует весь dev-сетап в Tiltfile, деплоит через реальные манифесты и — отдельно ценно для новичка — показывает наглядный web-UI, где видно сборки, логи и состояние ресурсов в одном месте.

Вместе k3d + Tilt покрывают обе боли, полностью локальны, это OSS и бесплатно. Альтернативы достойные: Skaffold и DevSpace решают похожую задачу (если вам ближе их стиль — пробуйте); Telepresence и mirrord — это другой, «удалённый» подход; Okteto и Garden — платформа и автоматизация сложных графов соответственно. Для одного сервиса myapp, который вы готовите к первому деплою, k3d + Tilt — самый короткий и понятный путь.

В следующей главе подготовим рабочее место: поставим всё необходимое и убедимся, что инструменты на месте.

Источники

• Comparing Local Kubernetes Development Tools: Telepresence, Gefyra, and mirrord — kubernetes.io blog
• mirrord (MetalBear) — официальный сайт
• k3d — официальная документация
• kind (Kubernetes IN Docker) — официальный сайт
• Helm — Charts (официальная документация)
• Kustomize reference — официальная документация kubectl
• Tilt — официальная документация
• Tilt Live Update reference — официальная документация
• Skaffold — официальная документация
• DevSpace — Introduction (официальная документация)
• k9s — официальный сайт
• Local Kubernetes Development — oneuptime, 2026