#Infrastructure Resources for Huawei Cloud Stack

#Overview

Before you write YAML for a Huawei Cloud Stack (HCS) cluster, prepare all required HCS inputs first. This page lists the values, sources, and constraints that must be ready before you fill any Secret, HCSMachineConfigPool, HCSMachineTemplate, KubeadmControlPlane, or HCSCluster manifest.

Use this page as the preparation checklist. After you complete it, continue with Creating Clusters on Huawei Cloud Stack and Managing Nodes on Huawei Cloud Stack for the manifest workflow.

#Before Writing YAML

Prepare the following inputs before you create or edit any cluster manifests:

#Credential Secret Inputs

Create the HCS credential Secret only after you collect all required values.

Existing credential Secrets created without schema continue to work unchanged. Only set schema if your HCS IAM endpoint uses http instead of the default https.

Note: Tenant administrators cannot retrieve region from the HCS UI. Get the exact provider-recognized value from the HCS administrator before you encode the Secret.

#Compute Values

Prepare the VM image, flavor, availability zone, temporary data volume layout, and persistent disk layout before you write the HCSMachineTemplate and HCSMachineConfigPool.

Note: Tenant administrators cannot retrieve the provider-recognized flavorName and availabilityZone values from the HCS UI. Get the exact API values from the HCS administrator before you write the manifest.

#Version and Component Baseline

Use the OS Support Matrix only for the component versions it explicitly lists, such as Kubernetes, coredns, etcd, and pause versions for supported MicroOS images.

The OS Support Matrix is not a complete source for all HCS manifest values. Before writing YAML, also get the approved release baseline for values such as the container image repository, DNS image repository, Kube-OVN version, Kube-OVN join CIDR, Pod CIDR, and Service CIDR. If your release does not publish a complete baseline source yet, use values validated for your environment by the platform or release owner.

#Network Inventory

Prepare the complete cluster network inventory before you write HCSCluster or HCSMachineConfigPool resources.

Your network plan must include:

• The target VPC name
• The target security group name
• Every subnet name the cluster will use
• The subnet ID and ELB-related subnet metadata for each subnet
• The CIDR of each subnet
• The gateway and DNS values of each subnet
• The planned free IP ranges for control plane nodes, worker nodes, the ELB VIP, and ELB L4/L7 virtual subnet IPs

If a single cluster uses multiple subnets, those subnets must belong to the same VPC and must allow cluster nodes to reach each other.

Important: HCSCluster.spec.network.subnets is the cluster subnet inventory. Every subnetName referenced by HCSMachineConfigPool, vipSubnetName, elbVirsubnetL4Ips[].subnetName, and elbVirsubnetL7Ips[].subnetName must already exist in that list.

For the initial cluster create flow, the controller can resolve existing subnets by name before the cluster becomes Ready. For an existing Ready cluster, do not append only a subnet name. Add the full subnet object, including at least name, id, and, when the subnet is used by the control plane ELB, neutronSubnetId. Keep cidr, gatewayIp, primaryDNS, and secondaryDNS in the inventory as well so the cluster subnet list remains complete.

#Multi-NIC Constraints

Multiple NICs are declared in HCSMachineConfigPool.spec.configs[].networks[]. Each networks[] entry only selects a subnet and a static IP for one NIC.

The current provider does not let you declare:

• The role or purpose of each NIC, such as management, service, or storage traffic
• The default gateway for a specific NIC
• Static routes or route metrics
• Per-NIC DNS settings

Treat the current multi-NIC capability as NIC attachment plus subnet and static IP selection.

#Control Plane ELB Address Plan

The HCS provider creates the control plane Elastic Load Balance (ELB) automatically. Plan the ELB inputs before you write HCSCluster.

This documentation uses the fixed-address ELB workflow. Prepare all ELB-related addresses before you write HCSCluster:

• vipSubnetName
• vipAddress
• elbVirsubnetL4Ips with exactly two L4 IPs
• elbVirsubnetL7Ips with exactly two L7 IPs
• Optional vipDomainName

If you set vipDomainName, configure HCS Cloud DNS Private Zones so the domain already resolves to vipAddress.

#Operational constraints

• The provider creates the ELB and enables Hybrid Load Balancing so cluster nodes can reach the API server through the ELB address.
• Do not disable Hybrid Load Balancing on the HCS ELB after the cluster is created.
• Do not write spec.controlPlaneEndpoint in the create manifest. The controller fills that field after the ELB is ready.

#Static IP Pool Plan

This page focuses on the planned static IP workflow.

Prepare the following before you create HCSMachineConfigPool resources:

• Control plane hostnames and static IPs
• Worker hostnames and static IPs, if workers are created
• Enough entries to cover the initial replica count
• Any pool-managed persistent disks that must be bound to each fixed hostname

For static IP control planes with at least three replicas, the recommended upgrade path uses KubeadmControlPlane.spec.rolloutStrategy.rollingUpdate.maxSurge: 0. This scale-down-then-scale-up approach usually does not require extra control plane IPs. If you plan a single-control-plane create-only topology (replicas: 1), do not copy that rollout setting into the create manifest. For pools that use persistent disks, keep maxSurge: 0 because each disk is bound to one fixed hostname and slot.

#Pool-Managed Persistent Disks

Declare HCS disks that must survive VM delete-recreate replacement in HCSMachineConfigPool.spec.configs[].persistentDisks[].

Use this model for /var/cpaas, monitoring data, log data, or other node-local state that must be retained during rolling replacement. Keep HCSMachineTemplate.spec.template.spec.dataVolumes[] for temporary disks that may be recreated with each new 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

Persistent disk field descriptions:

Update rules:

• Do not declare the same mountPath in both HCSMachineConfigPool.spec.configs[].persistentDisks[] and HCSMachineTemplate.spec.template.spec.dataVolumes[].
• You can append new persistentDisks[] entries to an existing machine configuration. The provider creates or claims the EVS disk, but it does not hot-mount the disk into the running ECS. Trigger a rolling replacement with maxSurge: 0 before you expect the new disk to be formatted and mounted inside the guest OS.
• Do not remove or change slot, size, type, format, or mountPath after the provider has accepted a persistent disk entry. These fields define the disk identity and claim contract.
• You can update mountOptions. The change takes effect when the node is replaced and the replacement VM renders its disk mounts.
• Keep KubeadmControlPlane.spec.rolloutStrategy.rollingUpdate.maxSurge: 0 and MachineDeployment.spec.strategy.rollingUpdate.maxSurge: 0 for pools that use persistent disks.

#Value-to-YAML Mapping

Use the following mapping after you complete the preparation checklist:

#Next Steps

After you complete the preparation checklist:

• Follow Creating Clusters on Huawei Cloud Stack to write the control plane and infrastructure manifests
• Follow Managing Nodes on Huawei Cloud Stack to add or modify worker nodes