Кластеры CCE standard и Turbo предоставляют корпоративного уровня Kubernetes хостинг кластеров, поддерживающий полное управление жизненным циклом контейнеризованных приложений. Они предлагают высокомасштабируемое, высокопроизводительное решение для развертывания и управления облачными нативными приложениями. На CCE console вы можете легко создавать кластеры CCE standard и Turbo. После создания кластера CCE размещает master nodes. Вам необходимо создать только worker nodes. Таким образом можно реализовать экономичное O&M и эффективное развертывание сервисов.
Перед покупкой кластера CCE standard или Turbo рекомендуется ознакомиться с What Is CCE, Networking Overview и Planning CIDR Blocks for a Cluster.
Шаг 1: Настройка базовых параметров
Базовые параметры определяют основную архитектуру и базовые правила ресурсов кластера, обеспечивая основу для работы кластера и распределения ресурсов.
- Войдите в CCE console. В левом верхнем углу страницы нажмите
и выберите регион для вашего кластера. Чем ближе выбранный регион к региону развертывания ресурсов, тем ниже задержка сети и тем быстрее доступ.После подтверждения региона нажмите Buy Cluster. Если вы используете CCE впервые, необходимо создать агентство согласно инструкциям.
- Настройте базовые параметры кластера. Подробности см. в Table 1.
Table 1 Базовые параметры (для CCE standard и Turbo кластеров) Parameter
Description
Modifiable After Cluster Creation
Type
Выберите CCE Turbo Cluster или CCE Standard Cluster по требованию.
- Кластеры CCE standard предоставляют высоконадежные и безопасные контейнеры для коммерческого использования.
- Кластеры CCE Turbo используют высокопроизводительную облачно‑нативную сеть. Такие кластеры обеспечивают облачно‑нативное гибридное планирование, достигая более высокой утилизации ресурсов и более широкого охвата сценариев.
Для получения подробной информации см. Comparison Between Cluster Types.
No
Billing Mode
Выберите billing mode для кластера по мере необходимости.
- Pay-per-use: постоплатный режим биллинга. Он подходит для сценариев, когда ресурсы будут оплачиваться в зависимости от частоты и длительности использования. Вы можете создавать или удалять ресурсы в любое время.
Yes
Cluster Name
Введите cluster name. Каждый cluster name в одном аккаунте должен быть уникальным.
Имя может содержать от 4 до 128 символов. Оно может начинаться со строчной буквы и не может заканчиваться дефисом (-). Разрешены только строчные буквы, цифры и дефисы (-).
Yes
Enterprise Project
Этот параметр доступен только для корпоративных пользователей, которые включили Enterprise Project.
После выбора Enterprise Project кластеры и их группы безопасности будут созданы в этом проекте. Для управления кластерами и другими ресурсами, такими как узлы, балансировщики нагрузки и группы безопасности узлов, вы можете использовать Enterprise Project.
Yes
Cluster Version
Выберите версию Kubernetes. Последняя коммерческая версия предоставляет более стабильные, надёжные функции и рекомендуется.
Yes
Cluster Scale
Выберите масштаб кластера по требованию. Этот параметр определяет максимальное количество рабочих узлов, которыми может управлять кластер.
Yes
Созданный кластер может быть только масштабирован в сторону увеличения. Подробнее см. Changing a Cluster Scale.
Master Nodes
Выберите количество мастер‑узлов. Мастер‑узлы автоматически размещаются CCE и разворачиваются с компонентами управления кластером Kubernetes, такими как kube-apiserver, kube-controller-manager и kube-scheduler.
- 3 (HA): Будут созданы три мастер‑узла для высокой доступности кластера.
- Single: В вашем кластере будет создан только один мастер‑узел.NOTE:
Если в кластере CCE несколько мастер‑узлов и более половины из них неисправны, кластер не сможет работать корректно.
Вы также можете выбрать AZs для развертывания мастер‑узлов конкретного кластера. По умолчанию AZs автоматически назначаются для мастер‑узлов.
- Automatic: Мастер‑узлы случайным образом распределяются по разным AZs для обеспечения DR кластера. Если доступных AZs недостаточно, CCE будет отдавать приоритет назначению узлов в AZs с достаточными ресурсами для гарантии создания кластера. Однако это может повлиять на DR на уровне зоны.
- Custom: Master nodes развернуты в конкретных AZ.
Если в кластере один master node, выберите AZ для master node по необходимости. Если в кластере несколько master node, вы можете выбрать несколько AZ.
- AZ: Master nodes развернуты в разных AZ для DR кластера.
- Host: Master nodes развернуты на разных хостах в одном AZ для DR кластера.
- Custom: Master nodes развернуты в указанных вами AZ.
No
После создания кластера количество master node и AZ, в которых они развернуты, изменить нельзя.
Step 2: Configure Network Settings
Конфигурация сети следует иерархической системе управления. Она обеспечивает сквозную сетевую связность и гарантию безопасности для контейнеризованных приложений посредством совместной настройки cluster networks, container networks и Service networks.
- Cluster network: обеспечивает связь между узлами, передавая трафик pod и Service, одновременно обеспечивая связность инфраструктуры кластера и безопасность.
- Container network: назначает каждому pod независимый IP-адрес, позволяя прямую связь контейнеров и межузловую связь.
- Service network: создает стабильную точку доступа, поддерживает балансировку нагрузки и оптимизирует управление трафиком для Services внутри кластера.
Перед настройкой параметров сети рекомендуется изучить концепции и взаимосвязи трех типов сетей. Подробнее см. Networking Overview.
Configuring Network Settings for a CCE Standard Cluster
- Настройте параметры cluster network. Подробнее см. Table 2.
Таблица 2 Настройки сети кластера Параметр
Описание
Изменяемо после создания кластера
VPC
Выберите VPC для кластера.
Если VPC недоступен, нажмите Create VPC, чтобы создать его. После создания VPC нажмите значок обновления.
Нет
Default Node Subnet
Выберите подсеть. После выбора все узлы в кластере автоматически будут использовать IP‑адреса, назначенные в этой подсети. При создании узла или node pool настройки подсети можно переустановить.
Нет
IPv6
После включения этой функции кластер поддерживает двойной стек IPv4/IPv6, что означает, что каждый рабочий узел может иметь как IPv4‑адрес, так и IPv6‑адрес. Оба IP‑адреса поддерживают доступ из частной и публичной сети. Перед включением функции убедитесь, что Default Node Subnet включает IPv6‑CIDR‑блок.
- Стандартные кластеры CCE (использующие сети VPC): IPv6 не поддерживается.
Нет
Default Node Security Group
Выберите Auto generate. Для кластера будут автоматически созданы две группы безопасности. Вы также можете выбрать существующие группы безопасности.
Группы безопасности должны разрешать трафик через определённые порты для обеспечения нормального взаимодействия. В противном случае узлы не могут быть созданы.
Yes
- Настройте параметры сети Под. Подробности см. в Table 3.
Table 3 Настройки сети Под Parameter
Description
Modifiable After Cluster Creation
Network Model
Модель сети, используемая контейнерной сетью в кластере.
- VPC network: применяется к небольшим кластерам (с 1 000 узлами или менее), требующим высокой производительности, например, AI‑вычислениям и обработке больших данных.
- Tunnel network: применяется к крупным кластерам (до 2 000 узлов) и сценариям, не требующим высокой производительности, таким как веб‑приложения и сервисы обработки и хранения данных с низким уровнем доступа.
Для получения более подробной информации об их различиях см. Overview.
No
DataPlane V2 (поддерживается кластерами, использующими VPC networks)
eBPF используется на уровне ядра для ускорения сети Kubernetes, улучшая высокопроизводительное взаимодействие сервисов через ClusterIP Services, точный контроль трафика с помощью network policies и интеллектуальное управление пропускной способностью с egress bandwidth. Для получения подробной информации см. DataPlane V2.
У этой функции есть ограничения, перечисленные ниже. Вы также можете просмотреть ограничения в DataPlane V2.
- Ограничения для кластеров: эту функцию можно включить только для кластеров v1.27.16-r30, v1.28.15-r20, v1.29.13-r0, v1.30.10-r0, v1.31.6-r0 или более новых, использующих VPC networks.
- Ограничения по памяти: после включения этой функции CCE автоматически развернёт cilium-agent на каждом узле кластера. Каждый cilium-agent будет использовать 80 MiB памяти, а использование памяти будет увеличиваться на 10 KiB при добавлении нового pod.
- Ограничения по ОС: после создания кластера узлы в кластере могут работать только на HCE OS 2.0 или Ubuntu 22.04.
No
Network Policies (поддерживается кластерами, использующими tunnel networks)
Сетевой контроль на основе политик для кластера. Для получения подробной информации см. Configuring Network Policies to Restrict Pod Access.
После включения этой функции, если CIDR‑блоки сервиса клиента конфликтуют с CIDR‑блоками on‑premises, ссылка на недавно добавленный шлюз может не быть установлена.
Например, если кластер использует соединение Direct Connect для доступа к внешнему адресу, внешнее коммутирующее устройство не поддерживает ip‑option. Включение network policies в этом сценарии может привести к сбою сетевого доступа.
Yes
Container CIDR Block
CIDR‑блок, используемый контейнерами. Этот параметр определяет максимальное количество контейнеров в кластере. Стандартные кластеры CCE поддерживают:
- Manually set: Вы можете настроить CIDR‑блоки контейнеров по мере необходимости. Для сквозного сетевого взаимодействия между VPC, убедитесь, что CIDR‑блок контейнеров не перекрывается с VPC CIDR‑блоком, к которому требуется доступ, чтобы избежать конфликтов. Для получения подробной информации см. Planning CIDR Blocks for a Cluster. Модель VPC сети позволяет настраивать несколько CIDR‑блоков, и CIDR‑блоки контейнеров могут быть добавлены даже после создания кластера. Для получения подробной информации см. Adding a Container CIDR Block for a Cluster That Uses a VPC Network.
- Auto select: CCE случайным образом выделит не конфликтующий CIDR‑блок из диапазонов 172.16.0.0/16‑172.31.0.0/16 или из 10.0.0.0/12, 10.16.0.0/12, 10.32.0.0/12, 10.48.0.0/12, 10.64.0.0/12, 10.80.0.0/12, 10.96.0.0/12 и 10.112.0.0/12. Поскольку выделенный CIDR‑блок нельзя изменить после создания кластера, рекомендуется вручную настроить CIDR‑блоки, особенно в коммерческих сценариях.ПРИМЕЧАНИЕ:
После создания кластера, использующего сеть контейнерных туннелей, CIDR‑блок контейнера нельзя расширять позже. Чтобы предотвратить исчерпание IP‑адресов, рекомендуется задать CIDR‑блок контейнера с максимальной длиной маски 19 бит.
No
После создания кластера, использующего сеть VPC, вы можете добавить CIDR‑блоки контейнера в кластер, но нельзя изменить или удалить существующие.
Reserved Pod IP Per Node (поддерживается кластерами, использующими сети VPC)
Количество IP‑адресов pod, которые могут быть выделены в сети контейнеров (alpha.cce/fixPoolMask). Этот параметр определяет максимальное количество pod, которые могут быть созданы на каждом узле. Pod, использующие сети хоста, не занимают зарезервированные IP‑адреса.
В a container network каждый pod получает уникальный IP‑адрес. Если количество зарезервированных IP‑адресов pod для каждого узла недостаточно, pod создать нельзя. Подробности см. в Number of Reserved Pod IP Addresses Per Node.
No
- Настройте параметры сети Service. Подробности см. в Table 4.
Table 4 настройки сети Service Параметр
Описание
Изменяемый после создания кластера
Service CIDR Block
Настройте диапазон IP-адресов для ClusterIP Services в кластере. Этот параметр управляет максимальным количеством ClusterIP Services в кластере. ClusterIP Services обеспечивают связь между контейнерами в кластере. Блок Service CIDR не может перекрываться с подсетью узла или блоком container CIDR.
No
Request Forwarding
Настройте балансировку нагрузки и переадресацию маршрутов трафика Service в кластере. Доступно несколько вариантов. Для подробностей см. Comparing iptables, nftables, and IPVS.
- nftables: режим высокопроизводительной переадресации, устраняющий узкие места производительности iptables и ограничения масштабируемости при больших нагрузках. Он предоставляет единый фреймворк конфигурации для управления правилами нескольких протоколов. Этот вариант доступен только в кластерах v1.35 и более поздних.
- iptables: традиционный режим kube-proxy. Применяется в сценарии, когда количество Services небольшое или одновременно устанавливается большое количество коротких соединений с клиентом. Кластеры IPv6 не поддерживают iptables.
- IPVS: обеспечивает более высокую пропускную способность и более быструю переадресацию. Подходит для больших кластеров или когда количество Services велико.
No
Настройка сетевых параметров для CCE Turbo Cluster
- Настройте параметры сетевого кластера. Для подробностей см. Table 5.
Table 5 Настройки сетевого кластера Параметр
Описание
Изменяемо после создания кластера
VPC
Выберите VPC для кластера.
Если VPC недоступен, нажмите Create VPC, чтобы создать его. После создания VPC нажмите refresh icon.
No
Default Node Subnet
Выберите подсеть. После выбора все узлы в кластере автоматически будут использовать IP‑адреса, назначенные в этой подсети. При создании узла или пула узлов настройки подсети можно переустановить.
No
IPv6
После включения этой функции кластер поддерживает двойной стек IPv4/IPv6, что означает, что каждый рабочий узел может иметь как IPv4‑адрес, так и IPv6‑адрес. Оба IP‑адреса поддерживают доступ из частной и публичной сети. Перед включением функции убедитесь, что Default Node Subnet содержит IPv6 CIDR block.
- Стандартные кластеры CCE (использующие сети VPC): IPv6 не поддерживается.
No
Default Node Security Group
Выберите Auto generate. Для кластера будут автоматически созданы две группы безопасности. Вы также можете выбрать существующие группы безопасности.
Группы безопасности должны разрешать трафик по определённым портам для обеспечения нормального взаимодействия. В противном случае узлы не могут быть созданы.
Yes
- Настройте параметры сети pod. Подробности см. в Table 6.
Таблица 6 Pod настройки сети Параметр
Описание
Изменяемый после создания кластера
Сетевая модель
Сетевая модель, используемая контейнерной сетью в кластере. Поддерживается только Cloud Native Network 2.0.
Для получения более подробной информации об этой сетевой модели см. Overview.
Нет
DataPlane V2
Для ускорения сети Kubernetes на уровне ядра используется eBPF, повышая производительность коммуникаций сервисов через ClusterIP Services, обеспечивая точный контроль трафика с помощью сетевых политик и интеллектуальное управление пропускной способностью при исходящем трафике. Для подробностей см. DataPlane V2.
Эта функция имеет следующие ограничения. Вы также можете просмотреть ограничения в DataPlane V2.
- Ограничения для кластеров: Эта функция доступна коммерчески для кластеров версии v1.34.3-r10 и новее.
- Ограничения по памяти: После включения этой функции CCE автоматически развернёт cilium-agent на каждом узле кластера. Каждый cilium-agent будет использовать 80 MiB памяти, а использование памяти будет увеличиваться на 10 KiB при добавлении нового pod.
- Ограничения по ОС: После создания кластера узлы в кластере могут работать только на HCE OS 2.0 или Ubuntu 22.04.
Нет
Pod Subnet
Выберите подсеть, к которой относится pod. Если подсеть недоступна, нажмите Create Subnet, чтобы создать её. Подсеть pod определяет максимальное количество контейнеров в кластере. Вы можете добавить подсети pod после создания кластера.
Yes
Default Security Group
Выберите security group, автоматически созданную CCE, или выберите существующую. Этот параметр управляет входящим и исходящим трафиком для предотвращения неавторизованного доступа.
Security group контейнеров должна разрешать доступ через указанные порты, чтобы обеспечить нормальное взаимодействие контейнеров в кластере.
Yes
- Настройте параметры сети Service. Подробности см. в Table 7.
Table 7 Service network settings Parameter
Description
Modifiable After Cluster Creation
Service CIDR Block
Настройте диапазон IP-адресов для ClusterIP Services в кластере. Этот параметр определяет максимальное количество ClusterIP Services в кластере. ClusterIP Services обеспечивают связь между контейнерами в кластере. Блок Service CIDR не может пересекаться с node subnet или container CIDR block.
No
Перенаправление запросов
Настройте балансировку нагрузки и перенаправление маршрутов трафика Service в кластере. Доступно несколько вариантов. Для получения подробной информации см. Comparing iptables, nftables, and IPVS.
- nftables: режим высокопроизводительного перенаправления, устраняющий узкие места производительности iptables и ограничения масштабируемости при больших нагрузках. Он предоставляет единый фреймворк конфигурации для управления правилами нескольких протоколов. Этот вариант доступен только в кластерах версии v1.35 и новее.
- iptables: традиционный режим kube-proxy. Применяется в сценарии, когда количество Service небольшое или одновременно устанавливается большое число коротких соединений с клиентом. Кластеры IPv6 не поддерживают iptables.
- IPVS: обеспечивает более высокую пропускную способность и более быстрое перенаправление. Подходит для больших кластеров или когда имеется большое количество Service.
No
IPv6 Service CIDR Block
Настройте IPv6-адреса для Service. Этот параметр доступен только после включения IPv6.
No
(Optional) Step 3: Настройте расширенные параметры
Расширенные параметры расширяют и усиливают предыдущие настройки, повышая безопасность, стабильность и соответствие требованиям в кластерах. Это достигается за счёт возможностей, таких как улучшенная аутентификация, управление ресурсами и механизмы безопасности.
Parameter | Description | Modifiable After Cluster Creation |
|---|---|---|
IAM Authentication | Кластеры CCE поддерживают аутентификацию IAM. Вы можете вызывать аутентифицированные IAM API для доступа к кластерам CCE. | No |
Certificate Authentication | Certificate authentication используется для аутентификации личности и контроля доступа. Он гарантирует, что только уполномоченные пользователи или сервисы могут получать доступ к определённым кластерам.
| No |
CPU Management | Политики управления CPU позволяют точно контролировать распределение CPU для pod‑ов. Подробнее см. CPU Policy.
| Yes |
Secret Encryption | Secret encryption определяет режим шифрования секретов в кластере CCE.
NOTE: Чтобы использовать эту функцию, отправьте запрос в службу поддержки. | No |
Overload Control | После включения этой функции одновременные запросы будут динамически контролироваться в зависимости от требований к ресурсам, получаемых мастер‑узлами, обеспечивая стабильную работу мастер‑узлов и кластера. Подробнее см. Enabling Overload Control for a Cluster. | Yes |
Cluster Deletion Protection | Мера, принимаемая для предотвращения случайного удаления кластеров через консоль или API. После включения этой функции вы не сможете удалить или отписаться от кластеров в CCE. Статус функции можно изменить в Settings после создания кластеров. | Да |
Time Zone | Запланированные задачи кластера и узлы подчиняются выбранному часовому поясу. | Нет |
Resource Tag | Добавление тегов к ресурсам позволяет выполнять пользовательскую классификацию и организацию. Можно добавить не более 20 тегов ресурса. Вы можете создать predefined tags в консоли TMS. Эти теги доступны всем ресурсам, поддерживающим теги. Вы можете использовать эти теги для повышения эффективности создания тегов и миграции ресурсов.
| Да |
Description | Информация о кластере, помогающая пользователям и администраторам быстро понять базовую конфигурацию, статус и использование кластера. Допускается не более 200 символов. | Да |
Step 4: Select Add-ons
CCE предоставляет разнообразные дополнения для расширения функций кластера и повышения функциональности и гибкости контейнеризованных приложений. Вы можете выбирать дополнения по мере необходимости. Некоторые базовые дополнения по умолчанию помечаются как обязательные. Если базовые дополнения не установлены во время создания кластера, их можно добавить позже на странице Add-ons после создания кластера.
- Click Next: Select Add-on. На отображённой странице выберите add-on, которые будут установлены при создании кластера.
- Выберите базовые add-on, чтобы обеспечить нормальную работу кластера. Подробности см. Table 9.
Table 9 Basic add-ons Add-on
Description
CCE Container Network (Yangtse CNI)
Это базовый add-on кластера. Он обеспечивает сетевое подключение, публичный доступ и изоляцию безопасности для pod‑ов в вашем кластере.
Этот add-on устанавливается по умолчанию. Это облачная нативная система хранения контейнеров, основанная на CSI, и поддерживает облачные сервисы хранения, такие как EVS.
Этот add-on устанавливается по умолчанию. Он обеспечивает DNS‑разрешение для вашего кластера и может использоваться для доступа к DNS‑серверу в облаке.
(Optional) После выбора этого add-on CCE автоматически установит его. NodeLocal DNSCache повышает производительность DNS кластера, запуская DNS‑кеш‑прокси на узлах кластера.
(Optional) После выбора этого add-on CCE автоматически установит его и задаст Volcano в качестве планировщика по умолчанию для кластера. Это позволит вам использовать расширенные возможности планирования для пакетных вычислений и высокопроизводительных вычислений.
- Выберите дополнения наблюдаемости, чтобы воспользоваться полной функцией наблюдаемости. Для получения подробной информации см. Table 9.
Table 10 Дополнения наблюдаемости Add-on
Description
(Optional) После выбора этого дополнения CCE автоматически установит его. Это дополнение собирает метрики мониторинга вашего кластера и передаёт их в AOM. Режим агента не поддерживает HPA, основанный на пользовательских запросах Prometheus. Если требуются связанные функции, установите это дополнение вручную после создания кластера.
(Optional) После выбора этого дополнения CCE автоматически установит его. Это дополнение помогает передавать логи в LTS. После создания кластера вы можете получать и управлять правилами сбора на странице Logging консоли кластера CCE.
(Optional) После выбора этого дополнения CCE автоматически установит его для обнаружения неисправностей и изоляции узлов с целью быстрой отладки кластера.
Step 5: Configure Add-ons
Настройте выбранные дополнения, чтобы обеспечить их стабильную и точную работу и соответствие требованиям сервиса.
Дополнения потребляют определённые ресурсы после установки. Убедитесь, что ресурсов узла достаточно. Для получения подробной информации о потреблении ресурсов см. консоль.
- нажмите Next: Configure Add-on.
- Настройте базовые дополнения. Для получения подробной информации см. Table 11.
Table 11 Базовые настройки дополнения Add-on
Description
CCE Container Network (Yangtse CNI)
Это дополнение не настраивается.
CCE Container Storage (Everest)
Это дополнение настраиваемо. Вы можете нажать Modify справа от дополнения.
CoreDNS
Это дополнение настраиваемо. Вы можете нажать Modify справа от дополнения.
NodeLocal DNSCache
Это дополнение настраиваемо. Вы можете нажать Modify справа от дополнения.
- Настройте дополнения наблюдаемости. Для получения подробностей см. Table 12. Чтобы изменить настройки дополнения, нажмите Modify справа от дополнения.
Table 12 Настройки наблюдаемости Add-on
Description
Мониторинг Cloud Native Cluster
Выберите экземпляр AOM для Cloud Native Cluster Monitoring, чтобы отправлять метрики. Если экземпляр AOM недоступен, нажмите Create Instance, чтобы создать его.
Сбор Log Cloud Native
Выберите журналы для сбора. Если включено, будет автоматически создана log group с именем k8s-log-{cluster-ID}, и для каждого выбранного типа журнала будет создан log stream.
- Container logs: собираются журналы стандартного вывода контейнеров. Соответствующий log stream называется в формате stdout-{cluster-ID}.
- Kubernetes events: собираются журналы Kubernetes. Соответствующий log stream называется в формате event-{cluster-ID}.
- Kubernetes audit logs: собираются журналы аудита мастер‑узлов. Log streams называются в формате audit-{cluster-ID}.
- Control plane logs: собираются журналы критических компонентов, таких как kube-apiserver, kube-controller-manager и kube-scheduler, работающих на мастер‑узлах. Log streams называются в формате kube-apiserver-{cluster-ID}, kube-controller-manager-{cluster-ID} и kube-scheduler-{cluster-ID} соответственно.
Если сбор Log отключён, выберите Logging в navigation pane консоли кластера после создания кластера и включите эту опцию.
Обнаружитель проблем узлов CCE
-
Шаг 6: Подтверждение настроек
Нажмите Next: Confirm Settings. Отображается список ресурсов кластера. Подтвердите информацию, прочитайте и отметьте check box, и нажмите Submit.
Создание кластера занимает около 5–10 минут. Вы можете нажать Back to Clusters, чтобы выполнить другие операции с кластером, или нажать Go to Cluster Events, чтобы просмотреть детали кластера.
Полезные ссылки
- Доступ к кластеру: вы можете использовать kubectl для доступа к кластеру и выполнения задач управления кластером в CLI. Подробнее см. Accessing a Cluster Using kubectl и Connecting to Multiple Clusters Using kubectl.
- Добавление узла: После создания кластера вы можете добавить узлы в кластер. Для получения подробной информации см. Creating a Node.
- Управление кластером: После создания кластера вы можете настроить политики планирования ресурсов, правила контроля безопасности и управление жизненным циклом, чтобы удовлетворить требования сервиса. Для получения подробной информации см. Cluster Management Overview.
- Создание кластера с двойным стеком IPv4/IPv6: Для получения подробной информации см. Creating an IPv4/IPv6 Dual-Stack Cluster in CCE.
- Если кластер не удалось создать, устраните ошибку, обратившись к Why Can't I Create a CCE Cluster?.