Облачная платформаAdvanced

Принятие узлов для управления

Язык статьи: Русский
Показать оригинал
Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

Сценарий

В CCE вы можете создать узел (Creating a Node) или добавить существующие узлы (ECSs) в ваш кластер для управления.

Notice
  • При принятии ECS вы можете сбросить его ОС до стандартного публичного образа, предлагающегося CCE. Если вы решите это сделать, необходимо переустановить пароль или ключ, так как предыдущий станет недействительным.
  • Во время процесса принятия информация LVM, включая группы томов (VGs), логические тома (LVs) и физические тома (PVs), будет удалена с системных дисков и дисков с данными, подключённых к выбранным ECSs. Убедитесь, что эта информация была сохранена.
  • Во время принятия ECS не выполняйте никаких операций над ECS через консоль ECS.

Примечания и ограничения

  • ECSs могут управляться.

Предварительные требования

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

  • Узел, подлежащий принятию, должен быть Running или Stopped, не должен использоваться другими кластерами и не должен иметь метку CCE-Dynamic-Provisioning-Node.
  • Узел, подлежащий принятию, и кластер должны находиться в одной VPC. (Если версия кластера старше v1.13.10, принимаемый узел и кластер CCE должны находиться в одной подсети.)
  • Диски с данными должны быть подключены к управляемым узлам, если системные компоненты этих узлов хранятся отдельно. Такие узлы могут быть оснащены либо локальным диском (диск с высокой нагрузкой), либо диском с данными объёмом не менее 20 GiB. Кроме того, любые уже подключённые диски с данными не должны быть меньше 10 GiB.
  • Узел, подлежащий принятию, должен иметь минимум 2 ядра CPU, 4 GiB памяти и только один сетевой интерфейс.
  • Только облачные серверы с одинаковой конфигурацией дисков с данными могут быть приняты пакетно для управления.
  • Для кластеров с поддержкой IPv6 только узлы с включённым IPv6 в подсети кластера могут быть приняты.
  • Кластеры CCE Turbo требуют, чтобы каждый узел поддерживал дополнительные сетевые интерфейсы. В качестве альтернативы необходимо привязать не менее 16 сетевых интерфейсов к каждому узлу. Подробную информацию о флейворах узлов см. в параметрах, предлагаемых в консоли при создании узла.
  • Диски с данными, которые были разделены, будут игнорироваться при управлении узлом. Убедитесь, что к узлу присоединён хотя бы один неразделённый диск с данными, соответствующий спецификациям.

Процедура

  1. Войдите в CCE console и перейдите к кластеру, в котором находится узел, подлежащий принятию.
  2. В панели навигации выберите Nodes. На отображаемой странице нажмите вкладку Nodes, а затем Accept Node в правом верхнем углу.
  3. Укажите параметры узла.

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

    Table 1 параметры конфигурации узла

    Параметр

    Описание

    Node Pool

    • Default node pool: Вы можете добавить узлы, отвечающие требованиям управления, в default node pool кластера.
    • Custom node pool: Вам необходимо выбрать только узлы, отвечающие требованиям управления. Эти узлы будут использовать базовые, сетевые и расширенные настройки custom node pool. Другие параметры настраивать не требуется. Подробности см. в Accepting Nodes in a Node Pool.

    Спецификации

    Нажмите Select Cloud Server и выберите серверы, которые необходимо принять.

    Можно выбрать несколько cloud server для пакетного принятия, но только те, у которых одинаковые конфигурации Диска с данными, могут быть добавлены вместе.

    Если cloud server содержит несколько Дисков с данными, выберите один из них для container runtime и kubelet.

    Container Engine

    CCE поддерживает Docker или containerd в качестве container runtime. Доступные runtimes различаются в зависимости от типа кластера, версии и OS. Выберите runtime, отображаемый в консоли CCE.

    OS

    Выберите тип OS. Разные типы узлов поддерживают разные OS.

    • Public image: Выберите public image для узла.
    • Private image: Выберите private image для узла.
    • Shared image: Вы можете выбрать image, совместно используемый другими пользователями. Эта опция поддерживается узлами BMS и PM.
    ПРИМЕЧАНИЕ:

    Контейнерные runtimes сервиса используют общее ядро и базовые вызовы узлов. Чтобы обеспечить совместимость, выберите версию дистрибутива Linux, которая совпадает или близка к версии конечного service container image для OS узла.

    Login Mode

    • Password

      Имя пользователя по умолчанию — root. Введите пароль для входа в узел и подтвердите пароль.

      Обязательно запомните пароль, так как он понадобится при входе в node.

    • Key Pair

      Выберите key pair, используемый для входа в node. Private key pairs доступны только вам. Account key pairs общедоступны для всех пользователей в аккаунте.

      Key pair используется для аутентификации личности при удалённом входе в node. Если key pair недоступен, нажмите Create Key Pair.

    • Image password (поддерживается для ECSs или PMs, чьи ОС являются private images)

      Сохраните пароль выбранного image. Чтобы использовать эту опцию, убедитесь, что для выбранного image установлен пароль.

    Storage Settings

    Настройте ресурсы хранилища на node для работающих на нём containers.

    Table 2 Configuration parameters

    Parameter

    Description

    System Disk

    Непосредственно используйте system disk cloud server.

    Default Data Disk

    Выберите data disk для container runtime и kubelet.

    System Component Storage

    Выберите диск для хранения системных компонентов.

    • Data Disk: Необходимо добавить диск с данными по умолчанию для container runtime и kubelet. Этот диск с данными нельзя отсоединять. В противном случае узел будет недоступен.
    • System Disk: хранит ресурсы CCE, такие как загруженные образы, эфемерное хранилище для контейнеров и stdout‑логи контейнеров. Если системный диск полностью заполнен, это негативно скажется на стабильности узла.
    ПРИМЕЧАНИЕ:

    В кластерах v1.23.18-r0, v1.25.13-r0, v1.27.10-r0, v1.28.8-r0, v1.29.4-r0 и более новых можно выбрать диск для хранения системных компонентов. Если используется CCE Node Problem Detector, убедитесь, что его версия 1.19.2 или новее.

    Data Disk

    • Для хранения компонентов container runtime и kubelet должен быть доступен диск с данными по умолчанию, если System Component Storage установлен в значение Data Disk. Этот диск с данными нельзя отсоединять. В противном случае узел будет недоступен. Эта функция доступна для кластеров версии ранее v1.23.18-r0, v1.25.13-r0, v1.27.10-r0, v1.28.8-r0 или v1.29.4-r0.
    • Если System Component Storage установлен в значение System Disk, добавлять диск с данными по умолчанию не требуется. Все диски с данными являются дисками общего назначения. Эта функция доступна для кластеров v1.23.18-r0, v1.25.13-r0, v1.27.10-r0, v1.28.8-r0, v1.29.4-r0 и более новых версий.

    Нажмите Expand, чтобы настроить Data Disk Space Allocation. Это резервирует место для container runtime, образов и эфемерного хранилища, обеспечивая нормальную работу. Подробности о распределении места на диске с данными см. в Space Allocation of a Data Disk.

    Для остальных дисков с данными по умолчанию создаётся необработанный диск. Вы также можете нажать Expand и выбрать Mount Disk, чтобы смонтировать диск с данными в указанный каталог.

    Advanced Settings

    Table 3 Параметры расширенной конфигурации

    Parameter

    Description

    Resource Tag

    Вы можете добавлять теги ресурсов для классификации ресурсов. Можно добавить не более восьми тегов ресурсов.

    Вы можете создать предопределённые теги в консоли TMS. Эти теги доступны всем ресурсам, поддерживающим теги. Вы можете использовать эти теги для повышения эффективности создания тегов и миграции ресурсов.

    CCE автоматически создаст тег CCE-Dynamic-Provisioning-Node=Node ID.

    Kubernetes Label

    Нажмите Add Label, чтобы задать пару ключ‑значение, привязанную к объектам Kubernetes (например, pod'ам). Можно добавить не более 20 меток.

    Метки можно использовать для различения узлов. С настройками привязки нагрузки контейнерные pod'ы могут быть запланированы на указанный узел. Для получения дополнительной информации см. Labels and Selectors.

    Kubernetes Taint

    Этот параметр по умолчанию оставлен пустым. Вы можете добавить taint'ы для настройки анти‑аффинности узла. Для каждого узла допускается не более 20 taint'ов. Каждый taint содержит следующие параметры:

    • Taint Key: Ключ должен содержать от 1 до 63 символов, начинаться и заканчиваться буквой или цифрой. Разрешены только буквы, цифры, дефисы (-), подчёркивания (_) и точки (.). В качестве префикса ключа можно использовать имя поддомена DNS.
    • Taint Value: Значение должно содержать от 1 до 63 символов, начинаться и заканчиваться буквой или цифрой. Разрешены только буквы, цифры, дефисы (-), подчёркивания (_) и точки (.).
    • Effect: Доступные варианты: NoSchedule, PreferNoSchedule и NoExecute.

    NOTE:

    Если используются taint'ы, необходимо настроить tolerations pod'ов. В противном случае операции масштабирования могут завершиться неудачей, либо pod'ы могут не быть запланированы на добавленные узлы.

    Max. Pods

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

    Это ограничение предотвращает перегрузку узла pod'ами.

    Команда предустановки

    Команда скрипта установки. Команда скрипта будет транскодирована в Base64. Количество символов как предустановочных, так и постустановочных скриптов рассчитывается централизованно, и общее количество символов после транскодирования не может превышать 10 240.

    Скрипт предустановки выполняется до установки Kubernetes. Если он завершится с ошибкой, установка Kubernetes также завершится с ошибкой.

    Команда постустановки

    Команда скрипта установки. Команда скрипта будет транскодирована в Base64. Количество символов как предустановочных, так и постустановочных скриптов рассчитывается централизованно, и общее количество символов после транскодирования не может превышать 10 240.

    Скрипт будет выполнен после установки программного обеспечения Kubernetes, что не влияет на процесс установки. Во время выполнения постустановочного скрипта pod'ы могут планироваться нормально. Однако, если скрипт превышает время выполнения, установка узла завершается с ошибкой. Чтобы предотвратить планирование pod'ов на узлах с неполным выполнением скрипта, включите параметр планировать pod'ы только после завершения постустановочного скрипта.

    ВНИМАНИЕ:

    Не используйте команду reboot в постустановочном скрипте для немедленной перезагрузки системы. Вместо этого используйте команду shutdown -r 1 для перезагрузки системы с задержкой в одну минуту.

    Имя узла Kubernetes

    Имя узла Kubernetes — это значение metadata.labels.kubernetes.io/hostname в YAML‑файле узла. Поддерживаются следующие два значения:

    • Node private IP: Значение должно совпадать с частным IP‑адресом узла (значение по умолчанию).
    • Cloud server name: Используйте пользовательское имя облачного сервера, настроенное в параметрах узла. Имена облачных серверов не обязаны быть уникальными. Чтобы избежать конфликтов имён, CCE автоматически добавляет случайный пятизначный суффикс к каждому имени облачного сервера.
      ПРИМЕЧАНИЕ:
      • Эта функция доступна только когда версия кластера v1.23.4-r0 или новее.
      • Имя облачного сервера можно указать в качестве имени узла Kubernetes только при создании или управлении облачным сервером. После создания или управления облачным сервером имя узла Kubernetes изменить нельзя. Подробности см. ECS Names, Node Names, and Kubernetes Node Names.
      • Существующие узлы в кластере сохраняют свои частные IP-адреса в качестве имен узлов Kubernetes. Ново‑созданные или добавленные узлы используют вместо этого имена облачных серверов.

        Это несоответствие между именами узлов и частными IP-адресами может потребовать адаптации. Например, при настройке привязки узлов вы не можете использовать метку kubernetes.io/hostname:\u003cnode-private-IP-address\u003e для выбора конкретных узлов.

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

  4. нажмите Next: Confirm, просмотрите примечание по использованию, отметьте флажок и нажмите Submit.