Решение проблем в Managed Service for Kubernetes

В этом разделе описаны типичные проблемы, которые могут возникать при работе Managed Service for Kubernetes, и методы их решения.

Ошибка при создании кластера в облачной сети другого каталогаОшибка при создании кластера в облачной сети другого каталога

Текст ошибки:

Permission denied

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

Чтобы создать кластер Managed Service for Kubernetes в облачной сети другого каталога, назначьте сервисному аккаунту для ресурсов следующие роли в этом каталоге:

• vpc.privateAdmin
• vpc.user

Для использования публичного IP-адреса дополнительно назначьте роль vpc.publicAdmin.

Пространство имен удалено, но все еще находится в статусе Terminating и не удаляетсяПространство имен удалено, но все еще находится в статусе Terminating и не удаляется

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

Чтобы устранить проблему, вручную удалите зависшие ресурсы.

Использую Yandex Network Load Balancer вместе с Ingress-контроллером, почему некоторые узлы моего кластера находятся в состоянии UNHEALTHY?Использую Yandex Network Load Balancer вместе с Ingress-контроллером, почему некоторые узлы моего кластера находятся в состоянии UNHEALTHY?

Это нормальное поведение балансировщика нагрузки при политике External Traffic Policy: Local. Статус HEALTHY получают только те узлы Managed Service for Kubernetes, поды которых готовы принимать пользовательский трафик. Оставшиеся узлы помечаются как UNHEALTHY.

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

kubectl describe svc <имя_сервиса_типа_LoadBalancer> \
| grep 'External Traffic Policy'

Подробнее в разделе Параметры сервиса типа LoadBalancer.

Почему созданный PersistentVolumeClaim остается в статусе Pending?Почему созданный PersistentVolumeClaim остается в статусе Pending?

Это нормальное поведение PersistentVolumeClaim. Созданный PVC находится в статусе Pending, пока не будет создан под, который должен его использовать.

Чтобы перевести PVC в статус Running:

1. Просмотрите информацию о PVC:

   kubectl describe pvc <имя_PVC> \
     --namespace=<пространство_имен,_в_котором_находится_PVC>
   

   Сообщение waiting for first consumer to be created before binding означает, что PVC ожидает создания пода.

2. Создайте под для этого PVC.

Почему кластер Managed Service for Kubernetes не запускается после изменения конфигурации его узлов?Почему кластер Managed Service for Kubernetes не запускается после изменения конфигурации его узлов?

Проверьте, что новая конфигурация узлов Managed Service for Kubernetes не превышает квоты:

Чтобы кластер Managed Service for Kubernetes запустился, увеличьте квоты.

Ошибка при обновлении сертификата Ingress-контроллераОшибка при обновлении сертификата Ingress-контроллера

Текст ошибки:

ERROR controller-runtime.manager.controller.ingressgroup Reconciler error
{"name": "some-prod", "namespace": , "error": "rpc error: code = InvalidArgument
desc = Validation error:\nlistener_specs[1].tls.sni_handlers[2].handler.certificate_ids:
Number of elements must be less than or equal to 1"}

Ошибка возникает, если для одного обработчика Ingress-контроллера указаны разные сертификаты.

Решение: исправьте и примените спецификации Ingress-контроллера таким образом, чтобы в описании каждого обработчика был указан только один сертификат.

Почему в кластере не работает разрешение имен DNS?Почему в кластере не работает разрешение имен DNS?

Кластер Managed Service for Kubernetes может не выполнять разрешение имен внутренних и внешних DNS-запросов по нескольким причинам. Чтобы устранить проблему:

1. Проверьте версию кластера Managed Service for Kubernetes и групп узлов.
2. Убедитесь, что CoreDNS работает.
3. Убедитесь, что кластеру Managed Service for Kubernetes достаточно ресурсов CPU.
4. Настройте автоматическое масштабирование.
5. Настройте локальное кеширование DNS.

Проверьте версию кластера и групп узловПроверьте версию кластера и групп узлов

1. Получите список актуальных версий Kubernetes:

   yc managed-kubernetes list-versions
   

2. Узнайте версию кластера Managed Service for Kubernetes:

   yc managed-kubernetes cluster get <имя_или_идентификатор_кластера> | grep version:
   

   Идентификатор и имя кластера Managed Service for Kubernetes можно получить со списком кластеров в каталоге.

3. Узнайте версию группы узлов Managed Service for Kubernetes:

   yc managed-kubernetes node-group get <имя_или_идентификатор_группы_узлов> | grep version:
   

   Идентификатор и имя группы узлов Managed Service for Kubernetes можно получить со списком групп узлов в кластере.

4. Если версии кластера Managed Service for Kubernetes или групп узлов не входят в список актуальных версий Kubernetes, обновите их.

Убедитесь, что CoreDNS работаетУбедитесь, что CoreDNS работает

Получите список подов CoreDNS и их состояние:

kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide

Все поды должны находится в состоянии Running.

Убедитесь, что кластеру достаточно ресурсов CPUУбедитесь, что кластеру достаточно ресурсов CPU

1. Перейдите на страницу каталога и выберите сервис Managed Service for Kubernetes.
2. Нажмите на имя нужного кластера Managed Service for Kubernetes и выберите вкладку Управление узлами.
3. Перейдите во вкладку Узлы и нажмите на имя любого узла Managed Service for Kubernetes.
4. Перейдите во вкладку Мониторинг.
5. Убедитесь, что на графике CPU, [cores] значения используемой мощности CPU used не достигают значений доступной мощности CPU total. Проверьте это для всех узлов кластера Managed Service for Kubernetes.

Настройте автоматическое масштабированиеНастройте автоматическое масштабирование

Настройте автоматическое масштабирование DNS по размеру кластера Managed Service for Kubernetes.

Настройте локальное кеширование DNSНастройте локальное кеширование DNS

Настройте NodeLocal DNS Cache. Чтобы применить оптимальные настройки, установите NodeLocal DNS Cache из Yandex Cloud Marketplace.

При создании группы узлов через CLI возникает конфликт параметров. Как его решить?При создании группы узлов через CLI возникает конфликт параметров. Как его решить?

Проверьте, указаны ли параметры --location, --network-interface и --public-ip в одной команде. Если передать эти параметры вместе, возникают ошибки:

• Для пар --location и --public-ip или --location и --network-interface:

  ERROR: rpc error: code = InvalidArgument desc = Validation error:
  allocation_policy.locations[0].subnet_id: can't use "allocation_policy.locations[0].subnet_id" together with "node_template.network_interface_specs"
  

• Для пары --network-interface и --public-ip:

  ERROR: flag --public-ip cannot be used together with --network-interface. Use '--network-interface' option 'nat' to get public address
  

Передавайте в команде только один из трех параметров. Расположение группы узлов Managed Service for Kubernetes достаточно указать в --location либо --network-interface.

Чтобы выдать доступ в интернет узлам кластера Managed Service for Kubernetes, выполните одно из действий:

• Назначьте публичные IP-адреса узлам кластера, указав --network-interface ipv4-address=nat или --network-interface ipv6-address=nat.
• Включите доступ к узлам Managed Service for Kubernetes из интернета после того, как создадите группу узлов.

Ошибка при подключении к кластеру с помощью Ошибка при подключении к кластеру с помощью kubectl

Текст ошибки:

ERROR: cluster has empty endpoint

Ошибка возникает, если подключаться к кластеру без публичного IP-адреса, а учетные данные для kubectl получить для публичного IP-адреса с помощью команды:

yc managed-kubernetes cluster \
   get-credentials <имя_или_идентификатор_кластера> \
   --external

Для подключения к внутреннему IP-адресу кластера с ВМ, находящейся в той же сети, получите учетные данные для kubectl с помощью команды:

yc managed-kubernetes cluster \
   get-credentials <имя_или_идентификатор_кластера> \
   --internal

Если вам нужно подключиться к кластеру из интернета, пересоздайте кластер и предоставьте ему публичный IP-адрес.

Ошибки при подключении к узлу по SSHОшибки при подключении к узлу по SSH

Тексты ошибок:

Permission denied (publickey,password)

Too many authentication failures

Ошибки возникают при подключении к узлу Managed Service for Kubernetes в следующих ситуациях:

• Публичный SSH-ключ не добавлен в метаданные группы узлов Managed Service for Kubernetes.

  Решение: обновите ключи группы узлов Managed Service for Kubernetes.

• Публичный SSH-ключ добавлен в метаданные группы узлов Managed Service for Kubernetes, но неправильно.

  Решение: приведите файл с публичными ключами к необходимому формату и обновите ключи группы узлов Managed Service for Kubernetes.

• Приватный SSH-ключ не добавлен в аутентификационный агент (ssh-agent).

  Решение: добавьте приватный ключ с помощью команды ssh-add <путь_к_файлу_приватного_ключа>.

Как выдать доступ в интернет узлам кластера Managed Service for Kubernetes?Как выдать доступ в интернет узлам кластера Managed Service for Kubernetes?

Если узлам кластера Managed Service for Kubernetes не выдан доступ в интернет, при попытке подключения к интернету возникнет ошибка:

Failed to pull image "cr.yandex/***": rpc error: code = Unknown desc = Error response from daemon: Gethttps://cr.yandex/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Есть несколько способов выдать доступ в интернет узлам кластера Managed Service for Kubernetes:

• Создайте и настройте NAT-шлюз или NAT-инстанс. В результате с помощью статической маршрутизации трафик будет направлен через шлюз или отдельную виртуальную машину с функциями NAT.
• Назначьте публичный IP-адрес группе узлов Managed Service for Kubernetes.

Почему я не могу выбрать Docker в качестве среды запуска контейнеров?Почему я не могу выбрать Docker в качестве среды запуска контейнеров?

Среда запуска контейнеров Docker не поддерживается в кластерах с версией Kubernetes 1.24 и выше. Доступна только среда containerd.

Ошибка при подключении репозитория GitLab к Argo CDОшибка при подключении репозитория GitLab к Argo CD

Текст ошибки:

FATA[0000] rpc error: code = Unknown desc = error testing repository connectivity: authorization failed

Ошибка возникает, если доступ в GitLab по протоколу HTTP(S) отключен.

Решение: включите доступ. Для этого:

1. В GitLab на панели слева выберите Admin → Settings → General.
2. В блоке Visibility and access controls найдите настройку Enabled Git access protocols.
3. Выберите в списке пункт, разрешающий доступ по протоколу HTTP(S).

Подробнее в документации GitLab.