#Управление узлами в Huawei DCS

В этом документе описано, как управлять рабочими узлами с помощью ресурсов Cluster API Machine.

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

#Обзор

Рабочие узлы управляются через ресурсы Cluster API Machine, обеспечивая декларативное и автоматизированное управление жизненным циклом узлов. Процесс развертывания включает:

1. Настройка пула IP-адресов и hostname — сетевые параметры для рабочих узлов
2. Настройка шаблона Machine — параметры виртуальной машины
3. Настройка bootstrap — параметры инициализации узла и подключения к кластеру
4. Развертывание Machine — оркестрация создания и управления узлами

#Развертывание рабочих узлов

#Шаг 1: Настройка пула IP-адресов и hostname

Пул IP-адресов и hostname определяет сетевую конфигурацию для виртуальных машин рабочих узлов. Перед развертыванием необходимо спланировать и настроить IP-адреса, hostname, DNS-серверы, дополнительные NIC и другие сетевые параметры.

В Huawei DCS пул IP-адресов также используется для объявления постоянных дисков, которые должны сохраняться при замене виртуальной машины. Используйте persistentDisk для диска /var/cpaas, требуемого платформой, а также для любого другого диска рабочего узла, который должен сохраняться при операциях удаления и повторного создания. Для этого сценария требуется DCS provider v1.0.16 или более поздней версии.

Пример:

Создайте DCSIpHostnamePool с именем <cluster-name>-worker-pool:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: DCSIpHostnamePool
metadata:
  name: <cluster-name>-worker-pool
  namespace: cpaas-system
spec:
  pool:
  - ip: "<worker-ip-1>"
    mask: "<worker-cidr-prefix-length>"
    gateway: "<worker-gateway>"
    dns: "<worker-dns>"
    hostname: "<worker-hostname-1>"
    machineName: "<worker-machine-name-1>"
    additionNic:
    - ip: "<worker-additional-ip-1>"
      mask: "<worker-additional-cidr-prefix-length>"
      gateway: "<worker-additional-gateway>"
      dns: "<worker-additional-dns>"
      dvSwitchName: "<additional-dvs>"
      portGroupName: "<additional-port-group>"
    persistentDisk:
    - slot: 0
      quantityGB: 40
      datastoreClusterName: <datastore-cluster-name>
      path: /var/cpaas
      format: xfs
  - ip: "<worker-ip-2>"
    mask: "<worker-cidr-prefix-length>"
    gateway: "<worker-gateway>"
    dns: "<worker-dns>"
    hostname: "<worker-hostname-2>"
    machineName: "<worker-machine-name-2>"
    persistentDisk:
    - slot: 0
      quantityGB: 40
      datastoreClusterName: <datastore-cluster-name>
      path: /var/cpaas
      format: xfs
  - ip: "<worker-ip-3>"
    mask: "<worker-cidr-prefix-length>"
    gateway: "<worker-gateway>"
    dns: "<worker-dns>"
    hostname: "<worker-hostname-3>"
    machineName: "<worker-machine-name-3>"
    persistentDisk:
    - slot: 0
      quantityGB: 40
      datastoreClusterName: <datastore-cluster-name>
      path: /var/cpaas
      format: xfs

Ключевые параметры:

*Поля, помеченные как Да*, требуются провайдеру для определения целевой сети и подключения дополнительного NIC. Поля, помеченные как Рекомендуется*, необходимы для сгенерированной статической гостевой сетевой конфигурации. CRD не требует эти поля.

#Шаг 2: Настройка шаблона Machine

DCSMachineTemplate определяет параметры виртуальных машин рабочих узлов, включая шаблоны VM, вычислительные ресурсы, конфигурацию хранилища и сетевые параметры.

Поля в этом ресурсе ссылаются на несколько понятий платформы Huawei DCS (DCS VM Template, DCS VM Folder, DCS Datastore и связанные элементы). Описание этих понятий и того, как они сопоставляются с ресурсами Cluster API, см. в разделе Huawei DCS Concepts and Terminology.

Пример:

Создайте DCSMachineTemplate с именем <cluster-name>-worker-template:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: DCSMachineTemplate
metadata:
  name: <cluster-name>-worker-template
  namespace: cpaas-system
spec:
  template:
    spec:
      vmTemplateName: <vm-template-name>
      location:
        type: folder
        name: <folder-name>
      vmConfig:
        dvSwitchName: <dv-switch-name> # Optional
        portGroupName: <port-group-name> # Optional
        dcsMachineCpuSpec:
          quantity: <worker-cpu>
        dcsMachineMemorySpec: # MB
          quantity: <worker-memory>
        dcsMachineDiskSpec: # GB
        - quantity: 0
          datastoreClusterName: <datastore-cluster-name>
          systemVolume: true
        - quantity: 100
          datastoreClusterName: <datastore-cluster-name>
          path: /var/lib/kubelet
          format: xfs
        - quantity: 100
          datastoreClusterName: <datastore-cluster-name>
          path: /var/lib/containerd
          format: xfs
      ipHostPoolRef:
        name: <cluster-name>-worker-pool

Ключевые параметры:

*Обязательно, когда указан родительский объект

#Постоянные диски, управляемые пулом IP

Объявляйте любой диск, который должен сохраняться при обновлении, в соответствующей записи DCSIpHostnamePool.spec.pool[].persistentDisk (DCS provider v1.0.16 или более поздней версии).

• Используйте это для /var/cpaas, который требуется платформой.
• Оставьте DCSMachineTemplate для системного диска и локальных дисков шаблона, которые могут быть пересозданы вместе с VM.
• Для каждой записи IP выбирайте уникальное значение slot. Контроллер использует (ip, slot) как идентификатор постоянного диска.
• На заменяемых узлах логика настройки диска гостевой ОС проверяет наличие существующей файловой системы. Если диск уже отформатирован, mkfs пропускается, и диск монтируется напрямую.
• Сценарии с постоянными дисками требуют замены по одному узлу, поэтому установите MachineDeployment.spec.strategy.rollingUpdate.maxSurge = 0.
• Вы можете добавлять новые записи persistentDisk, но удаление существующих записей не поддерживается. Контроллер подключает новый добавленный диск к работающей VM на стороне DCS, но не форматирует и не монтирует диск внутри гостевой ОС. Форматирование и монтирование в гостевой системе вступают в силу только после замены VM, когда replacement VM выполняет сгенерированную настройку диска во время bootstrap.
• Контроллер создает новые постоянные тома как независимые persistent normal volumes. При повторном использовании существующего тома требуется только, чтобы он был независимым и постоянным; конкретный тип тома DCS не требуется.
• Рассматривайте format, options и pciType как неизменяемые после создания.
• Используйте isThin только тогда, когда среде DCS требуется явное значение thin-provisioning для вновь создаваемых постоянных томов. Если поле не указано, провайдер не отправляет isThin, и DCS использует значение по умолчанию платформы.
• Рассматривайте изменения quantityGB и datastore как изменения, влияющие на rolling update. Webhook выполняет best-effort валидацию на стороне платформы DCS, когда имеет достаточно контекста кластера. isThin — это значение только для создания: его изменение не вызывает валидацию, reconcile или преобразование существующих томов и влияет только на постоянные тома, созданные позже.

Чтобы проверить состояние постоянных дисков во время операций с узлами, просмотрите status.persistentDiskStatus в пуле:

kubectl get dcsiphostnamepool <cluster-name>-worker-pool -n cpaas-system -o yaml

#Дополнительные NIC, управляемые пулом IP

Объявляйте дополнительные NIC рабочих узлов в DCSIpHostnamePool.spec.pool[].additionNic[].

• Провайдер применяет additionNic[] только при создании новой VM.
• Существующие рабочие VM не обновляются на лету при изменении Pool.
• Новые Machine рабочих узлов используют значения additionNic[] из того слота Pool, который они занимают.
• Каждый дополнительный NIC должен включать и dvSwitchName, и portGroupName, чтобы провайдер мог определить целевой DCS Port Group до клонирования VM.
• Если вы также используете persistentDisk[], установите MachineDeployment.spec.strategy.rollingUpdate.maxSurge = 0, чтобы фиксированные слоты IP и сохраненные диски перемещались по одному узлу за раз.
• Если у дополнительного NIC указан gateway, проверьте, что таблица маршрутов гостевой ОС по-прежнему использует нужную основную сеть для маршрута по умолчанию.

Чтобы проверить состояние дополнительных NIC во время выполнения, просмотрите DCSMachine.status.additionalNic:

kubectl -n cpaas-system get dcsmachine -l cluster.x-k8s.io/cluster-name=<cluster-name> \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.networkConfig.ip}{"\t"}{.status.additionalNic}{"\n"}{end}'

#Шаг 3: Настройка Bootstrap Template

KubeadmConfigTemplate определяет bootstrap-конфигурацию для рабочих узлов, включая учетные записи пользователей, SSH-ключи, системные файлы и настройки kubeadm join.

Пример:

apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
kind: KubeadmConfigTemplate
metadata:
  name: <cluster-name>-worker-kct
  namespace: cpaas-system
spec:
  template:
    spec:
      format: ignition
      users:
      - name: boot
        sshAuthorizedKeys:
        - "<ssh-authorized-keys>"
      files:
      - path: /etc/kubernetes/patches/kubeletconfiguration0+strategic.json
        owner: "root:root"
        permissions: "0644"
        content: |
          {
            "apiVersion": "kubelet.config.k8s.io/v1beta1",
            "kind": "KubeletConfiguration",
            "protectKernelDefaults": true,
            "staticPodPath": null,
            "tlsCertFile": "/etc/kubernetes/pki/kubelet.crt",
            "tlsPrivateKeyFile": "/etc/kubernetes/pki/kubelet.key",
            "streamingConnectionIdleTimeout": "5m",
            "clientCAFile": "/etc/kubernetes/pki/ca.crt"
          }
      preKubeadmCommands:
      - while ! ip route | grep -q "default via"; do sleep 1; done; echo "NetworkManager started"
      - mkdir -p /run/cluster-api && restorecon -Rv /run/cluster-api
      - if [ -f /etc/disk-setup.sh ]; then bash /etc/disk-setup.sh; fi
      postKubeadmCommands:
      - chmod 600 /var/lib/kubelet/config.yaml
      joinConfiguration:
        patches:
          directory: /etc/kubernetes/patches
        nodeRegistration:
          kubeletExtraArgs:
            node-ip: NODE_IP
            provider-id: PROVIDER_ID
            volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
            protect-kernel-defaults: "true"

PROVIDER_ID и NODE_IP — это буквальные magic tokens, которые DCS Provider подставляет во время подключения машины к кластеру — оставляйте их точно в том виде, как они написаны. Полный список см. в Magic-Token Placeholders.

files:
- contentFrom:
    secret:
      key: worker-kubelet-patch.json
      name: dcs-kubernetes-1.33-files
  owner: "root:root"
  path: /etc/kubernetes/patches/kubeletconfiguration0+strategic.json
  permissions: "0644"

#Шаг 4: Настройка Machine Deployment

MachineDeployment оркестрирует создание и управление рабочими узлами, ссылаясь на ранее настроенные ресурсы DCSMachineTemplate и KubeadmConfigTemplate. Он управляет требуемым количеством узлов и обрабатывает rolling updates.

Пример:

apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: <cluster-name>-md-0
  namespace: cpaas-system
spec:
  strategy:
    rollingUpdate:
      maxSurge: 0 # Required when this node pool relies on persistent disks
      maxUnavailable: 1
    type: RollingUpdate
  clusterName: <cluster-name>
  replicas: 3
  selector:
    matchLabels: null
  template:
    metadata:
      labels:
        cluster.x-k8s.io/cluster-name: <cluster-name>
        pool.name: <cluster-name>-md-0
    spec:
      nodeDrainTimeout: 1m
      nodeDeletionTimeout: 5m
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
          kind: KubeadmConfigTemplate
          name: <cluster-name>-worker-kct
          namespace: cpaas-system
      clusterName: <cluster-name>
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: DCSMachineTemplate
        name: <cluster-name>-worker-template
        namespace: cpaas-system
      version: <worker-kubernetes-version>

Ключевые параметры:

#Операции управления узлами

В этом разделе описаны распространенные операционные задачи по управлению рабочими узлами, включая масштабирование, обновления, апгрейды и изменения шаблонов.

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

Масштабирование рабочих узлов позволяет адаптировать емкость кластера к требованиям нагрузки. Cluster API автоматически управляет жизненным циклом узлов через ресурс MachineDeployment.

#Добавление рабочих узлов

Увеличьте количество рабочих узлов, чтобы обработать возросшую нагрузку или добавить новую емкость.

Сценарий использования: увеличение кластера для добавления вычислительных ресурсов

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

• Убедитесь, что в пуле IP-адресов достаточно свободных IP-адресов для новых узлов
• Убедитесь, что на платформе DCS достаточно ресурсов для подготовки новых VM

Порядок действий:

1. Проверьте текущее состояние узлов

   Просмотрите текущие машины в кластере:

   # List all machines in the cluster
   kubectl get machines -n cpaas-system
   
   # List machines for a specific MachineDeployment
   kubectl get machines -n cpaas-system -l cluster.x-k8s.io/deployment-name=<cluster-name>-md-0

2. Расширьте пул IP

   Перед увеличением количества узлов добавьте в пул новые конфигурации IP для дополнительных узлов.

   INFO

   Расширение пула IP Пул IP должен содержать как минимум столько записей, сколько требуется replicas. Добавьте новые записи IP для каждого дополнительного рабочего узла, который планируете развернуть.

   Добавьте записи IP в пул:

   Сначала экспортируйте текущую конфигурацию пула, чтобы сохранить существующие записи:

   kubectl get dcsiphostnamepool <cluster-name>-worker-pool -n cpaas-system -o yaml

   Затем используйте следующую команду, чтобы добавить новые конфигурации IP. Массив pool должен включать все существующие записи плюс новые записи:

   kubectl patch dcsiphostnamepool <cluster-name>-worker-pool -n cpaas-system \
     --type='merge' -p='
   {
     "spec": {
       "pool": [
         {
           "ip": "<existing-ip-1>",
           "mask": "<worker-cidr-prefix-length>",
           "gateway": "<worker-gateway>",
           "dns": "<worker-dns>",
           "hostname": "<existing-hostname-1>",
           "machineName": "<existing-machine-name-1>",
           "persistentDisk": [
             {
               "slot": 0,
               "quantityGB": 40,
               "datastoreClusterName": "<datastore-cluster-name>",
               "path": "/var/cpaas",
               "format": "xfs"
             }
           ]
         },
         {
           "ip": "<existing-ip-2>",
           "mask": "<worker-cidr-prefix-length>",
           "gateway": "<worker-gateway>",
           "dns": "<worker-dns>",
           "hostname": "<existing-hostname-2>",
           "machineName": "<existing-machine-name-2>",
           "persistentDisk": [
             {
               "slot": 0,
               "quantityGB": 40,
               "datastoreClusterName": "<datastore-cluster-name>",
               "path": "/var/cpaas",
               "format": "xfs"
             }
           ]
         },
         {
           "ip": "<new-worker-ip-1>",
           "mask": "<worker-cidr-prefix-length>",
           "gateway": "<worker-gateway>",
           "dns": "<worker-dns>",
           "hostname": "<new-worker-hostname-1>",
           "machineName": "<new-worker-machine-name-1>",
           "persistentDisk": [
             {
               "slot": 0,
               "quantityGB": 40,
               "datastoreClusterName": "<datastore-cluster-name>",
               "path": "/var/cpaas",
               "format": "xfs"
             }
           ]
         },
         {
           "ip": "<new-worker-ip-2>",
           "mask": "<worker-cidr-prefix-length>",
           "gateway": "<worker-gateway>",
           "dns": "<worker-dns>",
           "hostname": "<new-worker-hostname-2>",
           "machineName": "<new-worker-machine-name-2>",
           "persistentDisk": [
             {
               "slot": 0,
               "quantityGB": 40,
               "datastoreClusterName": "<datastore-cluster-name>",
               "path": "/var/cpaas",
               "format": "xfs"
             }
           ]
         }
       ]
     }'
   WARNING

   Важные замечания

   • Массив pool должен включать все существующие записи плюс новые записи, которые вы хотите добавить
   • Скопируйте существующие записи из экспортированного YAML, чтобы избежать потери данных
   • kubectl patch --type='merge' заменяет весь массив spec.pool, поэтому скопируйте каждый существующий блок persistentDisk без изменений, включая isThin, если он присутствует, если только вы не добавляете новые диски намеренно
   • Убедитесь, что каждая новая запись имеет уникальные значения ip, hostname и machineName
   • Если новым рабочим узлам также требуется диск /var/cpaas, обязательный для платформы, объявите его в persistentDisk каждой новой записи
   • Параметры сети (mask, gateway, dns) обычно совпадают с существующими записями

   Пример: добавление 2 новых узлов к существующему пулу из 3 узлов

   # Current pool has 3 entries (10.0.1.11, 10.0.1.12, 10.0.1.13)
   # Adding 2 more entries for nodes 4 and 5
   kubectl patch dcsiphostnamepool worker-pool-1-ippool -n cpaas-system \
     --type='merge' -p='
   {
     "spec": {
       "pool": [
         {
           "ip": "10.0.1.11",
           "mask": "24",
           "gateway": "10.0.1.1",
           "dns": "10.0.0.2",
           "hostname": "worker-node-1",
           "machineName": "worker-vm-1",
           "persistentDisk": [
             {
               "slot": 0,
               "quantityGB": 40,
               "datastoreClusterName": "shared-datastore-cluster",
               "path": "/var/cpaas",
               "format": "xfs"
             }
           ]
         },
         {
           "ip": "10.0.1.12",
           "mask": "24",
           "gateway": "10.0.1.1",
           "dns": "10.0.0.2",
           "hostname": "worker-node-2",
           "machineName": "worker-vm-2",
           "persistentDisk": [
             {
               "slot": 0,
               "quantityGB": 40,
               "datastoreClusterName": "shared-datastore-cluster",
               "path": "/var/cpaas",
               "format": "xfs"
             }
           ]
         },
         {
           "ip": "10.0.1.13",
           "mask": "24",
           "gateway": "10.0.1.1",
           "dns": "10.0.0.2",
           "hostname": "worker-node-3",
           "machineName": "worker-vm-3",
           "persistentDisk": [
             {
               "slot": 0,
               "quantityGB": 40,
               "datastoreClusterName": "shared-datastore-cluster",
               "path": "/var/cpaas",
               "format": "xfs"
             }
           ]
         },
         {
           "ip": "10.0.1.14",
           "mask": "24",
           "gateway": "10.0.1.1",
           "dns": "10.0.0.2",
           "hostname": "worker-node-4",
           "machineName": "worker-vm-4",
           "persistentDisk": [
             {
               "slot": 0,
               "quantityGB": 40,
               "datastoreClusterName": "shared-datastore-cluster",
               "path": "/var/cpaas",
               "format": "xfs"
             }
           ]
         },
         {
           "ip": "10.0.1.15",
           "mask": "24",
           "gateway": "10.0.1.1",
           "dns": "10.0.0.2",
           "hostname": "worker-node-5",
           "machineName": "worker-vm-5",
           "persistentDisk": [
             {
               "slot": 0,
               "quantityGB": 40,
               "datastoreClusterName": "shared-datastore-cluster",
               "path": "/var/cpaas",
               "format": "xfs"
             }
           ]
         }
       ]
     }'

3. Проверьте емкость пула IP

   После расширения пула IP убедитесь, что он содержит достаточно записей для требуемого числа replicas:

   kubectl get dcsiphostnamepool -n cpaas-system <cluster-name>-worker-pool -o yaml

   Убедитесь, что пул содержит как минимум столько записей, сколько соответствует требуемому числу replicas.

4. Увеличьте число replicas в MachineDeployment

   Измените поле replicas на требуемое количество узлов:

   kubectl patch machinedeployment <cluster-name>-md-0 -n cpaas-system \
     --type='json' -p='[{"op": "replace", "path": "/spec/replicas", "value": <new-replica-count>}]'

   Пример: увеличение с 3 до 5 узлов

   kubectl patch machinedeployment worker-pool-1 -n cpaas-system \
     --type='json' -p='[{"op": "replace", "path": "/spec/replicas", "value": 5}]'

5. Отслеживайте ход масштабирования

   Наблюдайте за процессом создания машин:

   # Watch machines being created
   kubectl get machines -n cpaas-system -w
   
   # Check MachineDeployment status
   kubectl get machinedeployment <cluster-name>-md-0 -n cpaas-system

   Контроллер Cluster API автоматически создаст новые машины на основе шаблона MachineDeployment.

6. Проверьте, что узлы присоединились к кластеру

   Переключитесь на контекст целевого кластера и проверьте новые узлы:

   # Switch to target cluster context
   kubectl config use-context <target-cluster-context>
   
   # Check all nodes are Ready
   kubectl get nodes

   Новые узлы должны появиться в списке и перейти в состояние Ready.

#Удаление рабочих узлов

Уменьшите количество рабочих узлов, чтобы сократить емкость кластера или удалить неиспользуемые ресурсы. Cluster API поддерживает две стратегии удаления:

1. Случайное удаление: уменьшите replicas, платформа случайным образом выбирает и удаляет машины
2. Целевое удаление: пометьте конкретные машины для удаления, затем уменьшите replicas (рекомендуется для восстановления IP)

#Случайное удаление

Сценарий использования: уменьшение кластера, когда можно удалить любой узел (нет требований к конкретному IP)

Порядок действий:

1. Определите текущее состояние машин

   Просмотрите текущие машины в MachineDeployment:

   kubectl get machines -n cpaas-system -l cluster.x-k8s.io/deployment-name=<cluster-name>-md-0

2. Уменьшите число replicas в MachineDeployment

   Измените поле replicas, чтобы сократить количество узлов:

   kubectl patch machinedeployment <cluster-name>-md-0 -n cpaas-system \
     --type='json' -p='[{"op": "replace", "path": "/spec/replicas", "value": <new-replica-count>}]'

   Пример: уменьшение с 5 до 3 узлов

   kubectl patch machinedeployment worker-pool-1 -n cpaas-system \
     --type='json' -p='[{"op": "replace", "path": "/spec/replicas", "value": 3}]'

   Контроллер Cluster API случайным образом выберет и удалит машины так, чтобы число соответствовало требуемому количеству replicas.

3. Отслеживайте ход удаления

   Наблюдайте за процессом удаления машин:

   kubectl get machines -n cpaas-system -w

   Контроллер Cluster API выполнит:

   • Drain выбранных узлов (эвакуация pods, если это возможно)
   • Удаление underlying VM с платформы DCS
   • Удаление ресурсов machine

4. Проверьте, что узлы удалены

   Переключитесь на контекст целевого кластера:

   kubectl config use-context <target-cluster-context>
   kubectl get nodes

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

#Целевое удаление

Сценарий использования: удалить конкретные машины (например, для восстановления IP, замены неисправных узлов)

Порядок действий:

1. Определите машины для удаления

   Просмотрите текущие машины:

   kubectl get machines -n cpaas-system -l cluster.x-k8s.io/deployment-name=<cluster-name>-md-0

   Запомните <machine-name> машин, которые необходимо удалить.

2. Добавьте аннотацию удаления для машин

   Пометьте конкретные машины для удаления:

   kubectl patch machine <machine-name> -n cpaas-system \
     --type='merge' -p='{"metadata": {"annotations": {"cluster.x-k8s.io/delete-machine": "true"}}}'

   Повторите для каждой машины, которую нужно удалить.

   Пример: удаление двух конкретных машин

   kubectl patch machine worker-pool-1-abc123 -n cpaas-system \
     --type='merge' -p='{"metadata": {"annotations": {"cluster.x-k8s.io/delete-machine": "true"}}}'
   
   kubectl patch machine worker-pool-1-def456 -n cpaas-system \
     --type='merge' -p='{"metadata": {"annotations": {"cluster.x-k8s.io/delete-machine": "true"}}}'

3. Уменьшите число replicas в MachineDeployment

   После аннотирования машин уменьшите количество replicas:

   INFO

   Количество replicas должно соответствовать числу аннотированных машин Уменьшите replicas ровно на количество аннотированных машин.

   • Если уменьшить меньше, будут удалены не все аннотированные машины
   • Если уменьшить больше, дополнительные машины будут выбраны для удаления случайным образом

   kubectl patch machinedeployment <cluster-name>-md-0 -n cpaas-system \
     --type='json' -p='[{"op": "replace", "path": "/spec/replicas", "value": <new-replica-count>}]'

   Пример: если вы аннотировали 2 машины, уменьшите replicas ровно на 2 (например, с 5 до 3)

   Платформа удалит аннотированные машины, а не выбранные случайным образом.

4. Отслеживайте ход удаления

   Наблюдайте за процессом удаления машин:

   kubectl get machines -n cpaas-system -w

5. Проверьте, что узлы удалены

   Переключитесь на контекст целевого кластера:

   kubectl config use-context <target-cluster-context>
   kubectl get nodes

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

#Обновление инфраструктуры Machine

Чтобы обновить параметры рабочих машин (CPU, memory, disk, VM template), выполните следующие шаги:

1. Создайте новый шаблон Machine

   • Скопируйте существующий DCSMachineTemplate, на который ссылается ваш MachineDeployment
   • Измените необходимые значения (CPU, memory, disk, VM template и т. д.)
   • Дайте новому шаблону уникальное имя
   • Примените новый DCSMachineTemplate к кластеру

2. Обновите Machine Deployment

   • Измените ресурс MachineDeployment
   • Обновите поле spec.template.spec.infrastructureRef.name, чтобы оно ссылалось на новый шаблон
   • Примените изменения

3. Rolling update

   • Система автоматически запустит rolling update
   • Рабочие узлы будут заменены с новыми параметрами
   • Любые диски, объявленные в DCSIpHostnamePool.spec.pool[].persistentDisk, будут отсоединены от старой VM и повторно подключены к replacement VM
   • Отслеживайте ход обновления через status MachineDeployment

Если вы переносите существующий кластер со старой схемы template-disk на управляемые пулом постоянные диски, сначала выполните Migrate Existing Huawei DCS Clusters to Pool-Managed Persistent Disks, прежде чем полагаться на сохранение данных во время обновления.

#Обновление bootstrap templates

Bootstrap templates (KubeadmConfigTemplate) используются ресурсами MachineDeployment и MachineSet. Изменения существующих шаблонов не запускают автоматический rollout существующих машин; только новые машины используют обновленный шаблон.

Процесс обновления:

1. Экспортируйте существующий шаблон

   kubectl get KubeadmConfigTemplate <template-name> -o yaml > new-template.yaml

2. Измените конфигурацию

   • Обновите нужные поля в экспортированном YAML
   • Измените metadata.name на новое уникальное имя
   • Удалите лишние поля metadata (resourceVersion, uid, creationTimestamp и т. д.)

3. Создайте новый шаблон

   kubectl apply -f new-template.yaml

4. Обновите MachineDeployment

   • Измените ресурс MachineDeployment
   • Обновите spec.template.spec.bootstrap.configRef.name, чтобы он ссылался на новый шаблон
   • Примените изменения, чтобы запустить rolling update

#Обновление версии Kubernetes

Для обновления Kubernetes в Huawei DCS см. Upgrading Kubernetes on Huawei DCS. В этом руководстве описаны требуемый порядок обновления, YAML-процесс для ресурсов MachineDeployment, а также workflow через web UI для обновления Node Pool.

#Управление node pool через Web UI

Node pool предоставляют декларативный способ управления группами узлов с идентичной конфигурацией. Через web UI можно просматривать, добавлять и удалять рабочие node pool.

Требование к версии: этот workflow требует Fleet Essentials и Alauda Container Platform DCS Infrastructure Provider версии 1.0.13 или более поздней. Если версия провайдера ниже 1.0.13, используйте описанные в этом документе YAML-based workflows для node pool. Если workflow node pool опирается на постоянные диски, управляемые пулом, используйте DCS provider v1.0.16 или более поздней версии. В v1.0.16 объявление persistentDisk в DCSIpHostnamePool остается доступным только в YAML и не отображается в UI node pool.

Если node pool использует постоянные диски, управляемые пулом, подготовьте или обновите соответствующую запись DCSIpHostnamePool с помощью YAML до использования workflow web UI, описанного здесь.

#Просмотр node pool

Вкладка Node Pools отображает все node pool в кластере:

Node Pool control plane:

• Фиксированное количество 3 replicas для высокой доступности
• Отображает версию Kubernetes с индикатором обновления, если он доступен
• Показывает ссылку Conditions для подробного статуса

Worker Node Pool:

• Настраиваемое количество replicas
• Независимое управление версией Kubernetes
• Операции масштабирования и обновления

Информация на карточке node pool:

#Добавление Worker Node Pool

Навигация: вкладка Node Pools → нажмите Add Worker Node Pool

Поля формы:

Проверка:

• Имя pool должно быть уникальным в пределах кластера
• В пуле IP должно быть достаточно доступных IP-адресов (≥ Replicas)
• Должны быть соблюдены ограничения maxSurge/maxUnavailable
• Если node pool использует постоянные диски, установите maxSurge = 0, чтобы Machine заменялись по одному

Подсказка: добавьте к имени pool префикс с именем кластера и дефисом (например, mycluster-worker-1), чтобы избежать конфликтов имен.

После создания новые узлы появятся на вкладке Nodes. Количество узлов будет равно настроенному значению Replicas.

#Удаление Worker Node Pool

Шаги:

1. Нажмите значок удаления на карточке Worker Node Pool
2. Подтвердите удаление в диалоговом окне

#Просмотр Conditions (только control plane)

Нажмите ссылку Conditions на карточке Control Plane Node Pool, чтобы просмотреть подробную информацию о статусе.

Список conditions:

#Устранение неполадок

#Новый worker Machine остается в состоянии Provisioning, а VM DCS — в состоянии creating

Диагностический процесс одинаков для объектов Machine control plane и worker — если DCSMachine достигает состояния Provisioning, при этом status.cdRomFile уже установлен (аутентификация DCS API и загрузка ISO выполнены), но underlying VM DCS так и не назначается на host, ошибка находится на стороне платформы DCS, а не контроллера.

Полное дерево диагностики см. в разделе Infrastructure → Troubleshooting: VM stuck in creating, где описаны:

• Проверка того, что проблема связана с зависанием размещения, а не с медленной загрузкой.
• Проверка свободного места в datastore.
• Проверка загрузки CPU / memory на host и коэффициентов overcommit.
• Координация с командой платформы DCS для перераспределения нагрузки, когда один DCS Host перегружен.
• Путь эскалации, когда задача развертывания действительно заблокирована.

Для обеспечения высокой доступности control plane на нескольких физических host см. Infrastructure → Cross-Host High Availability for Control Plane.

Та же диагностика применяется независимо от того, является ли зависший узел первым узлом control plane нового кластера, новым worker, добавленным через масштабирование MachineDeployment, или replacement worker, созданным во время rolling update.

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

• Create Clusters
• Upgrade Clusters