Часто встречающиеся проблемы и пути их устранения#

Ошибка CreateContainerConfigError#

Эта ошибка обычно возникает из-за отсутствия ConfigMap или secret (объекты DropApp, содержащие конфиденциальные данные, такие как, учетные данные для входа).

Проблема может заключаться в проблеме с аутентификацией в реестре контейнеров или в использовании неправильного имени или тега образа. Можно определить эти проблемы, выполнив соответствующие команды:

  1. Для идентификации проблемы выполните команду:

    kubectl get pods -n [namespace]

    Изучите вывод команды, чтобы определить, имеет ли pod статус CreateContainerConfigError.

  2. Для получения подробной информации по pods и решения проблемы, выполните команду:

    kubectl describe pod [podname] -n [namespace] # здесь может быть указан отсутствующий элемент или ошибка ConfigMap

    Просмотрите поле Events, которое будет содержать события pod, подобные следующему выводу:

    ~ kubectl describe pod [podname] -n [namespace] 

Name:             [podname]
Namespace:        [namespace]
Priority:         0
Service Account:  default
Node:             <node-details>
Start Time:       Wed, 25 Jan 2023 10:00:00 +0100
Labels:           app.DropApp.io/instance=my-service
                  app.DropApp.io/name=my-service
                  pod-template-hash=00000000
Annotations:      <annotations>
Status:           Pending
IP:               
IPs:
  IP:           
Controlled By:  ReplicaSet/
Containers:
  my-service:
    Container ID:
    Image:          <image-name>
    Image ID:
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       CreateContainerConfigError
    Ready:          False
    Restart Count:  0
    Limits:
      cpu:     100m
      memory:  128Mi
    Requests:
      cpu:      100m
      memory:   128Mi
    Liveness:   http-get http://:http/ delay=15s timeout=60s period=60s #success=1 #failure=3
    Readiness:  http-get http://:http/ delay=15s timeout=60s period=60s #success=1 #failure=3
    Environment:
    (...)
      WebJobsStorage:                                                       <set to the key 'JobsStorage' in secret '[namespace]'>                                     Optional: false
      AccessKey:                                                            <set to the key 'AccessKey' in secret '[namespace]'>                                       Optional: false
      TopicEndpoint:                                                        <set to the key 'TopicEndpoint' in secret '[namespace]'>                                   Optional: false
      ClientId:                                                             <set to the key 'ClientId' in secret '[namespace]'>                                        Optional: false
    (...)
    State:          Waiting
    (...)
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  94s                default-scheduler  Successfully assigned [namespace]/ to <node-name>
  Normal   Pulled     94s                kubelet            Successfully pulled image "image" in 165.014261ms
  Warning  Failed     77s (x4 over 94s)  kubelet            Error: couldn't find key ClientId in Secret my-service/my-service
(...)

    В разделе «Events» отображается список всех событий, произошедших в процессе создания pod.

    В приведенном выводе отсутствует secret ClientId, который необходимо запустить.

  3. Запустите эту команду, чтобы увидеть, существует ли ConfigMap в кластере DropApp. Например:

    kubectl get configmap [name]

    Если результатом будет являться null, значит ConfigMap отсутствует, и необходимо его создать.

  4. Убедитесь, что ConfigMap доступен, выполнив команду:

    get configmap [name]

  5. Если необходимо просмотреть содержимое ConfigMap в формате YAML, добавьте флаг -o yaml.

  6. Убедитесь, что ConfigMap существует, выполнив команду:

    kubectl get configmap [name]

  7. Убедитесь, что pod находится в состоянии Running выполнив команду:

    kubectl get pods -n [namespace]

Ошибка CrashLoopBackOff#

Эта ошибка возникает, когда pod не запланирован на node. Это может произойти из-за того, что ресурсов на node недостаточно для запуска pod или pod, которому не удалось подключить запрошенные тома. Исправляется само при перезапуске.

  1. Для идентификации проблемы выполните команду:

    kubectl get pods -n [namespace]

  2. Проверьте результат вывода и определите, имеет ли pod статус CrashLoopBackOff.

  3. Для получения подробной информации и решения проблемы выполните команду:

    kubectl describe pod [name]

    Вывод поможет определить причину проблемы. Ниже приведены общие причины:

    • Недостаточно ресурсов. Если на узле недостаточно ресурсов, можно вручную исключить pods из узла или масштабировать кластер DropApp, чтобы обеспечить доступность дополнительных узлов для pods.

    • Подключение тома. Если видите, что проблема заключается в подключении тома хранилища, проверьте, какой том pod пытается подключить. Убедитесь, что он правильно определен в манифесте pod, и проверьте доступность тома хранилища.

    • Использование hostPort - если pods привязаны к hostPort, можно запланировать только один pod для каждого узла. В большинстве случаев, можно не использовать hostPort, а использовать объект Service для обеспечения связи с pod.

Узел DropApp не готов#

Это происходит, когда рабочий узел завершает работу или происходит сбой, что приводит к недоступности всех pods с отслеживанием состояния, находящихся на node завершения работы. Проблема решается переносом на pods с отслеживанием состояния другого работающего node.

Для устранения неполадок в DropApp pods требуется выполнить следующие шаги:

  • изучите выходные данные команды pods описания kubectl;

  • проверьте наличие ошибки в описании pod;

  • проверьте несоответствие между сервером API и локальным манифестом pod (и диагностируйте другие проблемы pod с помощью журналов pod) и выполните отладку контейнера Exec, отладку контейнера Ephemeral Debug и команду pod отладки на node.