Ответ
Pod может перейти в состояние Error (CrashLoopBackOff) или быть завершенным по нескольким основным причинам:
- Завершение основного процесса контейнера: Если процесс с PID 1 в контейнере завершается с ненулевым кодом выхода. Kubernetes перезапустит контейнер согласно политике
restartPolicy. - OOMKill (Out Of Memory): Если контейнер превысит свой лимит памяти (
limits.memory), ядро Linux убьет процесс. В событиях Pod будетOOMKilled. - Неудачные пробы (Probes):
- Liveness Probe: После
failureThresholdнеудачных проверок контейнер будет убит и перезапущен. - Startup Probe: Если проба не завершится успешно за отведенное время, контейнер будет убит, подчиняясь политике перезапуска.
- Liveness Probe: После
- Сбой Init Container: Если любой init-контейнер завершится с ошибкой, Pod не запустится и останется в состоянии
Init:Error. - Проблемы с нодой (Node):
- Eviction: Kubelet может выселить Pod с ноды при нехватке ресурсов (DiskPressure, MemoryPressure).
- Node Failure: Если нода становится недоступной, контроллер репликации (например, Deployment) создаст новый Pod на другой ноде.
- Ошибки при работе с образами: Не удалось вытянуть образ (
ImagePullBackOff) из-за неверного имени, отсутствия прав в registry или проблем с сетью. - Ошибки конфигурации: Некорректные монтирования томов (например, ссылка на несуществующий PersistentVolumeClaim), проблемы с SecurityContext (например, попытка запуска от root при запрете).
Пример, приводящий к падению из-за liveness probe:
apiVersion: v1
kind: Pod
metadata:
name: liveness-example
spec:
containers:
- name: app
image: myapp:v1
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 3
periodSeconds: 3
failureThreshold: 2 # После 2 неудачных проверок контейнер будет убит
resources:
limits:
memory: "128Mi" # Превышение этого лимита вызовет OOMKill