Skip to content

xCloud Kube

Overview

xCloud Kube is a managed Kubernetes service for running your container workloads. You provision clusters in the xCloud web app, pick a size (flavor) and a Kubernetes version, and xCloud handles the control plane, node infrastructure, and lifecycle operations. Billing is consumption-based: you choose a maximum cluster size, but you are billed for the resources you actually use.

Typical use cases:

  • Hosting containerised applications without operating Kubernetes infrastructure yourself
  • Spinning up isolated test or staging clusters on demand
  • Running workloads that need a redundant control plane via the optional high-availability option

Getting Started

Prerequisites

  • An active xCloud account with complete billing details
  • A configured payment method
  • Basic familiarity with Kubernetes concepts (clusters, kubeconfig, kubectl)

Activating xCloud Kube

Before you can create clusters, the xCloud Kube subscription must be activated for your account:

  1. Open the xCloud Kube section in the xCloud dashboard
  2. Review the available cluster sizes and the Price details for each one
  3. Click Activate and accept the Terms of Service

Once activated, the cluster dashboard becomes available and you can create your first cluster.

Creating a Cluster

Click Create cluster to open the cluster creation dialog. The form is grouped into the following sections.

Step 1: Select Site

Choose the geographic location where the cluster will be provisioned. The site determines where your control plane and worker nodes run.

Step 2: Select Cluster Size

Cluster sizes (flavors) define the maximum resources available to the cluster:

  • vCPU: number of CPU cores
  • RAM: memory allocation
  • Ephemeral storage: node-local scratch storage
  • Pods: maximum number of pods

Five sizes are available:

Size vCPU RAM Ephemeral storage Pods
XS 1 2 GB 1 GB 10
S 2 6 GB 10 GB 20
M 4 16 GB 10 GB 40
L 8 32 GB 20 GB 80
XL 16 64 GB 40 GB 160

Billing model

The cluster size defines the maximum resource limit. Only actual consumption (usage and requests) is billed.

Step 3: Persistent Storage

Optionally allocate persistent storage for the cluster (1–1000 GB). Persistent storage is required if your workloads use PersistentVolumeClaim resources. Leave the field empty if you do not need persistent storage.

Step 4: High Availability

Enable High availability to provision a redundant control plane with increased fault tolerance. The price difference is shown next to the checkbox.

Warning

High availability cannot be changed after the cluster has been created. To switch later, you must create a new cluster.

Step 5: Basic Settings

  • Cluster name: must start with a lowercase letter and may only contain lowercase letters, digits, and hyphens (DNS-safe format)
  • Kubernetes version: select from the list of currently supported versions

Step 6: Complete the Order

The dialog shows the estimated monthly cost at maximum usage. Review the legal terms and click Order at cost to start provisioning. The new cluster appears in the dashboard with status Requested and progresses through the lifecycle states described below.

Managing Clusters

Cluster Dashboard

The dashboard lists every cluster in your account with the following columns:

  • Name: the cluster name you chose at creation
  • Version: the Kubernetes version currently running
  • Endpoint: the Kubernetes API server URL (with a copy-to-clipboard button)
  • Created at: timestamp of creation
  • State: the current lifecycle state (see below)

Cluster States

State Description
Requested Creation request received, not yet picked up
Pending Waiting for provisioning to start
Creating Cluster is being provisioned
Active Cluster is fully operational
Updating Configuration change or version upgrade in progress
Deleting Cluster is being torn down
Error Provisioning or an operation failed

Most actions are only available while a cluster is Active. Deletion is also available in the Pending state.

Cluster Actions

Each row in the dashboard exposes an actions menu:

  • View details: read-only overview of cluster configuration, current resource usage, and forecasted cost
  • Edit: change cluster size, persistent storage, or Kubernetes version (only when Active)
  • Price details: granular price breakdown for the cluster's current flavor
  • Download kubeconfig: download the credentials file needed by kubectl (only when Active)
  • Delete cluster: permanently remove the cluster and all its data

Accessing the Cluster

Once a cluster is Active, download the kubeconfig file from the actions menu and point your tooling at it:

export KUBECONFIG=~/Downloads/<cluster-name>-kubeconfig.yaml
kubectl get nodes

The kubeconfig contains the API endpoint and credentials needed to manage workloads in the cluster. Keep it secure — anyone with the file can administer the cluster.

Info

Kubeconfig download is only available once the cluster reaches the Active state. While provisioning, the action is disabled.

Runtime Environment

Every cluster ships with DNS, ingress, certificate issuance and block storage already in place. This section describes what you find after your first kubectl get nodes.

Endpoint and Automatic Subdomain

The endpoint shown in the dashboard is the hostname of your API server, for example cl-1a2b3c4d-my-cluster.kube.hamburg.xcloud.eu.

Below that name, xCloud automatically provisions a wildcard subdomain. Every name under it resolves via A record to your cluster's ingress:

*.cl-1a2b3c4d-my-cluster.kube.hamburg.xcloud.eu

You can use these names as ingress hosts right away, with no domain and no DNS record of your own. app.cl-1a2b3c4d-my-cluster.kube.hamburg.xcloud.eu works as soon as the cluster exists.

Using Your Own Domain

There are two ways to bring your own domain:

  • CNAME to the endpoint (recommended): point app.example.com at cl-1a2b3c4d-my-cluster.kube.hamburg.xcloud.eu.. The record stays valid even if the platform's IP changes.
  • A record to the ingress IP: required for apex domains such as example.com, which cannot carry a CNAME.

Look up the ingress IP from your endpoint:

dig +short cl-1a2b3c4d-my-cluster.kube.hamburg.xcloud.eu

DNS first, ingress second

Certificate issuance validates over HTTP-01. Create the DNS record before you create the ingress, otherwise validation fails.

Ingress

Services of type LoadBalancer and NodePort are blocked. Applications are published exclusively through ingress, over HTTPS on port 443. Port 80 is open, but it answers every request with a permanent redirect to HTTPS. You cannot serve plain HTTP, so a certificate is not optional.

Two ingress classes are available. Traefik serves both over the same IP. The only difference is which annotations they evaluate:

Ingress class Use for
x-ion the default choice; evaluates nginx.ingress.kubernetes.io/* annotations
x-ion-traefik evaluates traefik.ingress.kubernetes.io/* annotations

There is no default class: without spec.ingressClassName, no controller picks up the ingress. Only Ingress objects are evaluated. Traefik CRDs such as IngressRoute, Middleware or TLSOption have no effect.

Ingress objects must follow these rules:

  • Every rule needs a host; wildcards in the host (*.example.com) are not allowed
  • Host and path must be unique across the platform
  • A tls block must cover all hosts used in the rules
  • Snippet annotations (*-snippet) and spec.defaultBackend are blocked

Annotations for x-ion

Traefik evaluates the nginx annotations through a compatibility provider, not through nginx itself. The following take effect, among others:

  • Requests and timeouts: proxy-body-size, proxy-connect-timeout, proxy-read-timeout, proxy-send-timeout
  • Paths and redirects: rewrite-target, use-regex, app-root, permanent-redirect, temporal-redirect, x-forwarded-prefix, custom-http-errors
  • Access control: allowlist-source-range, auth-type with auth-secret for basic auth, auth-url with auth-signin for forward auth
  • CORS: enable-cors and the cors-* annotations
  • Backends and sessions: backend-protocol, upstream-vhost, load-balance, service-upstream, affinity with the session-cookie-* annotations
  • Rate limits: limit-rps, limit-rpm, limit-connections
  • Canary rollouts: the canary-* annotations

The provider does not implement every nginx annotation. Those have no effect, among them denylist-source-range (the allowlist does work), ssl-ciphers, ssl-prefer-server-ciphers, proxy-cookie-domain, proxy-cookie-path, preserve-trailing-slash, limit-rate, global-rate-limit-*, mirror-* and enable-modsecurity. Traefik's documentation lists every supported and unsupported annotation.

Annotations for x-ion-traefik

On the Ingress, router.priority, router.pathmatcher and router.rulesyntax take effect. The matching Service accepts service.serversscheme, service.passhostheader and the service.sticky.cookie* annotations.

Annotations that reference a Traefik CRD have no effect. The ingress controller runs at platform level, and only your Ingress and Service objects reach it, not your CRDs. This affects router.middlewares, router.tls.options, service.serverstransport and service.middlewares.

TLS Certificates

cert-manager runs at platform level. You request a Let's Encrypt certificate through an annotation on the ingress:

  • letsencrypt-production: regular, publicly trusted certificates
  • letsencrypt-staging: test certificates without strict rate limits, not trusted
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-production
spec:
  ingressClassName: x-ion
  tls:
    - hosts:
        - app.cl-1a2b3c4d-my-cluster.kube.hamburg.xcloud.eu
      secretName: web-tls
  rules:
    - host: app.cl-1a2b3c4d-my-cluster.kube.hamburg.xcloud.eu
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 80

The platform issues and renews the certificate and terminates TLS. The secret named under secretName is therefore not created inside your cluster.

Annotation only

cert-manager objects such as Certificate, Issuer or ClusterIssuer are not evaluated inside your cluster. Custom issuers, DNS-01 validation and wildcard certificates are therefore not possible.

Storage Classes

Three storage classes are available for PersistentVolumeClaim resources, all backed by OpenStack block storage:

Storage class Performance
default 50 read IOPS, 50 write IOPS
fast 500 read IOPS, 500 write IOPS. The default class if you do not specify one
max 1000 read IOPS, 1000 write IOPS

Technically all three behave the same:

  • Access mode: ReadWriteOnce only, a volume attaches to exactly one node. ReadWriteMany is not available.
  • Expansion: supported, raise the size in the PVC. Shrinking is not possible.
  • Binding: Immediate. The volume is created as soon as the PVC exists, not when a pod mounts it.
  • Reclaim policy: Delete. Deleting the PVC deletes the volume and its contents.

Volumes count against the persistent storage you booked for the cluster and against the PVC quota of your cluster size (see Object quotas).

Default Requests and Limits

For containers without their own resources block, the cluster applies these values automatically:

CPU RAM Ephemeral storage
Request (default) 200m 409Mi 1Gi
Limit (default) 400m 618Mi 1Gi
Minimum 10m 32Mi –
Maximum 8 20Gi –

Minimum and maximum apply per container. A container requesting less or more is rejected.

Requests drive the cost

Billing covers usage and requests. A pod without a resources block therefore occupies 200m CPU and 409Mi RAM of your allowance even while idle. Set requests explicitly if your workloads need less.

Object quotas

Besides CPU, RAM and storage, the cluster caps how many objects of certain types you can create. These quotas follow from the pod count of your cluster size:

Object Quota
Services 1 × pods
Endpoints 1 × pods
Secrets 2 × pods
ConfigMaps 2 × pods
PersistentVolumeClaims 2 × pods

An L cluster with 80 pods therefore allows 80 services, plus 160 each of secrets, configmaps and PVCs. The platform enforces these quotas. They appear neither in the interface nor as a ResourceQuota object inside the cluster.

Editing a Cluster

Open the cluster's actions menu and choose Edit to modify the configuration. The following fields are editable while the cluster is Active:

  • Cluster size: resize up or down to a different flavor
  • Persistent storage: increase or decrease the allocation
  • Kubernetes version: upgrade to a newer supported version

The following fields are fixed at creation time and shown as read-only: cluster name, site, high availability, creation date.

Resource Usage Awareness

While editing, the dialog shows live resource usage (CPU, RAM, ephemeral storage, persistent storage) against the current limits. If you choose a smaller flavor or storage allocation than what the cluster is currently using, a warning is displayed — proceeding may cause the cluster to suffer from resource scarcity.

Kubernetes Version Upgrades

  • Only upgrades are supported. Downgrades are not possible, and older versions are disabled in the dropdown.
  • Upgrades proceed step by step, by at most one minor version at a time. To jump across several versions, perform multiple upgrades in sequence.
  • The upgrade operation is safe: it either completes successfully or aborts cleanly without affecting cluster availability.
  • An upgrade puts the cluster into the Updating state while it runs.

Save changes with the Save changes button. The cluster transitions to Updating while the new configuration is rolled out.

Monitoring Resource Usage

Open View details for any Active cluster to see current usage:

  • CPU (vCPU): cores currently consumed vs. flavor maximum
  • RAM (GB): memory currently consumed vs. flavor maximum
  • Ephemeral storage (GB): node-local storage in use vs. flavor maximum
  • Persistent storage (GB): persistent volume usage vs. allocated storage

The same dialog displays:

  • Monthly cost at maximum usage: what you would pay if the cluster ran at the flavor's full limit
  • Forecasted monthly cost: projection based on current consumption

Deleting a Cluster

  1. Open the actions menu for the cluster
  2. Select Delete cluster
  3. Confirm the deletion in the dialog

Irreversible

Deleting a cluster permanently removes all data and workloads. This action cannot be undone. Back up anything you need before deleting.

Deletion is available in the Active and Pending states.

Pricing

xCloud Kube uses a consumption-based pricing model. The cluster size defines the upper bound on resources; you are billed for actual usage rather than the maximum.

Charges are composed of:

  • Compute resources: per-core hourly rate for CPU, per-GB hourly rate for RAM
  • Ephemeral storage: per-GB hourly rate
  • Control plane: flat hourly fee (standard) or higher flat fee (high availability)
  • Persistent storage: per-GB hourly rate, billed on the allocated volume
  • Egress traffic: tiered per-GB pricing; the first 1000 GB per month are included

Prices are shown including VAT for private customers and excluding VAT for business customers. The Price details dialog (accessible per cluster or from the activation view) breaks the costs down by resource.

Cancelling the Subscription

To deactivate xCloud Kube entirely:

  1. Delete all clusters in your account (cancellation is blocked while clusters exist)
  2. Open the xCloud Kube section
  3. Click Deactivate xCloud Kube and confirm

The change takes effect within a few minutes. You can re-activate the subscription later if needed.

Troubleshooting

Cluster Stuck in Creating

Provisioning typically takes a few minutes. If the cluster remains in Creating for an extended period, check the dashboard for an Error state and contact support if needed.

Kubeconfig Download Unavailable

The kubeconfig is only available once the cluster reaches the Active state. Wait for provisioning to finish before attempting to download.

Cannot Cancel Subscription

The deactivation button is disabled while any clusters exist on the account. Delete all clusters first, then retry the cancellation.

Resource Pressure After Resize

If a cluster is sluggish or workloads are being evicted after a resize, the new flavor may be smaller than the cluster's actual consumption. Open View details to check current usage, and edit the cluster to select a larger flavor if needed.