Будешь ли работать с Kubernetes

Что проверяют

Не столько согласие, сколько понимание, что для Java-разработчика означает «работать с Kubernetes». Обычно команда ждёт, что вы сами поправите манифест или Helm-чарт своего сервиса и разберётесь, почему под перезапускается. Следом спрашивают, что вы уже делали руками.

Как отвечать

Ответьте «да» и сразу очертите, какой частью готовы заниматься. Сильный ответ опирается на ваш опыт:

• упаковка: образ через Dockerfile, Jib или spring-boot:build-image, многоэтапная сборка, JRE вместо полного JDK;
• манифесты: Deployment, Service, ConfigMap и Secret для конфигурации, чаще через Helm или Kustomize;
• пробы: Spring Boot Actuator отдаёт /actuator/health/liveness и /actuator/health/readiness, их и вешают на livenessProbe и readinessProbe, а не общий health с проверкой базы;
• память JVM: современные JDK видят лимиты контейнера, размер кучи задают через -XX:MaxRAMPercentage и оставляют запас под metaspace, стеки потоков и off-heap;
• остановка: SIGTERM, корректное завершение (server.shutdown=graceful) и terminationGracePeriodSeconds, чтобы при выкатке не рвались запросы;
• диагностика: kubectl logs, kubectl describe, port-forward, события пода.

Назовите свои примеры: что деплоили, какую проблему нашли и как её решили. Цифры только реальные.

Если опыта нет, так и скажите: работал с Docker и docker-compose, понимаю, что такое под, деплоймент и сервис, готов разобраться с манифестами своего сервиса. Хорошо, если добавите, что уже поднимали локальный кластер в kind или minikube и выкатывали туда своё приложение.

Где спотыкаются

Отвечают «конечно, работал» и не могут объяснить разницу между liveness и readiness. Такой ответ хуже честного «не работал, но готов».

Путают Docker и Kubernetes и рассказывают только про docker run и Dockerfile.

Не знают, почему Java-сервис получает OOMKilled, хотя куча не заполнена. Лимит контейнера считает всю память процесса, а не только -Xmx, и куча в 100% лимита гарантирует падение.