Kubernetes Clusters via UI

Deploy and manage Kubernetes clusters through the console, including scaling, monitoring, and connecting via Kubeconfig.

Hyperstack makes it easy to deploy, scale, and manage Kubernetes clusters through a streamlined web-based interface. With support for GPU-accelerated workloads, high-speed networking, and dynamic scaling, the Hyperstack UI enables fast provisioning of production-ready clusters for AI and cloud-native applications.

This guide provides comprehensive instructions for deploying Kubernetes clusters using the Hyperstack Console, as well as managing them throughout their lifecycle. Topics include connecting via Kubeconfig, scaling clusters, monitoring cluster health, understanding billing behavior, and more.

Clusters can also be provisioned and managed via the Hyperstack API. For details, see the Kubernetes API Guide.

How to Deploy a Kubernetes Cluster in Hyperstack

Follow the steps below to deploy a Kubernetes cluster using the Kubernetes page in Hyperstack and click Deploy a New Cluster to begin the deployment process.

1. Start Cluster Deployment

   Navigate to the Kubernetes page in Hyperstack and click Deploy a New Cluster to begin the deployment process.

2. Choose Default Worker Flavor

   The flavor defines the hardware configuration of the default worker nodes deployed in the cluster, including the GPU, CPU, RAM, and disk. Select a flavor that meets the performance requirements of your workload. For more details, refer to the Flavors documentation.

   Spot worker node flavors

   If you select a spot worker node flavor (e.g., A100-80G-PCIe-spot), the underlying instances can be rebooted at any time without notice or automatically terminated due to capacity reallocation.

   If all worker nodes are terminated, the cluster will be deleted, as Kubernetes requires at least one active worker node to function.

   To learn more about spot VMs, click here.

3. Select an Environment

   Choose an environment in which to deploy your cluster. If you have not created one yet, follow the steps here.

   Regional Availability

   To deploy a cluster, you must select or create an environment in the CANADA-1 or NORWAY-1 regions, which offer the CPU-only flavors required for cluster deployment.

   The US-1 region is not currently supported for cluster deployment.

4. Specify Number of Nodes

   Select the number of master nodes to deploy in the cluster. A minimum of 2 and a maximum of 3 master nodes are supported.

   Select the number of default worker nodes to deploy in the cluster. A minimum of 1 and a maximum of 20 worker nodes are supported.

5. Select Deployment Mode

   Choose the deployment mode for your cluster which determines which nodes are included:

   a. Full Deployment - Provisions master, worker, load balancer, and bastion nodes. Master nodes are provisioned on separate physical hosts where possible to ensure the control plane remains available even if a single hardware host fails. IPs are assigned to the load balancer and bastion nodes. Learn more.

   b. Standard Deployment - Creates a minimal cluster with master and worker nodes only. One master node is assigned a public IP and takes on all control, access, and routing responsibilities. Learn more.

6. Select Master Node Flavor

   The master nodes must be deployed using a CPU-only flavor, as it hosts the Kubernetes control plane and is not billed based on compute resources.

   Supported flavors: n1-cpu-small, n1-cpu-medium, or n1-cpu-large

   Click here to see hardware specifications of the supported flavors

   Flavor Name	CPU Cores	RAM (GB)	Root Disk (GB)	Ephemeral Disk (GB)	Region
   n1-cpu-small	4	4	100	0	NORWAY-1, CANADA-1
   n1-cpu-medium	8	8	100	0	NORWAY-1, CANADA-1
   n1-cpu-large	16	16	200	0	NORWAY-1, CANADA-1

7. Select Kubernetes Version

   Choose the Kubernetes version for your cluster.

   Current supported Kubernetes versions: 1.33.4, 1.35.1, and 1.36.1 (default).
   By default, Hyperstack pre-selects the latest supported Kubernetes version for you. When a newer version becomes available, it automatically becomes the pre-selected default for new clusters.

   For the latest details on all supported versions, regional availability, and information about the images that come pre-configured with each version, call the List Cluster Versions API.

   For official Kubernetes version release notes and binaries, click here.

   Other Kubernetes Versions

   To request support for other versions, contact [email protected]. Custom versions are not currently supported but may be considered for future updates.

8. Select SSH Key

   Choose an SSH key to enable secure access to your cluster. If needed, you can create one by following the steps here.

9. Deploy the Cluster

   Review all configuration options and click Deploy to launch your Kubernetes cluster.

   If you are unable to deploy your VM and receive a message saying that you have insufficient credit, navigate to the billing page in Hyperstack and add credit to your account.

Cluster Deployment Time

Cluster creation usually takes around 15 minutes. Larger clusters, and deploying several clusters at once, take longer.

To connect to your new Kubernetes cluster, follow the steps outlined here.

Manage a Kubernetes Cluster in Hyperstack

To view and manage your Kubernetes clusters in Hyperstack, navigate to the Kubernetes page. Here, you'll find a list of all your existing clusters.

Cluster Kubeconfig

Access the Kubeconfig for your cluster by hovering over the "⋮" under the ACTIONS column of the Kubernetes page, and clicking Kubeconfig.

Delete Cluster

Hover over the "⋮" under the ACTIONS column of the Kubernetes page and click Delete.

Clusters can be deleted at any time, except when their virtual machines are in the CREATING state. To learn more about cluster statuses, click here.

Reducing costs without deleting the entire cluster

In addition to deleting the entire cluster, you can scale down by deleting individual worker nodes. This allows you to reduce resource usage and hourly billing costs while keeping the cluster operational.
To learn how to remove nodes, see Delete Cluster Node.
For billing details, see Scaling and Billing Impact.

Cluster Overview

On the Kubernetes page in Hyperstack, click the name of a Kubernetes cluster to view its details, including hourly cost, hardware configuration, number of worker nodes, cluster address, and more.

hourly running costs

The per-hour run cost for a cluster is displayed only after the cluster reaches the ACTIVE state. To learn more about cluster and node states, see Cluster and Node Statuses.
To understand how hourly running costs are calculated, see Cluster Billing Logic.

Cluster Events Log

To view actions performed on the cluster, go to the Events Log tab. Each entry includes a timestamp, event type, and description for detailed tracking of cluster activity.

Cluster Reconciliation

Cluster reconciliation is the process of reapplying the desired configuration state to a Kubernetes cluster. In Hyperstack, this occurs automatically during key lifecycle events such as cluster creation, scaling operations, or when the reconciliation is triggered manually. It ensures that system configurations and core components are correctly applied and helps resolve state drift or partial failures.

Manually Trigger Reconciliation

Manual reconciliation is the process of explicitly requesting the system to reapply the intended state to a cluster. This is useful when your cluster is in an ERROR state or experiencing issues such as stalled provisioning or unresponsive components.

Cluster status and reconciliation

Manual reconciliation is only available when the cluster is not already in the RECONCILING state.
If reconciliation fails during a scaling operation, the cluster returns to the ACTIVE state so you can trigger reconciliation again.
To understand what each cluster status means, refer to the cluster statuses guide.

To manually trigger a reconciliation for a Kubernetes cluster:

1. Navigate to the Kubernetes page in the UI.
2. Under the ACTIONS column, hover over the ⋮ menu.
3. Click Reconcile, and confirm the action.

Unsuccessful reconciliation

If the issue is not resolved after reconciliation, we recommend deleting the cluster and creating a new one rather than retrying. Repeated reconciliation attempts are unlikely to fix underlying infrastructure or configuration problems.

Managing Cluster Firewall Rules

Follow these steps to manage firewall rules for Kubernetes clusters. Firewall rules allow you to define and control which inbound and outbound traffic is permitted:

1. Navigate to the Kubernetes page in the Hyperstack console.
2. Click the name of the cluster you want to configure.
3. From the cluster details view, select Nodes.
4. Choose the node you want to manage firewall rules for.
5. Open the Firewall tab.
6. Under the Direct Firewall Rules section, add or delete firewall rules to customize permitted inbound and outbound traffic.

Cluster Node Types

Kubernetes clusters in Hyperstack consist of four node types: bastion, master, load balancer, and worker nodes. Each plays a specific role in managing access, orchestration, traffic routing, and workload execution. Learn more about each node type below:

Bastion Node

The bastion node acts as a secure gateway for administrative access to the cluster. It provides a controlled entry point for SSH access, reducing direct exposure of critical components to external threats.

Master Node

The master nodes run the control plane, which manages the cluster’s state and orchestrates workloads. It is responsible for scheduling, maintaining application lifecycle states, and ensuring overall cluster stability. Master nodes are provisioned on separate physical hosts where available to ensure the control plane remains available even if a single hardware host fails.

Worker Nodes

Worker nodes handle the actual execution of workloads by running containerized applications. Each worker node is equipped with Kubernetes components such as Kubelet and a container runtime, allowing it to process scheduled tasks efficiently.

Load Balancer Nodes

Load balancer nodes distribute incoming traffic across worker nodes to ensure efficient resource utilization and high availability. They play a crucial role in managing network traffic and optimizing cluster performance.

Cluster Deployment Modes

When creating a Kubernetes cluster in Hyperstack, you can choose between two deployment modes: Full and Standard. Each mode offers different infrastructure tradeoffs depending on your workload needs.

Full Deployment (Default)

Full deployment clusters include all recommended node types for a complete cluster setup. They include all core infrastructure components and provide dedicated nodes for secure access and traffic management.

This mode provisions all recommended infrastructure components:

• Master nodes — Run the Kubernetes control plane.
• Worker nodes — Run your application workloads.
• Load balancer nodes — Route external traffic to the Kubernetes API and services. A public IP is assigned to the load balancer node.
• Bastion nodes — Provide secure SSH access to internal nodes. A public IP is assigned to the bastion node.

Public IP Costs

Billing applies for two public IP addresses: one for the load balancer and one for the bastion node. Learn more.

Standard Deployment (Minimal)

Standard deployment clusters are a minimal, streamlined configuration with only the essential node types for advanced users who manage their own networking and access. They omit dedicated access and traffic routing nodes to keep the footprint smaller.

This streamlined deployment mode provisions only:

• Master nodes — Run the Kubernetes control plane. One master node is assigned the only public IP in the cluster and handles SSH access. Because there is no load balancer, no public DNS record is created.
• Worker nodes — Run your application workloads, identical to how they operate in full deployment mode.
• No load balancer or bastion nodes - Unlike full deployment clusters, standard deployment clusters do not include dedicated load balancer or bastion nodes, reducing infrastructure complexity.

Cluster Nodes & Scaling

On the Cluster Overview page, click the Nodes tab to view details for each node in your cluster, including its role, status, and IP address. You can scale the cluster by adjusting the number of worker or master nodes, depending on your application needs.

Scaling Requirements

All existing nodes must be in the ACTIVE state before adding or deleting nodes. Scaling operations must be performed one at a time — concurrent node changes are not supported.

You can also view nodes individually on the Virtual Machines page.

To understand how scaling affects hourly billing, see Scaling and Billing Impact.

Add Cluster Node

To add worker or master nodes:

1. Navigate to the Cluster Overview page.
2. Open the Nodes tab.
3. Click the + Add Nodes button.
4. Select the node role (worker or master), specify the node group (if adding workers), and define the number of nodes to add.
   • Each node group within a cluster must contain at least one and no more than 20 worker nodes. For example, if a node group currently has 2 worker nodes, you can add up to 18 more.
   • Each cluster must maintain a minimum of 2 and a maximum of 3 master nodes to ensure control plane availability.
5. Click Confirm to add node(s).

Delete Cluster Node

To remove a node from the cluster:

1. Go to the Cluster Overview page.
2. Open the Nodes tab.
3. Click the trash icon next to the worker or master node.
4. Confirm the action.

Minimum Node Requirements

A cluster must always maintain at least one worker node and two master nodes. You cannot delete a node if doing so would reduce the total below these minimum requirements.

Before Deleting a Node

To avoid orphaned Kubernetes resources, drain and delete the node from Kubernetes before removal:

terminal

kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data
kubectl delete node <node-name>

Once removed from Kubernetes, proceed with deletion in the Hyperstack UI.

Note: Any data stored on a deleted node will be permanently lost.

Cluster Node Groups

A cluster node group is a set of worker nodes within a Kubernetes cluster that all share the same flavor. In Hyperstack, a default node group is automatically created when you deploy a cluster through the UI, or via the API if you do not explicitly define any node_groups. This default group includes the initial set of worker nodes, each provisioned with the flavor you selected during deployment.

Currently, the Hyperstack UI supports only the creation of this default node group and the use of a single flavor across all worker nodes. To define more advanced configurations—such as using multiple node groups with different flavors—you'll need to use the Create Cluster API and include the optional node_groups parameter.

After initial deployment, you can add additional node groups via API, each with a specific flavor and desired number of worker nodes. This enables you to operate a single cluster with varied hardware profiles, optimized to handle workloads with diverse compute or memory requirements.

Worker Node Limits

Each node group must contain at least 1 and no more than 20 worker nodes.
Every cluster must always have at least one node group with at least one worker node.

For example:

• If a node group has 2 worker nodes, you can add up to 18 more.
• If it has 3 nodes, you can delete up to 2.

See Cluster Nodes & Scaling for instructions on adding or removing worker nodes within node groups.

Creating and Deleting Node Groups

Currently, creating and deleting node groups can only be performed through the API.

• To create a new node group, use the Create Node Group API.
• To delete an existing node group, use the Delete Node Group API.

Node Group Limits

Every cluster must always have at least one node group with at least one worker node.

UI-based workflows for node group management will be supported in future updates.

Cluster Capabilities & Restrictions

A cluster node's underlying virtual machine (VM) is managed by the cluster itself, rather than through the standard VM controls. Changing it outside the cluster leaves the control plane (master nodes) unaware and can break workloads or cause data loss. As a result, several VM-level actions that work on standalone VMs are restricted on cluster nodes, and some cluster operations work differently.

Hibernation

Neither individual nodes nor entire clusters can be hibernated. They remain active until explicitly deleted. Kubernetes expects its nodes to be running and continuously reporting healthy to the control plane. Hibernating a node's VM stops that communication, which causes the control plane to mark the node unavailable and reschedule or fail the workloads running on it. To reduce running costs when you need less capacity, scale the cluster down by removing worker nodes, or delete the cluster entirely to stop billing. See Cluster Billing & Data Retention.

Stopping a node

Cluster nodes cannot be stopped. A node that is powered off stops reporting to the control plane, which marks it unavailable and reschedules or fails the workloads running on it. Stopping a node also does not reduce its cost. A VM in the SHUTOFF state keeps its CPUs, memory, GPUs, storage, and public IP addresses allocated, so billing continues. To reduce running costs, scale the cluster down by removing worker nodes.

Snapshots

Cluster nodes cannot be snapshotted. Cluster nodes are designed to be ephemeral and reproducible, so the cluster can recreate any node from its configuration at any time. A point-in-time disk image of a single node is therefore not a meaningful unit of backup, and it would diverge from the cluster's actual state as soon as it is taken. To preserve data that must survive a node being replaced, store it on persistent volumes provisioned through the CSI driver.

Boot from volume

Neither individual nodes nor entire clusters can be booted from a bootable volume. Every node is provisioned from a standard image that matches the cluster's expected configuration, including the correct Kubernetes version and container runtime, so that all nodes within a node group are consistent and join the cluster correctly. Booting a node from a volume you created yourself would produce a node that may not match this configuration or integrate with the control plane.

In-place version upgrades

Hyperstack Kubernetes does not support in-place version upgrades: a cluster keeps the version it was deployed with, and its nodes are not upgraded individually. To run a newer Kubernetes version, you deploy a new cluster on the target version, migrate your workloads to it, and then delete the old cluster. For the full step-by-step procedure, including how to handle stateless and stateful workloads, see Upgrading your Kubernetes cluster version.

Cluster and Node Statuses

During deployment, clusters and their nodes progress through a series of statuses that indicate each stage of the provisioning and configuration process.

Node vs associated VM statuses

Cluster node statuses and their associated virtual machine (VM) statuses represent separate but coordinated lifecycle stages. While nodes reflect Kubernetes-level provisioning and configuration, billing is based solely on the status of the underlying VMs. For more, see Node VM Statuses.

Cluster Statuses

The following statuses represent the lifecycle of a Kubernetes cluster during and after deployment, along with when billing is applied or not:

Status	Description
CREATING	The cluster’s virtual machines are being provisioned and booted.
RECONCILING	Kubernetes and required components are being installed and configured. Clusters will enter this state during initial cluster provisioning or when nodes are being added to or removed from an existing cluster.
ACTIVE	The cluster is fully deployed, and all components are operational.
DELETING	The cluster is being deleted.

Node Statuses

Node statuses reflect the individual provisioning and readiness state of each node within the cluster:

Status	Description
CREATING	The node is being created and initialized.
WAITING	Waiting for public IP assignment to establish connectivity to the VMs through the bastion node.
RECONCILING	Kubernetes components are being installed and configured on the node.
ACTIVE	The node is fully configured and ready to run workloads.
DELETING	The node is being deleted from the cluster.

Node status during scaling

When new node(s) are added to a cluster, the nodes that were already part of the cluster may temporarily enter the WAITING or RECONCILING states while the cluster integrates the new additions. However, the underlying virtual machines (VMs) for these existing nodes remain in the ACTIVE state throughout. As a result, workloads on these nodes continue without interruption, and billing remains active during these transitional states.

Node VM Statuses

Each node is backed by a single virtual machine (VM), which provides the underlying compute and network infrastructure required by Kubernetes. The node status is tightly coupled with the lifecycle of this VM.

The following statuses reflect the provisioning lifecycle of VMs associated with cluster nodes:

Status	Description	Billing
CREATING	The VM is being provisioned. Hardware resources are allocated.	Not Billed
BUILD	The image is being fetched and written to disk. This prepares the VM with the requested operating system and configuration.	Not Billed
PRE_ACTIVE	The VM is online but not yet integrated into an active cluster. It remains in the PRE_ACTIVE state until it is active in the cluster, at which point the VM transitions to ACTIVE as well.	Not Billed
ACTIVE	The VM is fully initialized and attached to a Kubernetes node. Billing is applied when the VM associated with the cluster node is in the ACTIVE state.	Billed
DELETING	The VM is in the process of being terminated. Resources are being cleaned up.	Not Billed
ERROR	The VM has encountered an unrecoverable error during provisioning or operation.	Not Billed

cluster VM state and billed statuses

Billing is applied only when the VMs associated with cluster nodes are in the ACTIVE state.

No charges are incurred while VMs are in any of the following states: CREATING, BUILD, PRE_ACTIVE, DELETING, or ERROR.

Cluster Billing & Data Retention

Kubernetes clusters differ from individual virtual machines in how they are billed and managed. This section outlines key behaviors, limitations, and precautions to help you avoid unexpected charges or data loss.

Cluster Billing Logic

Clusters are billed based on the total cost of their associated virtual machine resources:

• Worker nodes – Billed hourly based on the selected flavor. Each worker node is backed by a dedicated VM, and billing applies only when that VM is in the ACTIVE state. Virtual machines in any other state, including PRE_ACTIVE, CREATING, RECONCILING, and WAITING, are not billed. For a full explanation of VM statuses and their billing implications, see Node Statuses.
• Public IP addresses - In full deployment, two public IPs are billed at a fixed hourly rate, one for the bastion node and one for the load balancer node. In standard deployment, one public IP is billed at a fixed hourly rate, attached to the primary master node.
• Master, Load Balancer, and Bastion nodes — Not billed; these nodes incur no resource-based charges. This policy may be subject to change in future updates.

Example:
A cluster is deployed with 4 worker nodes, each costing $1.00/hour based on the flavor of the associated VMs. Additionally, the cluster has 2 public IPs billed at $0.00672/hour each. The total hourly cost is calculated as follows:

Worker nodes: 4 × $1.00 = $4.00/hour
Public IPs: 2 × $0.00672 = $0.013/hour
Total: $4.01/hour

Scaling and Billing Impact

Scaling your cluster by adding or removing worker nodes directly affects your hourly billing. Charges are applied based on the selected flavor of each worker node, and the updated per-hour running cost is reflected after the scaling operation is applied. While nodes are being added or removed, existing or remaining nodes continue to function normally, and workloads are not interrupted.

Node vs associated VM statuses

Cluster node statuses and their associated virtual machine (VM) statuses represent separate but coordinated lifecycle stages. While nodes reflect Kubernetes-level provisioning and configuration, billing is based solely on the status of the underlying VMs. For more, see Node VM Statuses.

Adding Worker Nodes

Adding worker nodes increases your hourly cost based on the number of nodes added and the selected flavor. Each added worker node is backed by an associated virtual machine (VM), which progresses through the following status transitions:

CREATING → BUILD → PRE_ACTIVE → ACTIVE (For details on each of these VM states, see Node VM Statuses.)

Billing does not apply to the added node while its underlying VM is in the CREATING, BUILD, or PRE_ACTIVE states, or while the node itself is in the CREATING, WAITING, or RECONCILING states. These are all transitional states in which the node is still being provisioned and is not yet ready to run workloads. Billing begins only once the VM associated with the node reaches the ACTIVE state. At that point, the cluster's total hourly cost is updated to reflect the added resources.

During the addition of new nodes, the cluster will enter the RECONCILING state as it updates to accommodate the changes. Existing nodes that were already part of the cluster may temporarily transition into RECONCILING or WAITING states during this process. However, the underlying virtual machines (VMs) associated with these nodes remain in the ACTIVE state at all times. As a result, workloads running on these pre-existing nodes continue without interruption, and billing remains active even when the nodes are in transitional states such as RECONCILING or WAITING.

Example:
Adding 2 1x A100-80G-PCIe flavor nodes at $1.35/hour each will increase your cluster's total cost by $2.70/hour, effective once the VMs associated with these nodes become ACTIVE.

Node provisioning failure

If a newly added cluster node fails to provision and enters the ERROR state, it will not be billed. The VMs associated with the other nodes in the cluster will remain in the ACTIVE state and continue to incur charges.

Deleting Worker Nodes

Deleting worker nodes from a cluster reduces your hourly cost. Billing for the deleted node stops as soon as its associated VM transitions from the ACTIVE state to the DELETING state. The total cost reduction depends on the number and flavor of nodes being removed.

When nodes are removed from a cluster, it enters the RECONCILING state, and the remaining nodes may temporarily show WAITING or RECONCILING while the cluster adjusts. Despite this, the underlying virtual machines (VMs) for these existing nodes remain in the ACTIVE state at all times. This ensures that workloads on the remaining nodes continue without interruption, and billing persists during these transitional states.

Example:
Deleting 1 1x A100-80G-PCIe flavor node will reduce the cluster's hourly cost by $1.35/hour. This change takes effect once the VM associated with this node is no longer ACTIVE and enters the DELETING state.

Adding or Deleting Master Nodes

Adding or deleting master nodes does not affect billing, as master nodes are not billed. Each cluster must maintain a minimum of 2 and a maximum of 3 master nodes to ensure control plane availability.

Stopping Billing (No Hibernation)

Clusters do not support hibernation and will remain active — and billed — until explicitly deleted.

To stop all charges associated with a cluster, you must delete the cluster.

Contracts and Public IPs

Contract Expiration

When a contract expires, the behavior of a cluster with worker nodes under the contract depends on the configured contract policy:

• Delete Policy: Contracted worker nodes are automatically deleted when the contract ends. If no worker nodes remain, the entire cluster will also be deleted, as Kubernetes clusters require at least one worker node to function.
• Keep Policy: Contracted worker nodes are retained and transition to on-demand billing when the contract expires. The cluster remains active as long as your account has sufficient balance to cover the charges.

Contract expiration

Clusters will only remain active after contract expiration if the "Keep resources after expiration" policy is enabled. Otherwise, the contracted worker nodes and the associated cluster will be deleted.

Public IP Billing

If a cluster is created with a flavor covered by a contract that includes public IP discounts, standard public IP charges will still apply. Contracts only apply to worker nodes, which do not have public IPs; the required IPs are assigned to the bastion and load balancer nodes and are billed separately.

Cluster Deletion on Zero Balance

Kubernetes clusters are deleted if your account balance reaches zero—even if the cluster uses contracted flavors.

This deletion is permanent and includes all data not stored externally. Ensure your account maintains sufficient credit to avoid data loss.