0800 71 20000
Kontakt
...
Betriebsmodell entscheiden

Managed Kubernetes oder selbst betreiben: EKS, AKS und GKE gegen den eigenen Cluster

Bis etwa fünfzehn Knoten gewinnt der verwaltete Dienst fast immer. Die Control Plane kostet bei EKS, AKS und GKE jeweils rund 0,10 US-Dollar pro Cluster und Stunde, also gut 70 Euro im Monat, und dafür bekommst du Hochverfügbarkeit, etcd-Sicherung und ein geführtes Versionsupdate. Der Eigenbetrieb rechnet sich erst, wenn Datenhaltung, Netztrennung oder Souveränitätsauflagen den verwalteten Dienst ausschließen. Alles andere ist eine Entscheidung über Personal, nicht über Lizenzen.

5 Kapitel mit allen Befehlen
Passende Kurse ansehen Persönlich beraten lassen
Zwei IT-Entscheider vergleichen Plattformoptionen an einem großen Bildschirm
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum die Frage fast nie an der Technik hängt

Der Preisvergleich, mit dem die Diskussion meistens anfängt, geht am eigentlichen Kostenblock vorbei. Die Control Plane kostet bei Amazon EKS, Azure Kubernetes Service und Google Kubernetes Engine jeweils rund 0,10 US-Dollar pro Cluster und Stunde, also gut 70 Euro im Monat. Bezahlt wird der ganze Rest: Worker-Nodes, Blockspeicher, Load Balancer, NAT-Gateway und ausgehender Datenverkehr. Genau diese Posten fallen im Eigenbetrieb ebenfalls an, nur unter anderen Namen und mit anderer Abschreibung. Wer den eigenen Cluster damit begründet, dass die Control Plane nichts kostet, hat die Rechnung noch nicht aufgemacht.

Der zweite Posten ist Arbeitszeit, und die steht in keinem Angebot. Anbieter- und Beratungsvergleiche setzen für einen kleinen selbst betriebenen Cluster acht bis fünfzehn Stunden im Monat an: Updates, Zertifikatswechsel, etcd-Sicherung samt geprüftem Rückspielen, Betriebssystempflege der Knoten und die Fehlersuche, wenn das Netz-Plugin nach einem Kernel-Update nicht mehr startet. Dazu kommt das Versionsfenster. Kubernetes bringt drei Releases im Jahr, jedes bekommt rund vierzehn Monate lang Patches. Ein Cluster, den niemand einplant zu aktualisieren, ist nach zwei Jahren kein Kostenvorteil mehr, sondern ein offenes Sicherheitsproblem.

Erst der dritte Punkt schließt Optionen wirklich aus, und er kommt in Deutschland häufiger vor als anderswo. Wenn Daten das eigene Rechenzentrum nicht verlassen dürfen, wenn eine Aufsicht physische Netztrennung fordert, wenn die Fachanwendung an einem Dongle oder an speziellen Karten hängt oder wenn die Umgebung überhaupt keinen Internetzugang hat, hilft kein verwalteter Dienst. In allen anderen Fällen ist der Eigenbetrieb eine bewusste Entscheidung für mehr Kontrolle, und du bezahlst sie mit Stellen, nicht mit Rechnungen.

Miniatur-Szene: zwei Plattformen nebeneinander mit unterschiedlichen Cloud-Bausteinen, dazwischen eine Waage

Sechs Größen, an denen die Entscheidung kippt

  1. 01 Anzahl der Cluster, nicht Anzahl der Container
  2. 02 Verfügbare Betriebsstunden im Team, ehrlich geschätzt
  3. 03 Versionsfenster: drei Releases im Jahr, rund 14 Monate Pflege
  4. 04 Datenhaltung, Netztrennung und Souveränitätsauflagen
  5. 05 Egress, Load Balancer und NAT als versteckte Posten
  6. 06 Bindung an anbietereigene Bausteine und der Weg zurück
Was du mitnimmst

Drei Modelle, nicht zwei

Die Debatte wird meist als Entweder-oder geführt, dabei liegt die interessanteste Option in der Mitte. So ordnen wir die Wege ein.

Verwalteter Dienst beim Hyperscaler

EKS, AKS und GKE betreiben API-Server, Scheduler, Controller und etcd für dich, über mehrere Zonen verteilt, mit Sicherung und Wiederherstellung der Control Plane. Du behältst trotzdem die Knoten, das Betriebssystem darauf, die Netz- und Speicher-Plugins, Ingress, Zertifikate und alles, was in deinen Namespaces läuft. Der Dienst nimmt dir also den anspruchsvollsten, aber nicht den größten Teil der Arbeit ab.

Eigener Cluster auf gemieteten Maschinen

Kubeadm oder k3s auf virtuellen Maschinen eines beliebigen Anbieters ist der übersehene Mittelweg. Du bist unabhängig vom Cluster-Angebot des Hyperscalers, kannst zu einem europäischen Anbieter wechseln und behältst trotzdem elastische Kapazität. Der Preis ist der volle Control-Plane-Betrieb inklusive etcd, Zertifikatsrotation und Upgrade-Planung. Für Teams mit mehreren gleichartigen Clustern lohnt sich das, für einen einzelnen Produktivcluster selten.

Eigener Cluster auf eigener Hardware

Sinnvoll, wenn ohnehin ein Rechenzentrum betrieben wird, wenn Datenhaltung oder Netztrennung es erzwingen oder wenn du sehr konstante, große Lasten fährst. Hier gewinnst du gegen die Cloud vor allem bei dauerhaft ausgelasteten Knoten und bei viel ausgehendem Datenverkehr. Rechne Hardware, Strom, Fläche, Wartungsverträge, Ersatzteile und die Bereitschaft mit ein, sonst vergleichst du eine Vollkostenrechnung mit einer Teilkostenrechnung.

Souveräne Plattform als Unterbau

Zwischen Hyperscaler und Blech liegt die eigene oder eingekaufte Private Cloud, meist auf OpenStack. Sie gibt dir Selbstbedienung und API-gesteuerte Infrastruktur, ohne dass Daten das eigene oder ein deutsches Rechenzentrum verlassen. Der Aufwand ist erheblich, deshalb trägt dieser Weg vor allem dann, wenn mehrere Fachbereiche darauf laufen und die Plattform ein eigenes Team hat.

So rechnest du ehrlich

Stelle über drei Jahre gegenüber: Knotenkosten, Blockspeicher, Load Balancer, NAT und Egress auf der einen Seite, Hardware, Abschreibung, Strom, Fläche, Support und Ersatz auf der anderen. Dann addiere auf beiden Seiten die Personalzeit, und zwar zum internen Stundensatz. Erst diese Zahl entscheidet, und sie fällt oft anders aus als die Bauchentscheidung im Meeting.

Tutorial

Von der Zuständigkeitsmatrix bis zum getesteten Upgrade

Bis etwa fünfzehn Knoten gewinnt der verwaltete Dienst, darüber entscheidet die Personalfrage und nicht der Preis der Control Plane. Damit die Zahlen das auch belegen, trennst du zuerst die Zuständigkeiten, rechnest die Kosten über drei Jahre gegen, spielst das Versionsfenster durch, fasst die Betriebsaufgaben des Eigenbetriebs an und hältst dir am Ende den Wechsel zwischen beiden Modellen offen. Die Beispiele zeigen AWS und Azure nebeneinander, GKE verhält sich analog.

01

Schritt 1: Zuständigkeiten auf Papier trennen

Der häufigste Denkfehler ist die Annahme, ein verwalteter Dienst betreibe den Cluster. Er betreibt die Control Plane. Alles darüber und darunter bleibt bei dir, und genau das bestimmt deinen Aufwand.

Wer macht was, im verwalteten Dienst und im Eigenbetrieb

AufgabeVerwalteter DienstEigenbetrieb
API-Server, Scheduler, ControllerAnbieter, über mehrere Zonen verteiltDu, inklusive Lastverteilung davor
etcd sichern und zurückspielenAnbieterDu, mit geprüftem Rückspielen
Zertifikate der Control Plane rotierenAnbieterDu, jährlich und vor jedem Upgrade
Kubernetes-Version anhebenDu löst aus, Anbieter führt ausDu, Knoten für Knoten
Betriebssystem der Worker-NodesDu, oder verwaltete Node-GruppenDu
CNI, CSI, Ingress, ZertifikatsverwaltungDuDu
Kapazität, Kosten, Namespaces, RBACDuDu

Aus der Tabelle folgt eine unbequeme Zahl: Der verwaltete Dienst nimmt dir etwa ein Drittel der Betriebsaufgaben ab, nämlich den technisch anspruchsvollsten Teil. Zwei Drittel bleiben in beiden Modellen gleich. Wenn dein Team heute mit Ingress, Speicherklassen und Zertifikaten kämpft, löst ein Wechsel zu EKS oder AKS dieses Problem nicht. Die Frage, ob du überhaupt einen Cluster brauchst, gehört deshalb vor diese Entscheidung, und wir behandeln sie getrennt unter Brauche ich Kubernetes.

02

Schritt 2: Kosten über drei Jahre gegenrechnen

Bevor du vergleichst, brauchst du deine echte Rechnung, aufgeschlüsselt nach Diensten. Die Zahl im Kopf ist immer zu niedrig, weil Egress, Load Balancer und NAT selten mitgedacht werden.

Ist-Kosten je Dienst ziehen, AWS und Azure
# AWS: Vormonat nach Dienst aufgeschluesselt
aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE \
  --output table

# AWS: Datenverkehr und NAT sichtbar machen
aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Compute Cloud - Compute"]}}'

# Azure: Verbrauch im Zeitraum, danach in der Tabellenkalkulation gruppieren
az consumption usage list \
  --start-date 2026-06-01 --end-date 2026-06-30 \
  --query "[].{dienst:consumedService,menge:quantity,kosten:pretaxCost}" \
  --output tsv

Interessant sind vier Zeilen: Knoten, Blockspeicher, Load Balancer und alles mit DataTransfer oder NatGateway im Namen. Diese vier machen in der Regel über neunzig Prozent der Clusterkosten aus. Die Control Plane taucht als kleiner Fixposten auf und ist nie der Grund für eine hohe Rechnung.

Was auf die Seite des Eigenbetriebs gehört

  • Hardware inklusive Abschreibung über drei bis fünf Jahre, plus Ersatzteile und Wartungsvertrag.
  • Strom, Kühlung, Fläche und Netzanbindung, im eigenen Haus oder als Colocation-Rechnung.
  • Personalzeit für Betrieb und Bereitschaft, zum internen Stundensatz und nicht als Restposten.
  • Einmalige Aufbaukosten: Automatisierung, Sicherungskonzept, Monitoring, Schulung des Teams.
  • Das Risiko, dass genau eine Person den Cluster versteht, und was ein Ausfall dieser Person kostet.
03

Schritt 3: Das Versionsfenster einmal durchspielen

Kubernetes veröffentlicht drei Minor-Releases im Jahr, jedes wird rund vierzehn Monate lang mit Patches versorgt. Das bedeutet zwei bis drei Upgrades pro Jahr, in beiden Modellen. Der Unterschied liegt im Aufwand je Upgrade.

Verfügbare Versionen und aktuellen Stand abfragen
# AWS EKS
aws eks describe-cluster --name prod --region eu-central-1 \
  --query 'cluster.{version:version,status:status,platform:platformVersion}'
aws eks describe-addon-versions --kubernetes-version 1.33 \
  --addon-name vpc-cni --query 'addons[].addonVersions[].addonVersion'

# Azure AKS
az aks get-versions --location germanywestcentral --output table
az aks show -g rg-prod -n aks-prod --query "{version:kubernetesVersion,pools:agentPoolProfiles[].orchestratorVersion}"

# Google GKE
gcloud container get-server-config --region europe-west3
gcloud container clusters describe prod --region europe-west3 \
  --format='value(currentMasterVersion)'

Wichtig ist der Abgleich zwischen Control Plane und Knotenpools. Kubernetes erlaubt einen Versionsversatz von maximal drei Minor-Versionen zwischen Kubelet und API-Server, praktisch solltest du nie mehr als eine Version auseinanderliegen. Erst Control Plane, dann Knotenpools, nie umgekehrt.

Upgrade auslösen, verwaltet und selbst betrieben
# Verwaltet: eine Zeile, der Anbieter erledigt den Rest
aws eks update-cluster-version --name prod --kubernetes-version 1.33 --region eu-central-1
az aks upgrade -g rg-prod -n aks-prod --kubernetes-version 1.33.2 --control-plane-only

# Eigenbetrieb mit kubeadm: pro Knoten, in dieser Reihenfolge
kubeadm upgrade plan
kubeadm upgrade apply v1.33.2

kubectl drain node02 --ignore-daemonsets --delete-emptydir-data --timeout=300s
apt-mark unhold kubeadm kubelet kubectl
apt-get update && apt-get install -y kubeadm=1.33.2-1.1
kubeadm upgrade node
apt-get install -y kubelet=1.33.2-1.1 kubectl=1.33.2-1.1
apt-mark hold kubeadm kubelet kubectl
systemctl daemon-reload && systemctl restart kubelet
kubectl uncordon node02

Die zweite Hälfte ist der ehrliche Preis des Eigenbetriebs: dieselbe Sequenz für jeden Knoten, mit Wartungsfenster, mit Blick auf PodDisruptionBudgets und mit einem Plan für den Fall, dass ein Knoten nach dem Neustart nicht zurückkommt.

04

Schritt 4: Eigenbetrieb heißt etcd, Zertifikate und Quorum

Wenn du selbst betreibst, übernimmst du drei Aufgaben, die im verwalteten Dienst unsichtbar sind. Sie fallen selten auf, bis sie ausfallen.

etcd sichern und Zertifikatslaufzeiten prüfen
# etcd-Sicherung vom Control-Plane-Knoten
ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /var/backups/etcd-$(date +%F).db

ETCDCTL_API=3 etcdctl snapshot status /var/backups/etcd-$(date +%F).db -w table

# Gesundheit des Quorums
ETCDCTL_API=3 etcdctl endpoint status --cluster -w table

# Wann laufen die Zertifikate aus?
kubeadm certs check-expiration

Die Zertifikate der Control Plane laufen standardmäßig nach einem Jahr aus. kubeadm upgrade erneuert sie nebenbei, wer also regelmäßig aktualisiert, merkt davon nichts. Wer ein Jahr lang nichts anfasst, steht irgendwann vor einem Cluster, an dem sich niemand mehr anmelden kann.

Bevor ein selbst betriebener Cluster produktiv geht

  • Drei Control-Plane-Knoten, nicht zwei.etcd braucht ein ungerades Quorum. Mit zwei Knoten fällt der Cluster beim ersten Ausfall komplett aus, statt weiterzulaufen.
  • etcd-Sicherung automatisiert, verschlüsselt und außerhalb des Clusters abgelegt.Eine Sicherung auf demselben Cluster ist keine. Wenn etcd verloren geht, ist ohne externen Snapshot der gesamte Zustand weg, inklusive aller Objekte, die nie in Git standen.
  • Rückspielen einmal in einer Testumgebung durchgeführt und dokumentiert.Eine ungetestete Wiederherstellung ist eine Vermutung. Der Ernstfall ist der schlechteste Zeitpunkt, um zu lernen, dass der Snapshot unvollständig war.
  • Wartungsfenster für zwei bis drei Upgrades pro Jahr fest im Kalender.Ohne festen Termin verschiebt sich das Upgrade, bis die Version aus der Pflege fällt. Danach gibt es keine Sicherheitspatches mehr.
  • Mindestens zwei Personen, die die Wiederherstellung beherrschen.Ein Cluster, den genau eine Person versteht, ist ein Betriebsrisiko und blockiert Urlaub, Krankheit und Kündigung gleichermaßen.
  • Monitoring auf Zertifikatslaufzeit, etcd-Größe und Knotenzustand.Alle drei fallen nicht schlagartig aus, sondern kündigen sich an. Ohne Alarm bemerkst du sie erst, wenn der Cluster nicht mehr antwortet.
05

Schritt 5: Den Wechsel zwischen beiden Modellen offenhalten

Beide Entscheidungen sind revidierbar, solange deine Arbeitslasten nichts benutzen, was es nur bei einem Anbieter gibt. Der Test dafür dauert zehn Minuten.

Anbieterspezifische Bausteine im Cluster finden
# Speicher- und Ingress-Klassen: woher kommen sie?
kubectl get storageclass -o custom-columns=NAME:.metadata.name,PROVISIONER:.provisioner
kubectl get ingressclass -o wide

# Objekte, die es nur beim Anbieter gibt
kubectl api-resources --api-group=eks.amazonaws.com
kubectl api-resources | grep -Ei 'azure|aws|gke|elbv2'

# Dienste vom Typ LoadBalancer und ihre Annotationen
kubectl get svc -A -o json | \
  jq -r '.items[] | select(.spec.type=="LoadBalancer") | "\(.metadata.namespace)/\(.metadata.name): \(.metadata.annotations // {} | keys | join(","))"'

Jede Annotation mit service.beta.kubernetes.io/aws- oder service.beta.kubernetes.io/azure- ist ein Punkt, den du beim Wechsel anfassen musst. Das ist kein Grund, sie zu vermeiden, aber du solltest die Liste kennen und kurz halten.

Der stärkste Hebel für Portabilität ist nicht Verzicht, sondern Trennung. Halte alles, was anbieterspezifisch ist, an einer Stelle: Speicherklassen, Ingress-Konfiguration, Identitäten für Arbeitslasten und die Anbindung an Secret-Speicher. Der Rest deiner Manifeste bleibt dann austauschbar. Wenn die Infrastruktur selbst ohnehin als Code beschrieben ist, wird der Wechsel zu einer Frage von Modulen statt von Klickwegen, und genau dort setzt der Vergleich der Infrastructure-as-Code-Werkzeuge an.

Passende Kurse

Kurse zu Kubernetes-Betrieb und verwalteten Clustern bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.

Kubernetes Grundkurs 3 Tage Präsenz oder Live-Online nächster Termin 03.08.2026 Garantietermin Zum Kurs GCP-Schulung: Google Cloud Associate Cloud Engineer 3 Tage Präsenz nächster Termin 28.09.2026 Zum Kurs AZ-104 Training: Microsoft Azure Administrator (AZ-104T00) 4 Tage Präsenz nächster Termin 07.09.2026 Garantietermin Zum Kurs OpenStack-Schulung: Private und Sovereign Cloud 4 Tage Präsenz oder Live-Online Termine auf Anfrage Zum Kurs Kubernetes Aufbaukurs: Air-Gapped Kubernetes 3 Tage Präsenz nächster Termin 09.09.2026 Zum Kurs Cloud Operations on AWS 3 Tage Präsenz nächster Termin 14.09.2026 Zum Kurs
Unverbindlich beraten lassen Alle Cloud-Native-Kurse ansehen
Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Wissenstest Kubernetes Grundlagen Quiz Teste dein Wissen zu Pods, Deployments, Services, ConfigMaps, kubectl und der Cluster-Architektur. Quiz starten
Gut zu wissen

Häufige Fragen zu Kubernetes-Betrieb und verwalteten Clustern

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Was kostet die Control Plane bei EKS, AKS und GKE?
Alle drei Anbieter verlangen für die verwaltete Control Plane rund 0,10 US-Dollar pro Cluster und Stunde, das sind gut 70 Euro im Monat. Bei AKS gibt es zusätzlich eine kostenlose Stufe ohne zugesicherte Verfügbarkeit für die Control Plane, die für Test- und Lernumgebungen reicht, für Produktion aber nicht gedacht ist. Entscheidend ist, dass dieser Betrag im Vergleich zu Knoten, Blockspeicher, Load Balancern und Datenverkehr klein ist. Wer wegen der Control-Plane-Gebühr über Eigenbetrieb nachdenkt, spart an der falschen Stelle.
Wie viele Betriebsstunden muss ich für einen eigenen Cluster einplanen?
Für einen kleinen Produktivcluster nennen Anbieter- und Beratungsvergleiche acht bis fünfzehn Stunden im Monat. Darin stecken zwei bis drei Kubernetes-Upgrades im Jahr, Betriebssystempflege der Knoten, etcd-Sicherung mit geprüftem Rückspielen, Zertifikatsrotation und die Fehlersuche, wenn nach einem Update etwas nicht mehr startet. Der Wert steigt nicht linear mit der Clustergröße, sondern mit der Anzahl der Cluster. Wer fünf gleichartige Cluster automatisiert betreibt, kommt pro Cluster deutlich günstiger weg als jemand mit einem Einzelstück.
Ist ein verwalteter Cluster in einer deutschen Region datenschutzkonform nutzbar?
Die Region allein entscheidet das nicht. Sie legt fest, wo die Daten gespeichert und verarbeitet werden, und sowohl AWS mit Frankfurt als auch Azure mit Deutschland West-Mitte und Deutschland Nord bieten deutsche Standorte an. Dazu brauchst du einen Auftragsverarbeitungsvertrag, eine dokumentierte Bewertung des Drittlandtransfers und passende technische Maßnahmen, etwa Verschlüsselung mit eigenen Schlüsseln. Wenn zusätzlich ein Nachweis über die Sicherheit des Anbieters gefordert ist, führt der Weg über ein Testat, siehe dazu unsere Seite zu BSI C5.
Sind k3s oder ein Zwei-Knoten-Cluster eine ernsthafte Option?
Für Randstandorte, Testumgebungen und kleine interne Dienste ja, k3s ist ein vollwertiges Kubernetes mit deutlich kleinerem Fußabdruck. Für produktive Dienste mit Verfügbarkeitszusage nein, jedenfalls nicht mit zwei Knoten. etcd braucht ein ungerades Quorum, sonst führt der Ausfall eines Knotens zum Ausfall des gesamten Clusters. Wenn du klein bleiben willst, ist entweder ein Einzelknoten mit klar kommuniziertem Wartungsfenster oder ein Aufbau mit drei Control-Plane-Knoten die ehrliche Wahl.
Wie aufwendig ist ein späterer Wechsel zwischen den Modellen?
Die Arbeitslasten selbst ziehen meist problemlos um, weil Deployments, Services und ConfigMaps überall gleich aussehen. Aufwand entsteht an vier Stellen: Speicherklassen und die Daten darauf, Ingress und Zertifikate, Identitäten für Arbeitslasten samt Anbindung an Secret-Speicher sowie alles, was über Annotationen an Load Balancer des Anbieters gekoppelt ist. Wenn du diese vier Punkte bewusst an einer Stelle hältst und regelmäßig prüfst, bleibt der Wechsel ein Projekt von Wochen statt von Quartalen.

Quellen

Zuletzt geprüft am 26. Juli 2026.

Weiterlesen

Verwandte Cloud-Themen

Alle Cloud-Themen im Überblick
Entscheidung & Vergleich Brauchst du wirklich Kubernetes? Eine ehrliche Entscheidungshilfe Ansehen Betrieb & Kosten Kubernetes-Kosten senken: Wo das Geld im Cluster wirklich verschwindet Ansehen Betrieb & Kosten Kubernetes ohne Internetzugang betreiben: Air-Gapped-Cluster in regulierten Umgebungen Ansehen Entscheidung & Vergleich Souveräne Cloud: Welche Angebote es gibt und was Souveränität wirklich bedeutet Ansehen
Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

“
Der Kursinhalt entsprach voll meinen Erwartungen, die richtige Mischung aus Theorie und Praxis.
Rückmeldung aus dem Kurs „Kubernetes Grundkurs“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Cloud-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail
Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

0800 71 20000 E-Mail
Nächster Schritt

Modell entschieden, jetzt das Team dahinter aufbauen

Beide Wege stehen und fallen mit dem Kubernetes-Wissen im Team. Der Kubernetes Grundkurs legt die gemeinsame Grundlage, danach geht es entweder in Richtung verwalteter Dienst mit den Kursen zu Amazon EKS, Google Cloud und Azure oder in Richtung Eigenbetrieb mit dem Aufbaukurs zu Air-Gapped Kubernetes und der OpenStack-Schulung. Wenn du bei der Entscheidung noch schwankst, sprich uns an, wir schauen uns deine Ausgangslage gemeinsam an und sagen dir ehrlich, welches Modell zu deinem Team passt.

Beratung anfragen 0800 71 20000