Default Magnum cluster templates on Destination Earth

Default Magnum cluster templates define standard configurations for provisioning Kubernetes clusters.

Warning

Template availability is volatile. The set of templates, supported Kubernetes versions, and template features (for example provisioning driver, localstorage, cilium, dualstack) can change over time. Always treat the template list shown in Horizon (or returned by the CLI) as the authoritative source.

What we are going to cover

Prerequisites

1. Account

You need a Destination Earth hosting account with Horizon access: https://cloud.central.data.destination-earth.eu.

2. Familiarity with OpenStack Commands

Ensure you have the relevant OpenStack commands installed:

How To Install OpenStack and Magnum Clients for Command Line Interface to Destination Earth Horizon

Available cluster templates

See templates in Horizon

You select the cluster template during cluster creation, as described in How to Create a Kubernetes Cluster Using Destination Earth OpenStack Magnum.

There are two different places from which you can view the available cluster templates in Horizon:

• Project → Container Infra → Cluster Templates

• Project → Container Infra → Clusters → Create Cluster → Cluster Template

The list of templates is defined by the current site. You should treat the list shown in Horizon as authoritative.

CENTRAL Cluster TemplatesCENTRAL Create New Cluster

The list of cluster templates may vary from bridge to bridge. For example, this is the list for EUMETSAT bridge; you will notice it is two cluster templates shorter as compared to the one for CENTRAL:

EUMETSAT Cluster TemplatesEUMETSAT Create New Cluster

See templates with CLI

With CLI, use How To Use Command Line Interface for Kubernetes Clusters OpenStack Magnum.

To list available templates, run:

openstack coe cluster template list

Important

If the CLI command returns “The service catalog is empty” but Horizon shows templates, re-source the correct OpenRC file or application-credential script and verify you are using the intended project.

Suffix meanings at a glance

Suffix	Meaning
cilium	Uses the Cilium CNI instead of default Calico.
dualstack	IPv4/IPv6 dualstack networking enabled.
numbers / extra chars	Internal use only — can be ignored.

Basic capabilities of a cluster template

A Magnum cluster template defines the baseline capabilities of the cluster you are about to create. Focus on the following capabilities:

Kubernetes version

The start of the template name denotes its version. For example, template called k8s-v1.32.6.-1.0.0 provisions Kubernetes 1.32.

For more information on Kubernetes upstream version skew policy, see https://kubernetes.io/releases/version-skew-policy/

Version numbers up to 1.27 are not upgradeable through Magnum. The template is fixed at creation time. To change Kubernetes version or behavior, create a new cluster with the desired template and migrate workloads manually.

Versions with numbers greater than 1.29 are upgradeable. You can perform a rolling upgrade to a newer Kubernetes version without recreating the cluster.

See Upgrade a Kubernetes cluster on Destination Earth OpenStack Magnum

Note

For new clusters, always use the latest version of cluster templates.

Also, the list of available templates will change in time; new versions may be added and the older ones may be made deprecated.

Network plugins for Kubernetes clusters

Kubernetes cluster templates at Destination Earth cloud use calico or cilium plugins for controlling network traffic. Both are CNI compliant.

Calico (the default)

Calico uses BGP protocol to move network packets towards IP addresses of the pods. Calico can be faster then its competitors but its most remarkable feature is support for network policies. With those, you can define which pods can send and receive traffic and also manage the security of the network.

Calico can apply policies to multiple types of endpoints such as pods, virtual machines and host interfaces. It also supports cryptographics identity. Calico policies can be used on its own or together with the Kubernetes network policies.

Cilium

Cilium is drawing its power from a technology called eBPF. It exposes programmable hooks to the network stack in Linux kernel. eBPF uses those hooks to reprogram Linux runtime behaviour without any loss of speed or safety. There also is no need to recompile Linux kernel in order to become aware of events in Kubernetes clusters. In essence, eBPF enables Linux to watch over Kubernetes and react appropriately.

With Cilium, the relationships amongst various cluster parts are as follows:

• pods in the cluster (as well as the Cilium driver itself) are using eBPF instead of using Linux kernel directly,

• kubelet uses Cilium driver through the CNI compliance and

• the Cilium driver implements network policy, services and load balancing, flow and policy logging, as well as computing various metrics.

Using Cilium especially makes sense if you require fine-grained security controls or need to reduce latency in large Kubernetes clusters.

Dualstack templates

Some clouds provide templates with dualstack in the name. These provision clusters with IPv4/IPv6 dualstack networking enabled. This is useful for workloads that must support both IPv4 and IPv6 users.