xCloud Kube

Überblick

xCloud Kube ist ein verwalteter Kubernetes-Dienst zum Betrieb deiner Container-Workloads. Du provisionierst Cluster über die xCloud Web-App, wählst eine Clustergröße und eine Kubernetes-Version – xCloud kümmert sich um die Control Plane, die Node-Infrastruktur und den gesamten Lebenszyklus. Die Abrechnung erfolgt verbrauchsbasiert: Du legst eine maximale Clustergröße fest, gezahlt wird aber nur für die Ressourcen, die du tatsächlich nutzt.

Typische Einsatzszenarien:

• Betrieb containerisierter Anwendungen, ohne die Kubernetes-Infrastruktur selbst zu betreiben
• Aufbau isolierter Test- oder Staging-Cluster nach Bedarf
• Workloads, die eine redundante Control Plane über die optionale Hochverfügbarkeit benötigen

Erste Schritte

Voraussetzungen

• Ein aktiver xCloud-Account mit vollständigen Rechnungsdaten
• Eine eingetragene Zahlungsart
• Grundkenntnisse zu Kubernetes (Cluster, Kubeconfig, kubectl)

xCloud Kube aktivieren

Bevor du Cluster erstellen kannst, muss das xCloud-Kube-Abonnement für deinen Account aktiviert werden:

1. Öffne den Bereich xCloud Kube im xCloud-Dashboard
2. Sieh dir die verfügbaren Clustergrößen und die jeweiligen Preisdetails an
3. Klicke auf Aktivieren und akzeptiere die AGB

Nach der Aktivierung steht das Cluster-Dashboard zur Verfügung und du kannst deinen ersten Cluster anlegen.

Cluster erstellen

Klicke auf Cluster erstellen, um den Erstellungsdialog zu öffnen. Das Formular ist in folgende Abschnitte gegliedert.

Schritt 1: Standort wählen

Wähle den geografischen Standort, an dem der Cluster bereitgestellt wird. Der Standort bestimmt, wo Control Plane und Worker Nodes laufen.

Schritt 2: Clustergröße wählen

Die Clustergröße definiert die maximal verfügbaren Ressourcen des Clusters:

• vCPU: Anzahl der CPU-Kerne
• RAM: Arbeitsspeicher
• Flüchtiger Speicher: knotenlokaler Scratch-Speicher
• Pods: maximale Anzahl an Pods

Fünf Größen stehen zur Auswahl:

Größe	vCPU	RAM	Flüchtiger Speicher	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

Abrechnungsmodell

Die Clustergröße definiert das maximale Ressourcenlimit. Abgerechnet wird nur der tatsächliche Verbrauch (Usage & Requests).

Schritt 3: Persistenter Speicher

Optional kannst du persistenten Speicher für den Cluster bereitstellen (1–1000 GB). Persistenter Speicher ist erforderlich, wenn deine Workloads PersistentVolumeClaim-Ressourcen verwenden. Lass das Feld leer, wenn du keinen persistenten Speicher benötigst.

Schritt 4: Hochverfügbarkeit

Aktiviere Hochverfügbarkeit, um eine redundante Control Plane mit erhöhter Ausfallsicherheit bereitzustellen. Der Aufpreis wird neben der Checkbox angezeigt.

Warning

Hochverfügbarkeit kann nach der Erstellung nicht mehr geändert werden. Für einen Wechsel musst du einen neuen Cluster anlegen.

Schritt 5: Grundeinstellungen

• Clustername: muss mit einem Kleinbuchstaben beginnen und darf nur Kleinbuchstaben, Ziffern und Bindestriche enthalten (DNS-kompatibles Format)
• Kubernetes-Version: Auswahl aus den derzeit unterstützten Versionen

Schritt 6: Bestellung abschließen

Der Dialog zeigt die geschätzten monatlichen Kosten bei Maximalnutzung. Prüfe die rechtlichen Hinweise und klicke auf Kostenpflichtig bestellen, um die Provisionierung zu starten. Der neue Cluster erscheint im Dashboard mit dem Status Angefordert und durchläuft anschließend die unten beschriebenen Lebenszyklus-Zustände.

Cluster verwalten

Cluster-Dashboard

Das Dashboard listet alle Cluster deines Accounts mit folgenden Spalten:

• Name: der bei der Erstellung gewählte Cluster-Name
• Version: die aktuell laufende Kubernetes-Version
• Endpoint: die URL des Kubernetes-API-Servers (mit Kopier-Button)
• Erstellt am: Zeitpunkt der Erstellung
• Status: aktueller Lebenszyklus-Zustand (siehe unten)

Cluster-Zustände

Status	Beschreibung
Angefordert	Erstellungsanfrage empfangen, noch nicht aufgenommen
Ausstehend	Wartet auf den Start der Provisionierung
Wird erstellt	Cluster wird provisioniert
Aktiv	Cluster ist voll einsatzbereit
Wird aktualisiert	Konfigurationsänderung oder Versions-Upgrade läuft
Wird gelöscht	Cluster wird abgebaut
Fehler	Provisionierung oder Operation fehlgeschlagen

Die meisten Aktionen stehen nur im Zustand Aktiv zur Verfügung. Das Löschen ist zusätzlich im Zustand Ausstehend möglich.

Cluster-Aktionen

Jede Zeile im Dashboard verfügt über ein Aktionsmenü:

• Details anzeigen: schreibgeschützter Überblick über Konfiguration, aktuelle Ressourcennutzung und prognostizierte Kosten
• Bearbeiten: Clustergröße, persistenten Speicher oder Kubernetes-Version ändern (nur im Zustand Aktiv)
• Preisdetails: detaillierte Preisaufschlüsselung für die aktuelle Clustergröße
• Kubeconfig herunterladen: lädt die für kubectl benötigte Konfigurationsdatei herunter (nur im Zustand Aktiv)
• Cluster löschen: entfernt den Cluster und alle Daten unwiderruflich

Zugriff auf den Cluster

Sobald ein Cluster den Zustand Aktiv erreicht hat, lädst du die Kubeconfig-Datei aus dem Aktionsmenü herunter und richtest deine Tools darauf aus:

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

Die Kubeconfig enthält den API-Endpoint und die Zugangsdaten zur Verwaltung der Workloads. Bewahre sie sicher auf – wer Zugriff auf die Datei hat, kann den Cluster administrieren.

Info

Die Kubeconfig steht erst zum Download bereit, wenn der Cluster den Zustand Aktiv erreicht hat. Während der Provisionierung ist die Aktion deaktiviert.

Laufzeitumgebung

Jeder Cluster bringt DNS, Ingress, TLS-Ausstellung und Blockspeicher bereits mit. Dieser Abschnitt beschreibt, was du nach dem ersten kubectl get nodes vorfindest.

Endpoint und automatische Subdomain

Der Endpoint aus dem Dashboard ist der Hostname deines API-Servers, zum Beispiel cl-1a2b3c4d-mein-cluster.kube.hamburg.xcloud.eu.

Unterhalb dieses Namens legt xCloud automatisch eine Wildcard-Subdomain an. Jeder Name darunter zeigt per A-Record auf den Ingress deines Clusters:

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

Du kannst diese Namen sofort als Ingress-Host verwenden, ohne eigene Domain und ohne eigenen DNS-Eintrag. app.cl-1a2b3c4d-mein-cluster.kube.hamburg.xcloud.eu funktioniert direkt nach dem Anlegen des Clusters.

Eigene Domain verwenden

Für eigene Domains gibt es zwei Wege:

• CNAME auf den Endpoint (empfohlen): app.example.com als CNAME auf cl-1a2b3c4d-mein-cluster.kube.hamburg.xcloud.eu.. Der Eintrag bleibt gültig, auch wenn sich die IP der Plattform ändert.
• A-Record auf die Ingress-IP: nötig bei Apex-Domains wie example.com, die keinen CNAME führen dürfen.

Die Ingress-IP ermittelst du aus deinem Endpoint:

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

Erst DNS, dann Ingress

Die Zertifikatsausstellung validiert über HTTP-01. Lege den DNS-Eintrag an, bevor du den Ingress erstellst, sonst schlägt die Validierung fehl.

Ingress

Services vom Typ LoadBalancer und NodePort sind gesperrt. Anwendungen werden ausschließlich über Ingress veröffentlicht, und zwar per HTTPS auf Port 443. Port 80 ist zwar offen, beantwortet aber jede Anfrage mit einer permanenten Weiterleitung auf HTTPS. Reines HTTP kannst du nicht ausliefern, ein Zertifikat brauchst du also in jedem Fall.

Zwei IngressClasses stehen bereit. Traefik bedient beide über dieselbe IP. Der Unterschied liegt nur darin, welche Annotationen sie auswerten:

IngressClass	Wofür
x-ion	Standardwahl; wertet nginx.ingress.kubernetes.io/*-Annotationen aus
x-ion-traefik	wertet traefik.ingress.kubernetes.io/*-Annotationen aus

Eine Default-Class gibt es nicht: Ohne spec.ingressClassName nimmt kein Controller den Ingress an. Ausgewertet werden ausschließlich Ingress-Objekte. Traefik-CRDs wie IngressRoute, Middleware oder TLSOption haben keine Wirkung.

Für Ingress-Objekte gelten diese Regeln:

• Jede Regel braucht einen Host; Wildcards im Host (*.example.com) sind nicht erlaubt
• Host und Pfad müssen plattformweit eindeutig sein
• Ein tls-Block muss alle Hosts der Regeln abdecken
• Snippet-Annotationen (*-snippet) und spec.defaultBackend sind gesperrt

Annotationen für x-ion

Traefik wertet die nginx-Annotationen über einen Kompatibilitäts-Provider aus, nicht über nginx selbst. Wirksam sind unter anderem:

• Requests und Timeouts: proxy-body-size, proxy-connect-timeout, proxy-read-timeout, proxy-send-timeout
• Pfade und Weiterleitungen: rewrite-target, use-regex, app-root, permanent-redirect, temporal-redirect, x-forwarded-prefix, custom-http-errors
• Zugriffsschutz: allowlist-source-range, auth-type mit auth-secret für Basic Auth, auth-url mit auth-signin für Forward Auth
• CORS: enable-cors und die cors-*-Annotationen
• Backends und Sessions: backend-protocol, upstream-vhost, load-balance, service-upstream, affinity mit den session-cookie-*-Annotationen
• Rate Limits: limit-rps, limit-rpm, limit-connections
• Canary-Rollouts: die canary-*-Annotationen

Nicht jede nginx-Annotation implementiert der Provider. Diese bleiben wirkungslos, darunter denylist-source-range (die Allowlist wirkt), ssl-ciphers, ssl-prefer-server-ciphers, proxy-cookie-domain, proxy-cookie-path, preserve-trailing-slash, limit-rate, global-rate-limit-*, mirror-* und enable-modsecurity. Die Traefik-Dokumentation listet alle unterstützten und nicht unterstützten Annotationen auf.

Annotationen für x-ion-traefik

Am Ingress wirken router.priority, router.pathmatcher und router.rulesyntax. Am zugehörigen Service gelten service.serversscheme, service.passhostheader und die service.sticky.cookie*-Annotationen.

Annotationen, die auf ein Traefik-CRD verweisen, bleiben wirkungslos. Der Ingress-Controller läuft auf Plattform-Ebene, und dort kommen aus deinem Cluster nur die Ingress- und Service-Objekte an, nicht die CRDs. Betroffen sind router.middlewares, router.tls.options, service.serverstransport und service.middlewares.

TLS-Zertifikate

cert-manager läuft auf Plattform-Ebene. Du forderst ein Let's-Encrypt-Zertifikat über eine Annotation am Ingress an:

• letsencrypt-production: reguläre, öffentlich vertrauenswürdige Zertifikate
• letsencrypt-staging: Testzertifikate ohne strenge Rate Limits, nicht vertrauenswürdig

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-mein-cluster.kube.hamburg.xcloud.eu
      secretName: web-tls
  rules:
    - host: app.cl-1a2b3c4d-mein-cluster.kube.hamburg.xcloud.eu
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 80

Ausstellung und Erneuerung übernimmt die Plattform, TLS wird dort terminiert. Das unter secretName genannte Secret wird deshalb nicht in deinem Cluster angelegt.

Nur über die Annotation

cert-manager-Objekte wie Certificate, Issuer oder ClusterIssuer werden in deinem Cluster nicht ausgewertet. Eigene Issuer, DNS-01-Validierung und Wildcard-Zertifikate sind damit nicht möglich.

Storage-Klassen

Für PersistentVolumeClaim-Ressourcen stehen drei Storage-Klassen bereit, alle auf Basis von OpenStack-Blockspeicher:

Storage-Klasse	Leistung
default	50 IOPS lesend, 50 IOPS schreibend
fast	500 IOPS lesend, 500 IOPS schreibend. Default-Klasse wenn du keine angibst
max	1000 IOPS lesend, 1000 IOPS schreibend

Technisch verhalten sich alle drei gleich:

• Zugriffsmodus: nur ReadWriteOnce, ein Volume hängt an genau einem Node. ReadWriteMany gibt es nicht.
• Vergrößern: unterstützt, du erhöhst dazu die Größe im PVC. Verkleinern ist nicht möglich.
• Binding: Immediate. Das Volume entsteht sofort beim Anlegen des PVC, nicht erst, wenn ein Pod es einbindet.
• Reclaim Policy: Delete. Mit dem PVC verschwindet auch das Volume samt Inhalt.

Angelegte Volumes zählen gegen den persistenten Speicher, den du für den Cluster gebucht hast, und gegen das PVC-Kontingent deiner Clustergröße (siehe Objektkontingente).

Standard-Requests und -Limits

Für Container ohne eigene resources-Angabe setzt der Cluster automatisch Werte:

	CPU	RAM	Flüchtiger Speicher
Request (Standard)	200m	409Mi	1Gi
Limit (Standard)	400m	618Mi	1Gi
Minimum	10m	32Mi	–
Maximum	8	20Gi	–

Minimum und Maximum gelten pro Container. Fordert ein Container weniger oder mehr an, lehnt der Cluster ihn ab.

Requests bestimmen die Kosten

Abgerechnet werden Verbrauch und Requests. Ein Pod ohne resources-Angabe belegt damit 200m CPU und 409Mi RAM in deinem Kontingent, auch wenn er nichts tut. Setze Requests explizit, wenn deine Workloads weniger brauchen.

Objektkontingente

Neben CPU, RAM und Speicher begrenzt der Cluster, wie viele Objekte einiger Typen du anlegen kannst. Diese Kontingente leiten sich aus der Pod-Zahl deiner Clustergröße ab:

Objekt	Kontingent
Services	1 × Pods
Endpoints	1 × Pods
Secrets	2 × Pods
ConfigMaps	2 × Pods
PersistentVolumeClaims	2 × Pods

Ein L-Cluster mit 80 Pods erlaubt also 80 Services sowie je 160 Secrets, ConfigMaps und PVCs. Die Kontingente werden auf Plattform-Ebene durchgesetzt. Sie erscheinen weder in der Oberfläche noch als ResourceQuota-Objekt im Cluster.

Cluster bearbeiten

Öffne das Aktionsmenü eines Clusters und wähle Bearbeiten, um die Konfiguration zu ändern. Während der Cluster im Zustand Aktiv ist, sind folgende Felder bearbeitbar:

• Clustergröße: Wechsel auf eine andere Größe (kleiner oder größer)
• Persistenter Speicher: Erhöhen oder Verringern der zugewiesenen Menge
• Kubernetes-Version: Upgrade auf eine neuere unterstützte Version

Folgende Felder werden bei der Erstellung festgelegt und sind nicht änderbar: Clustername, Standort, Hochverfügbarkeit, Erstellungsdatum.

Hinweis zur Ressourcennutzung

Während der Bearbeitung zeigt der Dialog die aktuelle Ressourcennutzung (CPU, RAM, flüchtiger Speicher, persistenter Speicher) im Verhältnis zu den aktuellen Grenzen an. Wenn du eine kleinere Clustergröße oder weniger Speicher wählst als der Cluster gerade verbraucht, erscheint eine Warnung – der Cluster könnte unter Ressourcenmangel leiden.

Kubernetes-Versions-Upgrades

• Es werden ausschließlich Upgrades unterstützt. Downgrades sind nicht möglich; ältere Versionen sind im Auswahlmenü deaktiviert.
• Upgrades erfolgen schrittweise um maximal eine Minor-Version. Für einen Sprung über mehrere Versionen führst du entsprechend mehrere Upgrades nacheinander durch.
• Die Upgrade-Operation ist sicher: Sie wird entweder erfolgreich durchgeführt oder sicher abgebrochen, ohne die Cluster-Verfügbarkeit zu beeinträchtigen.
• Während des Upgrades wechselt der Cluster in den Zustand Wird aktualisiert.

Speichere die Änderungen mit Änderungen speichern. Der Cluster wechselt in den Zustand Wird aktualisiert, während die neue Konfiguration ausgerollt wird.

Ressourcennutzung überwachen

Öffne Details anzeigen für einen aktiven Cluster, um die aktuelle Nutzung einzusehen:

• CPU (vCPU): aktuell genutzte Kerne im Verhältnis zum Größenmaximum
• RAM (GB): aktuell genutzter Arbeitsspeicher im Verhältnis zum Größenmaximum
• Flüchtiger Speicher (GB): node-lokal genutzter Speicher im Verhältnis zum Größenmaximum
• Persistenter Speicher (GB): genutztes Volume im Verhältnis zur zugewiesenen Menge

Im selben Dialog werden außerdem angezeigt:

• Monatliche Kosten bei Maximalnutzung: was der Cluster kostet, wenn er das Limit der Clustergröße ausschöpft
• Geschätzte monatliche Kosten: Hochrechnung auf Basis der aktuellen Nutzung

Cluster löschen

1. Öffne das Aktionsmenü des Clusters
2. Wähle Cluster löschen
3. Bestätige die Löschung im Dialog

Unwiderruflich

Das Löschen eines Clusters entfernt alle Daten und Workloads dauerhaft. Diese Aktion kann nicht rückgängig gemacht werden. Sichere vorher alles, was du behalten möchtest.

Das Löschen ist in den Zuständen Aktiv und Ausstehend möglich.

Preise

xCloud Kube verwendet ein verbrauchsbasiertes Preismodell. Die Clustergröße definiert die Obergrenze der verfügbaren Ressourcen; abgerechnet wird der tatsächliche Verbrauch, nicht das Maximum.

Die Kosten setzen sich zusammen aus:

• Compute-Ressourcen: stündlicher Preis pro CPU-Kern, stündlicher Preis pro GB RAM
• Flüchtiger Speicher: stündlicher Preis pro GB
• Control Plane: pauschaler Stundenpreis (Standard) oder höherer pauschaler Stundenpreis (Hochverfügbarkeit)
• Persistenter Speicher: stündlicher Preis pro GB, berechnet auf das zugewiesene Volume
• Egress-Traffic: gestaffelte Preise pro GB; die ersten 1000 GB pro Monat sind inklusive

Für Privatkunden werden die Preise inklusive MwSt. ausgewiesen, für Geschäftskunden exklusive MwSt. Der Dialog Preisdetails (je Cluster oder über die Aktivierungsansicht erreichbar) schlüsselt die Kosten nach Ressource auf.

Abonnement kündigen

So deaktivierst du xCloud Kube vollständig:

1. Lösche alle Cluster in deinem Account (die Kündigung ist blockiert, solange Cluster existieren)
2. Öffne den Bereich xCloud Kube
3. Klicke auf xCloud Kube deaktivieren und bestätige

Die Änderung wird innerhalb weniger Minuten wirksam. Du kannst das Abonnement später jederzeit wieder aktivieren.

Fehlerbehebung

Cluster bleibt in „Wird erstellt“

Die Provisionierung dauert in der Regel wenige Minuten. Bleibt der Cluster längere Zeit im Zustand Wird erstellt, prüfe das Dashboard auf den Zustand Fehler und wende dich gegebenenfalls an den Support.

Kubeconfig-Download nicht verfügbar

Die Kubeconfig steht erst zur Verfügung, wenn der Cluster den Zustand Aktiv erreicht hat. Warte das Ende der Provisionierung ab, bevor du den Download startest.

Abonnement lässt sich nicht kündigen

Die Schaltfläche zur Deaktivierung ist deaktiviert, solange noch Cluster im Account existieren. Lösche zuerst alle Cluster und versuche die Kündigung erneut.

Ressourcenmangel nach Resize

Wenn ein Cluster nach einer Größenänderung träge reagiert oder Workloads verdrängt werden, ist die neue Clustergröße möglicherweise kleiner als der tatsächliche Verbrauch. Öffne Details anzeigen, um die aktuelle Nutzung zu prüfen, und wähle bei Bedarf über Bearbeiten eine größere Clustergröße.