Почему поды имеют статус CrashLoopBackOff?

Question

[dmitkorob]

Есть такой под:

apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    name: myapp
spec:
  containers:
  - name: myapp
    image: linuxcontainers/debian-slim
    resources:
      limits:
        memory: "128Mi"
        cpu: "100m"
      requests:
        memory: "128Mi"
        cpu: "100m"
    volumeMounts:
      - name: localtime
        mountPath: /etc/localtime
  volumes:
    - name: localtime
      hostPath:
        path: /usr/share/zoneinfo/Asia/Taipei
  restartPolicy: Always

После применения kubeclt apply -f pod.yml в kubectl describe myapp происходит так:
Normal Created 26m (x4 over 27m) kubelet Created container myapp
Normal Started 26m (x4 over 27m) kubelet Started container myapp
Normal Pulling 25m (x5 over 27m) kubelet Pulling image "jitesoft/alpine"
Normal Pulled 25m kubelet Successfully pulled image "jitesoft/alpine" in 3.701s
Warning BackOff 2m37s (x113 over 27m) kubelet Back-off restarting failed container myapp in pod myapp_default(dc280bb6-13e3-4921-9dbe-05c6e60a6a96)

Но
если использовать другой образ, например, spec.containers.image:{httpd,nginx} - поды работают корректно (Running).

Answer 1

[paran0id]

kubectl describe pod такой-то - там будет понятно

Comments

[dmitkorob]

Normal Pulled 4s kubelet Successfully pulled image "dockette/ssh" in 1.599s (1.599s including waiting). Image size: 23936262 bytes.
Warning BackOff 3s kubelet Back-off restarting failed container myapp in pod myapp_default(fcabb2f4-4bc0-41c9-a0b3-c86f42c3322a)

Вот что пишет всегда. Образ спулит, но потом рестартует сразу

[Kirils Curilovs]

Попробуйте поменять
image: linuxcontainers/debian-slim
на
linuxcontainers/debian-slim:latest

[paran0id]

kubectl logs -p ваш-под

[paran0id]

и из kubectl describe pod - последнюю причину завершения и последний exit-code

[dmitkorob]

paran0id, то же, что и в первом комментарии я писал. Причина одна и та же с разными образами.

[dmitkorob]

Kirils Curilovs, все также

[paran0id]

Что также? Где stdout/stderr контейнера? Где reason и exit code?

Last State:     Terminated                                                                       
      Reason:       Error                                                                            
      Exit Code:    1

[dmitkorob]

paran0id, как это узнать ?
kubectl logs -p myapp - пусто
kubectl describe pods myapp -
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning BackOff 1s (x365 over 79m) kubelet Back-off restarting failed container myapp in pod myapp_default(6406fa02-9d6a-41a4-9b45-40fcc8b25516)

[dmitkorob]

paran0id, поменял образ на jtcressy/cowsay - pod заработал.
Складывается впечатление, что при создании пода, когда начинает создаваться контейнер, ему не хватает каких-то данных что-ли? Из среды

[paran0id]

Может он с 0 завершается, а рестартится, потому что стоит restartPolicy: Always
Я не помню, какой там у дебиана CMD по дефолту. Будет он работать, если задать command: ['sleep', '999h'] ?

[dmitkorob]

paran0id, да, все оказалось просто. Контейнеры без запущенных процессов завершаются (имеют статус Exited). То есть поды с образами, например, httpd, nginx,cowsay, работали корректно, так как в них был запущенный процесс или процессы, а поды с образами, например, alpine, debian-slim, alma, сразу же завершались, так как по-умолчанию не имели никаких запущенных процессов. Для этого в конф. файле пода нужно указать параметр, например с такими значениями,
command: ['sh', '-c', 'sleep 100']
и тогда контейнер в поде будет в статусе Running в течение 180 сек.

Answer 2

[dmitkorob]

Работающий pod выглядит так
apiVersion: v1
kind: Pod
metadata:
name: "myapp"
namespace: default
labels:
app: "myapp"
spec:
containers:
- name: myapp
image: linuxcontainers/debian-slim:12.5
resources:
limits:
cpu: 100m
memory: 500Mi
requests:
cpu: 100m
memory: 200Mi
command: ['/bin/sh', '-c', 'sleep 180']