Взаимосвязь ресурсов в 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 составляются по следующим правилам:

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

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

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

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

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

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

Мастер — компонент, который управляет кластером 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 выбор конфигурации мастера доступен в консоли управления.

Доступны следующие конфигурации мастера на платформе 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 с автоматически сгенерированными именами. Чтобы сконфигурировать узлы, воспользуйтесь инструкциями по управлению группами узлов.

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

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

• Тип ВМ.

• Тип и количество ядер (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"

Подробнее о 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.

Статистика кластера 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 без предустановленных драйверов