Что делать, если Кластер доступен, но некоторые узлы в нём недоступны?

Kubernetes предоставляет heartbeats, помогающие определить, доступен ли узел. Для получения подробной информации о механизме и интервале обнаружения см. Heartbeats.

Возможные причины перечислены в порядке вероятности.

Если неисправность сохраняется после исключения причины, проверьте другие причины.

• Пункт проверки 1: Перегружен ли узел
• Пункт проверки 2: Удалён ли ECS или неисправен
• Пункт проверки 3: Возможен ли вход в ECS
• Пункт проверки 4: Было ли изменено Security Group
• Пункт проверки 5: Содержат ли правила Security Group правило, позволяющее коммуникацию между Master Nodes и Worker Nodes
• Пункт проверки 6: Ненормален ли диск
• Пункт проверки 7: Нормальны ли внутренние компоненты
• Пункт проверки 8: Правильно ли настроен DNS‑адрес
• Пункт проверки 9: Был ли удалён vdb Disk на узле
• Пункт проверки 10: Является ли Docker Service нормальным

Симптом

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

Локализация неисправности

1. Войдите в консоль CCE и нажмите название кластера, чтобы перейти в консоль кластера. В панели навигации выберите Nodes. В правой панели нажмите вкладку Nodes, найдите строку с недоступным узлом и нажмите Monitor.
2. В верхней части отображаемой страницы нажмите View More, чтобы перейти в консоль AOM и просмотреть исторические записи мониторинга.

   Слишком высокое использование CPU или памяти на узле приведёт к высокой задержке сети или вызовет системный OOM, поэтому узел отображается как недоступный.

Решение

1. Уменьшите количество рабочих нагрузок на узле, переместив services на другие узлы, и настройте ограничения ресурсов для рабочих нагрузок.
2. Очистите данные на узлах CCE в кластере.
3. Ограничьте квоты CPU и памяти для каждого Контейнера.
4. Добавьте больше узлов в кластер.
5. Перезапустите узел в консоли ECS.
6. Добавьте дополнительные узлы и разверните контейнеры с высоким потреблением памяти отдельно.
7. Сбросьте узлы.

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

1. Проверьте, доступен ли кластер.

   Войдите в консоль CCE и проверьте, доступен ли кластер.

   • If the cluster is unavailable, for example, an error occurs, perform operations described in How Do I Locate the Fault When a Cluster Is Unavailable?
   • If the cluster is running but some nodes in the cluster are unavailable, go to 2.

2. Log in to the ECS console and view the ECS status.
   • If the ECS status is Deleted, go back to the CCE console, delete the corresponding node from the node list of the cluster, and then create a new one.
   • If the ECS status is Stopped or Frozen, restore the ECS first. It takes about 3 minutes to restore the node.
   • Если ECS неисправен, перезапустите его, чтобы устранить неисправность.
   • If the ECS status is Running, log in to the ECS and locate the fault by referring to Check Item 7: Whether Internal Components Are Normal.

1. Войдите в консоль ECS.
2. Проверьте, совпадает ли отображаемое имя узла с именем на VM и можно ли использовать пароль или ключ для входа в узел.

   Если имена узлов несоответствуют и вход в узел с помощью пароля или ключа невозможен, это означает, что при создании ECS возникла проблема Cloud-Init. В этом случае перезапустите узел и отправьте запрос в службу поддержки ECS для выявления причины.

Войдите в консоль VPC. В панели навигации выберите Access Control > Security Groups и найдите master node security group кластера.

Имя этого security group имеет формат {cluster_name}-cce-control-{ID}. Вы можете выполнить поиск security group по имени кластера, а затем использовать -cce-control-.

Проверьте, были ли изменены правила security group. Подробную информацию о security groups см. в How Do I Modify Cluster Security Group Rules?.

Проверьте, существует ли такое правило security group.

При добавлении узла в кластер добавьте правила security group, показанные на рисунке ниже, в security group cluster-name-cce-control-random-ID, чтобы обеспечить доступность добавленного узла. Это необходимо, если к VPC подсети узла был добавлен вторичный CIDR‑блок и подсеть находится во вторичном CIDR‑блоке. Однако если вторичный CIDR‑блок уже был добавлен к VPC при создании кластера, этот шаг не требуется.

Проверьте, были ли изменены правила security group. Подробную информацию о security groups см. в How Do I Modify Cluster Security Group Rules?.

Каждый новый узел оснащён 100‑GiB Диском с данными, предназначенным для Docker. Если этот Диск с данными удалён или повреждён, сервис Docker будет прерван, и узел станет недоступным.

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

1. Войдите в узел и проверьте, работают ли правильно следующие ключевые компоненты:
   • kubelet
   • kube-proxy
   • Компоненты сети
     • yangtse: используется кластерами, которые используют сети VPC или Cloud Native 2.0
     • canal: используется кластерами, которые используют сети контейнерных туннелей
   • Среда выполнения: Docker или containerd
   • chronyd

   Проверьте состояние компонента. Например, чтобы проверить состояние kubelet, выполните следующую команду:

   systemctl status kubelet
   
   

   kubelet — это имя компонента. При необходимости его можно заменить.

   Ожидаемый вывод показан на рисунке ниже.

   

2. Если компонент находится не в состоянии Active, перезапустите его. Укажите команду перезапуска в зависимости от неисправного компонента. Если неисправен yangtse, выполните следующую команду:

   systemctl restart yangtse
   
   

   Проверьте состояние компонента еще раз.

   systemctl status yangtse
   
   

3. Если после перезапуска компонента статус узла все еще не восстановлен, создайте запрос в службу поддержки и обратитесь в службу обслуживания клиентов.

1. Войдите в узел и проверьте, зафиксированы ли сбои разрешения доменных имен в /var/log/cloud-init-output.log.

   cat /var/log/cloud-init-output.log | grep resolv

   Если вывод команды содержит следующую информацию, это означает, что произошёл сбой разрешения доменных имён.

   Could not resolve host: Unknown error

2. На узле выполните ping доменного имени, которое не удалось разрешить на предыдущем шаге, чтобы проверить, может ли доменное имя быть разрешено.
   • Если доменное имя нельзя пропинговать, DNS не может разрешить IP‑адрес. Проверьте, совпадает ли DNS‑адрес в файле /etc/resolv.conf с тем, который настроен в подсети VPC. В большинстве случаев DNS‑адрес в файле настроен неверно, что приводит к невозможности разрешить доменное имя. Чтобы устранить проблему, скорректируйте конфигурацию DNS подсети VPC и перезапустите узел.
   • Если да, конфигурация DNS‑адреса верна. Проверьте наличие других неисправностей.

Если диск vdb на узле был удалён, вы можете восстановить узел, обратившись к What Should I Do If the vdb Disk of a Node Is Damaged and the Node Can't Be Recovered After Reset?

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

   systemctl status docker
   
   

   

   Если команда не может быть выполнена или статус сервиса Docker не активен, определите причину или при необходимости обратитесь в техническую поддержку.

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

   docker ps -a | wc -l
   
   

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

   В этом случае прекратите повторное создание и удаление нагрузок или используйте больше узлов для распределения нагрузки. Обычно узел восстанавливается через некоторое время. При необходимости выполните команду docker rm {container_id}, чтобы вручную очистить аномальные контейнеры.