Всем привет, меня зовут Сергей Прощаев. Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech, а также преподаю на курсах разработки и архитектуры в OTUS.

В этой статье расскажу про путь, который многие считают адски сложным: как взять рабочее приложение на Spring Boot и за полчаса доставить его до боевого кластера Kubernetes.

Я часто вижу две крайности. Первая: разработчик пишет отличный код, но дальше слов «нужно собрать jar и задеплоить» начинается туман. Вторая: DevOps-инженер настраивает пайплайны, но не понимает, почему приложение падает в подах, хотя «на машине всё работало».

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

Почему «на моей машине работает» — это проклятие

Знакомая картина? Вы показываете работающий сервис на 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<String> 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) показан сквозной путь от коммита в репозиторий до живого приложения в 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"

Обратите внимание на две детали, которые часто упускают.

Обратите внимание на 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-проектах, где даунтайм даже в минуту означает потерю денег:

1. Stateless приложения. Ваш Spring Boot сервис не должен хранить сессии внутри себя. Иначе при рестарте пода пользователи вылетят. Сессии нужно вынести во внешнее хранилище (например, в Redis). Так при перезапуске любого экземпляра пользователь ничего не заметит.

2. Configuration as Code. Все параметры (адреса баз, ключи) — через ConfigMap и Secrets. Никаких хардкодных значений в application.properties.

3. 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: сборка, контейнеризация, деплой и базовая логика работы в кластере.}