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

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

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

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

#Обзор

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

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

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

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

#Шаг 1: Настройка Machine Configuration Pool

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

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

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

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: HCSMachineConfigPool
metadata:
  name: <worker-pool-name>
  namespace: cpaas-system
spec:
  configs:
    - hostname: <worker-1-hostname>
      networks:
        - subnetName: <subnet-name>
          ipAddress: <worker-1-ip>
    - hostname: <worker-2-hostname>
      networks:
        - subnetName: <subnet-name>
          ipAddress: <worker-2-ip>
    - hostname: <worker-3-hostname>
      networks:
        - subnetName: <subnet-name>
          ipAddress: <worker-3-ip>

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

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

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

#Шаг 2: Настройка Machine Template

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

Настройте рабочие узлы с системным томом и data volumes для /var/lib/kubelet, /var/lib/containerd и /var/cpaas. Вы можете добавить дополнительные data volumes, но сохраните эти пути, чтобы bootstrap узла и компоненты платформы могли использовать ожидаемые каталоги runtime. Эти пути не означают, что data volumes будут сохраняться при замене узлов.

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

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

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

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

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

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

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

apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
kind: KubeadmConfigTemplate
metadata:
  name: <worker-config-template>
  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 при обработке worker cloud-init data. Приведенный выше kubelet patch настраивает kubelet на использование этих сертификатов, предоставляемых контроллером.

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

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

apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: <worker-machine-deployment>
  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: <worker-config-template>
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: HCSMachineTemplate
        name: <worker-machine-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=<worker-machine-deployment>

2. Расширьте пул конфигурации

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

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

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

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

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

   Обновите поле replicas до нужного количества узлов:

   kubectl patch machinedeployment <worker-machine-deployment> -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 <worker-machine-deployment> -n cpaas-system

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

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

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

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

   kubectl patch machinedeployment <worker-machine-deployment> -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 выбранных узлов (по возможности evict pods)
   • Удаление базовых VM с платформы HCS
   • Удаление ресурсов machine

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

Чтобы обновить спецификации worker machine (CPU, memory, disk, VM image), выполните следующие действия:

Примечание: Обновления worker infrastructure основаны на поэтапной замене ресурсов Cluster API. Текущий провайдер HCS не сохраняет и не подключает повторно data disk при замене узла. Когда рабочий узел заменяется, старая VM и подключенные к ней тома могут быть удалены вместе. Перенесите stateful data во внешнее постоянное хранилище или завершите резервное копирование и миграцию до начала обновления.

1. Создайте новый Machine Template

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

   • imageName - образ VM

   • flavorName - тип экземпляра

   • rootVolume.size - размер системного диска

   • dataVolumes - конфигурации data disk

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

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

   • Измените metadata.name на <new-template>
   • Не задавайте поля идентичности runtime, включая 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 <worker-machine-deployment> -n cpaas-system \
     --type='merge' -p='{"spec":{"template":{"spec":{"infrastructureRef":{"name":"<new-template>"}}}}}'

4. Отслеживайте rolling update

   kubectl get machines -n cpaas-system -w

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

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

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

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

1. Обновите Machine Template

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

2. Обновите MachineDeployment

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

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

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

     kubectl patch machinedeployment <worker-machine-deployment> -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

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

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

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

Machine застрял в состоянии provisioning

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