#Расширение развертывания кластера VMware vSphere

В этом документе объясняется, как расширить базовое развертывание кластера VMware vSphere после успешного запуска минимального workflow для одного datacenter.

#Сценарии

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

• Вам нужен второй NIC на control plane или worker nodes.
• Вы хотите распределить узлы между несколькими datacenter или зонами развертывания.
• Вы хотите добавить больше дисков данных.
• Вы хотите масштабировать пул worker.

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

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

• Базовый workflow в Creating a VMware vSphere Cluster in the global Cluster успешно завершен.
• Вы проверили дополнительные параметры в Preparing Parameters for a VMware vSphere Cluster.
• Вы понимаете, какие manifests в вашем развертывании отвечают за настройки сети, размещения и дисков.

#Добавление второго NIC

Когда узлам требуется дополнительная сеть управления, хранения или сервисная сеть, расширьте manifests в следующих ресурсах:

• 02-vspheremachineconfigpool-control-plane.yaml
• 03-vspheremachineconfigpool-worker.yaml
• 20-control-plane.yaml
• 30-workers-md-0.yaml
• 04-failure-domains.yaml, если включены failure domains

Каждый слот узла задает свою конфигурацию NIC в network.primary и network.additional. Основной NIC используется для определения kubelet node-ip и остается основным идентификатором узла; дополнительные NIC объединяются после него в указанном порядке.

Добавьте второй NIC в каждый слот control plane в machine config pools:

network:
  primary:
    networkName: "<nic1_network_name>"
    deviceName: "<nic1_device_name>"
    ip: "<master_01_nic1_ip>/<nic1_prefix>"
    gateway: "<nic1_gateway>"
    dns:
    - "<nic1_dns_1>"
  additional:
  - networkName: "<nic2_network_name>"
    deviceName: "<nic2_device_name>"
    ip: "<master_01_nic2_ip>/<nic2_prefix>"
    gateway: "<nic2_gateway>"
    dns:
    - "<nic2_dns_1>"

Примените тот же шаблон к слотам worker nodes:

network:
  primary:
    networkName: "<nic1_network_name>"
    deviceName: "<nic1_device_name>"
    ip: "<worker_01_nic1_ip>/<nic1_prefix>"
    gateway: "<nic1_gateway>"
    dns:
    - "<nic1_dns_1>"
  additional:
  - networkName: "<nic2_network_name>"
    deviceName: "<nic2_device_name>"
    ip: "<worker_01_nic2_ip>/<nic2_prefix>"
    gateway: "<nic2_gateway>"
    dns:
    - "<nic2_dns_1>"

Добавьте второй NIC в machine templates:

network:
  devices:
  - networkName: "<nic1_network_name>"
  - networkName: "<nic2_network_name>"

Если включены failure domains, обновите список сетей в VSphereFailureDomain.spec.topology.networks:

topology:
  networks:
  - <nic1_network_name>
  - <nic2_network_name>

Когда вы задаете значения для второго NIC, подготовьте следующие placeholders в checklist и manifests:

• <master_01_nic2_ip>
• <master_02_nic2_ip>
• <master_03_nic2_ip>
• <worker_01_nic2_ip>
• <worker_02_nic2_ip>, если вы также расширяете worker pool

При переходе между одним NIC и двумя NIC применяйте следующие правила:

#Расширение с одного NIC до двух NIC

Обновите все следующие поля одновременно:

1. VSphereMachineConfigPool.spec.configs[].network.additional (добавьте вторую запись NIC; network.primary оставьте без изменений)
2. VSphereMachineTemplate.spec.template.spec.network.devices
3. VSphereFailureDomain.spec.topology.networks, если включены failure domains

#Возврат с двух NIC к одному NIC

Удалите блок второго NIC из всех следующих полей:

1. Вторая запись NIC в VSphereMachineConfigPool.spec.configs[].network.additional (оставьте список пустым или полностью удалите ключ additional)
2. Вторая запись устройства в VSphereMachineTemplate.spec.template.spec.network.devices
3. Второе имя сети в VSphereFailureDomain.spec.topology.networks

#Включение нескольких datacenter и failure domains

Используйте несколько datacenter и failure domains, когда требуется размещать узлы в разных datacenter vCenter или compute clusters.

Применяются следующие принципы:

• Один кластер может определять несколько объектов VSphereFailureDomain.
• Каждый VSphereDeploymentZone ссылается на один VSphereFailureDomain.
• control plane использует VSphereCluster.spec.failureDomainSelector.
• worker MachineDeployment использует spec.template.spec.failureDomain, когда его нужно привязать к определенной зоне развертывания.

Подготовьте следующие placeholders для первого datacenter:

• <compute_cluster_1>
• <default_datastore_1>
• <resource_pool_path_1>
• <fd_name_1>
• <dz_name_1>

Подготовьте следующие placeholders для второго datacenter:

• <dc_name_2>
• <fd_name_2>
• <dz_name_2>
• <compute_cluster_2>
• <default_datastore_2>
• <resource_pool_path_2>

Если вы добавляете третий datacenter, продолжайте использовать тот же шаблон placeholders:

• <dc_name_3>
• <fd_name_3>
• <dz_name_3>
• <compute_cluster_3>
• <default_datastore_3>
• <resource_pool_path_3>

Создайте объекты failure-domain в 04-failure-domains.yaml. Первому datacenter также нужны VSphereFailureDomain и VSphereDeploymentZone, если включены failure domains:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereFailureDomain
metadata:
  name: <fd_name_1>
spec:
  region:
    name: region-a
    type: Datacenter
    tagCategory: k8s-region
    autoConfigure: true
  zone:
    name: zone-1
    type: ComputeCluster
    tagCategory: k8s-zone
    autoConfigure: true
  topology:
    datacenter: <default_datacenter>
    computeCluster: <compute_cluster_1>
    datastore: <default_datastore_1>
    networks:
    - <nic1_network_name>
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
  name: <dz_name_1>
spec:
  server: <vsphere_server>
  failureDomain: <fd_name_1>
  controlPlane: true
  placementConstraint:
    resourcePool: <resource_pool_path_1>
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereFailureDomain
metadata:
  name: <fd_name_2>
spec:
  region:
    name: region-a
    type: Datacenter
    tagCategory: k8s-region
    autoConfigure: true
  zone:
    name: zone-2
    type: ComputeCluster
    tagCategory: k8s-zone
    autoConfigure: true
  topology:
    datacenter: <dc_name_2>
    computeCluster: <compute_cluster_2>
    datastore: <default_datastore_2>
    networks:
    - <nic1_network_name>
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
  name: <dz_name_2>
spec:
  server: <vsphere_server>
  failureDomain: <fd_name_2>
  controlPlane: true
  placementConstraint:
    resourcePool: <resource_pool_path_2>

Включите выбор control plane среди доступных failure domains, добавив failureDomainSelector в spec VSphereCluster в 10-cluster.yaml:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereCluster
metadata:
  name: <cluster_name>
  namespace: <namespace>
spec:
  controlPlaneEndpoint:
    host: "<vip>"
    port: <api_server_port>
  identityRef:
    kind: Secret
    name: <credentials_secret_name>
  server: "<vsphere_server>"
  thumbprint: "<thumbprint>"
  failureDomainSelector: {}

Укажите зону развертывания worker, когда worker MachineDeployment должен быть закреплен за одним target развертывания. Добавьте failureDomain в spec.template.spec в 30-workers-md-0.yaml:

apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: <cluster_name>-md-0
  namespace: <namespace>
spec:
  clusterName: <cluster_name>
  replicas: <worker_replicas>
  template:
    spec:
      clusterName: <cluster_name>
      failureDomain: <worker_failure_domain>
      version: "<k8s_version>"
      # ... rest of spec

Используйте имя VSphereDeploymentZone для <worker_failure_domain>, а не имя VSphereFailureDomain.

Рекомендация: Перед включением нескольких datacenter убедитесь, что VM template, сети и datastores доступны в каждом целевом datacenter.

Перед включением нескольких datacenter также убедитесь в выполнении следующих prerequisites:

1. Template уже синхронизирован с каждым целевым datacenter.
2. Имена сетей разрешаются в каждом целевом datacenter.
3. Имена datastore разрешаются в каждом целевом datacenter.
4. Список datacenter для vSphere CPI охватывает каждый целевой datacenter.

#Добавление дисков данных

Базовое развертывание включает следующие обязательные диски данных:

• Control plane nodes: var-cpaas, var-lib-containerd и var-lib-etcd (3 диска на узел). Не удаляйте ни один из этих дисков. Для диска var-lib-etcd необходимо задать wipeFilesystem: true, чтобы разрешить kubeadm join во время rolling updates.
• Worker nodes: var-cpaas и var-lib-containerd (2 диска на узел). Не удаляйте ни один из этих дисков.

Если узлу нужны дополнительные диски данных сверх обязательного набора, добавьте больше записей в тот же список persistentDisks в соответствующем слоте узла VSphereMachineConfigPool. Здесь особенно важны следующие необязательные поля:

• mountPath: если задан, диск форматируется и монтируется по указанному пути. Если не задан, диск подключается как raw device с symlink в /dev/disk/by-capv/<name>, что позволяет внешнему процессу управлять им во время выполнения.
• wipeFilesystem: если значение true, содержимое диска стирается при первой загрузке новой VM. Обычные перезагрузки и ручные перезапуски служб не затрагиваются. По умолчанию — false.

#Масштабирование worker nodes

Масштабирование worker зависит от соотношения между MachineDeployment.spec.replicas и доступными слотами узлов в worker machine config pool, VSphereMachineConfigPool.spec.configs[].

Применяйте следующие правила:

1. Количество слотов узлов может быть больше, чем replicas.
2. Неиспользуемые слоты не влияют на работающий кластер.
3. Если replicas превышает число доступных слотов, CAPV не сможет корректно назначить новые worker nodes.

Используйте следующий порядок при масштабировании worker:

1. Добавьте новые слоты worker nodes в 03-vspheremachineconfigpool-worker.yaml.
2. Увеличьте MachineDeployment.spec.replicas в 30-workers-md-0.yaml.

Следующий пример добавляет новый слот worker:

- hostname: "<worker_node_name_2>"
  datacenter: "<worker_02_datacenter>"
  network:
    primary:
      networkName: "<nic1_network_name>"
      ip: "<worker_02_nic1_ip>/<nic1_prefix>"
      gateway: "<nic1_gateway>"
      dns:
      - "<nic1_dns_1>"
  persistentDisks:
  - name: var-cpaas
    sizeGiB: <worker_var_cpaas_size_gib>
    mountPath: /var/cpaas
    fsFormat: ext4
  - name: var-lib-containerd
    sizeGiB: <worker_var_lib_containerd_size_gib>
    mountPath: /var/lib/containerd
    fsFormat: ext4

Чтобы подключить raw disk без форматирования или монтирования (например, когда диском управляет само приложение), опустите mountPath и fsFormat:

  persistentDisks:
  # ...required disks...
  - name: app-data
    sizeGiB: 50

Диск будет доступен внутри guest OS по пути /dev/disk/by-capv/app-data. При rolling updates тот же VMDK повторно подключается к новой VM, и symlink создается заново. Диск никогда не форматируется и не монтируется автоматически — за его управление во время выполнения отвечает приложение.

Затем обновите количество worker replicas:

replicas: <worker_replicas>

#Проверка

После каждого расширения проверьте состояние кластера с помощью следующих команд:

kubectl -n <namespace> get cluster,vspherecluster,kubeadmcontrolplane,machinedeployment,machine,vspheremachine,vspherevm
kubectl --kubeconfig=/tmp/<cluster_name>.kubeconfig get nodes -o wide

Подтвердите следующие результаты:

• Новые настройки размещения, NIC или дисков отражены в целевых ресурсах.
• Новые worker nodes переходят в состояние Ready.
• Существующие узлы остаются в рабочем состоянии после изменения.

#Дальнейшие действия

Применяйте одно расширение за раз. Проверяйте результат, прежде чем объединять несколько изменений в одном кластере.