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

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

#Сценарии

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

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

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

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

• Базовый рабочий процесс в Создание кластера VMware vSphere в глобальном Cluster успешно завершен.
• Вы проверили дополнительные параметры в Подготовка параметров для кластера VMware vSphere.
• Вы понимаете, какие манифесты определяют параметры сети, размещения и дисков в вашем развертывании.

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

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

• 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:

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 и манифестах:

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

При переходе от одного 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

#Включение нескольких дата-центров и failure domains

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

К таким принципам относятся следующие:

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

Подготовьте следующие placeholders для первого дата-центра:

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

Подготовьте следующие placeholders для второго дата-центра:

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

Если вы добавляете третий дата-центр, продолжайте использовать тот же шаблон 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. Первому дата-центру также нужны 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: {}

Пустой селектор {} соответствует каждой VSphereDeploymentZone, у которой controlPlane: true. Используйте match labels, чтобы ограничить control plane подмножеством зон.

Также добавьте блок [Labels] в ConfigMap CPI, чтобы vSphere CPI публиковал совпадающие метки зоны и региона на workload nodes. Ключи должны соответствовать значениям tagCategory, используемым в VSphereFailureDomain.spec.zone.tagCategory и VSphereFailureDomain.spec.region.tagCategory. Обновите данные vsphere.conf в 15-vsphere-cpi-clusterresourceset.yaml:

      vsphere.conf: |
        [Global]
        secret-name = "vsphere-cloud-secret"
        secret-namespace = "kube-system"
        service-account = "cloud-controller-manager"
        port = "443"
        insecure-flag = "<cpi_insecure_flag>"
        datacenters = "<cpi_datacenters>"

        [Labels]
        zone = "k8s-zone"
        region = "k8s-region"

        [VirtualCenter "<vsphere_server>"]

failureDomainSelector и блок [Labels] CPI должны включаться вместе. Если добавить только один из них, кластер окажется в несогласованном состоянии: узлы получат неразрешенные метки зоны или региона, либо control plane не сможет выбрать целевое размещение.

Задайте зону развертывания worker, если MachineDeployment для worker должен быть привязан к одной конкретной цели развертывания. Добавьте 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

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

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

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

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

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

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

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

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

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

#Масштабирование узлов worker

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

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

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

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

1. Добавьте новые слоты узлов worker в 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, и символическая ссылка создается заново. Диск никогда автоматически не форматируется и не монтируется — управление им во время выполнения выполняет приложение.

Затем обновите replicas worker:

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 переходят в состояние Ready.
• Существующие узлы остаются в исправном состоянии после изменения.

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

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