Облачная платформа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
Лог или событие	Возможная причина	Определение неисправности и решение
Логи Pod: код выхода 0	В pod нет процесса.	Проверьте, может ли pod работать корректно. Подробности см. No Process in the Pod (Exit Code: 0).
Событие Kubernetes: Liveness probe failed: Get http… Логи Pod: код выхода 137	Проверка состояния не удалась.	Проверьте, правильно ли настроен liveness probe для pod. Подробности см. Health Check Failed (Exit Code: 137).
Событие Kubernetes: 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: 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 nodes

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

crictl images -v

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

crictl rmi {Image ID}

Docker nodes

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

docker images

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

docker rmi {image-ID}

Note

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

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

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

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

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

Войдите в CCE console и нажмите название кластера, чтобы открыть консоль кластера. В панели навигации выберите Nodes. В правой панели нажмите Nodes tab, найдите строку, содержащую узел, и выберите 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

Devicemapper: 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   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: Добавьте новую ёмкость диска в системный диск Docker.

Расширьте ёмкость 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

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

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

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

 docker   ps -a | grep  $podName

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

 crictl  ps -a | grep   $podName

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

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

 docker   logs  $containerID

Если узел использует 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 в консоли. Значение секрета автоматически шифруется с помощью Base64.

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

echo -n "Content to be encoded" | base64

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

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

Выход команды tail -f xx в команде запуска контейнера (Код выхода: 141)

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

the failed container exited with ExitCode: 141

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

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

Решения

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

Решение 2: Сбросьте node и вместо этого используйте среду выполнения контейнеров Docker.

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

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

Войдите в 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

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

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

Общая проблема 1: Неправильная команда запуска Container

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

Решение

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

Общая проблема 2: "fatal error: procresize: invalid arg" при запуске

После создания рабочей нагрузки она не запускается. В журналах отображается следующая ошибка:

fatal error: procresize: invalid arg
runtime stack:
runtime.throw(0x75be20, 0x17)
	/usr/lib/google-golang/src/runtime/panic.go:530 +0x99
runtime.procresize(0x180, 0x0)
	/usr/lib/google-golang/src/runtime/proc1.go:2735 +0xba6
runtime.schedinit()
	/usr/lib/google-golang/src/runtime/proc1.go:72 +0x110
runtime.rt0_go(0x7ffcd751f9f8, 0x1, 0x7ffcd751f9f8, 0x0, 0x0, 0x1, 0x7ffcd7520b77, 0x0, 0x7ffcd7520b81, 0x7ffcd7520bc3, ...)
	/usr/lib/google-golang/src/runtime/asm_amd64.s:109 +0x132

Согласно журналам ошибок, программа Go падает при запуске, потому что среда выполнения пытается установить GOMAXPROCS на основе видимого количества CPU и вычисляет недопустимое значение из‑за переполнения целого числа. Это происходит, когда количество видимых CPU у container превышает 255 и версия Go равна 1.9 или 1.10. Версия Go в образе — 1.10.

В Go 1.9 и 1.10 среда выполнения использует 8‑битное целое число для хранения количества CPU, которое переполняется при наличии более 255 видимых ядер. Переполненное значение передаётся во внутреннюю функцию procresize, вызывая падение container.

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

cat /sys/fs/cgroup/cpuset/cpuset.cpus

Вывод 0-383, что превышает 255. Это подтверждает причину.

Решение

Используйте один из следующих методов для решения этой проблемы:

Обновите программу Go в образе до версии новее 1.10 (рекомендуется последняя версия). Пересоберите образ и повторно разверните.

Добавьте переменные окружения в файл YAML рабочей нагрузки, чтобы ограничить GOMAXPROCS.

- env:
  - name: GOMAXPROCS
    value: "1"

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

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

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

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

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

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

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