Создание пула узлов

В этом разделе описывается, как создать пул узлов и выполнять операции с пулом узлов. Подробную информацию о работе пула узлов см. в Node Pool Overview.

1. Войдите в CCE console.
2. Нажмите имя кластера, чтобы открыть консоль кластера. Выберите Nodes в панели навигации. В правой панели нажмите вкладку Node Pools.
3. В правом верхнем углу страницы нажмите Create Node Pool.

   Базовые настройки

   Table 1 Базовые настройки

   Параметр	Описание
   Node Pool Name	Имя пула узлов. По умолчанию имя имеет формат Cluster name-nodepool-Random number. Если вы не хотите использовать формат имени по умолчанию, можете задать собственное имя.
   Enterprise Project	Этот параметр доступен только для enterprise‑пользователей, которые включили Enterprise Project, и версия кластера должна быть v1.21.15-r0, v1.23.14-r0, v1.25.9-r0, v1.27.6-r0, v1.28.4-r0 или более новой. После выбора enterprise project узлы будут созданы в node pool внутри этого проекта. Для управления кластерами и другими ресурсами, такими как узлы, load balancers и node security groups, можно использовать enterprise projects.

   Node Configuration

   Вы можете настроить Флейвор и OS cloud server, на котором работают ваши containerized applications.

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

   Parameter	Description
   Node Type	Выберите node type в соответствии с требованиями сервиса. Затем вы можете выбрать подходящий Флейвор из node flavor list. CCE standard clusters поддерживают следующие node types: ECS (VM): VM ECS используется в качестве cluster node. ECS (PM): QingTian-backed bare metal server используется в качестве cluster node. CCE Turbo clusters поддерживают следующие node types: ECS (VM): VM ECS используется в качестве cluster node. CCE Turbo cluster поддерживает только cloud servers, которые позволяют использовать несколько сетевых интерфейсов. Выберите тип сервера, отображаемый в консоли CCE. ECS (PM): QingTian-backed bare metal server используется в качестве cluster node.
   Specifications	Выберите node flavor в соответствии с требованиями сервиса. Доступные node flavor различаются в зависимости от регионов. Для получения подробной информации см. консоль CCE. NOTE: Если node pool настроен с несколькими node flavor, поддерживаются только flavor (которые могут находиться в разных AZ) одного и того же типа node. Например, node pool, состоящий из узлов general computing-plus, поддерживает только node flavor типа general computing-plus, но не flavor типа general computing. Узлы, добавляемые в один node pool, должны иметь одинаковый тип GPU. Например, если вы выбираете flavor nvidia-v100, вы не можете выбрать flavor nvidia-t4. В node pool можно добавить не более 20 node flavor (flavor в разных AZ учитываются отдельно). При добавлении node flavor вы можете выбрать несколько AZ, но их необходимо указать. После создания node pool flavor существующих узлов удалить нельзя.
   Container Runtime (Original Container Engine)	CCE поддерживает Docker или containerd в качестве container runtime. Доступные runtime различаются в зависимости от типа кластера, версии и OS. Выберите runtime, отображаемый в консоли CCE.
   OS	Выберите тип OS. Разные типы узлов поддерживают разные OS. Public image: Выберите публичный образ для узла. Private image: Выберите приватный образ для узла. Shared image: Вы можете выбрать образ, которым делятся другие пользователи. Эта опция поддерживается узлами BMS и PM. NOTE: Контейнерные runtime сервиса используют общий kernel и системные вызовы узлов. Чтобы обеспечить совместимость, выберите версию дистрибутива Linux, совпадающую или близкую к версии конечного образа контейнера сервиса для node OS.
   Самовосстановление при отказе узла	Если критический компонент узла выходит из строя из‑за переходного сбоя или аномального завершения, механизм самовосстановления автоматически обнаруживает и восстанавливает его, минимизируя влияние на сервис. Basic self-healing (включено по умолчанию, когда CCE Node Problem Detector не установлен): CCE автоматически обнаруживает и перезапускает компоненты на основе встроенных проверок состояния. Advanced self-healing (включено по умолчанию, когда CCE Node Problem Detector установлен): расширяет базовое самовосстановление, охватывая исключения kubelet, сбои среды выполнения контейнеров и условия только для чтения файловой системы. Allow node restart when a system or Kubernetes component fails: Эта опция доступна только в режиме advanced self-healing. При включении узел автоматически перезапускается, если обнаружен сбой системного или Kubernetes‑компонента. Подробнее см. Node Self-Healing. ВНИМАНИЕ: Перезапуск узла выселяет или прерывает все pod‑ы, работающие на нём. Убедитесь, что ваши нагрузки устойчивы к перезапуску узлов.
   Login Mode	Password Имя пользователя по умолчанию root. Введите пароль для входа в узел и подтвердите пароль. Обязательно запомните пароль, так как он понадобится при входе в узел. Key Pair Выберите key pair, используемый для входа в узел. Приватные key pair доступны только вам. Account key pair общедоступны всем пользователям аккаунта. Key pair используется для аутентификации личности при удалённом входе в узел. Если key pair недоступен, нажмите Create Key Pair. Image password (поддерживается для ECSs or PMs, чьи ОС являются приватными образами) Сохраните пароль выбранного образа. Чтобы использовать эту опцию, убедитесь, что для выбранного образа установлен пароль.

   Storage Settings

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

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

   Parameter	Description
   System Disk	Системный диск, используемый ОС узла. Значения находятся в диапазоне от 40 GiB до 1,024 GiB. Значение по умолчанию — 50 GiB. Для кластеров v1.28 и более новых минимальный размер системного диска составляет 20 GiB. Однако примерно 15 GiB зарезервировано для образа ОС узла, пакетов установки компонентов и журналов системных компонентов. Таким образом, доступное пространство равно общей ёмкости минус зарезервированное пространство. Недостаток места на диске может нарушить стабильность узла, поэтому настройте disk alarms для мониторинга свободной ёмкости.
   System Component Storage	Выберите диск для хранения системных компонентов. Data Disk: добавлен по умолчанию для хранения среды выполнения контейнеров и компонентов kubelet. Размер диска находится в диапазоне от 20 GiB до 32,768 GiB. Значение по умолчанию — 100 GiB. Этот диск с данными нельзя отсоединять, иначе узел станет недоступным. System Disk: хранит ресурсы CCE, такие как загруженные образы, временное хранилище для контейнеров и журналы stdout контейнеров. Если системный диск полностью заполнен, это негативно скажется на стабильности узла. NOTE: В кластерах v1.23.18-r0, v1.25.13-r0, v1.27.10-r0, v1.28.8-r0, v1.29.4-r0 и более новых можно выбрать место хранения системных компонентов. Если в кластере требуется дополнение CCE Node Problem Detector, установите версию v1.19.2 или более новую. Подробную информацию о данном дополнении см. в CCE Node Problem Detector.
   Data Disk	Для хранения компонентов контейнерного runtime и kubelet должен быть доступен диск с данными по умолчанию, если System Component Storage установлен в Data Disk. Этот диск с данными нельзя отсоединять. В противном случае узел будет недоступен. Диск с данными по умолчанию: используется для компонентов контейнерного runtime и kubelet. Размер диска варьируется от 20 GiB до 32 768 GiB. Значение по умолчанию — 100 GiB. Другие общие диски с данными: вы можете задать размер диска с данными в диапазоне от 10 GiB до 32 768 GiB. Значение по умолчанию — 100 GiB. Если System Component Storage установлен в System Disk, добавлять диск с данными по умолчанию не требуется. В этом случае все диски с данными являются общими. Вы можете задать размер диска с данными в диапазоне от 10 GiB до 32 768 GiB. Значение по умолчанию — 100 GiB. ПРИМЕЧАНИЕ: Если тип узла является дискоемким или ультра‑высоким I/O, один диск с данными может быть локальным диском. Локальные диски могут выйти из строя и не гарантируют надежность данных. Храните данные сервисов на дисках EVS, которые более надежны, чем локальные диски. Advanced Settings Для диска с данными по умолчанию, используемого контейнерным runtime и kubelet, разверните Advanced Settings и настройте следующие параметры: Data Disk Space Allocation: выделяет пространство для контейнерного runtime, образов и временного хранилища, необходимого для их корректной работы. Подробнее о распределении пространства диска с данными см. Space Allocation of a Data Disk. Write Mode: для диска с данными по умолчанию можно выбрать Linear или Striped. Data Disk Encryption: шифрование диска с данными защищает ваши данные. Снимки, созданные с зашифрованных дисков, и диски, созданные на основе этих снимков, автоматически наследуют настройку шифрования. Not encrypted выбран по умолчанию. Если вы выбираете Enable (key name) для Data Disk Encryption, выберите существующий ключ. Если ключ недоступен, нажмите View Key List и создайте ключ. После создания ключа нажмите значок обновления рядом с полем ввода. Если вы выбираете Enable (key ID) для Data Disk Encryption, введите KMS‑ключ (который может быть доступен другим) в текущем регионе. Добавление дисков с данными По умолчанию нестандартные диски с данными создаются как raw disks без какой-либо обработки. Количество дисков с данными, которые можно присоединить к узлу, зависит от флейвора узла. Подробности см. в консоли. Также можно нажать Expand и выбрать любой из следующих вариантов: Default: По умолчанию создаётся raw disk без какой-либо обработки. Mount Disk: Диск с данными присоединяется к указанному каталогу. Use as PV: Выберите эту опцию, когда есть высокие требования к производительности PV. Метка node.kubernetes.io/local-storage-persistent добавляется к узлу с настроенным PV. Значение — linear или striped. Use as ephemeral volume: применимо, когда есть высокие требования к производительности emptyDir. ПРИМЕЧАНИЕ: Local PV поддерживаются только при версии кластера v1.21.2-r0 или новее и версии дополнения Everest v2.1.23 или новее. Local EV поддерживаются только при версии кластера v1.21.2-r0 или новее и версии дополнения Everest v1.2.29 или новее. Если диск с данными не монтируется по умолчанию, поддерживаются следующие режимы записи: Linear: Линейный логический том объединяет один или несколько физических томов. Данные записываются на следующий физический том, когда предыдущий исчерпан. Striped: Полосатый логический том распределяет данные по блокам одинакового размера и сохраняет их последовательно в нескольких физических томах. Это позволяет одновременно читать и записывать данные. Пул хранения, состоящий из полосатых томов, нельзя масштабировать. Эта опция доступна только при наличии как минимум двух дисков с данными.

   Настройки сети

   Настройте сетевые ресурсы, чтобы обеспечить доступ узла и контейнеризованного приложения.

   Таблица 4 Параметры конфигурации

   Параметр	Описание
   VPC	VPC, к которой по умолчанию принадлежит кластер, изменить нельзя.
   Node Subnet	Подсеть узла, выбранная при создании кластера, используется по умолчанию. При необходимости можно выбрать другую подсеть. Несколько подсетей: можно выбрать несколько подсетей в одной VPC для узлов. Ново‑добавленные узлы будут предпочтительно использовать IP‑адреса из подсети с наивысшим приоритетом. Одна подсеть: для пула узлов настроена только одна подсеть. Если IP‑адресов в единственной подсети недостаточно, настройте несколько подсетей. В противном случае масштабирование пула узлов может завершиться неудачей. ВНИМАНИЕ: Если вы удалите подсеть из VPC, немедленно обновите конфигурацию подсетей пула узлов. В противном случае масштабирование будет постоянно завершаться неудачей из‑за отсутствия действительных подсетей.
   Node IP	Поддерживается случайное распределение.
   Associate Security Group	Группа безопасности, используемая узлами, созданными в пуле узлов. Для лучшей сетевой производительности выбирайте не более пяти групп безопасности. Когда создаётся кластер, по умолчанию создаётся и используется группа безопасности узла с именем {Имя кластера}-cce-node-{Случайный ID}. Трафику необходимо проходить через определённые порты в группе безопасности узла, чтобы обеспечить связь узлов. Убедитесь, что вы включили эти порты, если выбираете другую группу безопасности. ПРИМЕЧАНИЕ: После создания пула узлов связанная с ним группа безопасности изменить нельзя.

   Advanced Settings

   Настройте расширенные возможности узла, такие как метки, таинты и команду запуска.

   Таблица 5 Параметры расширенной конфигурации

   Parameter	Description
   Resource Tag	Вы можете добавлять теги ресурсов для классификации ресурсов. Вы можете создать predefined tags в консоли TMS. Эти теги доступны всем ресурсам, поддерживающим теги. Вы можете использовать эти теги для повышения эффективности создания тегов и миграции ресурсов. CCE автоматически создаст тег CCE-Dynamic-Provisioning-Node=Node ID.
   Kubernetes Label	Пара ключ‑значение, добавляемая к объекту Kubernetes (например, pod). После указания метки нажмите Add для получения дополнительной информации. Можно добавить не более 20 меток. Метки могут использоваться для различения узлов. С помощью настроек привязки нагрузки контейнерные pod могут быть запланированы на указанный узел. Для получения дополнительной информации см. Labels and Selectors.
   Kubernetes Taint	Этот параметр по умолчанию оставлен пустым. Вы можете добавить taint'ы для настройки анти‑привязки узла. Для каждого узла допускается максимум 20 taint'ов. Каждый taint содержит следующие параметры: Taint Key: Ключ должен содержать от 1 до 63 символов, начинаться и заканчиваться буквой или цифрой. Разрешены только буквы, цифры, дефисы (-), подчёркивания (_) и точки (.). В качестве префикса ключа можно использовать имя поддомена DNS. Taint Value: Значение должно содержать от 1 до 63 символов, начинаться и заканчиваться буквой или цифрой. Разрешены только буквы, цифры, дефисы (-), подчёркивания (_) и точки (.). Effect: Доступные варианты: NoSchedule, PreferNoSchedule и NoExecute. Для подробностей см. Managing Node Taints. ПРИМЕЧАНИЕ: Для кластера версии v1.19 или более ранней нагрузка могла быть запланирована на узел до добавления taint'а. Чтобы избежать такой ситуации, выберите кластер версии v1.19 или более новой.
   Синхронизация для существующих узлов	После выбора параметров изменения тегов ресурсов и меток/taint'ов Kubernetes в пуле узлов будут синхронизированы со всеми существующими узлами в этом пуле.
   Планирование новых узлов	Политика планирования по умолчанию для узлов, недавно добавленных в пул узлов. Если вы выберете Unschedulable, вновь созданные узлы в пуле будут помечены как unschedulable. Таким образом, вы можете выполнить некоторые операции над узлами до того, как pod'ы будут запланированы на эти узлы. Scheduled Scheduling: После включения запланированного планирования новые узлы будут автоматически запланированы после истечения пользовательского времени. Disabled: По умолчанию запланированное планирование для новых узлов не включено. Чтобы включить эту функцию вручную, перейдите к списку узлов. Для подробностей см. Configuring a Node Scheduling Policy in One-Click Mode. Custom: значение тайм‑аута по умолчанию для несоставляемых узлов. Диапазон значений от 0 до 99 в минутах. NOTE: Если также требуется автоматическое масштабирование пулов узлов, убедитесь, что запланированный интервал составляет менее 15 минут. Если узел, добавленный через Autoscaler, не может быть запланирован более 15 минут, Autoscaler определяет, что scale out не удалось, и инициирует другое scale out. Кроме того, если узел не может быть запланирован более 20 минут, Autoscaler выполнит scale in узла. После включения этой функции узлы будут помечены taint‑ом node.cloudprovider.kubernetes.io/uninitialized во время создания или обновления пула узлов.
   Max. Pods	Максимальное количество pod‑ов, которые могут работать на узле, включая pod‑ы системы по умолчанию. Это ограничение предотвращает перегрузку узла pod‑ами. Это число также определяется другими факторами. Подробности см. в Maximum Number of Pods That Can Be Created on a Node.
   ECS Group	Группа ECS логически объединяет ECS. ECS в одной группе ECS соответствуют одной политике, связанной с группой ECS. Anti-affinity: ECS в группе ECS размещаются на разных физических хостах для повышения надёжности сервиса. Выберите существующую группу ECS или нажмите Create Cloud Server Group, чтобы создать её. После создания группы ECS нажмите значок обновления.
   Pre-installation Script	Команда скрипта установки. Команда скрипта будет транскодирована в Base64. Символы в скриптах предустановки и постустановки рассчитываются централизованно, и общее количество символов после транскодирования не может превышать 10 240. Скрипт предустановки выполняется до установки Kubernetes. Если он завершится с ошибкой, установка Kubernetes также завершится с ошибкой.
   Post-installation Script	Команда скрипта установки. Команда скрипта будет транскодирована в Base64. Символы как в скрипте предустановки, так и в скрипте постустановки рассчитываются централизованно, и общее количество символов после транскодирования не может превышать 10,240. Скрипт будет выполнен после установки программного обеспечения Kubernetes, что не влияет на установку. Во время выполнения скрипта постустановки pod‑ы могут планироваться нормально. Однако, если скрипт превышает время ожидания, установка узла завершается с ошибкой. Чтобы предотвратить планирование pod‑ов на узлах с неполным выполнением скрипта, включите параметр планировать pod‑ы только после завершения скрипта постустановки. ВНИМАНИЕ: Не используйте команду reboot в скрипте постустановки для немедленной перезагрузки системы. Вместо этого используйте команду shutdown -r 1 для перезагрузки системы с задержкой в одну минуту.
   Agency	Если вам необходимо предоставить ресурсы облачных серверов другим учетным записям или делегировать более профессиональному сотруднику или команде управление ресурсами, вы можете создать агентство в IAM и предоставить агентству права на управление ресурсами облачных серверов. Делегированная учетная запись может войти в облачную систему и переключиться на ваш аккаунт для управления ресурсами. Вам не требуется делиться учетными данными (например, паролями) с другими учетными записями, что обеспечивает безопасность вашего аккаунта. Если вы создали агентство, выберите агентство из раскрывающегося списка. Если агентство недоступно, нажмите Create Agency справа, чтобы создать его.
   Custom Prefix and Suffix	Пользовательский префикс и суффикс имени узла в пуле узлов. После настройки узлы в пуле будут именоваться с использованием заданного префикса и суффикса. Например, если префикс prefix-, а суффикс -suffix, узлы в пуле будут иметь имя в формате "prefix-Node pool name with five-digit random characters-suffix". УВЕДОМЛЕНИЕ: Имя узла может содержать не более 56 символов в формате "Prefix-Node pool name with five-digit random characters-Suffix". Префикс и суффикс могут содержать строчные буквы, цифры, точки (.) и дефисы (-). Точка должна сразу предшествоваться или следовать за строчной буквой или цифрой. Префикс должен начинаться со строчной буквы; суффикс должен заканчиваться строчной буквой или цифрой. Имя узла не поддерживает комбинацию точки (.) со специальными символами (например, .., .- или -.). Эта функция доступна только в кластерах версий v1.28.1, v1.27.3, v1.25.6, v1.23.11, v1.21.12 и более новых.
   Имя узла Kubernetes	Имя узла Kubernetes — это значение metadata.labels.kubernetes.io/hostname в YAML‑файле узла. Поддерживаются следующие два значения: Node private IP: Значение должно совпадать с частным IP‑адресом узла (значение по умолчанию). Cloud server name: Используйте пользовательское имя облачного сервера, настроенное в параметрах узла. Имена облачных серверов не обязаны быть уникальными. Чтобы избежать конфликтов имён, CCE автоматически добавляет случайный пятизначный суффикс к каждому имени облачного сервера. NOTICE: Эта функция доступна только при версии кластера 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.
5. Прочитайте инструкции, отметьте флажок подтверждения и нажмите Submit.