Infrastructure Resources for Huawei Cloud Stack
TOC
OverviewBefore Writing YAMLCredential Secret InputsCompute ValuesVersion and Component BaselineNetwork InventoryMulti-NIC ConstraintsControl Plane ELB Address PlanOperational constraintsStatic IP Pool PlanValue-to-YAML MappingNext StepsOverview
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.
Namespace Requirement
All HCS infrastructure resources must be deployed in the cpaas-system namespace to ensure proper integration with the platform as business clusters.
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.
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, and disk layout before you write the HCSMachineTemplate.
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:
vipSubnetNamevipAddresselbVirsubnetL4Ipswith exactly two L4 IPselbVirsubnetL7Ipswith 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.controlPlaneEndpointin 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
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. Prepare additional hostname and IP slots only when you plan to increase control plane replicas or set maxSurge greater than 0.
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