Что описать в YAML для приложения в Kubernetes

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

Знаете ли вы, из чего состоит рабочий деплой, и не остановитесь ли на манифесте Deployment с именем образа. Интервьюер ждёт, что вы сами вспомните про ресурсы, пробы и конфигурацию, вынесенную из образа.

Как отвечать

Минимум для приложения это Deployment и Service, всё остальное по потребностям. Что описывается:

• Deployment: число реплик, selector.matchLabels, шаблон пода с контейнером, образ по неизменяемому тегу или дайджесту, порты и стратегия обновления с maxSurge и maxUnavailable;
• requests и limits по процессору и памяти: без requests планировщик не знает, куда поставить под, а автоскейлер по процессору не может посчитать загрузку;
• пробы: readinessProbe убирает под из балансировки, пока он не готов, livenessProbe перезапускает зависший процесс, startupProbe даёт время медленному старту;
• конфигурация: ConfigMap и Secret, подключённые через envFrom или том, а не зашитые в образ;
• Service с селектором по меткам подов, а снаружи Ingress, если нужен вход по имени домена.

readinessProbe:
  httpGet: { path: /healthz, port: 8080 }

Хорошо завершить ответ тем, что руками одни и те же манифесты на каждое окружение не пишут: значения выносят в шаблоны, а сами файлы хранят в репозитории рядом с кодом.

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

Ставят плавающий тег вроде latest. Понять, какой образ реально запущен, нельзя, откат невозможен, а перезапуск пода может незаметно подтянуть другую сборку. Нужен тег версии, а лучше дайджест.

Вешают на livenessProbe проверку, которая ходит в базу или в соседний сервис. Зависимость моргнула, и кластер начинает перезапускать совершенно здоровые поды, превращая частичную деградацию в полный отказ. В liveness проверяется только сам процесс, внешние зависимости это забота readiness.

Путают метки. Поле selector у Deployment после создания менять нельзя, а Service находит поды по их меткам, а не по имени Deployment. Разъехавшиеся метки дают сервис без эндпоинтов при том, что поды подняты и выглядят здоровыми.