Связаться с намиПодключиться

Вопросы и ответы про Managed Service for Kubernetes

Статья создана
Улучшена
Обновлена 23 апреля 2025 г.

Общие вопросы

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

По умолчанию доступны:

Какая версия Kubernetes CLI (kubectl) должна быть установлена для полноценной работы с кластером?

Мы рекомендуем использовать последнюю доступную официальную версию kubectl, чтобы избежать проблем совместимости.

Сможет ли Yandex Cloud восстановить работоспособность кластера, если я допущу ошибки при его настройке?

Мастер находится под управлением Yandex Cloud, поэтому вы не сможете его повредить. Если у вас возникли проблемы с компонентами кластера Kubernetes, обратитесь в техническую поддержку.

Кто будет заниматься мониторингом здоровья кластера?

Yandex Cloud. В кластере проводится мониторинг повреждений файловой системы (corrupted file system), неисправностей ядра (kernel deadlock), потери связи с интернетом и проблем с компонентами Kubernetes. Мы также разрабатываем механизм автоматического восстановления для неисправных компонентов.

Как быстро Yandex Cloud закрывает уязвимости, обнаруженные в системе безопасности? Что делать, если злоумышленник успеет воспользоваться уязвимостью, и мои данные пострадают?

Сервисы Yandex Cloud, образы и конфигурация мастера изначально проходят различные проверки на безопасность и соответствие стандартам.

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

Я могу подключиться к узлу кластера через OS Login, по аналогии с ВМ Yandex Cloud?

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

Хранилище данных

Какие существуют особенности работы с дисковым хранилищем при размещении БД (MySQL®, PostgreSQL и т. д.) в кластере Kubernetes?

При размещении БД в кластере Kubernetes используйте контроллеры StatefullSet. Мы не рекомендуем запускать в Kubernetes statefull-сервисы в постоянными томами. Для работы с базами данных statefull-сервисов используйте управляемые базы данных Yandex Cloud, например Managed Service for MySQL® или Managed Service for PostgreSQL.

Как подключить под к управляемым базам данных Yandex Cloud?

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

Для подключения сертификата базы данных к поду используйте объекты типа secret или configmap.

Как правильно подключить постоянный том к контейнеру?

Вы можете выбрать режим для подключения дисков Compute Cloud в зависимости от ваших нужд:

Подробнее читайте в разделе Работа с постоянными томами.

Какие типы томов поддерживает Managed Service for Kubernetes?

Managed Service for Kubernetes поддерживает работу с временными (Volume) и постоянными (PersistentVolume) томами. Подробнее читайте в разделе Том.

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

Почему в моем кластере стало N узлов и он не уменьшается?

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

  • Поды, расселение которых ограничено с помощью PodDisruptionBudget.
  • Поды в пространстве имен kube-system:
    • которые созданы не под управлением контроллера DaemonSet;
    • для которых не установлен PodDisruptionBudget или расселение которых ограничено с помощью PodDisruptionBudget.
  • Поды, которые не были созданы под управлением контроллера репликации (ReplicaSet, Deployment или StatefulSet).
  • Поды с local-storage.
  • Поды, которые не могут быть расселены куда-либо из-за ограничений. Например, при недостатке ресурсов или отсутствии узлов, подходящих по селекторам affinity или anti-affinity.
  • Поды, на которых установлена аннотация, запрещающая расселение: "cluster-autoscaler.kubernetes.io/safe-to-evict": "false".

Примечание

Поды kube-system, поды с local-storage и поды без контроллера репликации можно расселить. Для этого установите аннотацию "safe-to-evict": "true":

kubectl annotate pod <имя_пода> cluster-autoscaler.kubernetes.io/safe-to-evict=true

Другие возможные причины:

  • Группа узлов уже достигла минимального размера.

  • Узел простаивает менее 10 минут.

  • В течение последних 10 минут группа узлов была масштабирована в сторону увеличения.

  • В течение последних 3 минут в группе узлов была неудачная попытка масштабирования в сторону уменьшения.

  • Произошла неудачная попытка остановить определенный узел. В этом случае следующая попытка происходит по истечении 5 минут.

  • На узле установлена аннотация, которая запрещает останавливать его при масштабировании: "cluster-autoscaler.kubernetes.io/scale-down-disabled": "true". Аннотацию можно добавить или снять с помощью kubectl.

    Проверьте наличие аннотации на узле:

    kubectl describe node <имя_узла> | grep scale-down-disabled

    Результат:

    Annotations:        cluster-autoscaler.kubernetes.io/scale-down-disabled: true

    Установите аннотацию:

    kubectl annotate node <имя_узла> cluster-autoscaler.kubernetes.io/scale-down-disabled=true

    Снять аннотацию можно, выполнив команду kubectl со знаком -:

    kubectl annotate node <имя_узла> cluster-autoscaler.kubernetes.io/scale-down-disabled-

Почему под удалился, а размер группы узлов не уменьшается?

Если узел недостаточно нагружен, он удаляется по истечении 10 минут.

Почему автоматическое масштабирование не выполняется, хотя количество узлов меньше минимума / больше максимума?

Установленные лимиты не будут нарушены при масштабировании, но Managed Service for Kubernetes не следит за соблюдением границ намеренно. Масштабирование в сторону увеличения сработает только в случае появления подов в статусе unschedulable.

Почему в моем кластере остаются поды со статусом Terminated?

Это происходит из-за того, что во время автоматического масштабирования контроллер Pod garbage collector (PodGC) не успевает удалять поды. Подробнее в разделе Удаление подов в статусе Terminated.

Ответы на другие вопросы об автоматическом масштабировании смотрите в документации Kubernetes.

Настройка и обновление

Что делать, если часть моих данных потеряется при обновлении версии Kubernetes?

Данные не потеряются: перед обновлением версии Kubernetes Managed Service for Kubernetes подготавливаем для них резервные копии. Вы можете самостоятельно настроить резервное копирование кластера в Yandex Object Storage. Также мы рекомендуем выполнять резервное копирование баз данных средствами самого приложения.

Можно ли настроить резервное копирование для кластера Kubernetes?

Данные в кластерах Managed Service for Kubernetes надежно хранятся и реплицируются в инфраструктуре Yandex Cloud. Однако в любой момент вы можете сделать резервные копии данных из групп узлов кластеров Managed Service for Kubernetes и хранить их в Object Storage или другом хранилище.

Подробнее читайте в разделе Резервное копирование кластера Managed Service for Kubernetes в Object Storage.

Будут ли ресурсы простаивать при обновлении версии Kubernetes?

При обновлении мастера будут простаивать ресурсы Control Plane. Поэтому такие операции, как создание или удаление группы узлов Managed Service for Kubernetes, будут недоступны. Пользовательская нагрузка на приложение продолжит обрабатываться.

Если значение max_expansion больше нуля, при обновлении групп узлов Managed Service for Kubernetes создаются новые узлы. На них переводится вся нагрузка, а старые группы узлов удаляются. Простой при этом будет равен времени рестарта пода при перемещении в новую группу узлов Managed Service for Kubernetes.

Можно ли обновить кластер Managed Service for Kubernetes в один этап?

Зависит от того, с какой на какую версию вы хотите перевести кластер Managed Service for Kubernetes. За один этап кластер Managed Service for Kubernetes можно обновить только до следующей минорной версии относительно текущей. Обновление до более новых версий производится в несколько этапов, например: 1.19 → 1.20 → 1.21. Подробнее см. в разделе Обновление кластера.

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

Обновляется ли плагин Container Network Interface вместе с кластером Managed Service for Kubernetes?

Да. Если вы используете контроллеры Calico и Cilium, они обновляются вместе с кластером Managed Service for Kubernetes. Чтобы обновить кластер Managed Service for Kubernetes, выполните одно из действий:

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

Можно ли прислать вам YAML-файл с конфигурацией, чтобы вы применили его к моему кластеру?

Нет. Вы можете использовать kubeconfig-файл, чтобы применить YAML-файл с конфигурацией кластера самостоятельно.

Можете ли вы установить Web UI Dashboard, Rook и другие инструменты?

Нет. Вы можете установить все необходимые инструменты самостоятельно.

Что делать, если после обновления Kubernetes не подключаются тома?

Если после обновления Kubernetes вы получаете ошибку:

AttachVolume.Attach failed for volume "pvc":
Attach timeout for volume yadp-k8s-volumes/pvc

Обновите драйвер s3-CSI до актуальной версии.

Ресурсы

Какие ресурсы требуются для обслуживания кластера Kubernetes, в который входит группа, например, из трех узлов?

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

Можно ли изменять ресурсы для каждого узла в кластере Kubernetes?

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

Кто будет следить за масштабированием кластера Kubernetes?

В Managed Service for Kubernetes можно включить автоматическое масштабирование кластера.

Логи

Как я могу отслеживать состояние кластера Managed Service for Kubernetes?

Получите статистику кластера. Описание доступных метрик кластера приводится в справочнике.

Я могу получить логи моей работы в сервисах?

Да, вы можете запросить информацию о работе с вашими ресурсами из логов сервисов Yandex Cloud. Подробнее читайте в разделе Запросы данных.

Можно ли самостоятельно сохранять логи?

Для сбора и хранения логов используйте Fluent Bit.

Можно ли использовать сервис Yandex Cloud Logging для просмотра логов?

Да, для этого настройте отправку логов в Cloud Logging при создании или изменении кластера Managed Service for Kubernetes. Настройка доступна только в CLI, Terraform и API.

Есть ли поддержка Horizontal Pod Autoscaler?

Да, Managed Service for Kubernetes поддерживает механизм горизонтального автомасштабирования подов (Horizontal Pod Autoscaler).

Решение проблем

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

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

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

Permission denied

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    kubectl proxy

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

    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:

  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 не превышает квоты:

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

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

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

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

  2. Проверьте состояние узлов 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 запустился, увеличьте квоты.

Ошибка при обновлении сертификата 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-запросов по нескольким причинам. Чтобы устранить проблему:

  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 и их состояние:

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

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

Убедитесь, что кластеру достаточно ресурсов 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

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

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

Ошибка при подключении к кластеру с помощью 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 в следующих ситуациях:

Как выдать доступ в интернет узлам кластера 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:

Примечание

Если вы назначили публичные 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) отключен.

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

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

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

Предыдущая
Решение проблем
Следующая
Обучающие курсы