RESVRL
Open navigation

Kubernetes Clusters

RESVRL provides a managed Kubernetes workflow for users who want a ready-to-use cluster without building every node manually. This guide follows the actual web-console flow: where the entry is, what you can do on the list page, what to fill in on the create page, and where to verify status after submission.

Kubernetes Clusters

RESVRL provides a managed Kubernetes workflow for users who want a ready-to-use cluster without building every node manually. This guide follows the actual web-console flow: where the entry is, what you can do on the list page, what to fill in on the create page, and where to verify status after submission.

Where to start

  1. Sign in to the member console.
  2. Open Kubernetes from the left navigation.
  3. The first screen is the cluster list page.

The list page normally shows:

  • Cluster name, which links to the cluster details page.
  • Cluster status such as Creating, Running, Failed, or Deleting.
  • Kubernetes version.
  • Control-plane and worker-node counts.
  • Health information for the cluster.

The top toolbar on the list page lets you:

  • Create a cluster.
  • Refresh the list.
  • Delete one or more selected clusters.

What the product creates for you

When you create a cluster in RESVRL, the platform provisions:

  • A Kubernetes control plane sized automatically from the worker count.
  • A configurable number of worker nodes.
  • An optional gateway node for external traffic.
  • A dedicated cluster network.
  • A cluster management workspace with overview, node, workload, network, storage, and access-control pages.

Before you start

Prepare the following first:

  • A target region and host machine group with available capacity.
  • A virtual network for the cluster's internal communication.
  • If you need north-south traffic, a gateway network and an associated security group.
  • A rough estimate for worker CPU, memory, storage, and expected peak node count.

Create a cluster

  1. On the Kubernetes list page, click Create.
  2. In the create page, select the region group and host machine first.
  3. Enter the cluster name.
  4. Confirm the Kubernetes version. The current UI usually exposes 1.30.
  5. Set the worker-node count.
  6. Configure worker CPU, memory, and system storage.
  7. Decide whether to enable auto scaling. If enabled, set the maximum node count.
  8. Select the internal cluster network.
  9. Decide whether to include a gateway.
  10. If gateway is enabled, continue with gateway bandwidth and related network settings.
  11. Review the calculated price and configuration summary.
  12. Submit the order and wait for provisioning.

The create page typically calculates control-plane capacity automatically from the worker-node count, so you do not size every control-plane node manually.

Key creation options

Worker nodes

  • Worker count defaults to a small starter cluster and can be increased during creation.
  • Worker CPU, memory, and storage determine the capacity available to workloads.
  • Control plane sizing is derived automatically from the worker-node count.
  • The page recalculates price when you change size or count, so review the total again before submission.

Auto scaling

  • Auto scaling can be enabled during creation.
  • When enabled, you set the maximum number of nodes the cluster can grow to.
  • Plan capacity and budget for the maximum, not only the initial worker count.

Cluster network

  • The cluster network is required.
  • Use a private network when workloads only need internal service-to-service traffic.
  • Keep the cluster network separate from unrelated environments when possible.

Gateway

  • The gateway is optional.
  • Use it when workloads need external exposure.
  • Gateway configuration requires a network and a security group.
  • Gateway bandwidth affects the external traffic path, so size it for expected ingress and egress.

Check status after submission

After the order is submitted, return to the Kubernetes list page and watch the status:

  • Creating means nodes and platform components are still being prepared.
  • Running means the cluster is ready.
  • Failed means provisioning did not complete successfully.
  • Deleting means the cluster is already in the removal workflow.

If the latest state does not appear immediately, use Refresh on the toolbar.

What you can do after provisioning

After the cluster becomes available, the Kubernetes console exposes several operating areas.

Overview

  • View cluster version, region, node totals, ready state, pod counts, and aggregate CPU, memory, and disk usage.
  • Use this page first to confirm whether the cluster is fully ready for workloads.

Nodes

  • Filter by role and status.
  • Check node IP, version, pressure indicators, and age.
  • Cordon and uncordon nodes during maintenance.
  • When workloads behave unexpectedly, confirm node readiness here first.

Workloads

  • Browse pods, deployments, stateful sets, daemon sets, jobs, and cron jobs.
  • Use these pages to inspect workload state before changing application manifests.
  • If an application replica does not start, begin troubleshooting from the workload pages.

Network

  • Review services, gateway resources, and network policies.
  • Use security groups together with cluster networking when exposing services outside the cluster.
  • For public services, validate gateway settings, service exposure, and security-group rules together.

Storage

  • Review persistent volume claims and storage classes.
  • Confirm storage resources before scheduling stateful applications.

Configuration and access control

  • Inspect namespaces, config maps, and secrets.
  • Review service accounts, roles, and bindings for cluster access design.

Settings

  • Use the settings area for cluster-level configuration and future maintenance actions exposed by the console.

Delete a cluster

  1. Return to the Kubernetes list page.
  2. Select one or more clusters.
  3. Click Delete.
  4. Confirm the action in the confirmation dialog.

After that, the cluster usually stays visible for a while in Deleting status until the workflow completes.

Operational guidance

  • Start with the minimum worker size that can run your workloads, then expand after monitoring real usage.
  • Use a separate security group for gateway traffic instead of reusing a permissive VM group.
  • Keep private workloads on the cluster network and expose only the entry points that users actually need.
  • Review node readiness and resource pressure before scaling workloads.

Common questions

When should I enable the gateway?

Enable the gateway when services in the cluster must accept traffic from outside the cluster network, such as public websites, APIs, or shared ingress endpoints.

Do I need a security group for every cluster?

Not for the internal cluster network. A security group is required when you enable a public-facing gateway path.

Can I manage workloads from the RESVRL console?

The product exposes workload, node, storage, network, and access-control views for cluster operations. Use those pages for inspection and routine operations, and use your standard Kubernetes tooling for application delivery workflows where needed.

Why does the create page show only one Kubernetes version?

The UI generally exposes only versions already validated by the platform, such as 1.30. Confirm product availability first if you need another version.