Создание локального кластера
Содержание
Предварительные требования
Требования к узлам
- Если вы скачали установочный пакет для одной архитектуры с Download Installation Package, убедитесь, что архитектура ваших узлов совпадает с архитектурой пакета. Иначе узлы не запустятся из-за отсутствия образов, специфичных для архитектуры.
- Проверьте, что операционная система и ядро узлов поддерживаются. Подробности см. в разделе Supported OS and Kernels.
- Выполните проверки доступности узлов. Конкретные пункты проверки смотрите в разделе Node Preprocessing > Node Checks.
- Если IP-адреса узлов недоступны напрямую по SSH, предоставьте для узлов SOCKS5-прокси. Кластер
globalбудет обращаться к узлам через этот прокси-сервис.
Балансировка нагрузки
Для производственных сред необходим балансировщик нагрузки для узлов управляющей плоскости кластера, чтобы обеспечить высокую доступность.
Вы можете использовать собственный аппаратный балансировщик нагрузки или включить Self-built VIP, который обеспечивает программную балансировку нагрузки с помощью haproxy + keepalived.
Рекомендуется использовать аппаратный балансировщик нагрузки, потому что:
- Лучшая производительность: Аппаратная балансировка работает лучше программной.
- Меньшая сложность: Если вы не знакомы с keepalived, неправильная настройка может сделать кластер недоступным, что приведёт к длительному устранению неполадок и серьёзно повлияет на надёжность кластера.
При использовании собственного аппаратного балансировщика нагрузки вы можете указать VIP балансировщика как параметр IP Address / Domain. Если у вас есть доменное имя, разрешающееся в VIP балансировщика, можно использовать это доменное имя.
Примечание:
- Балансировщик нагрузки должен корректно перенаправлять трафик на порты
6443,11780и11781на всех узлах управляющей плоскости кластера. - Если в кластере только один узел управляющей плоскости и вы используете IP этого узла как
IP Address / Domain, кластер нельзя будет масштабировать с одного узла до высокодоступного многозвенного кластера. Поэтому рекомендуется использовать балансировщик нагрузки даже для однозвенных кластеров.
При включении Self-built VIP необходимо подготовить:
- Доступный VRID
- Сеть хоста, поддерживающую протокол VRRP
- Все узлы управляющей плоскости и VIP должны находиться в одной подсети, при этом VIP должен отличаться от IP любого узла.
Подключение кластера global и рабочих кластеров
Платформа требует взаимного доступа между кластером global и рабочими кластерами. Если они находятся в разных сетях, необходимо:
- Обеспечить
External Accessдля рабочего кластера, чтобы кластерglobalмог получить к нему доступ. Требования к сети: кластерglobalдолжен иметь доступ к портам6443,11780и11781на всех узлах управляющей плоскости. - Добавить дополнительный адрес в
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.
Процедура создания
-
Перейдите в представление Administrator и в левом навигационном меню выберите Clusters/Clusters.
-
Нажмите Create Cluster.
-
Настройте следующие разделы согласно инструкциям ниже: 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 |
|
Container Network
Корпоративная система оркестрации сетей контейнеров Cloud Native Kubernetes, разработанная Alauda. Переносит зрелые сетевые возможности из области OpenStack в Kubernetes, поддерживает управление сетями между облаками, традиционную сетевую архитектуру и межсоединение инфраструктур, сценарии развертывания на периферии, значительно повышая безопасность, эффективность управления и производительность сетей контейнеров Kubernetes.
| Параметр | Описание |
|---|---|
| Subnet | Также известен как Cluster CIDR, представляет подсеть по умолчанию. После создания кластера можно добавлять дополнительные подсети. |
| Transmit Mode | Overlay: Виртуальная сеть, абстрагированная над инфраструктурой, не потребляющая физические сетевые ресурсы. При создании Overlay-подсети по умолчанию все Overlay-подсети в кластере используют одинаковую конфигурацию cluster NIC и node NIC.
|
| Service CIDR | Диапазон IP-адресов, используемый Kubernetes Service типа ClusterIP. Не должен пересекаться с диапазоном подсети по умолчанию. |
| Join CIDR | В режиме Overlay — диапазон IP-адресов для связи между узлами и pod. Не должен пересекаться с подсетью по умолчанию или Service CIDR. |
Node Settings
| Параметр | Описание |
|---|---|
| Network Interface Card | Имя сетевого интерфейса хоста, используемого сетевым плагином кластера. Примечание:
|
| Node Name | Можно выбрать использование IP-адреса узла или его hostname в качестве имени узла на платформе. Примечание: При выборе hostname убедитесь, что имена всех узлов в кластере уникальны. |
| Nodes | Добавьте узлы в кластер или Восстановите из черновика временно сохранённую информацию об узлах. Подробные параметры добавления узлов описаны ниже. |
| Monitoring Type | Поддерживаются Prometheus и VictoriaMetrics. - 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. Если вы можете войти на узел с помощью команды |
| 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-сервиса, например, |
| SSH Username | Имя пользователя SSH с правами root, например, |
| Proxy | Использовать ли прокси для доступа к SSH-порту узла. Если кластер Примечание: В настоящее время поддерживается только SOCKS5-прокси. Access URL: Адрес прокси-сервера, например, Password: Пароль для доступа к прокси-серверу. |
| SSH Authentication | Метод аутентификации и соответствующая информация для входа на добавляемый узел. Варианты: Password: Требуется имя пользователя с правами root и соответствующий SSH пароль. |
| Save Draft | Сохраняет текущие настройки в диалоге как черновик и закрывает окно Add Node. Не покидая страницу Create Cluster, вы можете выбрать Restore from draft, чтобы открыть диалог Add Node и восстановить сохранённые данные. Примечание: Восстанавливаются самые последние сохранённые данные черновика. |
Extended Parameters
Примечание:
-
Помимо обязательных настроек, не рекомендуется задавать расширенные параметры, так как неправильные значения могут сделать кластер недоступным, а после создания кластера изменить их нельзя.
-
Если введённый Key совпадает с ключом параметра по умолчанию, он переопределит стандартную настройку.
Процедура
- Нажмите Extended Parameters, чтобы развернуть область настройки расширенных параметров. Можно опционально задать следующие параметры:
| Параметр | Описание |
|---|---|
| Docker Parameters |
|
| Kubelet Parameters |
Примечание: При вводе параметра Node IP Count в разделе Container Network автоматически создаётся параметр Kubelet с ключом Если добавить новый ключ-значение |
| Controller Manager Parameters |
|
| Scheduler Parameters |
|
| APIServer Parameters |
|
| APIServer URL |
|
| Cluster Annotations | Аннотации кластера — метаданные в виде ключ-значение, которые позволяют компонентам платформы или бизнес-компонентам получать информацию о характеристиках кластера. |
- Нажмите Create. Вы вернётесь на страницу списка кластеров, где состояние кластера будет Creating.
Действия после создания
Просмотр прогресса создания
На странице списка кластеров отображается список созданных кластеров. Для кластеров в состоянии Creating можно просмотреть ход выполнения.
Процедура
-
Нажмите на иконку View Execution Progress справа от статуса кластера.
-
В появившемся диалоге можно увидеть прогресс выполнения кластера (status.conditions).
Совет: Если какой-либо тип находится в процессе или в состоянии ошибки с указанием причины, наведите курсор на причину (синяя подсветка), чтобы увидеть подробности (status.conditions.reason).
Ассоциация с проектами
После создания кластера вы можете добавить его в проекты в представлении управления проектами.