Облачная платформаAdvanced

Что делать, если запуск Pod не удался?

Эта статья полезна?

Язык статьи: Русский

Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

Поиск неисправности

На странице сведений о рабочей нагрузке, если отображается событие, указывающее, что pod не удалось запустить, выполните следующие действия для поиска неисправности:

Войдите в узел, где находится аномальная рабочая нагрузка.

Проверьте ID контейнера, в котором pod рабочей нагрузки завершается аномально.

Если узел использует Docker, выполните следующую команду:

 docker   ps -a | grep  $podName

Если узел использует containerd, выполните следующую команду:

 crictl  ps -a | grep   $podName

Просмотрите журналы контейнера.

Если узел использует Docker, выполните следующую команду:

 docker   logs  $containerID

Если узел использует containerd, выполните следующую команду:

 crictl logs  $containerID

Исправьте неисправность рабочей нагрузки на основе журналов.

Проверьте журналы ошибок ОС. Например, проверьте, содержат ли журналы ошибки OOM.

 cat /var/log/messages | grep  $containerID   | grep oom

Проверьте, был ли вызван системный OOM на основе журналов.

Устранение неполадок

Определите причину на основе журналов или событий, как указано в Table 1.

Table 1 Pod startup failure
Журнал или событие	Возможная причина	Поиск неисправности и решение
Pod logs: exit code 0	В поде нет процесса.	Проверьте, может ли pod работать корректно. Для подробностей см. No Process in the Pod (Exit Code: 0).
Kubernetes event: Liveness probe failed: Get http… Pod logs: exit code 137	Проверка состояния не прошла.	Проверьте, правильно ли настроен liveness probe для pod. Для подробностей см. Health Check Failed (Exit Code: 137).
Kubernetes event: Thin Pool has 15991 free data blocks which is less than minimum required 16383 free data blocks. Create more free space in thin pool or use dm.min_free_space option to change behavior Pod logs: no left space	Недостаточно места на диске.	Увеличьте объём диска или удалите ненужные файлы. Для подробностей см. Insufficient Disk Space of the Pod.
Pod logs: oom	Недостаточно памяти pod.	Проверьте, имеет ли pod правильные настройки ресурсов. Для получения подробной информации см. Insufficient Container Resources.
Pod logs: Address already in use	В pod возникает конфликт между портами контейнеров.	Проверьте, существует ли конфликт портов контейнеров в pod. Для получения подробной информации см. Container Port Conflict in the Pod.
Kubernetes event: Error: failed to start container "filebeat": Error response from daemon: OCI runtime create failed: container_linux.go:330: starting container process caused "process_linux.go:381: container init caused \"setenv: invalid argument\"": unknown	Секрет монтируется к рабочей нагрузке, и значение секрета не зашифровано с использованием Base64.	Для получения подробной информации о решении см. Improper Value of the Secret Mounted to the Workload.
Kubernetes event: the failed container exited with ExitCode: 255	Контейнерный образ x86 может работать на узле Arm.	Для получения подробной информации о решении см. Unmatched Container Image Tag with the Node Architecture.
Kubernetes event: the failed container exited with ExitCode: 141	Версия containerd несовместима с версией tail.	Для получения подробной информации о решении см. Exit of tail -f xx in the Container Startup Command (Exit Code: 141).
Other pod logs	Локализуйте неисправность на основе сервисов.	Для получения подробной информации о локализации неисправности см. Service Setting Checks.

No Process in the Pod (Exit Code: 0)

Войдите в узел, где находится аномальная рабочая нагрузка.

Просмотрите статус pod.

Если узел использует Docker, выполните следующую команду:

 docker   ps -a | grep  $podName

Если узел использует containerd, выполните следующую команду:

 crictl  ps -a | grep   $podName

Ниже приведён пример.

Если в pod нет процесса, отображается код статуса Exited (0).

Health Check Failed (Exit Code: 137)

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

Если для рабочей нагрузки настроен liveness probe и количество неудачных проверок состояния превышает порог, pod будет перезапущен. На странице сведений о рабочей нагрузке, если события Kubernetes содержат Liveness probe failed: Get http..., проверка состояния не проходит.

Решение

Нажмите имя рабочей нагрузки, чтобы перейти на страницу сведений о рабочей нагрузке, нажмите вкладку Containers. Затем выберите Health Check, чтобы проверить, корректна ли политика и правильно ли работают сервисы.

Недостаточно места на диске Pod

Следующее сообщение относится к thin pool диску, который выделяется из Docker диска, выбранного при создании узла. Вы можете выполнить команду lvs от пользователя root для просмотра текущего использования диска.

Thin Pool has 15991 free data blocks which is less than minimum required 16383 free data blocks. Create more free space in thin pool or use dm.min_free_space option to change behavior

Решение

Решение 1: Очистка образов

Выполните следующие действия для очистки неиспользуемых образов:

Узлы, использующие containerd

Получите локальные образы на узле.

crictl images -v

Удалите ненужные образы по ID образа.

crictl rmi {Image ID}

Узлы, использующие Docker

Получите локальные образы на узле.

docker images

Удалите ненужные образы по ID образа.

docker rmi {image-ID}

Note

Не удаляйте системные образы, такие как образ cce-pause. В противном случае создание pod может завершиться ошибкой.

Решение 2: Расширение ёмкости диска

Чтобы расширить ёмкость диска, выполните следующие действия:

Увеличьте ёмкость диска с данными в консоли EVS.

Только ёмкость хранилищ EVS‑дисков может быть увеличена. Необходимо выполнить следующие операции для расширения ёмкости логических томов и файловых систем.

Войдите в CCE console и нажмите название кластера, чтобы открыть консоль кластера. В панели навигации выберите Nodes. В правой панели нажмите вкладку Nodes, найдите строку, содержащую узел, и выберите More > Sync Server Data в столбце Operation.

Войдите в узел.

Выполните lsblk, чтобы просмотреть информацию о блочных устройствах узла.

Диск с данными делится в зависимости от контейнерного хранилища Rootfs:

Overlayfs: независимый thin pool не выделяется. Данные образа хранятся в dockersys.

Проверьте ёмкость диска и разделов устройства.

# lsblk
NAME                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                   8:0    0   50G  0 disk 
└─sda1                8:1    0   50G  0 part /
 sdb                    8:16   0  150G  0 disk      # The data disk has been expanded to 150 GiB, but 50 GiB space is free.
├─ vgpaas-dockersys   253:0    0   90G  0 lvm  /var/lib/containerd
└─vgpaas-kubernetes 253:1    0   10G  0 lvm  /mnt/paas/kubernetes/kubelet

Увеличьте ёмкость диска.

Добавьте новую ёмкость диска в логический том dockersys, используемый средой выполнения контейнеров.

Увеличьте ёмкость PV, чтобы LVM мог обнаружить новую ёмкость EVS. /dev/sdb указывает физический том, где находится dockersys.

pvresize /dev/sdb

Отображается информация, аналогичная следующей:

Physical volume "/dev/sdb" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized

Увеличьте свободную ёмкость на 100 % до логического тома. vgpaas/dockersys указывает логический том, используемый средой выполнения контейнеров.

lvextend -l+100%FREE -n vgpaas/dockersys

Отображается информация, аналогичная следующей:

Size of logical volume vgpaas/dockersys changed from <90.00 GiB (23039 extents) to 140.00 GiB (35840 extents).
Logical volume vgpaas/dockersys successfully resized.

Отрегулируйте ёмкость файловой системы. /dev/vgpaas/dockersys указывает путь к файловой системе среды выполнения контейнеров.

resize2fs /dev/vgpaas/dockersys

Отображается информация, аналогичная следующей:

Filesystem at /dev/vgpaas/dockersys is mounted on /var/lib/containerd; on-line resizing required
old_desc_blocks = 12, new_desc_blocks = 18
The filesystem on /dev/vgpaas/dockersys is now 36700160 blocks long.

Проверьте, расширена ли ёмкость.

# lsblk
NAME                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                   8:0    0   50G  0 disk 
└─sda1                8:1    0   50G  0 part /
 sdb                    8:16   0  150G  0 disk
├─ vgpaas-dockersys   253:0    0   140G  0 lvm  /var/lib/containerd
└─vgpaas-kubernetes 253:1    0   10G  0 lvm  /mnt/paas/kubernetes/kubelet

Device Mapper: Тонкий пул выделен для хранения данных образа.

Проверьте ёмкость диска и разделов устройства.

# lsblk
NAME                                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda                                   8:0    0   50G  0 disk 
└─vda1                                8:1    0   50G  0 part /
 vdb                                    8:16   0  200G  0 disk 
├─ vgpaas-dockersys                   253:0    0   18G  0 lvm  /var/lib/docker    
├─vgpaas-thinpool_tmeta             253:1    0    3G  0 lvm                   
│ └─ vgpaas-thinpool                  253:3    0   67G  0 lvm                   # Space used by thin pool
│   ...
├─vgpaas-thinpool_tdata             253:2    0   67G  0 lvm  
│ └─vgpaas-thinpool                 253:3    0   67G  0 lvm  
│   ...
└─vgpaas-kubernetes                 253:4    0   10G  0 lvm  /mnt/paas/kubernetes/kubelet

Расширьте ёмкость диска.

Option 1: Добавьте новую ёмкость диска в thin pool.

Расширьте ёмкость PV, чтобы LVM мог определить новую ёмкость EVS. /dev/vdb указывает физический том, где расположен thin pool.

pvresize /dev/vdb

Отображается информация, аналогичная следующей:

Physical volume "/dev/vdb" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized

Расширьте 100 % свободной ёмкости до логического тома. vgpaas/thinpool указывает логический том, используемый средой выполнения контейнеров.

lvextend -l+100%FREE -n vgpaas/thinpool

Отображается информация, аналогичная следующей:

Size of logical volume vgpaas/thinpool changed from <67.00 GiB (23039 extents) to <167.00 GiB (48639 extents).
Logical volume vgpaas/thinpool successfully resized.

Не изменяйте ёмкость файловой системы, так как thin pool не смонтирован ни на какие устройства.

Запустите команду lsblk, чтобы проверить ёмкость диска и разделов устройства и убедиться, расширена ли ёмкость. Если новая ёмкость диска добавлена в thin pool, ёмкость расширена.

# lsblk
NAME                                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda                                   8:0    0   50G  0 disk 
└─vda1                                8:1    0   50G  0 part /
 vdb                                    8:16   0  200G  0 disk 
├─vgpaas-dockersys                  253:0    0   18G  0 lvm  /var/lib/docker    
├─vgpaas-thinpool_tmeta             253:1    0    3G  0 lvm                   
│ └─ vgpaas-thinpool                  253:3    0   167G  0 lvm             # Thin pool space after capacity expansion
│   ...
├─vgpaas-thinpool_tdata             253:2    0   67G  0 lvm  
│ └─vgpaas-thinpool                 253:3    0   67G  0 lvm  
│   ...
└─vgpaas-kubernetes                 253:4    0   10G  0 lvm  /mnt/paas/kubernetes/kubelet

Option 2: Add the new disk capacity to the dockersys disk.

Расширьте ёмкость PV, чтобы LVM мог определить новую ёмкость EVS. /dev/vdb указывает физический том, где расположен dockersys.

pvresize /dev/vdb

Отображается информация, аналогичная следующей:

Physical volume "/dev/vdb" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized

Расширьте 100 % свободной ёмкости до логического тома. vgpaas/dockersys указывает логический том, используемый средой выполнения контейнеров.

lvextend -l+100%FREE -n vgpaas/dockersys

Отображается информация, аналогичная следующей:

Size of logical volume vgpaas/dockersys changed from <18.00 GiB (4607 extents) to <118.00 GiB (30208 extents).
Logical volume vgpaas/dockersys successfully resized.

Отрегулируйте ёмкость файловой системы. /dev/vgpaas/dockersys указывает путь к файловой системе среды выполнения контейнера.

resize2fs /dev/vgpaas/dockersys

Отображается информация, аналогичная следующей:

Filesystem at /dev/vgpaas/dockersys is mounted on /var/lib/docker; on-line resizing required
old_desc_blocks = 3, new_desc_blocks = 15
The filesystem on /dev/vgpaas/dockersys is now 30932992 blocks long.

Запустите команду lsblk, чтобы проверить ёмкость диска и разделов устройства и убедиться, расширена ли ёмкость. Если новая ёмкость диска была добавлена в dockersys, ёмкость расширена.

# lsblk
NAME                                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda                                   8:0    0   50G  0 disk 
└─vda1                                8:1    0   50G  0 part /
 vdb                                    8:16   0  200G  0 disk 
├─ vgpaas-dockersys                   253:0    0   118G  0 lvm  /var/lib/docker     # dockersys after capacity expansion
├─vgpaas-thinpool_tmeta             253:1    0    3G  0 lvm                   
│ └─vgpaas-thinpool                 253:3    0   67G  0 lvm             
│   ...
├─vgpaas-thinpool_tdata             253:2    0   67G  0 lvm  
│ └─vgpaas-thinpool                 253:3    0   67G  0 lvm  
│   ...
└─vgpaas-kubernetes                 253:4    0   10G  0 lvm  /mnt/paas/kubernetes/kubelet

Insufficient Container Resources

Если достигнут верхний предел ресурсов контейнера, OOM будет отображён в деталях события, а также в журнале:

cat /var/log/messages | grep 96feb0a425d6 | grep oom

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

Container Port Conflict in the Pod

Войдите в node, где находится аномальная рабочая нагрузка.

Проверьте ID контейнера, в котором pod рабочей нагрузки завершается аномально.

Если node использует Docker, запустите следующую команду:

 docker   ps -a | grep  $podName

Если node использует containerd, запустите следующую команду:

 crictl  ps -a | grep   $podName

Просмотрите журналы контейнера.

Если node использует Docker, запустите следующую команду:

 docker   logs  $containerID

Если node использует containerd, запустите следующую команду:

 crictl logs  $containerID

Устраните ошибку рабочей нагрузки на основе журналов. Как показано на следующем рисунке, порты контейнеров в одном pod конфликтуют. В результате контейнер не может быть запущен.

Рисунок 1 Сбой перезапуска pod из‑за конфликта порта контейнера

Решение

Настройте корректные порты контейнеров, которые не конфликтуют друг с другом. Затем создайте рабочую нагрузку заново.

Если pod использует host network (с параметром hostNetwork: true), может возникнуть конфликт порта контейнера. Это происходит потому, что контейнеры в pod разделяют сетевой интерфейс и диапазон портов с узлом‑хостом. Несколько pod, использующих один и тот же порт, не могут работать на одном узле.

Неправильное значение Secret, монтируемого в рабочую нагрузку

В событии отображается информация, аналогичная следующей:

Error: failed to start container "filebeat": Error response from daemon: OCI runtime create failed: container_linux.go:330: starting container process caused "process_linux.go:381: container init caused \"setenv: invalid argument\"": unknown

Коренной причиной является монтирование секрета в рабочую нагрузку, но значение секрета не зашифровано с помощью Base64.

Решение

Создайте Secret в консоли. Значение Secret автоматически шифруется с помощью Base64.

Если вы используете YAML для создания Secret, необходимо вручную зашифровать его значение с помощью Base64.

echo -n "Content to be encoded" | base64

Несоответствующий тег образа контейнера архитектуре узла

При создании рабочей нагрузки на узле Arm не используется корректный тег образа. Чтобы решить проблему, используйте правильный тег образа.

Выход команды tail -f xx в Container Startup Command (Код выхода: 141)

Событие Kubernetes выглядит следующим образом:

the failed container exited with ExitCode: 141

Возможная причина

Устаревшая версия containerd несовместима с версией tail (≥ 8.28) в образе контейнера. В результате выполнение команды tail -f приводит к неожиданному завершению, возвращая код выхода 141.

Временное решение

Измените tail -f xx в параметрах запуска на sleep 2 && tail -f xx и создайте рабочую нагрузку заново.

Решение

Обновите кластер до версии v1.25.16-r20, v1.27.16-r20, v1.28.15-r10, v1.29.10-r10, v1.30.6-r10, v1.31.4-r0 или более новой.

Сбросьте узел и вместо этого используйте контейнерный runtime Docker.

Проверка настроек сервиса

Проверьте, правильно ли выполняется команда запуска рабочей нагрузки или есть ли в ней ошибка.

Войдите в узел, где находится аномальная рабочая нагрузка.

Проверьте ID контейнера, в котором pod рабочей нагрузки завершается аномально.

Если узел использует Docker, выполните следующую команду:

 docker   ps -a | grep  $podName

Если узел использует containerd, выполните следующую команду:

 crictl  ps -a | grep   $podName

Просмотрите логи контейнера.

Если узел использует Docker, выполните следующую команду:

 docker   logs  $containerID

Если узел использует containerd, выполните следующую команду:

 crictl logs  $containerID

Примечание: В предыдущей команде containerID указывает идентификатор контейнера, который завершил работу.

Figure 2 Неправильная команда запуска контейнера

Как показано на рисунке выше, контейнер не запускается из‑за неправильной команды запуска. Для других ошибок исправьте баги, основываясь на журналах.

Решение

Создайте новый workload и настройте правильную команду запуска.

Родительская тема: Workload Exception Troubleshooting

Предыдущая статья

Что делать, если Pod не может загрузить Image?

Следующая статья

Что делать, если Pod не может быть выселен?

Эта статья полезна?

Поддержка Юридические документы Политика конфиденциальности