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

Статья создана

Улучшена

Обновлена 16 октября 2026 г.

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

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

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

Permission denied

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

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

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

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

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

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

CLI

Если у вас еще нет интерфейса командной строки Yandex Cloud (CLI), установите и инициализируйте его.

По умолчанию используется каталог, указанный при создании профиля CLI. Чтобы изменить каталог по умолчанию, используйте команду yc config set folder-id <идентификатор_каталога>. Также для любой команды вы можете указать другой каталог с помощью параметров --folder-name или --folder-id.

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

Подключитесь к кластеру Managed Service for Kubernetes.

Узнайте, какие ресурсы остались в пространстве имен:

kubectl api-resources --verbs=list --namespaced --output=name \
  | xargs --max-args=1 kubectl get --show-kind \
  --ignore-not-found --namespace=<пространство_имен>

Удалите найденные ресурсы:

kubectl delete <тип_ресурса> <имя_ресурса> --namespace=<пространство_имен>

Если после этого пространство имен все равно находится в статусе Terminating и не удаляется, удалите его принудительно, использовав finalizer:

Включите проксирование API Kubernetes на ваш локальный компьютер:
```
kubectl proxy
```

Удалите пространство имен:

kubectl get namespace <пространство_имен> --output=json \
  | jq '.spec = {"finalizers":[]}' > temp.json && \
curl --insecure --header "Content-Type: application/json" \
  --request PUT --data-binary @temp.json \
  127.0.0.1:8001/api/v1/namespaces/<пространство_имен>/finalize

Не рекомендуется сразу удалять пространство имен в статусе Terminating с помощью finalizer, так как при этом зависшие ресурсы могут остаться в кластере Managed Service for Kubernetes.

Использую 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. Созданный PVC находится в статусе Pending, пока не будет создан под, который должен его использовать.

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

Просмотрите информацию о PVC:
```
kubectl describe pvc <имя_PVC> \
  --namespace=<пространство_имен>
```
Где --namespace — пространство имен, в котором находится PVC.

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

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

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

CLI

Если у вас еще нет интерфейса командной строки Yandex Cloud (CLI), установите и инициализируйте его.

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

Подключитесь к кластеру Managed Service for Kubernetes.

Проверьте состояние узлов Managed Service for Kubernetes:

yc managed-kubernetes cluster list-nodes <идентификатор_кластера>

Сообщение о том, что ресурсы кластера Managed Service for Kubernetes исчерпаны, отображается в первом столбце вывода команды. Пример:

+--------------------------------+-----------------+------------------+-------------+--------------+
|         CLOUD INSTANCE         | KUBERNETES NODE |     RESOURCES    |     DISK    |    STATUS    |
+--------------------------------+-----------------+------------------+-------------+--------------+
| fhmil14sdienhr5uh89no          |                 | 2 100% core(s),  | 64.0 GB hdd | PROVISIONING |
| CREATING_INSTANCE              |                 | 4.0 GB of memory |             |              |
| [RESOURCE_EXHAUSTED] The limit |                 |                  |             |              |
| on total size of network-hdd   |                 |                  |             |              |
| disks has exceeded.,           |                 |                  |             |              |
| [RESOURCE_EXHAUSTED] The limit |                 |                  |             |              |
| on total size of network-hdd   |                 |                  |             |              |
| disks has exceeded.            |                 |                  |             |              |
+--------------------------------+-----------------+------------------+-------------+--------------+

Если квоты исчерпаны, запросите их увеличение. Проверьте квоты как Managed Service for Kubernetes, так и Compute Cloud.

Эти проверки полезны и при длительном состоянии STARTING после создания или запуска кластера. Также проверьте роли сервисного аккаунта для ресурсов кластера. Ему нужна роль k8s.clusters.agent; для использования публичных IP-адресов — vpc.publicAdmin.

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

После изменения маски подсети узлов в настройках кластера количество подов, размещаемых на узлах, не соответствует ожидаемому

Решение: пересоздайте группу узлов.

Ошибка при обновлении сертификата 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?

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

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

Получите список актуальных версий Kubernetes:
```
yc managed-kubernetes list-versions
```
Узнайте версию кластера Managed Service for Kubernetes:
```
yc managed-kubernetes cluster get <имя_или_идентификатор_кластера> | grep version:
```
Идентификатор и имя кластера Managed Service for Kubernetes можно получить со списком кластеров в каталоге.
Узнайте версию группы узлов Managed Service for Kubernetes:
```
yc managed-kubernetes node-group get <имя_или_идентификатор_группы_узлов> | grep version:
```
Идентификатор и имя группы узлов Managed Service for Kubernetes можно получить со списком групп узлов в кластере.
Если версии кластера Managed Service for Kubernetes или групп узлов не входят в список актуальных версий Kubernetes, обновите их.

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

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

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

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

kubectl logs -l k8s-app=kube-dns -n kube-system --all-containers=true

Для дополнительной диагностики используйте инструкцию Kubernetes по проверке DNS.

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

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

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

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

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

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

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

При создании группы узлов через 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

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

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 не выдан доступ в интернет, при попытке подключения к интернету возникнет ошибка:

Failed to pull image "cr.yandexcloud.kz/***": rpc error: code = Unknown desc = Error response from daemon: Gethttps://cr.yandexcloud.kz/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.

Примечание

Если вы назначили публичные IP-адреса узлам кластера и затем настроили NAT-шлюз или NAT-инстанс, доступ в интернет через публичные адреса пропадет. Подробнее читайте в документации сервиса Yandex Virtual Private Cloud.

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

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

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

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

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

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

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

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

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

При развертывании обновлений приложения в кластере с Yandex Application Load Balancer наблюдается потеря трафика

Если трафик вашего приложения управляется балансировщиком Application Load Balancer и для Ingress-контроллера балансировщика включена политика управления трафиком externalTrafficPolicy: Local, то запросы обслуживаются приложением на том узле, куда запрос передал балансировщик. Передача трафика между узлами исключается.

Проверка состояния по умолчанию отслеживает состояние узла, а не приложения. Поэтому трафик с Application Load Balancer может направляться на узел, где отсутствует работающее приложение. При развертывании новой версии приложения в кластере Ingress-контроллер Application Load Balancer передает запрос балансировщику на изменение конфигурации группы бэкендов. Обработка запроса занимает не менее 30 секунд, и в течение этого времени приложение может не получать пользовательский трафик.

Чтобы исключить такую ситуацию, рекомендуется настраивать проверки состояния бэкендов на балансировщике Application Load Balancer. Благодаря проверкам состояния балансировщик своевременно отслеживает недоступные бэкенды и направляет трафик на другие бэкенды. После обновления приложения трафик будет снова распределен на все бэкенды.

Подробнее в разделах Рекомендации по настройке проверок состояния Yandex Application Load Balancer и Аннотации (metadata.annotations).

Некорректно отображается системное время на узлах, а также в журналах контейнеров и подов кластера Managed Service for Kubernetes

Время кластера Managed Service for Kubernetes может расходиться со временем других ресурсов, например виртуальной машины, если они используют для синхронизации часов разные источники. Например, кластер Managed Service for Kubernetes синхронизируется со служебным сервером времени (по умолчанию), а ВМ синхронизируется с собственным или публичным NTP-сервером.

Решение: настройте синхронизацию времени кластера Managed Service for Kubernetes с собственным NTP-сервером. Для этого:

Укажите адреса NTP-серверов в настройках DHCP подсетей мастера и рабочих узлов. Если рабочие узлы находятся в других подсетях, повторите настройку для этих подсетей.
Консоль управления

CLI

Terraform

API
1. В консоли управления выберите каталог.
2. Перейдите в сервис Managed Service for Kubernetes.
3. Нажмите на имя нужного кластера Kubernetes.
4. В блоке Конфигурация мастера нажмите на имя подсети.
5. Нажмите кнопку Редактировать в правом верхнем углу.
6. В открывшемся окне раскройте блок Настройки DHCP.
7. Нажмите кнопку Добавить NTP-сервер и укажите IP-адрес NTP-сервера.
8. Нажмите Сохранить изменения.
Если у вас еще нет интерфейса командной строки Yandex Cloud (CLI), установите и инициализируйте его.

По умолчанию используется каталог, указанный при создании профиля CLI. Чтобы изменить каталог по умолчанию, используйте команду yc config set folder-id <идентификатор_каталога>. Также для любой команды вы можете указать другой каталог с помощью параметров --folder-name или --folder-id.

Если вы обращаетесь к ресурсу по имени, поиск будет выполнен в каталоге по умолчанию. Если вы обращаетесь к ресурсу по идентификатору, поиск будет выполнен глобально — во всех каталогах с учетом прав доступа.
1. Посмотрите описание команды CLI для обновления параметров подсети:
  yc vpc subnet update --help
2. Выполните команду subnet с параметром --ntp-server, указав IP-адрес NTP-сервера:
  yc vpc subnet update <идентификатор_подсети> --ntp-server <адрес_сервера>
Совет

Чтобы узнать идентификаторы подсетей, в которых находится кластер, получите подробную информацию о кластере.
1. В файле конфигурации Terraform измените описание подсети кластера. Добавьте блок dhcp_options (если он отсутствует) с параметром ntp_servers и укажите IP-адрес NTP-сервера:
  ... resource "yandex_vpc_subnet" "lab-subnet-a" { ... v4_cidr_blocks = ["<IPv4-адрес>"] network_id = "<идентификатор_сети>" ... dhcp_options { ntp_servers = ["<IPv4-адрес>"] ... } } ...
  Подробная информация о параметрах ресурса yandex_vpc_subnet в Terraform приведена в документации провайдера.
2. Примените изменения:
  1. В терминале перейдите в директорию с конфигурационным файлом.
  2. Проверьте корректность конфигурации с помощью команды:
    
    terraform validate
    
    Если конфигурация является корректной, появится сообщение:
    
    Success! The configuration is valid.
  3. Выполните команду:
    
    terraform plan
    
    В терминале будет выведен список планируемых изменений: ресурсы и/или выходные переменные. На этом этапе изменения не будут внесены. Если в конфигурации есть ошибки, Terraform на них укажет.
  4. Примените изменения конфигурации:
    
    terraform apply
  5. Подтвердите изменения: введите в терминале слово yes и нажмите Enter.
  Terraform изменит все требуемые ресурсы. Проверить изменение подсети можно в консоли управления или с помощью команды CLI:
  yc vpc subnet get <имя_подсети>
Воспользуйтесь методом update для ресурса Subnet и передайте в запросе:
- IP-адрес NTP-сервера в параметре dhcpOptions.ntpServers.
- Обновляемый параметр dhcpOptions.ntpServers в параметре updateMask.
Совет

Чтобы узнать идентификаторы подсетей, в которых находится кластер, получите подробную информацию о кластере.
Важно

Для высокодоступного мастера, который размещается в трех зонах доступности, изменения необходимо внести в каждую из трех подсетей.
Разрешите подключение из кластера к NTP-серверам.

Создайте правило для исходящего трафика в группе безопасности кластера и групп узлов:
- Диапазон портов — 123. Если вместо порта 123 вы используете на NTP-сервере другой порт, укажите его.
- Протокол — UDP.
- Назначение — Диапазон адресов.
- IPv4 CIDR — <IP-адрес_NTP-сервера>/32. Для мастера, который размещается в трех зонах доступности, укажите три блока: <IP-адрес_NTP-сервера_в_подсети1>/32, <IP-адрес_NTP-сервера_в_подсети2>/32, <IP-адрес_NTP-сервера_в_подсети3>/32.
Обновите сетевые параметры в группе узлов кластера одним из следующих способов:
- Подключитесь к каждому узлу группы по SSH или через OS Login и выполните команду sudo dhclient -v -r && sudo dhclient.
- Перезагрузите узлы группы в удобное для вас время.
Важно

Обновление сетевых параметров может привести к недоступности сервисов внутри кластера на несколько минут.

Для рабочих узлов с systemd-timesyncd также можно настроить источники времени через DaemonSet. Вариант требует привилегированного контейнера и изменяет конфигурацию хоста. Проверьте используемую службу синхронизации времени перед применением.

Пример DaemonSet для настройки systemd-timesyncd

В NTP_SERVERS укажите доступные с узлов NTP-серверы. Пример создает отдельный файл конфигурации, поэтому повторный запуск не зависит от наличия закомментированной строки NTP= в основном файле.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ntp-configurator
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: ntp-configurator
  template:
    metadata:
      labels:
        app: ntp-configurator
    spec:
      hostPID: true
      hostNetwork: true
      initContainers:
        - name: configure-ntp
          image: ubuntu:22.04
          env:
            - name: NTP_SERVERS
              value: "<NTP-сервер_1> <NTP-сервер_2>"
          command:
            - /bin/bash
            - -ec
            - |
              nsenter --mount=/proc/1/ns/mnt -- /bin/sh -ec '
                mkdir -p /etc/systemd/timesyncd.conf.d
                printf "[Time]\nNTP=%s\n" "$1" > /etc/systemd/timesyncd.conf.d/90-custom-ntp.conf
                systemctl restart systemd-timesyncd
                systemctl is-active systemd-timesyncd
              ' sh "$NTP_SERVERS"
          securityContext:
            privileged: true
      containers:
        - name: sleep
          image: ubuntu:22.04
          command: ["/bin/sleep", "infinity"]

DaemonSet применяет настройки только на узлах, на которых может быть запланирован. Удаление DaemonSet не удаляет созданный файл с узлов. Для отмены настройки удалите файл /etc/systemd/timesyncd.conf.d/90-custom-ntp.conf и перезапустите systemd-timesyncd на затронутых узлах.

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

Что делать, если я удалил сетевой балансировщик нагрузки или целевые группы Yandex Network Load Balancer, автоматически созданные для сервиса типа LoadBalancer?

Восстановить сетевой балансировщик или целевые группы Network Load Balancer вручную нельзя. Пересоздайте сервис типа LoadBalancer — балансировщик и целевые группы будут созданы автоматически.

Ошибка при подключении виртуальной машины Yandex Compute Cloud в качестве внешнего узла Managed Service for Kubernetes

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

Unable to create remote dir /home/kubernetes/bin/: ssh run `mkdir -p -m 0644 /home/kubernetes/bin/': Process exited with status 142
Please login as the user "NONE" rather than the user "root".

Чтобы устранить проблему, пересоздайте виртуальную машину, указав в метаданных для ключа user-data параметр disable_root: false.

Пример метаданных

#cloud-config
datasource:
 Ec2:
  strict_id: false
disable_root: false
users:
- name: <имя_пользователя>
  sudo: ALL=(ALL) NOPASSWD:ALL
  shell: /bin/bash
  ssh_authorized_keys:
  - ssh-rsa <публичный_ключ_доступа_к_ВМ>

Что делать при ошибке `node(s) had untolerated taint`?

Ошибка означает, что на узле установлено ограничение taint, для которого у пода нет соответствующего допуска toleration. Эффект ограничения определяет поведение: NoSchedule запрещает назначать новые поды, NoExecute также вытесняет уже работающие поды, а PreferNoSchedule задает мягкое ограничение.

Проверьте ограничения узла и допуски пода:

kubectl describe node <имя_узла>
kubectl describe pod <имя_пода> --namespace <пространство_имен>

Если под должен работать на этом узле, добавьте соответствующий допуск в spec.tolerations пода. Если ограничение больше не требуется, удалите его или измените эффект на PreferNoSchedule. Подробнее о taint и toleration в документации Kubernetes.

Почему под остается в состоянии Pending?

Посмотрите описание пода:

kubectl describe pod <имя_пода> --namespace <пространство_имен>

Сообщения в разделе Events помогут определить причину: например, недостаток ресурсов, ограничения размещения или проблему с подключением тома. Дальнейшие действия зависят от сообщения об ошибке.

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

Что делать при ошибке `DEADLINE_EXCEEDED` при выгрузке метрик?

При выгрузке метрик Managed Service for Kubernetes через API Monitoring запрос может завершиться с кодом 504 и сообщением DEADLINE_EXCEEDED. Одна из возможных причин — большой объем метрик, из-за которого запрос не успевает выполниться.

Уменьшите объем данных с помощью параметра selectors. Например, в конфигурации Prometheus укажите пространство имен:

scrape_configs:
  - job_name: yc-monitoring-export
    metrics_path: /monitoring/v2/prometheusMetrics
    params:
      folderId:
        - '<идентификатор_каталога>'
      service:
        - managed-kubernetes
      selectors:
        - 'namespace=<пространство_имен>'
    bearer_token: '<IAM-токен>'

Это фрагмент конфигурации сбора метрик: сохраните настройки адреса сервера из своей конфигурации. Для метрик подов можно также использовать маску имени, например pod=app*. Подробнее о языке запросов Monitoring.

Что делать, если HPA не получает метрики?

Если HPA сообщает FailedGetResourceMetric или запросы к metrics.k8s.io завершаются по таймауту, проверьте группы безопасности кластера и ресурсы узла, на котором работает Metrics Server.

Если на этом узле недостаточно ресурсов, перенесите под Metrics Server на другой узел:

Найдите имя пода и узел:

kubectl get pods -n kube-system -o wide | grep metrics-server

Убедитесь, что другой узел имеет достаточно ресурсов и соответствует правилам размещения пода. Запретите назначение новых подов на исходный узел и удалите под Metrics Server:
```
kubectl cordon <исходный_узел>
kubectl delete pod <имя_пода_metrics-server> -n kube-system
```
Контроллер создаст новый под. До его запуска метрики могут быть недоступны.
Проверьте готовность нового пода и узел, на котором он размещен:
```
kubectl get pods -n kube-system -o wide | grep metrics-server
```
После запуска пода снова разрешите назначение подов на исходный узел:
```
kubectl uncordon <исходный_узел>
```
Если перенос не удался, также отмените cordon перед дальнейшей диагностикой.

Если ошибка сохраняется, создайте запрос в техническую поддержку. Укажите идентификатор кластера, имя проблемного пода и приложите вывод kubectl describe hpa --namespace <пространство_имен>.

Что делать при таймауте подключения тома к поду?

При подключении тома может возникнуть ошибка:

Unable to attach or mount volumes: timed out waiting for the condition

Проверьте события пода и PVC, чтобы определить причину:

kubectl describe pod <имя_пода> --namespace <пространство_имен>
kubectl describe pvc <имя_PVC> --namespace <пространство_имен>

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

Если проблема связана с подключением диска к ВМ узла, может помочь остановка и повторный запуск ВМ. Остановите ВМ, дождитесь состояния STOPPED, затем запустите ее. Это прервет работу подов на узле, поэтому рекомендуется проводить операцию в период минимальной нагрузки.

Почему долго монтируется том с большим количеством файлов?

Если монтирование завершается по таймауту, проверьте журнал kubelet на узле:

sudo journalctl -u kubelet --no-pager --since today

Сообщение If the volume has a lot of files then setting volume ownership could be slow... указывает на долгое изменение владельца и прав доступа к файлам тома.

Если для пода задан fsGroup, Kubernetes может рекурсивно изменять права при монтировании. Для поддерживаемых томов параметр fsGroupChangePolicy: OnRootMismatch в spec.securityContext позволяет пропускать эту операцию, если права корневого каталога уже соответствуют ожидаемым. Подробнее об условиях применения — в документации Kubernetes.

Что делать, если узлы долго находятся в состоянии `RECONCILING`?

Если состояние RECONCILING сохраняется более 20 минут, проверьте использование квот и состояние узлов:

yc managed-kubernetes node-group list-nodes <идентификатор_группы_узлов> --format yaml

Сообщение Kubelet stopped posting node status означает, что kubelet перестал передавать состояние узла. Подключитесь к узлу по SSH и проверьте службы:

sudo systemctl status containerd kubelet

Если службы работают некорректно, изучите их журналы и перезапустите:

sudo systemctl restart containerd
sudo systemctl restart kubelet

Перезапуск может повлиять на приложения узла. После него повторно проверьте состояние служб и узла.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что делать при ошибке ?Что делать при ошибке node(s) had untolerated taint?

Почему под остается в состоянии Pending?Почему под остается в состоянии Pending?

Что делать при ошибке при выгрузке метрик?Что делать при ошибке DEADLINE_EXCEEDED при выгрузке метрик?

Что делать, если HPA не получает метрики?Что делать, если HPA не получает метрики?

Что делать при таймауте подключения тома к поду?Что делать при таймауте подключения тома к поду?

Почему долго монтируется том с большим количеством файлов?Почему долго монтируется том с большим количеством файлов?

Что делать, если узлы долго находятся в состоянии ?Что делать, если узлы долго находятся в состоянии RECONCILING?

Была ли статья полезна?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что делать при ошибке `node(s) had untolerated taint`?

Почему под остается в состоянии Pending?

Что делать при ошибке `DEADLINE_EXCEEDED` при выгрузке метрик?

Что делать, если HPA не получает метрики?

Что делать при таймауте подключения тома к поду?

Почему долго монтируется том с большим количеством файлов?

Что делать, если узлы долго находятся в состоянии `RECONCILING`?