Create a Kubernetes Cluster

This page breaks the Kubernetes creation flow into the actual web-console steps. It is intended for first-time users and for teams that want a standard operating procedure.

Prepare before opening the create page

Before you click Create, confirm the following:

• Which region the workload should run in.
• Which host machine or host group should be used.
• What type of workloads the cluster will run.
• Rough CPU, memory, and storage needs for worker nodes.
• Whether the cluster needs external access.
• Whether auto scaling is required.

Recommended operating sequence on the create page

1. Select region and host machine

1. Open the Kubernetes list page.
2. Click Create.
3. Select the region group.
4. Select the host machine.

Choose based on workload placement and network planning rather than only by name.

2. Set basic cluster information

The create page usually asks you to confirm:

• Cluster name.
• Kubernetes version.

The current console generally exposes validated versions only, such as 1.30.

3. Configure worker nodes

You usually set:

• Worker-node count.
• Worker CPU.
• Worker memory.
• Worker storage.

For a first deployment, start with the smallest size that can carry the initial workload and scale later after monitoring real usage.

4. Review control plane and auto scaling

In the web UI, control-plane capacity is usually derived automatically from the worker-node count.

If you enable auto scaling, also configure:

• The auto-scaling toggle.
• The maximum node count.

Set the maximum with both budget and host capacity in mind, not only the initial cluster size.

5. Select the cluster network

The cluster network is required and carries internal cluster communication.

Recommendations:

• Prefer a private network for internal workloads.
• Avoid reusing the same cluster network across unrelated environments.
• Verify that the selected network belongs to the correct region before submission.

6. Decide whether to enable a gateway

You only need a gateway when services must be reachable from outside the cluster.

If you enable it, the page usually asks for:

• Gateway bandwidth.
• The related gateway network.

If the current workload is for internal testing only, leave the gateway disabled unless there is a real external-access requirement.

7. Review price calculation

The page usually recalculates price based on your current configuration.

Before you submit, verify again:

• The worker-node count.
• The auto-scaling limit.
• Whether the gateway was enabled intentionally.
• Whether the bandwidth size matches the expected traffic.

8. Submit the order

Submit the order after the configuration is confirmed. The platform will start cluster provisioning.

Suggested sizing approaches

Development and test environments

• Use a small worker count.
• Leave the gateway disabled at first if external access is not required.
• Prefer private networking.

Public-facing application environments

• Reserve enough gateway bandwidth.
• Define the security-group strategy clearly.
• Do not size workers only for the absolute minimum current load.

Workloads with strong traffic peaks

• Consider auto scaling first.
• Also cap the maximum node count to avoid unexpected cost growth.

How to confirm the cluster was created successfully

After submission, go back to the list page and check:

• Whether the status moves from Creating to Running.
• Whether health information looks normal.
• Whether the node counts match the intended configuration.

If the status stays in provisioning for too long, continue with order status, notifications, or the support path.