#Инфраструктурные ресурсы для Huawei Cloud Stack

#Обзор

Перед тем как писать YAML для кластера Huawei Cloud Stack (HCS), сначала подготовьте все необходимые входные данные HCS. На этой странице перечислены значения, источники и ограничения, которые должны быть готовы до заполнения любого манифеста Secret, HCSMachineConfigPool, HCSMachineTemplate, KubeadmControlPlane или HCSCluster.

Используйте эту страницу как контрольный список подготовки. После завершения перейдите к Создание кластеров в Huawei Cloud Stack и Управление узлами в Huawei Cloud Stack для выполнения workflow манифестов.

#Перед написанием YAML

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

#Входные данные для Secret с учетными данными

Создавайте Secret с учетными данными HCS только после того, как собраны все необходимые значения.

Существующие Secret с учетными данными, созданные без schema, продолжают работать без изменений. Указывайте schema только если ваш endpoint HCS IAM использует http вместо значения по умолчанию https.

Примечание: Администраторы tenant не могут получить region из UI HCS. Получите точное значение, распознаваемое provider, у администратора HCS перед кодированием Secret.

#Значения для Compute

Подготовьте образ VM, flavor, availability zone, layout временного data volume и layout постоянных дисков перед написанием HCSMachineTemplate и HCSMachineConfigPool.

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

#Базовая версия и версия компонентов

Используйте OS Support Matrix только для тех версий компонентов, которые в ней явно перечислены, таких как Kubernetes, coredns, etcd и pause для поддерживаемых образов Alauda OS.

OS Support Matrix не является полным источником всех значений манифеста HCS. Перед написанием YAML также получите одобренную базовую версию релиза для таких значений, как container image repository, DNS image repository, версия Kube-OVN, Kube-OVN join CIDR, Pod CIDR и Service CIDR. Если ваш релиз еще не публикует полный источник базовой версии, используйте значения, проверенные для вашей среды platform owner или release owner.

#Инвентарь сети

Подготовьте полный сетевой инвентарь кластера перед созданием ресурсов HCSCluster или HCSMachineConfigPool.

Ваш план сети должен включать:

• Целевое имя VPC
• Целевое имя security group
• Имя каждого subnet, который будет использовать кластер
• ID subnet и метаданные subnet, связанные с ELB, для каждого subnet
• CIDR каждого subnet
• Значения gateway и DNS для каждого subnet
• Планируемые диапазоны свободных IP для узлов control plane, worker, VIP ELB и IP виртуальных subnet ELB L4/L7

Если один кластер использует несколько subnet, эти subnet должны принадлежать одной и той же VPC и должны позволять узлам кластера взаимодействовать друг с другом.

Важно: HCSCluster.spec.network.subnets — это инвентарь subnet кластера. Каждый subnetName, на который ссылаются HCSMachineConfigPool, vipSubnetName, elbVirsubnetL4Ips[].subnetName и elbVirsubnetL7Ips[].subnetName, уже должен существовать в этом списке.

Для первоначального потока создания кластера controller может разрешить существующие subnet по имени до того, как кластер станет Ready. Для существующего Ready-кластера не добавляйте только имя subnet. Добавьте полный объект subnet, включая как минимум name, id и, если subnet используется ELB control plane, neutronSubnetId. Также сохраняйте cidr, gatewayIp, primaryDNS и secondaryDNS в инвентаре, чтобы список subnet кластера оставался полным.

#Ограничения Multi-NIC

Несколько NIC объявляются в HCSMachineConfigPool.spec.configs[].networks[]. Каждый элемент networks[] выбирает только subnet и статический IP для одного NIC.

Текущий provider не позволяет задавать:

• Роль или назначение каждого NIC, например management-, service- или storage-трафик
• Default gateway для конкретного NIC
• Static routes или route metrics
• Настройки DNS для каждого NIC

Рассматривайте текущую возможность multi-NIC как подключение NIC плюс выбор subnet и статического IP.

#План адресов ELB для control plane

Provider HCS автоматически создает Elastic Load Balance (ELB) для control plane. Спланируйте входные данные ELB до написания HCSCluster.

В этой документации используется workflow ELB со статическим адресом. Подготовьте все адреса, связанные с ELB, до написания HCSCluster:

• vipSubnetName
• vipAddress
• elbVirsubnetL4Ips с ровно двумя IP L4
• elbVirsubnetL7Ips с ровно двумя IP L7
• Необязательный vipDomainName

Если вы задаете vipDomainName, настройте HCS Cloud DNS Private Zones так, чтобы домен уже разрешался в vipAddress.

#Операционные ограничения

• Provider создает ELB и включает Hybrid Load Balancing, чтобы узлы кластера могли обращаться к API server через адрес ELB.
• Не отключайте Hybrid Load Balancing на ELB HCS после создания кластера.
• Не указывайте spec.controlPlaneEndpoint в манифесте создания. Controller заполнит это поле после готовности ELB.

#План размещения HA control plane

Для control plane с несколькими replica вы можете настроить provider HCS так, чтобы он создавал и поддерживал server group, принадлежащую provider, для размещения ECS control plane. Включите это через HCSCluster.spec.controlPlaneHA при написании манифеста кластера.

Спланируйте политику размещения до включения функции:

Эта функция действует на уровне кластера и применяется только к машинам control plane. Она не настраивает пулы worker-узлов. Provider создает server group, привязывает к этой группе запросы на создание ECS control plane, записывает server group в HCSCluster.status.controlPlaneHA и сообщает о прогрессе через condition ControlPlaneHAReady.

Для существующего кластера включение HCSCluster.spec.controlPlaneHA создает и записывает server group, принадлежащую provider, но не добавляет обратно уже запущенные экземпляры ECS control plane в эту группу. Размещение в server group применяется, когда ECS control plane создается с os:scheduler_hints.group. Чтобы привести существующий кластер к целевому состоянию, включите controlPlaneHA, дождитесь HCSCluster.status.controlPlaneHA.id, а затем запустите rolling replacement control plane, чтобы заменяющие экземпляры ECS создавались с server group. Пока текущие участники ECS control plane не будут заменены и обнаружены в группе, ControlPlaneHAReady может оставаться False с причиной ControlPlaneHAPending.

Пример манифеста и команды проверки см. в Настройка HCSCluster и Проверка HA control plane.

#План пула статических IP

На этой странице основное внимание уделяется workflow с запланированными статическими IP.

Подготовьте следующее перед созданием ресурсов HCSMachineConfigPool:

• Hostname control plane и статические IP
• Hostname worker и статические IP, если worker создаются
• Достаточное количество записей для покрытия начального количества replica
• Любые постоянные диски, управляемые пулом, которые должны быть привязаны к каждому фиксированному hostname

Для control plane со статическими IP и как минимум тремя replica рекомендуемый путь обновления использует KubeadmControlPlane.spec.rolloutStrategy.rollingUpdate.maxSurge: 0. Этот подход с масштабированием вниз, а затем вверх обычно не требует дополнительных IP control plane. Если вы планируете топологию только для создания с одним control plane (replicas: 1), не копируйте эту настройку rollout в манифест создания. Для пулов, использующих постоянные диски, сохраняйте maxSurge: 0, поскольку каждый диск привязан к одному фиксированному hostname и слоту.

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

Объявляйте диски HCS, которые должны пережить удаление и повторное создание VM, в HCSMachineConfigPool.spec.configs[].persistentDisks[].

Используйте эту модель для /var/cpaas, данных мониторинга, логов или другого node-local состояния, которое необходимо сохранять во время rolling replacement. Оставляйте HCSMachineTemplate.spec.template.spec.dataVolumes[] для временных дисков, которые могут быть пересозданы с каждым новым ECS.

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

Описание полей постоянного диска:

Правила обновления:

• Не указывайте один и тот же mountPath одновременно в HCSMachineConfigPool.spec.configs[].persistentDisks[] и HCSMachineTemplate.spec.template.spec.dataVolumes[].
• Вы можете добавлять новые записи persistentDisks[] в существующую конфигурацию машины. Provider создает или claim-ит диск EVS, но не выполняет hot-mount диска в работающий ECS. Запустите rolling replacement с maxSurge: 0, прежде чем ожидать, что новый диск будет отформатирован и смонтирован внутри guest OS.
• Не удаляйте и не изменяйте slot, size, type, format или mountPath после того, как provider принял запись постоянного диска. Эти поля определяют идентичность диска и contract claim.
• Вы можете обновить mountOptions. Изменение вступает в силу, когда узел заменяется, и replacement VM применяет свои подключения дисков.
• Для пулов, использующих постоянные диски, сохраняйте KubeadmControlPlane.spec.rolloutStrategy.rollingUpdate.maxSurge: 0 и MachineDeployment.spec.strategy.rollingUpdate.maxSurge: 0.

#Сопоставление значений с YAML

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

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

После завершения контрольного списка подготовки:

• Следуйте инструкции Создание кластеров в Huawei Cloud Stack, чтобы написать манифесты control plane и infrastructure
• Следуйте инструкции Управление узлами в Huawei Cloud Stack, чтобы добавить или изменить worker-узлы