#Подготовка параметров для кластера VMware vSphere

Этот документ помогает собрать значения, необходимые для создания кластера рабочей нагрузки VMware vSphere из кластера global. Завершите этот чек-лист перед применением манифестов в Создание кластера в кластере global.

#Сценарии

Используйте этот чек-лист в следующих сценариях:

• Вы подготавливаете новое развертывание кластера VMware vSphere.
• Вы хотите проверить внешние зависимости до начала развертывания.
• Вы планируете включить расширенные сценарии, такие как несколько центров обработки данных, несколько NIC или дополнительные worker-узлы.

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

Перед началом убедитесь, что выполнены следующие условия:

• У вас есть доступ к кластеру global с помощью kubectl.
• Объекты кластера рабочей нагрузки должны храниться в пространстве имен cpaas-system.
• У вас есть доступ к целевым ресурсам vCenter: инвентарю, сетям, datastore и шаблонам.

#Как использовать этот чек-лист

Используйте этот чек-лист в следующем порядке:

1. Соберите параметры развертывания, перечисленные в этом документе.
2. Замените каждый заполнитель в шаблонах манифестов фактическими значениями, собранными здесь.
3. Используйте одно и то же значение везде, где один и тот же заполнитель встречается в нескольких манифестах.
4. Если какая-либо необязательная функция не включена, удалите соответствующий блок YAML в точности так, как описано в документе расширения.
5. Если необязательное поле (например, deviceName) не требуется, удалите всю строку из манифеста YAML.

#Терминология

Следующие термины последовательно используются во всех документах по созданию кластера VMware vSphere.

#machine config pool

Пул конфигурации машины — это пользовательский ресурс VSphereMachineConfigPool. Он предварительно определяет слоты узлов. Каждый слот может включать:

• Имя хоста узла
• Целевой центр обработки данных
• Статическую конфигурацию IP для каждого NIC
• Определения постоянных дисков

#Слот узла

Слот узла — это запись в VSphereMachineConfigPool.spec.configs[]. Один слот обычно соответствует одному узлу, например cp-01 или worker-01. Поле hostname слота определяет имя узла Kubernetes, DNS SAN сертификата kubelet serving certificate и (вместе с вычисленными адресами основного NIC) значение node-ip kubelet; оно должно быть допустимым поддоменом DNS-1123.

#Сетевая схема слота

Каждый слот задает схему NIC в network.primary и network.additional:

• network.primary обязателен. Для него должно быть задано networkName, и он используется как источник node-ip для kubelet.
• network.additional — необязательный список дополнительных NIC, который объединяется после основного NIC в указанном порядке.

#deviceName

deviceName — это необязательное поле в сетевой конфигурации VSphereMachineConfigPool. Оно используется для управления именем NIC, видимым внутри гостевой операционной системы, например eth0 или eth1.

Используйте следующие различия при заполнении значений:

• networkName — это имя сети или port group в vCenter.
• deviceName — это имя NIC внутри гостевой операционной системы.
• Если deviceName не указан, CAPV обычно назначает имена, такие как eth0, eth1 и eth2, в порядке NIC.

#Пул ресурсов vCenter

Пул ресурсов vCenter — это нативный объект инвентаря vCenter, например:

/Datacenter1/host/cluster1/Resources

В сценариях расширения этот путь используется в VSphereDeploymentZone.spec.placementConstraint.resourcePool.

#Вычислительный кластер

Вычислительный кластер — это имя целевого compute-cluster в vCenter. В этих документах он в основном используется, когда VSphereFailureDomain сопоставляется с конкретной целью развертывания.

#Datastore

Datastore — это хранилище vSphere, в котором размещаются диски виртуальных машин. Как системные диски, так и диски данных должны находиться на конкретных datastore.

#Шаблон VM

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

#Thumbprint

Thumbprint — это SHA-1 отпечаток сертификата сервера vCenter. CAPV использует его для проверки целевого сервера vCenter.

Используйте следующую команду, чтобы получить его:

openssl s_client -connect <vsphere_server>:443 -servername <vsphere_server> </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha1

#Предварительные требования для management-кластера

Используйте следующую таблицу, чтобы записать требуемые значения и результаты проверок.

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

#Информация о подключении к vCenter

Примечание: В этих документах предполагается стандартный HTTPS-порт vCenter 443.

#Требования к шаблону VM

Шаблон также должен соответствовать следующим требованиям:

• В нем используется операционная система, поддерживаемая политикой образов вашей платформы.
• В него включен cloud-init.
• В него включены VMware Tools или open-vm-tools.
• В него включен containerd.
• В него включены базовые компоненты, необходимые для bootstrap kubeadm.
• В нем находятся заранее экспортированные tar-файлы образов контейнеров в /root/images/. Эти файлы импортируются в containerd скриптом capv-load-local-images.sh перед запуском kubeadm, чтобы bootstrap узла не зависел от загрузки образов из удаленного registry.
• Файлы /root/images/*.tar обязательно должны содержать образ sandbox (pause), ссылка на который в точности соответствует значению sandbox_image (containerd v1) или sandbox (containerd v2), настроенному в /etc/containerd/config.toml. Например, если containerd настроен с sandbox_image = "registry.example.com/tkestack/pause:3.10", один из tar-файлов должен содержать именно эту ссылку на образ. Несоответствие приводит к тому, что containerd будет загружать образ sandbox из сети, что сводит на нет предварительную локальную загрузку и приводит к сбою в изолированных от сети средах.

#Предварительные требования для балансировщика нагрузки

VIP control plane обслуживается внешним балансировщиком нагрузки, который вы разворачиваете до создания кластера. Описанный поток для vSphere не разворачивает компонент VIP внутри кластера, поэтому балансировщик нагрузки, выделение VIP и обслуживание его backend-ов (real-server) подготавливаются и управляются вне кластера.

#Базовые параметры кластера

#Минимальные параметры для одного центра обработки данных

#Центр обработки данных и размещение ресурсов

#Параметры основного NIC

#Пул конфигурации машины control plane

#Пул конфигурации машины worker

#Вычислительные ресурсы

#Стандартные диски данных

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

#Поля постоянного диска

#Узлы control plane (3 диска на узел)

#Узлы worker (2 диска на узел)

#Параметры размеров

#Параметры vSphere CPI

#Необязательные параметры расширения

#Несколько центров обработки данных и несколько failure domain

#Параметры второго NIC

#Итоговая проверка готовности

Перед началом развертывания подтвердите все следующие пункты:

1. Кластер global доступен.
2. Убедитесь, что установлены два плагина кластера: Alauda Container Platform Kubeadm Provider и Alauda Container Platform VMware vSphere Infrastructure Provider.
3. Включен ClusterResourceSet=true.
4. Собраны сервер vCenter, имя пользователя, пароль и thumbprint.
5. VIP control plane, балансировщик нагрузки и порт 6443 готовы.
6. Pod CIDR, Service CIDR и kube-ovn-join-cidr не пересекаются с существующими сетями.
7. Шаблон VM доступен в каждом требуемом центре обработки данных.
8. Подтверждены требуемые datastore и пути к пулу ресурсов vCenter.
9. Значения machine config pool для минимальной топологии с одним центром обработки данных заполнены.
10. Подтвержден размер базового системного диска и дисков данных.
11. Каждому требуемому параметру присвоено фактическое значение.

#Следующие шаги

После завершения этого чек-листа перейдите к Создание кластера в кластере global.