Java в Kubernetes: главные отличия от «просто Docker»
Контейнер с JVM чувствителен к CPU throttling и лимитам памяти. В 2025 году для Java 17/21 UseContainerSupport включён по умолчанию, но heap всё равно нужно настраивать осознанно. Вместо жёсткого -Xmx в образе чаще используют -XX:MaxRAMPercentage=75 — так лимиты Pod и JVM остаются согласованными.
Probes: startup, readiness, liveness
Медленный старт Spring Boot — норма. Без startupProbe kubelet может убить Pod раньше, чем приложение поднимется (классический CrashLoopBackOff). Readiness отсекает трафик, пока зависимости не готовы. Liveness должен быть консервативным: рестарт только при реальном зависании, а не при кратковременной деградации БД.
startupProbe:
httpGet: { path: /actuator/health/liveness, port: 8081 }
failureThreshold: 30
periodSeconds: 10
readinessProbe:
httpGet: { path: /actuator/health/readiness, port: 8081 }
periodSeconds: 5
Отдельный management-порт для Actuator (например, 8081) — распространённая практика: бизнес-порт не светит служебные эндпоинты наружу.
Resources: memory request = limit
Память в Kubernetes несжимаема. Для Java обычно ставят requests.memory == limits.memory, чтобы избежать OOMKill из‑за overcommit. С CPU осторожнее: жёсткий limit часто душит GC-потоки. Многие команды в проде оставляют CPU request без жёсткого limit или дают запас ≥ 1–2 ядер на сервис.
Graceful shutdown
При rolling update Pod получает SIGTERM. Нужны:
server.shutdown=gracefulв Spring Boot;preStopsleep на пару секунд, чтобы endpoint успел выпасть из Service;- достаточный
terminationGracePeriodSeconds.
Конфигурация и секреты
ConfigMap — для несекретных настроек, Secret / внешний vault — для паролей и ключей. Не кладите секреты в образ. Для Spring удобны Spring Cloud Kubernetes Config или обычные envFrom + application-prod.yaml в ConfigMap.
Образы
Multi-stage build + slim/distroless JRE, layertools Spring Boot для кэширования слоёв в CI — стандарт индустрии. Non-root user в контейнере — must-have для security policies кластера.
Вывод
Успешный Java-сервис в Kubernetes — это согласованные memory/CPU, корректные probes, graceful shutdown и наблюдаемость. Именно эти темы чаще всего разбирают в продакшен-статьях на Habr и в reference architecture Spring + K8s.
