Create and Manage a Kubernetes Cluster in the Gozunga Cloud Portal

Run managed Kubernetes on Gozunga Cloud infrastructure in Sioux Falls, with US-based infrastructure, predictable monthly pricing, and 24/7 support from engineers who know the platform. In the example shown here, the control plane was active in about 10 minutes and the workers joined within that same deployment window. Provisioning time can vary by cluster size and current capacity.

1. What You Will Create
2. Prerequisites
3. Start a New Cluster
4. Select the Kubernetes Version and Configure the Control Plane
5. Configure the Worker Pool
6. Keep the Standard Options and Create the Cluster
7. Monitor Cluster Creation
8. Review the Managed Cloud Resources
9. Confirm That the Cluster Is Healthy
10. Download the Kubeconfig
11. Verify Access with kubectl
12. Manage or Delete the Cluster
13. Next Steps

1. What You Will Create

The Gozunga Cloud Portal creates the Kubernetes cluster and its supporting cloud resources for you. The example in this guide creates:

• One control plane node that manages the cluster
• Three worker nodes that run your applications
• A private network that connects the nodes
• A secure public endpoint for the Kubernetes API
• Network security rules for the control plane and worker nodes
• A configuration file that lets you manage the cluster from your computer

The screenshots show one example cluster. The available Kubernetes versions, server sizes, prices, and locations can change.

Note: Cluster nodes, storage, floating IPs, and other cloud resources can add charges to your project. Review the price summary in the portal before you create the cluster.

Example monthly node cost

The example uses one gp.medium1 control plane node at $26.28 per month and three co.medium2 worker nodes at $86.87 per month each:

$26.28 + (3 × $86.87) = $286.89 per month

The listed flavor prices include the storage shown for each server size. The $286.89 monthly total covers the four nodes shown in this guide. Floating IPs, persistent block volumes, load balancers, and other added resources can have separate charges. Check the portal summary and the Gozunga Cloud pricing page for the current total before you create a cluster.

2. Prerequisites

Before you start, you need:

• A Gozunga Cloud Portal account and project
• An SSH public key in the project
• kubectl installed on the computer that you will use to manage the cluster

You do not need to create the cluster network, router, security groups, or virtual machines first. The cluster service creates these resources during deployment.

3. Start a New Cluster

1. Sign in to the Gozunga Cloud Portal.
2. Select the correct project from the project menu at the top of the page.
3. Select Kubernetes in the left menu.
4. Select Create Kubernetes Cluster.

The portal opens the cluster configuration page. A summary at the side of the page shows each selection as you complete it.

4. Select the Kubernetes Version and Configure the Control Plane

First, configure the Kubernetes control plane:

1. Select the location for the cluster.
2. In Template, select the Kubernetes version. This example uses k8s-v1-36-1 (v1.36.1).

Next, configure the control plane nodes in Control Plane:

1. Choose whether to enable High Availability.
   • Leave it off to create one control plane node. This option is suitable for a small test cluster, but it does not provide control plane redundancy.
   • Turn it on to create three control plane nodes in active-active mode. This option keeps the control plane available if one node stops working.
2. Select a flavor category for the control plane nodes.
3. Select the control plane node flavor. This example uses gp.medium1.

The control plane nodes run the Kubernetes API and other services that manage the cluster. High availability creates three control plane nodes, so it also increases the cluster cost. Review the updated price summary before you continue.

Production recommendation: Enable High Availability for production clusters so that the control plane can continue to operate if one control plane node stops working.

Important: The version in this screenshot is an example. Select a Kubernetes version that your applications and tools support.

5. Configure the Worker Pool

Worker nodes run your application pods. In Worker Pool:

1. Set the number of worker nodes. This example uses three nodes.
2. Select a flavor category.
3. Select a worker flavor. This example uses the performance-optimized co.medium2 flavor.
4. Confirm the worker pool selection in the summary.

Choose worker capacity for the total CPU, memory, and storage that your applications need. Three worker nodes let Kubernetes distribute workloads across multiple virtual machines. You can use Rescale after deployment if you must change the worker count.

6. Keep the Standard Options and Create the Cluster

For this example, keep the standard values for the remaining cluster options:

• Autoscaling: Off
• Networking: Do not select an existing network. The service creates a network for the cluster.
• Floating IP: Off. This option controls public access to individual nodes. The service still creates the floating IP that the Kubernetes API endpoint needs.
• Labels: None

Then complete these steps:

1. In SSH Key, select the key that you want to install on the nodes. You can also add or generate a key from this section.
2. In Name, enter a clear cluster name. This example uses my-kube-cluster.
3. Review all entries in the summary.
4. Select Create Cluster.

Security note: Select an SSH key that you control. Do not share the private key. You usually manage the cluster through the Kubernetes API and do not need direct SSH access to its nodes.

7. Monitor Cluster Creation

The portal opens the cluster overview after it accepts the request. During deployment, the cluster shows Create In Progress. It can temporarily show Unhealthy while the control plane and worker nodes start. This is expected until the creation process is complete.

Use the refresh button to get the current state. Do not delete or change the generated resources while cluster creation is in progress. Wait until the portal shows Create Complete and Healthy.

8. Review the Managed Cloud Resources

The cluster service creates several OpenStack resources on your behalf. You can see these resources in the standard portal pages. Their generated names contain the cluster identifier.

Private network and router

Open Networking → Networks. The service creates one private network for communication between the cluster nodes.

Open the Routers tab. The managed router connects the cluster network to the external network.

Kubernetes API floating IP

Open the Floating IPs tab. The service assigns a floating IP to the Kubernetes API endpoint. The IP address in the cluster overview matches this endpoint.

Security groups

Open the Security Groups tab. The service creates separate managed security groups for the control plane and worker nodes. These groups contain the rules that the cluster components need.

Control plane and worker virtual machines

Open Servers. This example shows four active virtual machines: one control plane node and three worker nodes. The control plane node uses gp.medium1, and the worker nodes use co.medium2.

These resources are part of the managed cluster. Do not rename, detach, or delete them from their individual portal pages. Use the Kubernetes cluster controls to rescale, upgrade, or delete the cluster. This lets the service keep the cluster state and the cloud resources consistent.

9. Confirm That the Cluster Is Healthy

Return to Kubernetes and select the cluster. The overview now shows:

• Status: Create Complete
• Health Status: Healthy
• The Kubernetes version and API endpoint
• The control plane and worker node counts
• The location and creation time

The Pools, Nodes, and Networks tabs show the objects that belong to the cluster. The Labels section records settings such as the Kubernetes version, minimum and maximum worker count, and autoscaling state.

10. Download the Kubeconfig

The kubeconfig file contains the API endpoint and credentials that kubectl uses.

1. In the cluster Overview, find Actions.
2. Select Download kubeconfig.
3. Save the file in a secure location. The browser can save it as kubeconfig.yaml in your Downloads directory.
4. Restrict access to the file:

chmod 600 ~/Downloads/kubeconfig.yaml

Security note: Treat the kubeconfig as a secret. Do not send it in chat, store it in a public location, or commit it to source control. Its credentials can provide administrative access to the cluster.

11. Verify Access with kubectl

Set the KUBECONFIG environment variable to the downloaded file. Use an absolute path so that the command works from any directory:

export KUBECONFIG="$HOME/Downloads/kubeconfig.yaml"

List the pods in all namespaces:

kubectl get pods -A

A new cluster has system pods in the kube-system namespace. The output can include Calico networking, CoreDNS, the Kubernetes API server, the scheduler, the OpenStack cloud controller, and the Cinder CSI storage components. The exact pod names can change between Kubernetes versions.

Confirm that the system pods reach the Running state. Some pods can show a small restart count during initial startup. If pods remain pending or fail repeatedly, return to the cluster overview and check its health status before you deploy applications.

12. Manage or Delete the Cluster

Use the controls on the cluster page for lifecycle operations:

• Rescale changes the worker capacity.
• Upgrade starts a supported Kubernetes upgrade.
• Pools shows the control plane and worker pools.
• Nodes shows the nodes that are registered with the cluster.
• Networks shows the cluster network configuration.
• Download kubeconfig gets a new client configuration when you need one.
• Delete Cluster removes the managed cluster.

Before an upgrade, read the target version notes and confirm that your applications, admission controllers, and Kubernetes APIs support the new version. Before a rescale operation, confirm that the remaining workers have enough capacity for the workloads. Kubernetes can move normal pods, but local data and strict scheduling rules can prevent a safe move.

When you no longer need the cluster, use Delete Cluster from the Kubernetes page instead of deleting its servers or network objects one at a time. Confirm that you have backed up required application data and persistent volumes first. After deletion is complete, check Servers, Volumes, and Networking for any resources that you chose to retain.

13. Next Steps

Build out the cluster with the Gozunga Cloud services that your applications need:

• Use Block Storage for persistent application data and Kubernetes persistent volumes.
• Use Load Balancers to publish services and distribute application traffic.
• Review Gozunga Cloud Pricing before you add nodes, volumes, floating IPs, or load balancers.
• If you are moving from EKS, GKE, or a self-managed cluster, talk to our engineers about architecture and migration support.

You now have a healthy Gozunga Cloud Kubernetes cluster and a working local kubectl connection. You can use this cluster to deploy applications, create services, and attach persistent storage through the installed OpenStack integrations.