Как разрабатывать приложения для Kubernetes: инструменты и подходы
Как разрабатывать приложения для Kubernetes: инструменты и подходы
Писать приложение, которое будет работать в Kubernetes, — задача с подвохом: привычный цикл «сохранил файл — увидел изменения» здесь ломается о контейнеры, образы и деплойменты. О том, как вернуть разработчику комфортную скорость итераций, рассказывают инженеры Red Hat и Weaveworks Майкл Хаузенблас и Илья Дмитриченко в материале о разработке на Kubernetes.
Где запускать кластер
Авторы выделяют четыре концептуальных режима разработки. Первый — полностью офлайн: локальный кластер на Minikube или встроенном Kubernetes в Docker Desktop для Mac и Windows. Второй — proxied-режим, когда трафик из кластера пробрасывается на машину разработчика, как в Telepresence. Третий — live-режим: сборка и деплой идут в удалённом кластере. Четвёртый — полностью онлайн-среда, примеры которой Eclipse Che и Cloud 9. Выбор зависит от этапа: от прототипа в одиночку до интеграции зрелых микросервисов.
Инструменты, которые сокращают цикл
Draft помогает развернуть любое приложение в Kubernetes с минимальной подготовкой. Skaffold автоматизирует сборку и деплой. Telepresence соединяет контейнеры на рабочей станции с удалённым кластером двусторонним прокси и эмулирует внутрикластерное окружение, включая доступ к config maps и secrets — ценой некоторой сетевой задержки и работы через side-car на базе sshuttle. Ksync синхронизирует код и конфигурацию между локальной машиной и контейнером в кластере, пропуская шаги сборки образа и ревизионного контроля, но требует привилегированного DaemonSet и Docker с overlayfs2.
В практической части авторы берут простой симулятор биржи из двух микросервисов: генератор данных на Go и потребитель на Node.js с эндпоинтами /average/$SYMBOL и /healthz. На нём пошагово показывают работу ksync, Minikube с локальной сборкой и Skaffold — вплоть до правки кода и наблюдения за обновлением в кластере. Подробности на сайте — в исходном материале.
Что это значит
Главный тезис статьи: чем меньше инструменты меняют привычный рабочий процесс, тем выше шансы, что разработчик не сбежит от Kubernetes. Для команд это означает ставку на локальные кластеры и синхронизацию кода вместо долгих циклов «собрал образ — задеплоил — подождал». Для платформенных инженеров — запрос на простые обёртки, скрывающие YAML и манифесты.
Экосистема инструментов для Kubernetes меняется быстро, и разбираться в ней стоит на практике: попробуйте поднять локальный кластер и прогнать цикл разработки на небольшом сервисе. Узнайте больше о технологиях и подходах к разработке.
📌 Чтобы не пропустить новые публикации, подписывайтесь там, где вам удобнее: Дзен или MAX.
💛 Если статья оказалась полезной, поддержите автора донатом.
Материал подготовлен на основе информации из открытых источников. Все права на исходные материалы принадлежат их авторам. Если вы являетесь правообладателем и возражаете против использования, свяжитесь с нами по адресу info@11st.press.
