Troubleshooting

☸️ Пошаговое руководство по поиску и устранению неисправностей в Kubernetes – CodhLoopBackOff Pod

by itisgood
written by itisgood

Одна из причин, почему Kubernetes настолько сложен, состоит в том, что устранение неисправностей требует многоуровневого сбора информации.

Это все равно что пытаться найти конец одной струны в запутанном клубке струн.

В этом руководстве я собираюсь рассказать вам об устранении неполадок в состоянии CrashLoopBackOff.

Ваш под может потерпеть неудачу во всех отношениях.

Одним из состояний отказа является CrashLoopBackOff.

Обычно вы увидите это, когда будете выполнять команду kubectl get pods.

Ваш Под может потерпеть неудачу во всех отношениях.

Одним из состояний отказа является CrashLoopBackOff.

Обычно вы можете увидить это, когда будете выполнять kubectl get pods

$ kubectl get pods
NAME                                    READY   STATUS             RESTARTS   AGE
pod-crashloopbackoff-7f7c556bf5-9vc89   1/2     CrashLoopBackOff   35         2h

Что это значит?

Это означает, что ваш под запускается, падает, запускается снова, а затем снова падает.

Шаг первый: опишите под для получения дополнительной информации

Чтобы получить больше информации, вы должны описать под, чтобы получить больше информации:
$ kubectl describe pod pod-crashloopbackoff-7f7c556bf5-9vc89
Name:               pod-crashloopbackoff-7f7c556bf5-9vc89
Namespace:          dev-k8sbot-test-pods
Priority:           0
PriorityClassName:  <none>
Node:               gke-gar-3-pool-1-9781becc-bdb3/10.128.15.216
Start Time:         Tue, 12 Feb 2019 15:11:54 -0800
Labels:             app=pod-crashloopbackoff
                    pod-template-hash=3937112691
Annotations:        <none>
Status:             Running
IP:                 10.44.46.8
Controlled By:      ReplicaSet/pod-crashloopbackoff-7f7c556bf5
Containers:
  im-crashing:
    Container ID:  docker://a3ba2841f39414390b6cbd85fe94932a0f50c2698e68c34d52a5b23cfe73094c
    Image:         ubuntu:18.04
    Image ID:      docker-pullable://ubuntu@sha256:7a47ccc3bbe8a451b500d2b53104868b46d60ee8f5b35a24b41a86077c650210
    Port:          8080/TCP
    Host Port:     0/TCP
    Command:
      /bin/bash
      -ec
      echo 'hello, there...'; sleep 1; echo 'hello, there...'; sleep 1; echo 'exiting with status 0'; exit 1;
    State:          Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Tue, 12 Feb 2019 15:12:47 -0800
      Finished:     Tue, 12 Feb 2019 15:12:49 -0800
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Tue, 12 Feb 2019 15:12:28 -0800
      Finished:     Tue, 12 Feb 2019 15:12:30 -0800
    Ready:          False
    Restart Count:  2
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-csrjs (ro)
  good-container:
    Container ID:   docker://00d634023be399358d9496d557e2cb7501cc5c52ac360d5809c74d4ca3a3b96c
    Image:          gcr.io/google_containers/echoserver:1.0
    Image ID:       docker-pullable://gcr.io/google_containers/echoserver@sha256:6240c350bb622e33473b07ece769b78087f4a96b01f4851eab99a4088567cb76
    Port:           8080/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Tue, 12 Feb 2019 15:12:27 -0800
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-csrjs (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  default-token-csrjs:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-csrjs
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason     Age               From                                     Message
  ----     ------     ----              ----                                     -------
  Normal   Scheduled  56s               default-scheduler                        Successfully assigned dev-k8sbot-test-pods/pod-crashloopbackoff-7f7c556bf5-9vc89 to gke-gar-3-pool-1-9781becc-bdb3
  Normal   Pulling    50s               kubelet, gke-gar-3-pool-1-9781becc-bdb3  pulling image "gcr.io/google_containers/echoserver:1.0"
  Normal   Created    24s               kubelet, gke-gar-3-pool-1-9781becc-bdb3  Created container
  Normal   Pulled     24s               kubelet, gke-gar-3-pool-1-9781becc-bdb3  Successfully pulled image "gcr.io/google_containers/echoserver:1.0"
  Normal   Started    23s               kubelet, gke-gar-3-pool-1-9781becc-bdb3  Started container
  Normal   Pulling    4s (x3 over 55s)  kubelet, gke-gar-3-pool-1-9781becc-bdb3  pulling image "ubuntu:18.04"
  Normal   Created    3s (x3 over 50s)  kubelet, gke-gar-3-pool-1-9781becc-bdb3  Created container
  Normal   Started    3s (x3 over 50s)  kubelet, gke-gar-3-pool-1-9781becc-bdb3  Started container
  Normal   Pulled     3s (x3 over 51s)  kubelet, gke-gar-3-pool-1-9781becc-bdb3  Successfully pulled image "ubuntu:18.04"
  Warning  BackOff    1s (x2 over 19s)  kubelet, gke-gar-3-pool-1-9781becc-bdb3  Back-off restarting failed container
Тут очень много выходных данных.
Первое, на что я бы посмотрел в этом выводе, это Events.
Этот пункт скажет вам, что делает Kubernetes.
Чтение раздела «Events» сверху вниз говорит мне: под был назначен ноде, начинает тянуть образ, запускает этот образ, а затем переходит в это состояние BackOff.
Type     Reason     Age               From                                     Message
----     ------     ----              ----                                     -------
Warning  BackOff    1s (x2 over 19s)  kubelet, gke-gar-3-pool-1-9781becc-bdb3  Back-off restarting failed container
Это сообщение говорит, что контейнере отказывает в перезапуске.
Скорее всего, это означает, что Kubernetes запустил ваш контейнер, а затем контейнер упал.
Как мы все знаем, контейнер Docker должен удерживать и поддерживать pid 1 в рабочем состоянии, или контейнер падает.
Когда контейнер падает, Kubernetes попытается перезапустить его.
После перезапуска несколько раз он объявит его в состояние BackOff.
Тем не менее, Kubernetes будет продолжать пытаться перезапустить его.
$ kubectl get pods
NAME                                    READY   STATUS   RESTARTS   AGE
pod-crashloopbackoff-7f7c556bf5-9vc89   1/2     Error    6          6m

Шаг второй: Посмотрите логи Пода

На этом этапе вы должны изучить логи.

$ kubectl logs pod-crashloopbackoff-7f7c556bf5-9vc89 im-crashing
hello, there...
hello, there...
exiting with status 0
В нашем случае, если вы посмотрите выше на команду, мы выводим некоторый текст и затем завершаем работу, чтобы показать вам эту демонстрацию.
Однако, если у вас было настоящее приложение, это может означать, что ваше приложение по какой-то причине закрывается, и, надеюсь, журналы приложений сообщат вам почему или дадут вам подсказку, почему оно закрывается.

Шаг третий: Посмотрите на Liveness значение

Другая возможность – сбой модуля из-за того, что датчик liveness не возвращает успешный статус.

Он будет находиться в том же состоянии CrashLoopBackOff в выводе get pods, и вы должны описать pod для получения реальной информации.

$ kubectl describe pod pod-crashloopbackoff-liveness-probe-7564df8646-v96tq
Name:               pod-crashloopbackoff-liveness-probe-7564df8646-v96tq
Namespace:          dev-k8sbot-test-pods
Priority:           0
PriorityClassName:  <none>
Node:               gke-gar-3-pool-1-9781becc-bdb3/10.128.15.216
Start Time:         Tue, 12 Feb 2019 15:21:45 -0800
Labels:             app=pod-crashloopbackoff-liveness-probe
                    pod-template-hash=3120894202
Annotations:        <none>
Status:             Running
IP:                 10.44.46.9
Controlled By:      ReplicaSet/pod-crashloopbackoff-liveness-probe-7564df8646
Containers:
  im-crashing:
    Container ID:  docker://e29f6ad6f28b740ad115a6eb3f32267f7067e3c725a92c0a909fbe2ff3aac855
    Image:         ubuntu:18.04
    Image ID:      docker-pullable://ubuntu@sha256:7a47ccc3bbe8a451b500d2b53104868b46d60ee8f5b35a24b41a86077c650210
    Port:          8080/TCP
    Host Port:     0/TCP
    Command:
      /bin/bash
      -ec
      echo 'hello, there...'; sleep 1;
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Tue, 12 Feb 2019 15:22:28 -0800
      Finished:     Tue, 12 Feb 2019 15:22:29 -0800
    Ready:          False
    Restart Count:  2
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-csrjs (ro)
  good-container:
    Container ID:   docker://af6bc7caabd0fc8b682d3cd58d285dd577730492cc9d2ea43d94cf0684e44fb2
    Image:          gcr.io/google_containers/echoserver:1.0
    Image ID:       docker-pullable://gcr.io/google_containers/echoserver@sha256:6240c350bb622e33473b07ece769b78087f4a96b01f4851eab99a4088567cb76
    Port:           8080/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Tue, 12 Feb 2019 15:22:28 -0800
    Last State:     Terminated
      Reason:       Error
      Exit Code:    137
      Started:      Tue, 12 Feb 2019 15:21:47 -0800
      Finished:     Tue, 12 Feb 2019 15:22:27 -0800
    Ready:          True
    Restart Count:  1
    Liveness:       http-get http://:9999/healthz delay=3s timeout=1s period=3s #success=1 #failure=3
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-csrjs (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  default-token-csrjs:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-csrjs
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason     Age                From                                     Message
  ----     ------     ----               ----                                     -------
  Normal   Scheduled  81s                default-scheduler                        Successfully assigned dev-k8sbot-test-pods/pod-crashloopbackoff-liveness-probe-7564df8646-v96tq to gke-gar-3-pool-1-9781becc-bdb3
  Normal   Started    79s                kubelet, gke-gar-3-pool-1-9781becc-bdb3  Started container
  Warning  BackOff    73s (x2 over 74s)  kubelet, gke-gar-3-pool-1-9781becc-bdb3  Back-off restarting failed container
  Warning  Unhealthy  70s (x3 over 76s)  kubelet, gke-gar-3-pool-1-9781becc-bdb3  Liveness probe failed: Get http://10.44.46.9:9999/healthz: dial tcp 10.44.46.9:9999: connect: connection refused
  Normal   Pulling    39s (x3 over 80s)  kubelet, gke-gar-3-pool-1-9781becc-bdb3  pulling image "ubuntu:18.04"
  Normal   Killing    39s                kubelet, gke-gar-3-pool-1-9781becc-bdb3  Killing container with id docker://good-container:Container failed liveness probe.. Container will be killed and recreated.
  Normal   Pulled     38s (x2 over 79s)  kubelet, gke-gar-3-pool-1-9781becc-bdb3  Successfully pulled image "gcr.io/google_containers/echoserver:1.0"
  Normal   Created    38s (x2 over 79s)  kubelet, gke-gar-3-pool-1-9781becc-bdb3  Created container
  Normal   Pulled     38s (x3 over 79s)  kubelet, gke-gar-3-pool-1-9781becc-bdb3  Successfully pulled image "ubuntu:18.04"
  Normal   Created    38s (x3 over 79s)  kubelet, gke-gar-3-pool-1-9781becc-bdb3  Created container
  Normal   Started    38s (x3 over 79s)  kubelet, gke-gar-3-pool-1-9781becc-bdb3  Started container
  Normal   Pulling    38s (x2 over 79s)  kubelet, gke-gar-3-pool-1-9781becc-bdb3  pulling image "gcr.
Еще раз, мы сначала посмотрим на Events.
В нем примерно те же предметы, что и в прошлый раз, но потом мы сталкиваемся с:
Warning  BackOff    73s (x2 over 74s)  kubelet, gke-gar-3-pool-1-9781becc-bdb3  Back-off restarting failed container
Warning  Unhealthy  70s (x3 over 76s)  kubelet, gke-gar-3-pool-1-9781becc-bdb3  Liveness probe failed: Get http://10.44.46.9:9999/healthz: dial tcp 10.44.46.9:9999: connect: connection refused
Kubernetes отказывается от перезапуска контейнера так много раз.
Затем следующее событие сообщает нам, что Liveness показатель не успешен.
Это дает нам указание на то, что мы должны посмотреть на наш Liveness probe.
Либо мы неправильно настроили Liveness probe для нашего приложения, либо он действительно не работает.

Мы должны начать с проверки одного, а затем другого.

Таким образом, ошибка CrashLoopBackOff может быть хитрой, если мы не знаем, где искать, но с помощью нескольких команд и глядя на правильные места, мы можем извлечь кусок информации, который нам нужен, чтобы понять, почему Kubernetes объявляет ошибку..

Затем мы должны протестировать несколько вещей, чтобы убедиться, что все правильно с нашей конфигурацией и / или нашим приложением.

You may also like

⚙️ Решаем ошибку SMB Protocol Negotiation Failed

💻 Обзор самых распространенных поломок ноутбуков

⚙️ Как исправить ошибку “bash: curl: command not...

🐳 Error: can only create exec sessions on...

🐳 Решение ошибки WARNING: IPv4 forwarding is disabled....

🐳 Как решить ошибку “buildx is not a...

⚙️ Как исправить “sudo unable to open read-only...

🐧 Как исправить ошибку: Failed to Download Metadata...

🛠️ qemu не запускается : vnc server started

🛠️ Команда grpck – удаление поврежденных или дублирующихся...

Leave a Comment

Save my name, email, and website in this browser for the next time I comment.