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

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

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

При использовании YAML-примеров в этом документе заменяйте только значения, заключенные в <>, на значения, соответствующие вашей среде. Остальные поля сохраняйте без изменений, если только политика вашего кластера не требует другого значения.

#Обзор

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

1. Пул конфигурации машин — параметры сети для рабочих узлов
2. Шаблон машины — характеристики ВМ
3. Конфигурация bootstrap — параметры инициализации узла
4. Развертывание машин — оркестрация создания и управления узлами

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

Перед подготовкой YAML для рабочих узлов выполните контрольный список входных данных HCS в Infrastructure Resources for Huawei Cloud Stack. В частности, перечислите все подсети рабочих узлов в HCSCluster.spec.network.subnets, выделите IP-адреса рабочих узлов из заранее подготовленных свободных диапазонов IP и соберите значения API flavorName и availabilityZone, распознаваемые провайдером. Если вы добавляете новую подсеть рабочих узлов в существующий кластер в состоянии Ready, изменяйте HCSCluster.spec.network.subnets, указывая полный объект подсети, а не только имя подсети.

#Шаг 1: Настройка пула конфигурации машин

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

Используйте один селектор подсети для каждой записи networks[]. Для новых манифестов задавайте либо subnetName, либо subnetId, но не оба сразу. В существующих манифестах можно оставить устаревшее поле subenetName; если при обновлении такого манифеста вы также добавляете subnetName, его значение должно в точности совпадать со значением subenetName. Не указывайте конфликтующие значения в subenetName, subnetName и subnetId.

Если вы используете subnetName для рабочих узлов, добавьте то же имя подсети в родительский список HCSCluster.spec.network.subnets до создания или масштабирования пула рабочих узлов. Для существующего кластера в состоянии Ready добавляйте полный объект подсети, включая идентификатор подсети, а не только ее имя.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: HCSMachineConfigPool
metadata:
  name: <cluster-name>-worker-pool
  namespace: cpaas-system
  labels:
    cluster.x-k8s.io/cluster-name: <cluster-name>
spec:
  configs:
    - hostname: <worker-1-hostname>
      networks:
        - subnetName: <subnet-name>
          ipAddress: <worker-1-ip>
      persistentDisks:
        - slot: 0
          size: 100
          type: SSD
          mountPath: /var/cpaas
          format: xfs
    - hostname: <worker-2-hostname>
      networks:
        - subnetName: <subnet-name>
          ipAddress: <worker-2-ip>
      persistentDisks:
        - slot: 0
          size: 100
          type: SSD
          mountPath: /var/cpaas
          format: xfs
    - hostname: <worker-3-hostname>
      networks:
        - subnetName: <subnet-name>
          ipAddress: <worker-3-ip>
      persistentDisks:
        - slot: 0
          size: 100
          type: SSD
          mountPath: /var/cpaas
          format: xfs

*Для новых манифестов задавайте либо subnetName, либо subnetId. В существующих манифестах можно продолжать использовать subenetName, а subnetName можно добавлять только если оба поля используют одно и то же значение. Не задавайте конфликтующие значения селектора подсети.

Поля постоянного диска обязательны, если указан persistentDisks.

Используйте persistentDisks[] для локального состояния узла, которое должно сохраняться при замене рабочих узлов. Не объявляйте тот же путь монтирования в HCSMachineTemplate.spec.template.spec.dataVolumes[].

Примечание: В схеме CRD поля subnetName, subenetName и subnetId указаны как необязательные, и допустимые комбинации между ними не выражены. При создании манифестов следуйте приведенным выше правилам уровня провайдера.

Примечание: networks[] может содержать более одной записи, если рабочему узлу требуется несколько NIC. Текущий провайдер использует каждую запись только для подключения NIC с селектором подсети и статическим IP-адресом. Он не поддерживает объявления роли для каждого NIC, выбор шлюза по умолчанию, статические маршруты, метрики маршрутов или параметры DNS для каждого NIC.

#Управляемые пулом постоянные диски для рабочих узлов

Объявляйте диски рабочих узлов, которые должны сохраняться при замене, в соответствующей записи HCSMachineConfigPool.spec.configs[].persistentDisks[]. Используйте эту модель для /var/cpaas и для любого другого локального состояния узла, которое необходимо сохранять при поэтапной замене.

• Оставляйте HCSMachineTemplate.spec.template.spec.dataVolumes[] для временных дисков, которые могут пересоздаваться вместе с каждой ECS.
• Для каждого имени хоста сохраняйте уникальные и непрерывные слоты, начиная с 0. Провайдер использует (hostname, slot) как идентификатор постоянного диска.
• Рассматривайте slot, size, type, format и mountPath как неизменяемые после того, как провайдер принял запись.
• Вы можете обновлять mountOptions. Изменение вступит в силу после замены рабочего узла.
• Вы можете добавлять новые записи persistentDisks[]. Провайдер создает или выделяет диск EVS, но не подключает его на лету к работающей ECS. Запустите поэтапную замену с MachineDeployment.spec.strategy.rollingUpdate.maxSurge: 0, прежде чем ожидать, что новый диск будет отформатирован и смонтирован внутри гостевой ОС.

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

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

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

HCSMachineTemplate определяет характеристики ВМ для рабочих узлов.

Настраивайте рабочие узлы с системным томом и временными томами данных для путей, которые могут пересоздаваться вместе с каждой ECS, например /var/lib/kubelet и /var/lib/containerd. Помещайте /var/cpaas в HCSMachineConfigPool.spec.configs[].persistentDisks[], если состояние платформы должно сохраняться при замене рабочего узла.

При подготовке шаблона рабочего узла используйте значения API flavorName и availabilityZone, распознаваемые провайдером. Эти значения не являются отображаемыми именами в интерфейсе tenant.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: HCSMachineTemplate
metadata:
  name: <cluster-name>-worker-template
  namespace: cpaas-system
spec:
  template:
    spec:
      imageName: <vm-image-name>
      flavorName: <instance-flavor>
      availabilityZone: <availability-zone>
      rootVolume:
        type: SSD
        size: 100
      configPoolRef:
        name: <cluster-name>-worker-pool
      dataVolumes:
        - size: 20
          type: SSD
          mountPath: /var/lib/kubelet
          format: xfs
        - size: 20
          type: SSD
          mountPath: /var/lib/containerd
          format: xfs

*Обязательно, если указан dataVolumes.

dataVolumes[] пересоздаются вместе с ECS. Не используйте их для /var/cpaas или любого другого пути, который должен сохраняться при поэтапной замене.

Примечание: Не задавайте в манифестах HCSMachineTemplate такие поля идентичности времени выполнения, как providerID или serverId. Эти значения назначает провайдер при создании экземпляров HCS.

Примечание: Администраторы tenant не могут получить значения flavorName и availabilityZone, распознаваемые провайдером, из интерфейса HCS. Получите точные значения у администратора HCS перед применением манифеста.

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

KubeadmConfigTemplate определяет конфигурацию bootstrap для рабочих узлов.

apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
kind: KubeadmConfigTemplate
metadata:
  name: <cluster-name>-worker-kct
  namespace: cpaas-system
spec:
  template:
    spec:
      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"
            }
      postKubeadmCommands:
        - chmod 600 /var/lib/kubelet/config.yaml
      joinConfiguration:
        patches:
          directory: /etc/kubernetes/patches
        nodeRegistration:
          kubeletExtraArgs:
            volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"

Контроллер HCS внедряет /etc/kubernetes/pki/kubelet.crt и /etc/kubernetes/pki/kubelet.key при разрешении данных cloud-init для рабочих узлов. Патч kubelet выше настраивает kubelet на использование этих предоставленных контроллером файлов сертификатов.

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

MachineDeployment координирует создание и управление рабочими узлами.

apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: <cluster-name>-md-0
  namespace: cpaas-system
spec:
  clusterName: <cluster-name>
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1
  template:
    spec:
      clusterName: <cluster-name>
      version: <kubernetes-version>
      nodeDrainTimeout: 1m
      nodeDeletionTimeout: 5m
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
          kind: KubeadmConfigTemplate
          name: <cluster-name>-worker-kct
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: HCSMachineTemplate
        name: <cluster-name>-worker-template

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

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

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

Масштабирование рабочих узлов позволяет изменять емкость кластера в зависимости от требований рабочей нагрузки.

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

Увеличьте количество рабочих узлов, чтобы справиться с возросшей нагрузкой.

Процедура:

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. Расширение пула конфигурации

   Добавьте в пул новые конфигурации машин для дополнительных узлов. Если новым рабочим узлам требуется сохраняемое локальное состояние, например /var/cpaas, включите соответствующие записи persistentDisks[] в каждую новую конфигурацию.

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

   Измените пул, добавив новые записи IP, затем примените:

   kubectl apply -f <updated-pool-config.yaml>

   При редактировании пула оставляйте все существующие записи configs[] и принятые записи persistentDisks[] без изменений, если только вы намеренно не добавляете новый слот диска.

3. Увеличение масштаба MachineDeployment

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

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

4. Мониторинг процесса масштабирования

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

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

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

Процедура:

1. Уменьшение масштаба MachineDeployment

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

2. Мониторинг процесса удаления

   kubectl get machines -n cpaas-system -w

   Контроллер Cluster API выполнит следующие действия:

   • выполнит drain выбранных узлов (по возможности выведет pods)
   • удалит базовые ВМ с платформы HCS
   • удалит ресурсы machine

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

Чтобы обновить характеристики рабочей машины (CPU, память, диск, образ ВМ), выполните следующие шаги:

Примечание: Обновления инфраструктуры рабочих узлов основаны на поэтапной замене Cluster API. Тома HCS dataVolumes[] не сохраняются при замене. Чтобы сохранить локальное состояние узла, например /var/cpaas, объявите его в HCSMachineConfigPool.spec.configs[].persistentDisks[] до начала rollout и оставьте MachineDeployment.spec.strategy.rollingUpdate.maxSurge: 0.

1. Создание нового шаблона машины

   Скопируйте существующий HCSMachineTemplate и измените необходимые значения:

   • imageName — образ ВМ
   • flavorName — тип экземпляра
   • rootVolume.size — размер системного диска
   • dataVolumes — конфигурации временных дисков данных

   Если вам нужно добавить новый управляемый пулом постоянный диск, сначала добавьте его в рабочий HCSMachineConfigPool. Провайдер создает или выделяет диск EVS, но работающая ECS не смонтирует его, пока эта поэтапная замена не создаст заменяющий рабочий узел.

   kubectl get hcsmachinetemplate <current-template> -n cpaas-system -o yaml > new-template.yaml

   Затем отредактируйте new-template.yaml перед применением:

   • Измените metadata.name на <new-template>
   • Не задавайте поля идентичности времени выполнения, включая spec.template.spec.providerID и spec.template.spec.serverId
   • Удалите поля, создаваемые сервером, такие как:
     • metadata.resourceVersion
     • metadata.uid
     • metadata.creationTimestamp
     • metadata.managedFields
     • status

2. Развертывание нового шаблона

   kubectl apply -f new-template.yaml -n cpaas-system

3. Обновление Machine Deployment

   Измените MachineDeployment, чтобы он ссылался на новый шаблон:

   kubectl patch machinedeployment <cluster-name>-md-0 -n cpaas-system \
     --type='merge' -p='{"spec":{"template":{"spec":{"infrastructureRef":{"name":"<new-template>"}}}}}'

4. Мониторинг поэтапного обновления

   kubectl get machines -n cpaas-system -w

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

Обновление версии Kubernetes требует согласованных изменений как в MachineDeployment, так и в базовом шаблоне ВМ.

Примечание: Убедитесь, что версия Kubernetes в шаблоне ВМ совпадает с версией, указанной в MachineDeployment. Несоответствие версий приведет к сбоям присоединения узлов.

Процедура:

1. Обновление шаблона машины

   Создайте новый HCSMachineTemplate с обновленным imageName, поддерживающим целевую версию Kubernetes.

2. Обновление MachineDeployment

   Измените следующие поля:

   • spec.template.spec.version — целевая версия Kubernetes

   • spec.template.spec.infrastructureRef.name — имя нового шаблона машины

     kubectl patch machinedeployment <cluster-name>-md-0 -n cpaas-system \
       --type='merge' -p='{"spec":{"template":{"spec":{"version":"<kubernetes-version>","infrastructureRef":{"name":"<new-template>"}}}}}'

3. Мониторинг обновления

   Убедитесь, что новые узлы присоединяются к кластеру с правильной версией Kubernetes:

   kubectl get nodes

#Проверка

После развертывания рабочих узлов проверьте развертывание:

# Check machine status
kubectl get machines -n cpaas-system

# Verify nodes are Ready
kubectl get nodes

# Check MachineDeployment status
kubectl get machinedeployment -n cpaas-system

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

#Просмотр журналов контроллера

# View HCS controller logs
kubectl logs -n cpaas-system deployment/hcs-controller-manager

# View machine details
kubectl describe hcsmachine <machine-name> -n cpaas-system

#Распространенные проблемы

Узел не может присоединиться к кластеру

• Проверьте, что шаблон ВМ соответствует версии Kubernetes
• Проверьте сетевое подключение между узлами
• Убедитесь, что в пуле конфигурации есть доступные записи

Machine зависает в состоянии provisioning

• Проверьте доступность ресурсов на платформе HCS
• Проверьте учетные данные и разрешения
• Просмотрите журналы контроллера на наличие сообщений об ошибках