|
Professor Seleznov
|
Всем привет, меня зовут Сергей Прощаев. Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech, а также преподаю на курсах разработки и архитектуры в OTUS.
В этой статье расскажу про путь, который многие считают адски сложным: как взять рабочее приложение на Spring Boot и за полчаса доставить его до боевого кластера Kubernetes.
Я часто вижу две крайности. Первая: разработчик пишет отличный код, но дальше слов «нужно собрать jar и задеплоить» начинается туман. Вторая: DevOps-инженер настраивает пайплайны, но не понимает, почему приложение падает в подах, хотя «на машине всё работало».
Проблема не в сложности технологий, а в отсутствии связки между миром разработки и инфраструктурой. Давайте просто возьмем и пройдем этот путь вместе, шаг за шагом.
Рис. 1 Путь от кода до кластера
Почему «на моей машине работает» — это проклятие
Знакомая картина? Вы показываете работающий сервис на localhost:8080. Приходит DevOps, оборачивает его в Docker, закидывает в Kubernetes… и всё. Приложение не starts up. В логах — CrashLoopBackOff.
Первая мысль: «Наверное, Kubernetes сложный». На самом деле, проблема всегда в деталях, которые мы упускаем на уровне кода. Мы думаем, что «инфраструктура — это не моя задача», но в мире облачных вычислений эта граница давно стерлась.
Хотите увидеть, как современное приложение проходит путь от репозитория до живого окружения в кластере, не растягиваясь при этом на неделю? Тогда поехали.
Шаг 1. Готовим Spring Boot так, будто завтра в production
Первое, с чего я начинаю любое приложение, которое планирует жить в контейнере — не игнорировать production-ready метрики заранее. Многие думают, что Actuator и Health-чеки нужны только на проде. А потом мы гадаем, почему Kubernetes убивает поды при старте, хотя приложение ещё просто подключается к базе.
Я всегда добавляю в build.gradle или pom.xml зависимости:
implementation ("org.springframework.boot:spring-boot-starter-actuator")
implementation ("org.springframework.boot:spring-boot-starter-web")
И сразу делаю простой контроллер, чтобы было что проверять:
@RestController
public class HealthController {
@GetMapping("/health")
public ResponseEntity health() {
return ResponseEntity.ok("I'm alive!");
}
}
Важное уточнение. Этот самописный /health — намеренное упрощение для первого знакомства. В реальном проекте лучше сразу использовать штатный эндпоинт /actuator/health, который «из коробки» умеет проверять состояние базы данных, брокеров сообщений и других зависимостей. Но для демонстрации принципа работы проб наш контроллер более чем достаточен, а в манифесте ниже мы уже перейдём на /actuator/health.
Казалось бы, тривиально. Но именно этот эндпоинт через 15 минут станет вашим главным индикатором жизни приложения в кластере.
Мой горький опыт: помню историю, когда первый раз разворачивал Java-сервис, который отлично работал локально. В Kubernetes он падал с OOMKilled. Оказалось, локально был выставлен -Xmx256m, а в контейнере никто об этом не подумал. Приложение съело все доступные ресурсы ноды и упало. С тех пор я прописываю лимиты всегда явно.
Шаг 2. Dockerfile без магии и хрупких конструкций
Я перестал верить в супер-оптимизированные Docker-образы размером в 50 КБ, когда мы из-за отсутствия shell внутри контейнера не могли задебажить сетевую проблему. Инженерная реальность требует баланса.
Вот мой рабочий вариант — без изысков, но максимально понятный:
FROM openjdk:17-slim
WORKDIR /app
COPY build/libs/user-service-0.0.1.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]
Если хотите действовать строго по современным best practice, замените базовый образ на eclipse-temurin:17-jdk — сообщество Java-разработчиков переориентировалось на Temurin после изменения лицензионной политики Oracle. Для учебного туториала slim-образ тоже отлично работает.
Да, есть multi-stage сборки. Да, есть Distroless образы от Google. Но для первого шага (и даже для второго) этот Dockerfile абсолютно работоспособен и читаем. Потом, когда метрики покажут, что образ надо ужать, мы к этому вернемся.
Шаг 3. Контейнер локально: проверяем прежде, чем лететь в облако
Самая обидная ошибка — пушить образ в registry, ждать деплоя и видеть ошибку, которую можно было отловить локально. Я всегда следую правилу: три минуты локального тестирования экономят час логов в продакшене.
docker build -t user-service:v1 .
docker run -d -p 8080:8080 user-service:v1
curl localhost:8080/health
Если видим I'm alive!, значит, базовый кейс работает. Если нет — ищем причину в логах контейнера, а не на удалённом сервере.
Визуализируем план действий
Чтобы не запутаться, я всегда рисую последовательность. Она помогает и мне, и команде видеть общую картину, а не священный град из bash-команд.
Рис. 2 План действий: от кода до кластера
На схеме (рис. 2) показан сквозной путь от коммита в репозиторий до живого приложения в Kubernetes. Разработчик отправляет код Spring Boot в систему непрерывной интеграции (CI), где он собирается и тестируется. Затем CI собирает Docker-образ и публикует его в Container Registry. Кластер Kubernetes самостоятельно забирает новый образ в поды и применяет манифесты Deployment/Service, после чего приложение становится доступным пользователю. Ключевая мысль: весь процесс автоматизирован, участники действуют по цепочке, и для разработчика деплой сводится к обычной операции push.
Реальная история: как Adidas переизобрел свой CI/CD и сократил время деплоя
В 2020-2021 годах инженерная команда Adidas столкнулась с классической проблемой: монолитная архитектура CI/CD и ручные процессы тормозили вывод новых фич. Разработчики ждали деплоя часами, а то и днями.
Что они сделали: внедрили внутреннюю платформу на основе Kubernetes и стандартизировали доставку контейнеров. Вместо ручных операций появился self-service портал, где команды сами управляли релизами, а пайплайн от коммита до пода занимал минуты, а не часы.
Ключевой урок оттуда, который я применяю: автономия команд. Не нужно каждому разработчику становиться SRE. Нужно дать ему простой стандарт — как наш Dockerfile и Health-чеки — и понятную кнопку «задеплоить». Тогда путь «от кода до продуктива» перестает быть страшным ритуалом с бубном.
Шаг 4. Манифесты Kubernetes: меньше YAML-портянок, больше логики
Многие новички пугаются простыней YAML. Но если разложить на атомарные сущности, Kubernetes — это просто три главных вопроса: что запускаем (Deployment), кто и как общается (Service), и куда смотрит пользователь (Ingress).
Вот минимальный набор для нашего Spring Boot приложения:
Deployment (базовый):
apiVersion: apps/v1
kind: Deployment
metadata:
name: user-service
spec:
replicas: 2
selector:
matchLabels:
app: user-service
template:
metadata:
labels:
app: user-service
spec:
containers:
- name: app
image: user-service:v1
imagePullPolicy: Always
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /actuator/health
port: 8080
initialDelaySeconds: 60
readinessProbe:
httpGet:
path: /actuator/health
port: 8080
initialDelaySeconds: 20
resources:
requests:
memory: "256Mi"
limits:
memory: "512Mi"
Обратите внимание на две детали, которые часто упускают.
Во-первых, readinessProbe стартует через 20 секунд после запуска, а livenessProbe — через 60. Так Kubernetes сначала проверяет готовность пода принимать трафик, и только потом начинает следить, не завис ли он. Если поставить одинаковые задержки, медленно прогревающееся приложение рискует быть убитым раньше времени.
Во-вторых, в эндпоинтах проб я заменил наш учебный /health на штатный /actuator/health. Он идёт в комплекте с добавленным ранее Actuator и умеет автоматически проверять базу данных, очереди и другие зависимости. Самописный /healthмы оставили только для быстрого локального теста — в реальном кластере гораздо надёжнее полагаться на Actuator. |
Обратите внимание на resources и probes. Именно здесь, а не в фичах приложения, решается вопрос стабильности. Без livenessProbe Kubernetes никогда не узнает, что ваш поток завис. А без readinessProbe трафик польется в еще не поднятое приложение.
Шаг 5. Собираем всё в единый CI (на примере GitLab CI)
Теперь самое важное — автоматизация. Никаких «я сейчас соберу руками и залью на сервер». Это путь в ад и к звонкам в час ночи. Ваш CI — это конвейер, который превращает код в работающий сервис без участия человека.
Пример пайплайна:
stages:
- build
- docker
- deploy
build:
stage: build
script:
- ./gradlew build
docker:
stage: docker
script:
- docker build -t $REGISTRY/user-service:$CI_COMMIT_SHORT_SHA .
- docker push $REGISTRY/user-service:$CI_COMMIT_SHORT_SHA
deploy:
stage: deploy
script:
- kubectl set image deployment/user-service app=$REGISTRY/user-service:$CI_COMMIT_SHORT_SHA
С этим пайплайном время от идеи до ее реализации в кластере сокращается до получаса. И большая часть этого времени — осознанное написание кода и тестов, а не борьба с инфраструктурой.
Откровенно говоря, в реальных проектах никто не обновляет поды прямым kubectl set image вручную или в CI‑скрипте. Обычно применяют Helm, Kustomize или полноценный GitOps (ArgoCD, Flux). В нашем туториале мы сознательно используем самый простой способ, чтобы вы почувствовали, как CI касается кластера. Когда пойдёте в production — дорастите этот шаг до инструментов, управляющих инфраструктурой как кодом.
Лучшие практики, которые спасли мои проекты
Хочу поделиться теми практиками, которые проверены в реальных FinTech-проектах, где даунтайм даже в минуту означает потерю денег:
- Stateless приложения. Ваш Spring Boot сервис не должен хранить сессии внутри себя. Иначе при рестарте пода пользователи вылетят. Сессии нужно вынести во внешнее хранилище (например, в Redis). Так при перезапуске любого экземпляра пользователь ничего не заметит.
- Configuration as Code. Все параметры (адреса баз, ключи) — через ConfigMap и Secrets. Никаких хардкодных значений в application.properties.
- Graceful Shutdown. Обязательно настройте server.shutdown=graceful и spring.lifecycle.timeout-per-shutdown-phase=30s. Это даст приложению 30 секунд, чтобы завершить текущие запросы перед тем, как Kubernetes прибьет под. Мелочь, которая спасла сотни запросов при выкатках.
Вывод: архитектор, а не пользователь
Развернуть Spring Boot в Kubernetes — это не задачка на «зазубрить команды кубектла». Это симуляция реальной инженерной работы, где ваша ценность измеряется не количеством написанных вами YAML-файлов, а способностью видеть систему целиком — от строчки кода до живучего и наблюдаемого сервиса.
Хороший разработчик, понимающий инфраструктуру, экономит команде дни отладки и предотвращает ночные инциденты. Плохой — создаёт код, который «работает только на его машине».
Если этот разбор был вам полезен и вы хотите перестать бояться стендов и выкаток, приглашаю вас на открытый урок курса «Инфраструктурная платформа на основе Kubernetes» в OTUS.
- 7 мая, 20:00.«От кода до Kubernetes за полтора часа». Записаться
На открытом уроке разберём, как современное приложение проходит путь от репозитория до живого окружения в Kubernetes: сборка, контейнеризация, деплой и базовая логика работы в кластере.
| 📍 Бесплатное вступительное тестированиек курсу «Инфраструктурная платформа на основе Kubernetes» поможет понять, где вы сейчас: уже готовы разбираться в деплое, кластерах и платформенном подходе глубже — или сначала стоит подтянуть базу. |
-Источник
|
