Alauda Container Platform
  • Русский

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

    Содержание

    Предварительные требованияТребования к узламБалансировка нагрузкиПодключение кластера global и рабочих кластеровРеестр образовСетевое взаимодействие контейнеровПроцедура созданияBasic InfoContainer NetworkNode SettingsExtended ParametersДействия после созданияПросмотр прогресса созданияАссоциация с проектами

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

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

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

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

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

    Если в вашей среде есть аппаратный LoadBalancer, его использование рекомендуется. Если нет, можно включить Self-built VIP, который обеспечивает программную балансировку нагрузки с помощью keepalived.

    Рекомендация: При использовании аппаратного LoadBalancer рекомендуется настраивать Cluster Endpoint с доменным именем. Если VIP аппаратного LoadBalancer изменится после установки кластера, можно обновить DNS-запись вместо перенастройки кластера.

    Примечание: Self-built VIP не поддерживает настройку доменного имени.

    Балансировщик нагрузки должен корректно перенаправлять трафик на порты 6443, 11780 и 11781 на всех узлах управляющей плоскости кластера.

    Если в вашем кластере только один узел управляющей плоскости и вы используете IP этого узла в параметре Cluster Endpoint, то впоследствии масштабировать кластер с одного узла до высокодоступного многозвенного нельзя. Поэтому рекомендуется предоставить балансировщик нагрузки даже для кластеров с одним узлом.

    При включении 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.

    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: По умолчанию отключено. Включайте только если балансировщик нагрузки не предоставлен. При включении установщик автоматически развернет 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: Этот режим передачи опирается на физические сетевые устройства. Он может напрямую выделять физические сетевые адреса для Pod, обеспечивая лучшую производительность и связь с физической сетью. Узлы в 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-адресов для связи между узлами и Pod. Не должен пересекаться с подсетью по умолчанию или 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-адреса узла или имени хоста в качестве имени узла на платформе.


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

    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 для раскрытия области настройки расширенных параметров. Можно опционально задать следующие параметры для кластера:
    ПараметрОписание
    Kubelet Parameters

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


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


    Добавление новой пары ключ-значение max-pods: максимальное количество запускаемых Pod в разделе 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).

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

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