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

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

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

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

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

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

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

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

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

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

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

• Зональный — создается в подсети в одной зоне доступности.

• Региональный — создается распределенно в трех подсетях в каждой зоне доступности. При недоступности одной зоны региональный мастер остается работоспособным.

  Важно

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

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

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

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

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

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

• Тип ВМ.

• Тип и количество ядер (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-клиент и YC 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-политика группы узлов препятствует этому.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПодПод

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

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

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

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

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

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

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

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

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

По умолчанию сервис доступен только внутри конкретного кластера 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.

Статистика кластера 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.