Если pod находится в состоянии Pending и события содержат информацию, указывающую на сбой планирования pod, вы можете определить причину на основе событий. Подробности о том, как просматривать события, см. How Can I Locate the Root Cause If a Workload Is Abnormal?
Определите причину на основе событий, перечисленных в Table 1.
Событие | Причина и решение |
|---|---|
no nodes available для планирования pods. | В кластере нет доступных узлов. |
0/2 узлов доступно: 2 Insufficient cpu. 0/2 узлов доступно: 2 Insufficient memory. | Ресурсы (CPU и память) на узле недостаточны. |
0/2 узлов доступно: 1 узел(ов) didn't match node selector, 1 узел(ов) didn't match pod affinity rules, 1 узел(ов) didn't match pod affinity/anti-affinity. | Конфигурации node и pod affinity являются взаимно исключающимися. Ни один узел не удовлетворяет требованиям pod. Пункт проверки 3: Конфигурация Affinity и Anti-Affinity рабочей нагрузки |
0/2 узлов доступно: 2 узел(ов) had volume node affinity conflict. | Том EVS, смонтированный к pod, и узел находятся в разных AZ. Пункт проверки 4: Находятся ли том Workload и узел в одной AZ |
0/1 узлов доступно: 1 узел(ов) had taints that the pod didn't tolerate. | На узле есть некоторые taints, и pod не может их терпеть. |
0/7 узлов доступно: 7 Insufficient ephemeral-storage. | Эфемерное пространство хранения на узле недостаточно. |
0/1 узлов доступно: 1 everest driver not found at node | everest-csi-driver на узле не находится в рабочем состоянии. Пункт проверки 7: Работает ли дополнение CCE Container Storage (Everest) корректно |
Failed to create pod sandbox: ... Создайте больше свободного места в thin pool или используйте параметр dm.min_free_space, чтобы изменить поведение | 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 завершится неудачей.
Решение
Добавьте больше узлов в кластер. Scale-out является распространённым решением при недостатке ресурсов.
Несоответствующие политики affinity приведут к неудаче планирования pod.
Например, для рабочей нагрузки 1 и рабочей нагрузки 2 настроена политика anti-affinity. Они работают на узле 1 и узле 2 соответственно.
Если вы попытаетесь настроить политику affinity для рабочей нагрузки 3 и рабочей нагрузки 2, а затем развернёте рабочую нагрузку 3 на узле, отличном от того, где размещена рабочая нагрузка 2, например на узле 1, это вызовет конфликт и приведёт к ошибке развертывания рабочей нагрузки.
0/2 nodes are available: 1 node(s) не соответствует node selector, 1 node(s) не соответствует pod affinity rules, 1 node(s) не соответствует 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. indicates that an affinity conflict occurs between the volume mounted to the pod and the host node. As a result, the pod scheduling fails.
Это происходит потому, что диски EVS нельзя подключать к узлам, находящимся в разных AZ от дисков EVS. Например, pod рабочей нагрузки с томом EVS в AZ 1 не может быть запланирован на узел в AZ 2.
По умолчанию тома EVS, созданные в CCE, имеют настройки affinity, как показано ниже.
kind: PersistentVolumeapiVersion: v1metadata:name: pvc-c29bfac7-efa3-40e6-b8d6-229d8a5372acspec:...nodeAffinity:required:nodeSelectorTerms:- matchExpressions:- key: failure-domain.beta.kubernetes.io/zoneoperator: Invalues:-
Решение
В AZ, где находится узел рабочей нагрузки, создайте том. Либо создайте идентичную рабочую нагрузку и выберите автоматически назначенный том облачного хранилища.
0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate. indicates that there are some taints on the node, and the pod cannot tolerate these taints.
В этом случае вы можете проверить taints на узле. Если отображается информация, похожая на следующую, на узле присутствуют некоторые taints:
$ kubectl describe node 192.168.0.37Name: 192.168.0.37...Taints: key1=value1:NoSchedule...
В некоторых случаях система автоматически добавляет taint к узлу. Встроенные taint включают:
Решение
Чтобы запланировать 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. указывает, что на узле недостаточно места для временного хранилища.
В этом случае вы можете проверить, ограничено ли пространство временного тома подом. Если требуемое приложением пространство временного тома превышает существующую ёмкость на узле, приложение не может быть запланировано на этот узел. Чтобы решить проблему, измените пространство временного тома или увеличьте ёмкость диска на узле.
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: Очистка образов
Выполните следующие действия для очистки неиспользуемых образов: Do not delete system images, such as the cce-pause image. Otherwise, the pod creation may fail.
Решение 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"}}