Alauda Container Platform
Русский

Создание локального кластера

Содержание

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

Требования к узлам

  1. Если вы скачали пакет установки для одной архитектуры с Download Installation Package, убедитесь, что архитектура ваших узлов совпадает с архитектурой пакета. Иначе узлы не запустятся из-за отсутствия образов, специфичных для архитектуры.
  2. Проверьте, что операционная система и ядро узлов поддерживаются. Подробности смотрите в разделе Supported OS and Kernels.
  3. Выполните проверки доступности узлов. Конкретные пункты проверки смотрите в разделе Node Preprocessing > Node Checks.
  4. Если IP-адреса узлов недоступны напрямую по SSH, предоставьте для узлов SOCKS5-прокси. Кластер global будет обращаться к узлам через этот прокси-сервис.

Балансировка нагрузки

Для производственных сред требуется балансировщик нагрузки для узлов управляющей плоскости кластера, чтобы обеспечить высокую доступность. Вы можете использовать собственный аппаратный балансировщик нагрузки или включить Self-built VIP, который обеспечивает программную балансировку нагрузки с помощью haproxy + keepalived. Рекомендуется использовать аппаратный балансировщик нагрузки, потому что:

  • Лучшая производительность: Аппаратная балансировка работает лучше, чем программная.
  • Меньшая сложность: Если вы не знакомы с keepalived, неправильная настройка может привести к недоступности кластера, что вызовет длительный поиск и устранение неисправностей и серьезно повлияет на надежность кластера.

При использовании собственного аппаратного балансировщика нагрузки вы можете указать VIP балансировщика в параметре IP Address / Domain. Если у вас есть доменное имя, которое резолвится в VIP балансировщика, вы можете использовать это доменное имя в качестве параметра IP Address / Domain. Примечание:

  • Балансировщик нагрузки должен корректно перенаправлять трафик на порты 6443, 11780 и 11781 всех узлов управляющей плоскости кластера.
  • Если в кластере только один узел управляющей плоскости и вы используете IP этого узла в параметре IP Address / Domain, то в дальнейшем кластер нельзя будет масштабировать с одного узла до высокодоступного многозвенного. Поэтому рекомендуется использовать балансировщик нагрузки даже для однозвенных кластеров.

При включении Self-built VIP необходимо подготовить:

  1. Доступный VRID
  2. Сеть хоста, поддерживающую протокол VRRP
  3. Все узлы управляющей плоскости и VIP должны находиться в одной подсети, при этом VIP должен отличаться от IP любого узла.

Подключение кластера global и рабочих кластеров

Платформа требует взаимного доступа между кластером global и рабочими кластерами. Если они находятся в разных сетях, необходимо:

  1. Обеспечить External Access для рабочего кластера, чтобы кластер global мог получить к нему доступ. Требования к сети: global должен иметь доступ к портам 6443, 11780 и 11781 всех узлов управляющей плоскости.
  2. Добавить дополнительный адрес в global, доступный рабочему кластеру. При создании рабочего кластера добавьте этот адрес в аннотации кластера с ключом cpaas.io/platform-url и значением, равным адресу публичного доступа к global.

Регистры образов

Образы кластера поддерживают варианты: встроенный в платформу, частный репозиторий и публичный репозиторий.

  • Встроенный в платформу: Использует реестр образов, предоставляемый кластером global. Если кластер не может получить доступ к global, смотрите Add External Address for Built-in Registry.
  • Частный репозиторий: Использует ваш собственный реестр образов. Для подробностей о загрузке необходимых образов в ваш реестр обратитесь в техническую поддержку.
  • Публичный репозиторий: Использует публичный реестр образов платформы. Перед использованием выполните Updating Public Repository Credentials.

Сетевая подсистема контейнеров

Если вы планируете использовать Kube-OVN Underlay для вашего кластера, обратитесь к разделу Preparing Kube-OVN Underlay Physical Network.

Процедура создания

  1. Перейдите в представление Administrator и в левом навигационном меню выберите Clusters/Clusters.

  2. Нажмите Create Cluster.

  3. Настройте следующие разделы согласно инструкциям ниже: Basic Info, Container Network, Node Settings и Extended Parameters.

Basic Info

ПараметрОписание
Kubernetes Version

Все доступные версии тщательно протестированы на стабильность и совместимость.


Рекомендация: Выберите последнюю версию для оптимальных возможностей и поддержки.

Container Runtime

По умолчанию используется containerd.


Если вы предпочитаете Docker в качестве контейнерного рантайма, обратитесь к разделу Choosing a Container Runtime.

Cluster Network Protocol

Поддерживаются три режима: IPv4 single stack, IPv6 single stack, IPv4/IPv6 dual stack.


Примечание: При выборе dual stack убедитесь, что у всех узлов корректно настроены IPv6-адреса; протокол сети нельзя изменить после настройки.

Cluster Endpoint

IP Address / Domain: Введите заранее подготовленное доменное имя или VIP, если доменное имя отсутствует.


Self-Built VIP: По умолчанию отключено. Включайте только если не предоставлен LoadBalancer. При включении установщик автоматически развернет keepalived для поддержки программной балансировки нагрузки.


External Access: Введите внешний доступный адрес, подготовленный для кластера, если он находится в другой сетевой среде, отличной от кластера global.

Container Network

Kube-OVN
Calico
Flannel
Custom

Корпоративная система оркестрации сетей контейнеров Cloud Native Kubernetes, разработанная компанией Alauda. Она переносит зрелые сетевые возможности из области OpenStack в Kubernetes, поддерживает межоблачное управление сетью, межсоединение традиционной сетевой архитектуры и инфраструктуры, а также сценарии развертывания на периферии, значительно повышая безопасность, эффективность управления и производительность сетей контейнеров Kubernetes.

ПараметрОписание
Subnet

Также известна как Cluster CIDR, представляет собой подсеть по умолчанию. После создания кластера можно добавлять дополнительные подсети.

Transmit Mode

Overlay: Виртуальная сеть, абстрагированная над инфраструктурой, не потребляющая физические сетевые ресурсы. При создании Overlay-подсети по умолчанию все Overlay-подсети кластера используют одинаковую конфигурацию cluster NIC и node NIC.
Underlay: Этот режим передачи опирается на физические сетевые устройства. Он может напрямую выделять физические сетевые адреса подам, обеспечивая лучшую производительность и связь с физической сетью. Узлы в Underlay-подсети должны иметь несколько NIC, а NIC, используемый для мостовой сети, должен использоваться исключительно для Underlay и не должен нести другой трафик, например SSH. При создании Underlay-подсети по умолчанию cluster NIC фактически является NIC по умолчанию для мостовой сети, а node NIC — это конфигурация NIC узла в мостовой сети.

  • Default Gateway: Адрес шлюза физической сети, который является шлюзом для сегмента Cluster CIDR (должен находиться в диапазоне адресов Cluster CIDR).
  • VLAN ID: Идентификатор виртуальной локальной сети (номер VLAN), например 0.
  • Reserved IPs: Укажите зарезервированные IP-адреса, которые не будут автоматически выделяться, например IP-адреса в подсети, уже используемые другими устройствами.
Service CIDR

Диапазон IP-адресов, используемый Kubernetes Service типа ClusterIP. Не должен пересекаться с диапазоном подсети по умолчанию.

Join CIDR

В режиме передачи Overlay это диапазон IP-адресов для связи между узлами и подами. Не должен пересекаться с подсетью по умолчанию или Service CIDR.

Node Settings

ПараметрОписание
Network Interface Card

Имя сетевого интерфейса хоста, используемого сетевым плагином кластера.


Примечание:

  • При выборе режима передачи Underlay для подсети Kube-OVN по умолчанию необходимо указать имя сетевого интерфейса, который будет использоваться как NIC по умолчанию для мостовой сети.
    - По умолчанию платформа распознаёт трафик на интерфейсах с именами, начинающимися на eth.|en.|wl.|ww.. Если вы используете интерфейсы с другими именами, после добавления кластера обратитесь к разделу Collect Network Data from Custom-Named Network Interfaces для изменения соответствующих ресурсов и обеспечения корректного мониторинга трафика.
Node Name

Можно выбрать использование IP-адреса узла или его hostname в качестве имени узла на платформе.


Примечание: При выборе hostname убедитесь, что имена всех узлов в кластере уникальны.

Nodes

Добавьте узлы в кластер или Восстановите из черновика временно сохранённую информацию об узлах. Подробное описание параметров добавления узлов приведено ниже.

Monitoring Type

Поддерживаются Prometheus и VictoriaMetrics.
При выборе VictoriaMetrics необходимо указать Deploy Type:
- Deploy VictoriaMetrics: Разворачивает все компоненты, включая VMStorage, VMAlert, VMAgent и др.


- Deploy VictoriaMetrics Agent: Разворачивает только компонент сбора логов VMAgent. При таком способе развертывания необходимо связать его с уже развернутым экземпляром VictoriaMetrics на другом кластере платформы для предоставления мониторинга.

Monitoring Nodes

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


Чтобы не влиять на производительность кластера, рекомендуется отдавать предпочтение вычислительным узлам. После успешного создания кластера компоненты мониторинга с типом хранения Local Volume будут развернуты на выбранных узлах.

Параметры добавления узлов

ПараметрОписание
Type

Control Plane Node: Отвечает за запуск компонентов kube-apiserver, kube-scheduler, kube-controller-manager, etcd, сетевого плагина и некоторых компонентов управления платформой. При включенной опции Application Deployable узлы управляющей плоскости могут использоваться как вычислительные узлы.


Worker Node: Отвечает за размещение бизнес-подов, работающих в кластере.

IPv4 Address

IPv4-адрес узла. Для кластеров, созданных в режиме внутренней сети, указывайте приватный IP узла.

IPv6 Address

Действительно при включенном dual stack IPv4/IPv6. IPv6-адрес узла.

Application Deployable

Действительно при Node Type = Control Plane Node. Разрешить ли развертывание бизнес-приложений на этом узле управляющей плоскости, то есть планировать бизнес-поды на этот узел.

Display NameОтображаемое имя узла.
SSH Connection IP

IP-адрес, по которому можно подключиться к узлу через SSH.


Если вы можете войти на узел с помощью команды ssh <username>@<IPv4-адрес узла>, этот параметр не обязателен. В противном случае укажите публичный IP или внешний NAT IP узла, чтобы кластер global и прокси могли подключаться к узлу по этому IP.

Network Interface Card

Укажите имя сетевого интерфейса, используемого узлом. Приоритет эффективности конфигурации сетевого интерфейса следующий (слева направо, по убыванию):


Kube-OVN Underlay: Node NIC > Cluster NIC


Kube-OVN Overlay: Node NIC > Cluster NIC > NIC, соответствующий маршруту по умолчанию узла


Calico: Cluster NIC > NIC, соответствующий маршруту по умолчанию узла


Flannel: Cluster NIC > NIC, соответствующий маршруту по умолчанию узла

Associated Bridge Network

Примечание: При создании кластера конфигурация мостовой сети не поддерживается; этот параметр доступен только при добавлении узлов в кластер, в котором уже созданы Underlay-подсети.


Выберите существующую Add Bridge Network. Если не хотите использовать NIC по умолчанию мостовой сети, можно отдельно настроить node NIC.

SSH Port

Номер порта SSH, например 22.

SSH Username

Имя пользователя SSH с правами root, например root.

Proxy

Использовать ли прокси для доступа к SSH-порту узла. Если кластер global не может напрямую подключиться к добавляемому узлу по SSH (например, кластер global и рабочий кластер находятся в разных подсетях; IP узла — внутренний, недоступный напрямую из global), включите этот переключатель и настройте параметры прокси. После настройки прокси доступ к узлу и развертывание будут осуществляться через прокси.


Примечание: В настоящее время поддерживается только SOCKS5-прокси.


Access URL: Адрес прокси-сервера, например 192.168.1.1:1080 .
Username: Имя пользователя для доступа к прокси-серверу.


Password: Пароль для доступа к прокси-серверу.

SSH Authentication

Метод аутентификации и соответствующая информация для входа на добавляемый узел. Варианты:


Password: Требуется имя пользователя с правами root и соответствующий SSH пароль.
Key: Требуется приватный ключ с правами root и пароль к приватному ключу.

Save Draft

Сохраняет текущие настройки в диалоге как черновик и закрывает окно Add Node.


Не покидая страницу Create Cluster, вы можете выбрать Restore from draft для открытия диалога Add Node и восстановления сохранённых данных.


Примечание: Восстанавливаются самые последние сохранённые данные черновика.

Extended Parameters

Примечание:

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

  • Если введённый Key совпадает с ключом параметра по умолчанию, он переопределит стандартную конфигурацию.

Процедура

  1. Нажмите Extended Parameters для раскрытия области настройки расширенных параметров. Вы можете опционально задать следующие параметры:
ПараметрОписание
Docker Parameters

dockerExtraArgs — дополнительные параметры конфигурации Docker, которые будут записаны в /etc/sysconfig/docker. Рекомендуется не изменять. Для настройки Docker через файл daemon.json параметры должны быть заданы в формате ключ-значение.

Kubelet Parameters

kubeletExtraArgs — дополнительные параметры конфигурации Kubelet.


Примечание: При вводе параметра Node IP Count в разделе Container Network автоматически создаётся параметр Kubelet с ключом max-pods и значением Node IP Count, который задаёт максимальное количество подов на любом узле кластера. Этот параметр не отображается в интерфейсе.


Если добавить новый ключ-значение max-pods: максимальное количество подов в разделе Kubelet Parameters, он переопределит значение по умолчанию. Допускаются любые положительные целые числа, но рекомендуется использовать значение по умолчанию (Node IP Count) или не превышать 256.

Controller Manager Parameters

controllerManagerExtraArgs — дополнительные параметры конфигурации Controller Manager.

Scheduler Parameters

schedulerExtraArgs — дополнительные параметры конфигурации Scheduler.

APIServer Parameters

apiServerExtraArgs — дополнительные параметры конфигурации APIServer.

APIServer URL

publicAlternativeNames — адреса доступа к APIServer, указанные в сертификате. Можно вводить только IP или доменные имена, максимум 253 символа.

Cluster Annotations

Аннотации кластера — метаданные в формате ключ-значение, которые позволяют компонентам платформы или бизнес-компонентам получать информацию о характеристиках кластера.

  1. Нажмите Create. Вы вернётесь на страницу списка кластеров, где созданный кластер будет иметь статус Creating.

Действия после создания

Просмотр прогресса создания

На странице списка кластеров можно просмотреть список созданных кластеров. Для кластеров в состоянии Creating доступен просмотр прогресса выполнения.

Процедура

  1. Нажмите на иконку View Execution Progress справа от статуса кластера.

  2. В появившемся диалоговом окне можно просмотреть прогресс выполнения кластера (status.conditions).

    Совет: Если какой-либо тип находится в процессе или в состоянии ошибки с указанием причины, наведите курсор на причину (отображается синим текстом), чтобы увидеть подробную информацию (status.conditions.reason).

Ассоциация с проектами

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

Просмотреть полную документацию в формате PDF