Yandex Cloud
Поиск
Связаться с намиПодключиться
  • Истории успеха
  • Документация
  • Блог
  • Все сервисы
  • Статус работы сервисов
    • Доступны в регионе
    • Инфраструктура и сеть
    • Платформа данных
    • Контейнеры
    • Инструменты разработчика
    • Бессерверные вычисления
    • Безопасность
    • Мониторинг и управление ресурсами
    • AI Studio
    • Бизнес-инструменты
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Партнёрская программа
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Тарифы Yandex Cloud
    • Промоакции и free tier
    • Правила тарификации
  • Истории успеха
  • Документация
  • Блог
Проект Яндекса
© 2025 ТОО «Облачные Сервисы Казахстан»
Yandex Managed Service for Kubernetes
  • Сопоставление с другими сервисами Yandex Cloud
  • Начало работы
    • Взаимосвязь ресурсов сервиса
    • Релизные каналы и обновления
    • Шифрование
    • Сеть в Managed Service for Kubernetes
    • Сетевые настройки и политики кластера
    • Автоматическое масштабирование
    • Политика аудита
    • Внешние узлы кластера
    • Квоты и лимиты
    • Рекомендации по использованию Managed Service for Kubernetes
  • Управление доступом
  • Правила тарификации
  • Справочник Terraform
  • Метрики Monitoring
  • Аудитные логи Audit Trails
  • История изменений
  • Обучающие курсы

В этой статье:

  • Кластер Kubernetes
  • Метки кластера
  • Мастер
  • Вычислительные ресурсы мастера
  • Группа узлов
  • Конфигурация
  • Подключение к узлам группы
  • Политики taints и tolerations
  • Метки узлов
  • Под
  • Маскарадинг IP-адресов подов
  • Сервис
  • Пространство имен
  • Сервисные аккаунты
  • Статистика кластера Managed Service for Kubernetes
  • Примеры использования
  1. Концепции
  2. Взаимосвязь ресурсов сервиса

Взаимосвязь ресурсов в Managed Service for Kubernetes

Статья создана
Yandex Cloud
Улучшена
ShaposhnikovDV
Обновлена 3 июля 2025 г.
  • Кластер Kubernetes
    • Метки кластера
  • Мастер
    • Вычислительные ресурсы мастера
  • Группа узлов
    • Конфигурация
    • Подключение к узлам группы
    • Политики taints и tolerations
    • Метки узлов
  • Под
    • Маскарадинг IP-адресов подов
  • Сервис
  • Пространство имен
  • Сервисные аккаунты
  • Статистика кластера Managed Service for Kubernetes
  • Примеры использования

Примечание

В регионе Казахстан доступна только зона доступности kz1-a.

Примечание

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

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

Основная сущность, которой оперирует сервис, — кластер Kubernetes.

Кластер KubernetesКластер Kubernetes

Кластер Kubernetes состоит из мастера и одной или нескольких групп узлов. Мастер отвечает за управление кластером Kubernetes. На узлах запускаются контейнеризованные приложения пользователя.

Сервис полностью управляет мастером, а также следит за состоянием и работоспособностью группы узлов. Пользователь может управлять узлами напрямую, а также настраивать кластер Kubernetes с помощью консоли управления Yandex Cloud, CLI и API Managed Service for Kubernetes.

Важно

Группам узлов Kubernetes требуется доступ в интернет для скачивания образов и компонентов.

Предоставить доступ в интернет можно следующими способами:

  • Назначить каждому узлу в группе публичный IP адрес.
  • Настроить виртуальную машину в качестве NAT-инстанса.
  • Настроить NAT-шлюз.

При работе с кластером Kubernetes на инфраструктуре Yandex Cloud задействуются следующие ресурсы:

Ресурс Количество Комментарий
Подсеть 2 Kubernetes резервирует диапазоны IP-адресов, которые будут использоваться для подов и сервисов.
Публичный IP N В количество N входит:
* Один публичный IP для NAT-инстанса.
* Публичный IP каждому узлу в группе, если вы используете технологию one-to-one NAT.

Метки кластераМетки кластера

Для разделения кластеров Kubernetes по логическим группам используйте облачные метки.

Облачные метки для кластеров Kubernetes составляются по следующим правилам:

  • Параметры ключа метки:

    • Длина — от 1 до 63 символов.
    • Может содержать строчные буквы латинского алфавита, цифры, дефисы и подчеркивания.
    • Первый символ — буква.
  • Параметры значения метки:

    • Длина — до 63 символов.
    • Может содержать строчные буквы латинского алфавита, цифры, дефисы и подчеркивания.

Об управлении облачными метками читайте в разделе Изменение кластера.

Примечание

Кластеру нельзя назначить Kubernetes-метки.

МастерМастер

Мастер — компонент, который управляет кластером Kubernetes.

Мастер запускает управляющие процессы Kubernetes, которые включают сервер Kubernetes API, планировщик и контроллеры основных ресурсов. Жизненный цикл мастера управляется сервисом при создании или удалении кластера Kubernetes. Мастер отвечает за глобальные решения, которые выполняются на всех узлах кластера Kubernetes. Они включают в себя планирование рабочих нагрузок, таких как контейнерные приложения, управление жизненным циклом рабочих нагрузок и масштабированием.

Мастер бывает следующих типов, которые отличаются количеством хостов мастера и размещением в зонах доступности:

  • Базовый — содержит один хост мастера в одной зоне доступности. Такой мастер дешевле, но он не является отказоустойчивым. Прежнее название — зональный.

    Важно

    Базовый мастер тарифицируется как зональный и отображается в Yandex Cloud Billing как Managed Kubernetes. Zonal Master - small.

  • Высокодоступный — содержит три хоста мастера, которые вы можете разместить следующим образом:

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

    Внутренний IP-адрес высокодоступного мастера доступен только в пределах одной облачной сети Yandex Virtual Private Cloud.

    Прежнее название — региональный.

    Важно

    Высокодоступный мастер тарифицируется как региональный и отображается в Yandex Cloud Billing как Managed Kubernetes. Regional Master - small.

Подробнее о настройках мастера см. на странице Создание кластера Managed Service for Kubernetes.

Вычислительные ресурсы мастераВычислительные ресурсы мастера

По умолчанию для работы одного хоста мастера предоставляются следующие ресурсы:

  • платформа — Intel Cascade Lake;
  • гарантированная доля vCPU — 100%;
  • количество vCPU — 2;
  • объем RAM — 8 ГБ.

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

Примечание

Функциональность выбора и изменения конфигурации мастера находится на стадии Preview.

На стадии Preview выбор конфигурации мастера доступен в консоли управления.

Доступны следующие конфигурации мастера на платформе Intel Cascade Lake с гарантированной долей vCPU 100%:

  • Standard — стандартные хосты с соотношением объема RAM к vCPU, равным 4 к 1:

    Количество vCPU Объем RAM
    2 8
    4 16
    8 32
    16 64
    32 128
    64 256
    80 320
  • CPU optimized — хосты с уменьшенным соотношением RAM к vCPU, равным 2 к 1:

    Количество vCPU Объем RAM
    4 8
    8 16
    16 32
    32 64
  • Memory optimized — хосты с увеличенным соотношением RAM к vCPU, равным 8 к 1:

    Количество vCPU Объем RAM
    2 16
    4 32
    8 64
    16 128
    32 256

Изменение конфигурации мастера не требует остановки кластера Managed Service for Kubernetes.

Также доступна возможность запретить изменение конфигурации мастера.

Группа узловГруппа узлов

Группа узлов — группа ВМ с одинаковой конфигурацией в кластере Kubernetes, на которых запускаются пользовательские контейнеры.

Отдельные узлы в группах узлов — это виртуальные машины Yandex Compute Cloud с автоматически сгенерированными именами. Чтобы сконфигурировать узлы, воспользуйтесь инструкциями по управлению группами узлов.

Внимание

Не изменяйте параметры ВМ узлов, в том числе имена, сетевые интерфейсы и SSH-ключи, с помощью интерфейсов Compute Cloud или SSH-подключения к ВМ.

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

КонфигурацияКонфигурация

Примечание

В регионе Казахстан доступны только платформы standard-v3 (Intel Ice Lake) и standard-v3-t4i (Intel Ice Lake with T4i). Другие типы платформ, кластеры GPU и выделенные хосты недоступны.

При создании группы узлов вы можете сконфигурировать следующие параметры ВМ:

  • Тип ВМ.

  • Тип и количество ядер (vCPU).

  • Объем памяти (RAM) и диска.

  • Параметры ядра.

    • Безопасные (safe) параметры ядра изолированы между подами.
    • Небезопасные (unsafe) параметры влияют на работу не только подов, но и узла в целом. В Managed Service for Kubernetes нельзя изменять небезопасные параметры ядра, имена которых не были явно указаны при создании группы узлов.

    Примечание

    Указывайте только параметры ядра, которые принадлежат пространствам имен, например, net.ipv4.ping_group_range. Параметры, которые не принадлежат пространствам имен, например, vm.max_map_count, необходимо разрешать непосредственно в операционной системе или при помощи DaemonSet с контейнерами в привилегированном режиме после создания группы узлов Managed Service for Kubernetes.

    Подробнее о параметрах ядра см. в документации Kubernetes.

В одном кластере Kubernetes можно создавать группы с разными конфигурациями и размещать их в разных зонах доступности.

Для Managed Service for Kubernetes в качестве среды запуска контейнеров доступна только платформа containerd.

Подключение к узлам группыПодключение к узлам группы

К узлам группы можно подключаться следующими способами:

  • через SSH-клиент с помощью стандартной пары SSH-ключей, см. Подключение к узлу по SSH;
  • через SSH-клиент и CLI с помощью OS Login, см. Подключение к узлу через OS Login.

Политики taints и tolerationsПолитики taints и tolerations

Taints — это особые политики, которые присваиваются узлам в группе. С помощью taint-политик можно запретить некоторым подам выполняться на определенных узлах. Например, можно указать, что поды для рендеринга должны запускаться только на узлах с GPU.

Преимущества использования taint-политик:

  • политики сохраняются, когда узел перезапускается или заменяется новым;
  • при добавлении узлов в группу политики назначаются этому узлу автоматически;
  • политики автоматически назначаются новым узлам при масштабировании группы узлов.

Назначить taint-политику на группу узлов можно при создании или изменении группы. Если назначить taint-политику на уже созданную группу узлов или снять политику с группы, эта группа пересоздается. Сначала удаляются все узлы в группе, затем в нее добавляются узлы с новой конфигурацией.

Каждая taint-политика состоит из трех частей:

<ключ> = <значение>:<эффект>

Список доступных taint-эффектов:

  • NO_SCHEDULE — запретить запуск новых подов на узлах группы (уже запущенные поды продолжат работу);
  • PREFER_NO_SCHEDULE — избегать запуска подов на узлах группы, если для запуска этих подов есть свободные ресурсы в других группах;
  • NO_EXECUTE — завершить работу подов на узлах этой группы, расселить их в другие группы, а запуск новых подов запретить.

Tolerations — это исключения из taint-политик. С помощью tolerations можно разрешить определенным подам работать на узлах, даже если taint-политика группы узлов препятствует этому.

Tolerations бывают двух типов:

  • Equal — срабатывает, если в taint-политике и toleration совпадают ключ, значение и эффект. Используется по умолчанию.

  • Exists — срабатывает, если в taint-политике и toleration совпадают ключ и эффект. Значение ключа не учитывается.

Например, если для узлов в группе настроена taint-политика key1=value1:NoSchedule, разместить поды на узле с помощью tolerations можно так:

apiVersion: v1
kind: Pod
...
spec:
  ...
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoSchedule"

Или так:

apiVersion: v1
kind: Pod
...
spec:
  ...
  tolerations:
  - key: "key1"
    operator: "Exists"
    effect: "NoSchedule"

Примечание

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

Подробнее о taint-политиках и исключениях см. в документации Kubernetes.

Метки узловМетки узлов

Метки узлов — механизм группировки узлов в Managed Service for Kubernetes. Существуют два вида меток узлов:

  • Облачные метки — используются для логического разделения и маркировки ресурсов. Например, с помощью облачных меток можно следить за расходами на различные группы узлов. Обозначаются в CLI как template-labels и в Terraform — как labels.

    Облачные метки узлов составляются по следующим правилам:

    Параметры ключа метки:

    • Может содержать строчные буквы латинского алфавита, цифры и символы -_./\@.
    • Первый символ — буква.
    • Максимальная длина — 63 символа.

    Параметры значения метки:

    • Может содержать строчные буквы латинского алфавита, цифры и символы -_./\@.
    • Максимальная длина — 63 символа.

    Об управлении облачными метками читайте в разделе Изменение группы узлов.

  • Kubernetes-метки — используются для группировки объектов Kubernetes и распределения подов по узлам кластера. Обозначаются в CLI как node-labels и в Terraform — как node_labels.

    При назначении Kubernetes-меток указывайте характеристики узлов, по которым вы будете группировать объекты. Примеры Kubernetes-меток см. в документации Kubernetes.

    Набор Kubernetes-меток ключ: значение может быть определен для каждого объекта. Для него все ключи должны быть уникальными.

    Ключи Kubernetes-меток узлов могут состоять из двух частей: префикса и имени, которые разделены знаком /.

    Префикс — необязательная часть ключа. Требования к префиксу:

    • Должен быть поддоменом DNS — серия DNS-меток, разделенных точками ..
    • Длина — до 253 символов.
    • За последним символом — /.

    Имя — обязательная часть ключа. Требования к имени:

    • Длина — до 63 символов.
    • Может содержать строчные буквы латинского алфавита, цифры и символы -_..
    • Первый и последний символы — буква или цифра.

    Для значения действуют те же правила, что и для имени.

    Пример метки: app.kubernetes.io/name: mysql, где app.kubernetes.io/ — префикс, name — имя, mysql — значение.

    Для управления Kubernetes-метками доступны API Managed Service for Kubernetes и API Kubernetes. Их особенности:

    • Kubernetes-метки, добавленные через API Kubernetes, могут быть потеряны, так как во время обновления или изменения групп узлов часть узлов пересоздается с другим именем, а часть старых — удаляется.
    • Если Kubernetes-метки созданы через API Managed Service for Kubernetes, их не получится удалить через API Kubernetes. Иначе метки будут восстановлены после удаления.

    Важно

    Чтобы избежать потери меток, используйте API Managed Service for Kubernetes.

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

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

ПодПод

Под — запрос на запуск одного или более контейнеров на одном узле группы. В рамках кластера Kubernetes каждый под имеет уникальный IP-адрес, чтобы приложения не конфликтовали при использовании портов.

Контейнеры описываются в поде через объект, написанный на языке JSON или YAML.

Маскарадинг IP-адресов подовМаскарадинг IP-адресов подов

Если поду требуется доступ к ресурсам за пределами кластера, его IP-адрес будет заменен на IP-адрес узла, на котором работает под. Для этого в кластере используется механизм маскарадинга IP-адресов.

По умолчанию, маскарадинг включен в направлении всего диапазона IP-адресов, кроме направлений CIDR подов и CIDR адресов link-local.

Для реализации механизма маскарадинга на каждом узле кластера развернут под ip-masq-agent. Настройки этого пода хранятся в объекте ConfigMap с именем ip-masq-agent. Если необходимо отключить маскарадинг IP-адресов подов в определенном направлении, например, для доступа к ним через VPN или Yandex Cloud Interconnect, укажите в параметре data.config.nonMasqueradeCIDRs нужные диапазоны IP-адресов:

...
data:
  config: |+
    nonMasqueradeCIDRs:
      - <CIDR_IP-адресов_в_направлении_которых_не_требуется_маскарадинг>
...

Чтобы посмотреть, как строятся правила для маскарадинга IP-адресов в iptables на конкретном узле, подключитесь к узлу по SSH и выполните команду:

sudo iptables -t nat -L IP-MASQ -v -n

Подробнее см. на странице ip-masq-agent на GitHub.

СервисСервис

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

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

Пространство именПространство имен

Пространство имен — абстракция, которая логически изолирует ресурсы кластера Kubernetes и распределяет квоты на них. Это полезно для разделения ресурсов разных команд и проектов в одном кластере Kubernetes.

Сервисные аккаунтыСервисные аккаунты

В кластерах Managed Service for Kubernetes используется два типа сервисных аккаунтов:

  • Облачные сервисные аккаунты

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

    Подробнее см. в разделе Управление доступом в Managed Service for Kubernetes и Сервисные аккаунты.

  • Сервисные аккаунты Kubernetes

    Эти аккаунты существуют и действуют только на уровне отдельного кластера Managed Service for Kubernetes. Они применяются Kubernetes для:

    • Аутентификации запросов к API кластера от приложений, развернутых в кластере.
    • Настройки прав доступа для этих приложений.

    Набор сервисных аккаунтов Kubernetes автоматически создается в пространстве имен kube-system при развертывании кластера Managed Service for Kubernetes.

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

    Подробнее см. в Создание статического файла конфигурации, а также в документации Kubernetes.

Важно

Не путайте облачные сервисные аккаунты и сервисные аккаунты Kubernetes.

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

Статистика кластера Managed Service for KubernetesСтатистика кластера Managed Service for Kubernetes

Managed Service for Kubernetes автоматически отправляет метрики кластеров в сервис Yandex Monitoring. Доступны метрики следующих объектов Kubernetes:

  • контейнер;
  • мастер;
  • узел;
  • под;
  • постоянный том.

Метрики кластеров можно получить с помощью следующих инструментов:

  • консоль управления;
  • интерфейс Monitoring;
  • API Monitoring;
  • приложение Metrics Provider;
  • приложение Prometheus Operator.

Подробнее читайте в разделе Мониторинг состояния кластера Managed Service for Kubernetes.

Описание метрик приводится в разделе Справочник метрик Yandex Monitoring.

Примеры использованияПримеры использования

  • Создание и настройка кластера Kubernetes без доступа в интернет
  • Резервное копирование кластера Managed Service for Kubernetes в Object Storage
  • Мониторинг кластера с помощью Prometheus и Grafana
  • Изменение параметров сервера метрик
  • Использование групп узлов c GPU без предустановленных драйверов

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

Предыдущая
Использование Metrics Provider для трансляции метрик
Следующая
Релизные каналы и обновления
Проект Яндекса
© 2025 ТОО «Облачные Сервисы Казахстан»