Если pod находится в состоянии Pending, а события содержат информацию, указывающую на ошибку планирования pod, вы можете определить причину на основе событий. Подробности о том, как просматривать события, см. How Can I Locate the Root Cause If a Workload Is Abnormal?
Определите причину на основе событий, перечисленных в Table 1.
Событие | Причина и решение |
|---|---|
no nodes available для планирования pod. | В кластере нет доступных узлов. |
0/2 узлов доступно: 2 Insufficient cpu. 0/2 узлов доступно: 2 Insufficient memory. | Ресурсы (CPUs и memory) на узле недостаточны. Пункт проверки 2: достаточны ли ресурсы Node (CPUs и Memory) |
0/2 nodes are available: 1 node(s) didn't match node selector, 1 node(s) didn't match pod affinity rules, 1 node(s) didn't match pod affinity/anti-affinity. | The node and pod affinity configurations are mutually exclusive. No node meets the pod requirements. Check Item 3: Конфигурация привязки и антипривязки рабочей нагрузки |
0/2 nodes are available: 2 node(s) had volume node affinity conflict. | The EVS volume mounted to the pod and the node are not in the same AZ. Check Item 4: Находятся ли том рабочей нагрузки и узел в одной AZ |
0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate. | There are some taints on the node, and the pod cannot tolerate these taints. |
0/7 nodes are available: 7 Insufficient ephemeral-storage. | The ephemeral storage space on the node is insufficient. |
0/1 nodes are available: 1 everest driver not found at node | The everest-csi-driver on the node is not in the running state. Check Item 7: Работает ли дополнение CCE Container Storage (Everest) корректно |
Failed to create pod sandbox: ... Create more free space in thin pool or use dm.min_free_space option to change behavior | The node thin pool space is insufficient. |
0/1 nodes are available: 1 Too many pods. | The number of pods scheduled to the node exceeds the maximum allowed. Пункт проверки 9: Имеет ли узел слишком много запланированных pod‑ов |
UnexpectedAdmissionError Allocate failed due to not enough cpus available to satisfy request, which is unexpected. | The kubelet static CPU pinning is abnormal due to a known community issue. Пункт проверки 10: Является ли статическое привязывание CPU kubelet аномальным |
Вы можете войти в консоль CCE и проверить, имеет ли статус узла значение Available. Вы также можете использовать следующую команду, чтобы проверить, имеет ли статус узла значение Ready:
$ kubectl get nodeNAME STATUS ROLES AGE VERSION192.168.0.37 Ready <none> 21d v1.19.10-r1.0.0-source-121-gb9675686c54267192.168.0.71 Ready <none> 21d v1.19.10-r1.0.0-source-121-gb9675686c54267
Если статус всех узлов Not Ready, это означает, что в кластере нет доступных узлов.
Решение
0/2 nodes are available: 2 Insufficient cpu. указывает, что CPU недостаточно.
0/2 nodes are available: 2 Insufficient memory. указывает, что память недостаточна.
Если ресурсы, запрашиваемые pod, превышают выделяемые ресурсы на узле, где pod будет запускаться, планирование pod на этот узел обязательно завершится неудачей из‑за недостатка ресурсов узла.
Если на узле выделяемых ресурсов меньше, чем запрашивает pod, планирование pod завершится неудачей.
Решение
Добавьте больше узлов в кластер. Масштабирование наружу является обычным решением при недостатке ресурсов.
Несоответствующие политики affinity приведут к неудаче планирования pod.
Например, для рабочей нагрузки 1 и рабочей нагрузки 2 настроена политика anti-affinity. Они работают на узлах 1 и 2 соответственно.
Если вы попытаетесь настроить политику affinity для рабочей нагрузки 3 и рабочей нагрузки 2, а затем развернёте рабочую нагрузку 3 на узле, отличном от того, где размещена рабочая нагрузка 2, например на узле 1, это вызовет конфликт и приведёт к ошибке развертывания рабочей нагрузки.
0/2 nodes are available: 1 node(s) didn't match node selector, 1 node(s) didn't match pod affinity rules, 1 node(s) didn't match pod affinity/anti-affinity.
Решение
No nodes are available that match all of the following predicates: MatchNode Selector, NodeNotSupportsContainer
Если значение false, планирование pod завершится неудачей.
0/2 nodes are available: 2 node(s) had volume node affinity conflict. указывает, что конфликт аффинности возник между томом, смонтированным в pod, и узлом‑хостом. В результате планирование pod завершается неудачей.
Это происходит потому, что диски EVS нельзя подключать к узлам в разных AZ, отличных от AZ дисков EVS. Например, pod workload с томом EVS, находящимся в AZ 1, нельзя запланировать на узел в AZ 2.
Созданные в CCE тома EVS имеют настройки аффинности по умолчанию, как показано ниже.
kind: PersistentVolumeapiVersion: v1metadata:name: pvc-c29bfac7-efa3-40e6-b8d6-229d8a5372acspec:...nodeAffinity:required:nodeSelectorTerms:- matchExpressions:- key: failure-domain.beta.kubernetes.io/zoneoperator: Invalues:-
Решение
В AZ, где находится узел workload, создайте том. Либо создайте идентичный workload и выберите автоматически назначенный том облачного хранилища.
0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate. указывает, что на узле присутствуют некоторые taint, и pod не может их терпеть.
В этом случае можно проверить taint на узле. Если отображается информация, аналогичная следующей, на узле присутствуют некоторые taint:
$ kubectl describe node 192.168.0.37Name: 192.168.0.37...Taints: key1=value1:NoSchedule...
В некоторых случаях система автоматически добавляет таинт к узлу. Встроенные таинты включают:
Решение
Чтобы запланировать pod на узел, используйте любой из следующих методов:
apiVersion: v1kind: Podmetadata:name: nginxspec:containers:- name: nginximage: nginx:alpinetolerations:- key: "key1"operator: "Equal"value: "value1"effect: "NoSchedule"
0/7 nodes are available: 7 Insufficient ephemeral-storage. указывает, что на узле недостаточно места для временного хранилища.
В этом случае вы можете проверить, ограничено ли пространство временного тома pod‑ом. Если требуемое приложением пространство временного тома превышает существующую емкость на узле, приложение не может быть запланировано на этот узел. Чтобы решить эту проблему, измените пространство временного тома или увеличьте емкость диска на узле.
apiVersion: v1kind: Podmetadata:name: frontendspec:containers:- name: appimage: images.my-company.example/app:v4resources:requests:ephemeral-storage: "2Gi"limits:ephemeral-storage: "4Gi"volumeMounts:- name: ephemeralmountPath: "/tmp"volumes:- name: ephemeralemptyDir: {}
Чтобы получить общую емкость (Capacity) и доступную емкость (Allocatable) временных томов на узле, выполните команду kubectl describe node и проверьте запрос памяти и ограничение выделенного временного тома на узле.
Ниже приведён пример вывода:
...Capacity:cpu: 4ephemeral-storage: 61607776Kihugepages-1Gi: 0hugepages-2Mi: 0localssd: 0localvolume: 0memory: 7614352Kipods: 40Allocatable:cpu: 3920mephemeral-storage: 56777726268hugepages-1Gi: 0hugepages-2Mi: 0localssd: 0localvolume: 0memory: 6180752Kipods: 40...Allocated resources:(Total limits may be over 100 percent, i.e., overcommitted.)Resource Requests Limits-------- -------- ------cpu 1605m (40%) 6530m (166%)memory 2625Mi (43%) 5612Mi (92%)ephemeral-storage 0 (0%) 0 (0%)hugepages-1Gi 0 (0%) 0 (0%)hugepages-2Mi 0 (0%) 0 (0%)localssd 0 0localvolume 0 0Events: <none>
0/1 nodes are available: 1 everest driver not found at node указывает на то, что everest-csi-driver из CCE Container Storage (Everest) не запущен корректно на узле.
В этом случае вы можете проверить демон с именем everest-csi-driver в пространстве имён kube-system и убедиться, запущен ли pod корректно. Если нет, удалите pod. Демон перезапустит другой pod.
Для kubelet и среды выполнения контейнеров будет подключён отдельный Диск с данными к новому узлу. Если пространство Диска с данными недостаточно, pod не может быть создан на узле.
Решение 1: Очистка образов
Выполните следующие действия для очистки неиспользуемых образов: Не удаляйте системные образы, такие как cce-pause image. В противном случае создание pod может завершиться ошибкой.
Решение 2: Расширение ёмкости диска
Чтобы расширить ёмкость диска, выполните следующие операции:
Расширяется только ёмкость хранилища дисков EVS. Для расширения ёмкости логических томов и файловых систем необходимо выполнить следующие операции.
A data disk is divided depending on the container storage Rootfs:
0/1 nodes are available: 1 Too many pods. указывает, что на узел запланировано чрезмерное количество Pods.
При создании узла настройте Max. Pods в области Advanced Settings, чтобы указать максимальное количество Pods, которое может корректно работать на узле. Значение по умолчанию зависит от флейвора узла. При необходимости вы можете изменить значение.
На странице Nodes получите значение Pods (Allocated/Total Available Addresses/Total) узла и проверьте, достигло ли количество запланированных Pods на узле верхнего предела. Если да, добавьте узлы или измените максимальное количество Pods.
Чтобы изменить максимальное количество Pods, которое может работать на узле, выполните следующее:
Если pod имеет init‑container с запросом CPU, отличающимся от настроек основного контейнера, и ему назначен класс QoS Guaranteed, в то время как kubelet использует статическое закрепление CPU (с параметром cpuManagerPolicy, установленным в static), планирование pod может завершиться неудачей, что приводит к ошибке UnexpectedAdmissionError.
Проблема, связанная с сообществом: https://github.com/kubernetes/kubernetes/issues/112228
Решение
Установите запрос CPU для init‑container в десятичное значение, соответствующее ограничению CPU, и избегайте использования закрепления CPU.
Например: основной контейнер: {"limits":{"cpu":"7","memory":"60G"},"requests":{"cpu":"7","memory":"60G"}}; init‑container: {"limits":{"cpu":"6.9","memory":"60G"},"requests":{"cpu":"6.9","memory":"60G"}}