Напишите манифест Kubernetes: Deployment на 3 реплики с пробами и ресурсами плюс Service. Объясните, зачем нужны liveness и readiness probes.
Короткий ответ
- Deployment: selector должен совпадать с labels шаблона пода
- Readiness управляет попаданием пода в endpoints Service
- Liveness перезапускает зависший контейнер
- Неверная liveness вызывает каскадные рестарты
- Requests и limits обязательны для планирования и QoS
- Service связывается с подами через selector по лейблам
Рабочий минимум прода — Deployment с пробами и ресурсами и Service, находящий поды по лейблам.
Как сказать вслух
пример ответаDeployment описывает три реплики пода, где селектор обязан совпадать с лейблами шаблона, иначе манифест не применится. Readiness-проба решает, готов ли под принимать трафик: пока она не прошла, Service не шлёт на него запросы — это критично при старте и деплое. Liveness-проба перезапускает действительно зависший контейнер, и её надо делать осторожно, иначе при деградации зависимостей начнутся каскадные рестарты. Service находит поды по тем же лейблам и балансирует трафик на готовые реплики.
Подробный ответ
Основной ответ
Связки в манифесте: spec.selector.matchLabels Deployment совпадает с template.metadata.labels, и те же лейблы использует selector Service — так трафик находит поды. Readiness probe определяет участие пода в endpoints: не прошла — под исключается из балансировки, но не перезапускается; это обеспечивает плавный rolling update вместе с maxUnavailable. Liveness probe при серии неудач перезапускает контейнер — проверка должна отражать только «процесс завис», без обращения к внешним зависимостям, иначе недоступность базы уложит все реплики рестартами. Для медленного старта есть startupProbe. Ресурсы: requests для планирования, limits как потолок. Service типа ClusterIP — внутренняя точка входа; наружу — Ingress или LoadBalancer.
Ключевые моменты
- Readiness vs liveness. Readiness управляет трафиком, liveness — перезапуском; путать их — самая дорогая ошибка в проде.
- Селекторы и лейблы. Три места должны быть согласованы: selector Deployment, лейблы шаблона и selector Service.
- Пробы без внешних зависимостей. Liveness не должна зависеть от БД и соседних сервисов, иначе каскадные рестарты при любой деградации.
- Ресурсы в шаблоне. Без requests невозможно корректное планирование, без limits по памяти — защита ноды от утечек.
Практический контекст
Написать или починить такой манифест просят на большинстве практических секций по Kubernetes. В работе это буквально ежедневный артефакт — через Helm или Kustomize, но понимать «сырой» YAML обязательно. Частые реальные баги, которые проверяют на интервью: расхождение селекторов, liveness с проверкой базы данных, отсутствие readiness, из-за чего трафик идёт на неготовые поды при деплое.
Пример кода
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
replicas: 3
selector:
matchLabels: {app: api}
template:
metadata:
labels: {app: api}
spec:
containers:
- name: api
image: registry.local/api:1.4.2
ports: [{containerPort: 8000}]
resources:
requests: {cpu: 100m, memory: 256Mi}
limits: {memory: 256Mi}
readinessProbe:
httpGet: {path: /ready, port: 8000}
periodSeconds: 5
livenessProbe:
httpGet: {path: /healthz, port: 8000}
initialDelaySeconds: 10
periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
name: api
spec:
selector: {app: api}
ports: [{port: 80, targetPort: 8000}]Частые ошибки
- Путают назначение liveness и readiness или делают их одинаковыми
- Селектор Service не совпадает с лейблами подов — «сервис не работает»
- Liveness-проба ходит во внешнюю зависимость и вызывает каскадные рестарты