Learn how you can create your Kubernetes cluster with us and what you need to consider when doing so.
This service is currently in Early Access. Contact us to request access.
First of all, you need a Xelon HQ account. If you don't have an account yet, you can contact our Sales team who can create an account for you and simplify the onboarding process. Once you have an account and are logged in, you can follow these instructions.
Basic information
Go to “Kubernetes” in the side overview bar and click on “Create Cluster”. Our creation wizard is divided into three sections, which are listed below.
Basics
The creation wizard then opens and asks for all the necessary information listed below.
- Cluster name: This name is a display name that makes it easier to recognize the cluster.
- Select Tenant: As a reseller, you can use this option to provide a cluster for an end customer.
- Select Cloud: By default, all nodes of a Kubernetes cluster run in a dedicated cloud, but you can choose which cloud to use.
- Talos Version: Talos is the operating system we use to run our service, select the desired version here.
- Kubernetes Version: Kubernetes is the software for orchestrating containers, details of the current versions can be found on the official website.
Newer Kubernetes versions are generally better.
Please consider: Kubernetes uses the semantic versioning format,, but minor patches also contain incompatible API adaptations.
Network Settings
The cluster network settings control access to the cluster as well as the IP distribution and DNS settings in the cluster.
- Kubernetes API allowed IPs: This list of IP addresses and networks allows external access to the KubeAPI. This rule is enforced by the load balancers. The KubeAPI is used to configure and manage the workload on the Kubernetes cluster.
- Talos API allowed IPs: This list of IP addresses and networks allows external access to the TalosAPI, this rule is enforced by load balancers. The TalosAPI is used to manipulate the configuration of the operating system of the nodes.
- Cluster Domain: Kubernetes uses DNS resolution internally to point to services and containers, all services and containers have their own “fully qualified domain name” that ends in the cluster domain.
- Pod Subnet: This cannot currently be manipulated; we use a network from the CGNAT area by default, which is not routed on the Internet. Find out more about this in RFC 6598.
- Service Subnet: This cannot currently be manipulated; we use a network from the CGNAT area by default, which is not routed on the Internet. Find out more about this in RFC 6598.
Bonus tip: If no IPs are added to the IP lists in point 1 & 2, all are allowed. To prevent this, you can add a fake localhost address, such as: “127.0.0.127”.
Pools and Nodes
Pools are a logical abstraction in order to have a predefined size for the virtual machines. Nodes, on the other hand, are the virtual machines themselves. In general, you can decide for yourself how many resources you want to make available to the virtual machines.
-
Primary Load Balancer: The Primary Load Balancer Cluster is used to publish Kubernetes services of the type Load Balancer, the standard Ingress Controller as well as the KubeAPI and TalosAPI. It is also used as a gateway for the Kubernetes nodes themselves. Production mode scales the number of load balancer nodes from one to two, which increases fault tolerance through failover mechanisms.
- 0_ControlPlane: The number at the beginning of the pool name is the pool index number. This pool is the ControlPlane pool that hosts the brain (ETCD) of Kubernetes. The productive mode scales the number of ControlPlane nodes from one node to three nodes, which increases the fault tolerance and enables the management of the Kubernetes cluster / KubeAPI even while a ControlPlane node is not available.
- 1_Worker: This pool is the first worker pool; depending on the structure and function of the cluster, one or more worker pools are created. In this example, a distinction is made between compute nodes and storage nodes. The number of worker nodes is up to you and scalable at any time, but it is recommended to have at least two worker nodes to enable workload failover.
- 2_Storage: This pool is the second worker pool that we can add via the “Add WorkerPool” button. The special feature here is that we have activated the “Storage Pool” option, which allows us to add another hard disk for each node in this pool, which we can use as local storage. Please consider: These hard disks are bound to the nodes and are deleted as soon as the corresponding node is deleted.
Once everything is selected as desired, you can create the cluster using “Deploy Cluster” at the bottom of the screen. After pressing this button the deployment is started directly and you can see a small overview.
Creating a cluster takes between 3 and 10 minutes, depending on the resources allocated.
Cluster Dashboard
Use the navigation bar to go to Kubernetes and select your desired cluster.
Initially, the cluster health status is displayed as “unhealthy”; this can be checked using the “Check” function and the status is adjusted a few seconds later.
The Cluster Dashboard provides you with an overview of your Kubernetes cluster.
Cluster Info
The Cluster Info section displays the most important information about the cluster. You can also download the Talos configuration file here, which you can use to control and manipulate your nodes. For security reasons, we also offer you the option of manipulating the list of permitted IPs via “Talos API Allowed IPs”.
As mentioned above, all IPs are permitted unless you specify a dedicated IP.
Cluster Resources
The Cluster Resources summarizes how many resources are used for all devices together. Not only the Kubernetes nodes are displayed here, but also the load balancers.
Kubernetes Configuration
The Kubernetes Configuration area shows the basic settings of your Kubernetes cluster, where you can also adjust the “K8S API Allowed IPs” and update the Kubernetes version. You will also find the Kube Config here, which you can download directly to access it with Kubectl or other tools.
Linked Load Balancers
The Linked Load Balancers section displays the connected load balancers, the IP displayed for each load balancer is not the IP used for Kubernetes load balancing, but the primary IP address of the load balancer.
Pools and Nodes
The Pools and Nodes section is the most exciting part. A worker pool can be extended by one node using the “+” button, this is also known as horizontal scaling. Scaling means not only expanding a cluster, but also reducing the size of a cluster, which is also possible using the “Delete” button.
Please note that there are two types of “Delete” buttons, one is located at the pool level and deletes the entire pool.The second one is on the node level and deletes a specific node.
As our customers' requirements are more variable, it is possible to create multiple worker pools. A worker pool is a logical declaration of resources that are used to create new nodes. To make the scaling of the available resources even more efficient, we also allow vertical scaling of the pools, click on the “⚙” of the corresponding pool.
Extending the resources requires a restart of the node, we will gently shut down the node via the API. To do this, it is important that you have enough resources on the other nodes to restart a node. The resource upgrade of the nodes is done serially.
Cluster Changes
The Cluster Changes section is a history of the actions that have been carried out on the current cluster. These logs can also be exported.