Zum Inhalt springen
Betaleser gesucht. Die deutsche Ausgabe ist übersetzt. Sie erscheint, sobald ich Rückmeldungen von einigen Betalesern habe. Wenn du dabei sein willst, sag mir Bescheid: eröffne ein Issue auf GitHub · schreib mir auf X.
Cover von Kubernetes 101: fast schwarzer blauer Hintergrund, der Titel in Weiß, die Zahl 101 in Kubernetes-Blau und der Name Javier Vela Aylón am unteren Rand.

Buch · Deutsche Ausgabe · 2026

Kubernetes 101 – der praktische Leitfaden, um Kubernetes von Grund auf zu verstehen

15 Kapitel, 5 Anhänge und ein Praxisteil mit 55 Labs auf einem echten Cluster, ohne etwas zu installieren. Du liest das Konzept und probierst es sofort aus.

381 Seiten · Ausgabe 2026 · Kubernetes 1.37 · Kindle und Taschenbuch

Für wen

Für wen ist dieses Buch?

Für alle, die Kubernetes wirklich lernen wollen, ob sie aus der IT-Welt kommen oder nicht. Und auch – vor allem – für die, die schon täglich mit der Technologie arbeiten und nie ganz verstehen, was unter der Haube passiert.

Es ist das Buch, das ich vor ein paar Jahren gern gelesen hätte: mit Diagrammen, die erklären, wer was tut, und mit einem Praxisteil, in dem du ohne Angst Dinge kaputt machen kannst.

Der Prolog

Leser

Was die sagen, die es schon gelesen haben

Inhalt

Was du lernen wirst

Jedes Kapitel hat sein Lab, und der Anhang D auch. Dazu kommt ein Block, der nur als Lab existiert: die finale Challenge.

  • Kapitel im Buch
  • Praxis-Lab
Kapitel 01

Einführung in Container und Orchestrierung

Image, Container, Controller und Node, erklärt, bevor Kubernetes überhaupt beim Namen genannt wird. Wie das Image gebaut wird, das im ganzen Buch ausgerollt wird: Multistage-Dockerfile, Distroless-Basis und ein Prozess, der nicht als root läuft. Und die echten Vor- und Nachteile von Containern, samt dem, was kompliziert wird, wenn du sie im großen Maßstab orchestrierst.

Sein Lab ist das Modul „Container“: Du baust das Image tienda/api und veröffentlichst es in der Registry.

  • Kapitel im Buch
  • Praxis-Lab
Kapitel 02

Kubernetes-Architektur

Der kube-apiserver und das kubelet, und die Hub-and-Spoke-Kommunikation: warum alles über den API-Server läuft und nur er mit etcd spricht. Die übrigen Komponenten kommen dort dran, wo sie wirklich gebraucht werden – kube-proxy im Netzwerk, der Scheduler im Scheduling – und alle zusammen, am Ende, im Anhang D.

Sein Lab ist das Modul „Der Cluster von innen“, auf einem echten kubeadm-Cluster, zusammen mit dem Anhang D.

  • Kapitel im Buch
  • Praxis-Lab
Kapitel 03

Mit dem Cluster sprechen

Warum kubectl nicht Kubernetes ist, sondern ein HTTP-Client gegen den API-Server, und wie du das mit --v siehst. Der leere Namespace tienda, der erste Pod web darin, in ihn hineinschauen, seine Logs lesen und ihn löschen. Es ist das Kapitel, in dem es noch egal ist, wenn du nicht ganz verstehst, was du ausrollst.

Teilt sich das Lab mit Kapitel 04, im Modul „Grundlagen“.

  • Kapitel im Buch
  • Praxis-Lab
Kapitel 04

Kubernetes-Objekte

Der erste Pod, Namespaces, Labels und Selektoren, und Annotations: wie das, was im Cluster lebt, benannt und gruppiert wird. Und warum die Liste der Typen, die ein Cluster versteht, nicht eingefroren ist – die Tür zum Kapitel Erweiterbarkeit.

Teilt sich das Lab mit Kapitel 03, im Modul „Grundlagen“.

  • Kapitel im Buch
  • Praxis-Lab
Kapitel 05

Workloads

Pods mit Probes, requests, limits und QoS. ReplicaSets, Deployments mit Rollout und Rollback, StatefulSets, DaemonSets, Jobs und CronJobs.

  • Kapitel im Buch
  • Praxis-Lab
Kapitel 06

Skalierung

Autoscaling von Nodes (Cluster Autoscaler und Karpenter) und von Pods: Horizontal Pod Autoscaler und Vertical Pod Autoscaler, was jeder misst und wann sie sich gegenseitig in die Quere kommen.

  • Kapitel im Buch
  • Praxis-Lab
Kapitel 07

Netzwerk

kube-proxy und die Regeln, die dafür sorgen, dass die IP eines Service bei einem Pod landet. Services und internes DNS mit CoreDNS, Ingress, Gateway API – der Ingress wird abgerissen und neu gebaut – und NetworkPolicy, um den Traffic auf Schicht 3 und 4 zu sperren.

  • Kapitel im Buch
  • Praxis-Lab
Kapitel 08

Konfiguration

ConfigMaps für das, was nicht vertraulich ist, und Secrets für das, was es ist, konsumiert als Umgebungsvariablen oder als Dateien, die im Pod gemountet werden. imagePullSecrets, um Images aus einer privaten Registry herunterzuladen, und die Downward API, damit der Pod weiß, wer er ist und wo er läuft.

  • Kapitel im Buch
  • Praxis-Lab
Kapitel 09

Storage

StorageClass, PersistentVolume und PersistentVolumeClaim mit CSI-Provisionern, wie ein Pod am Ende die Platte mountet, die er nicht verlieren darf, und VolumeSnapshot für die Backups.

  • Kapitel im Buch
  • Praxis-Lab
Kapitel 10

Sicherheit

Authentifizierung und Autorisierung gegenüber der API, RBAC und ServiceAccounts, die Admission-Kette, securityContext und die Pod Security Standards, die PSA pro Namespace durchsetzt. Und was der securityContext nicht schützt: die Supply Chain, mit SBOM und Signatur per cosign.

  • Kapitel im Buch
  • Praxis-Lab
Kapitel 11

Policies

ResourceQuota und LimitRange: das CPU- und Speicherbudget eines Namespace und die Standardwerte für jeden Container.

  • Kapitel im Buch
  • Praxis-Lab
Kapitel 12

Scheduling

Taints und Tolerations, nodeSelector, Affinitäten und nodeName; Priorität und Preemption, PodDisruptionBudgets und Dynamic Resource Allocation.

  • Kapitel im Buch
  • Praxis-Lab
Kapitel 13

Arbeiten mit dem Cluster

Kontexte und Namespaces, die Einstellungsdatei kuberc, vier Fallen, die immer wieder zuschnappen, was Kustomize bringt und was Helm bringt, GitOps mit Argo CD und Flux, und wo du hinschaust, wenn in der tienda, dem Beispielsystem des Buchs, etwas kaputtgeht. Die komplette Befehlsreferenz lebt im Anhang E.

  • Kapitel im Buch
  • Praxis-Lab
Kapitel 14

Erweiterbarkeit

Die CRD, die dem Cluster ein neues Wort beibringt – die Promocion der tienda – und der Operator, der dafür sorgt, dass es etwas bedeutet: die Kontrollschleife (reconciliation loop), was der status verrät und wann du keinen Operator schreiben solltest. Im Lab schreibst du ihn komplett, in Go und mit controller-runtime.

  • Kapitel im Buch
  • Praxis-Lab
Kapitel 15

Observability

Die Events des Clusters, Metriken, Logs und Traces – Prometheus, Loki, Grafana –, welches der vier du zuerst anschaust, und die aufkommende Observability mit eBPF.

  • Kapitel im Buch
  • Praxis-Lab

Und ein Block, der nur als Lab existiert

Er steckt im Praxisteil und ist kostenlos zugänglich, hat aber kein zugehöriges Kapitel im Buch. Braucht er auch nicht: Es gibt nichts Neues zu lernen, er ist die Prüfung über alles davor.

Nur im Praxisteil

Finale Challenge: Schalte den Scheduler ab

Diagnostiziere den Cluster am offenen Herzen, ohne Scheduler, und hol ihn ins Leben zurück. Was aufhört zu funktionieren und was weiterläuft – und das ist nicht das, was fast alle erwarten.

Und fünf Anhänge

Anhang A

Abkürzungsglossar

Die 74 Abkürzungen, die im Buch vorkommen, in einer Tabelle gesammelt, um sie auf einen Blick nachzuschlagen. Vollständig veröffentlicht im Glossar der Website (auf Spanisch).

Anhang B

Das komplette System

Alles, was Kapitel für Kapitel gebaut wurde, zusammen und in der Reihenfolge, in der du sie anwendest: über sechshundert Zeilen YAML, die du nicht von einem Blatt Papier abtippst, sondern die im Code-Repository leben.

Anhang C

Seit wann welches Teil funktioniert

Kapitel für Kapitel, welche Funktionen das Buch datiert und seit welcher Version es sie gibt, damit du auf einen Blick prüfen kannst, ob das, was du liest, in deinem Cluster noch gilt. Alles bezogen auf Kubernetes 1.37.

Anhang D

Der Cluster von innen

Der Maschinenraum, am Ende und nicht am Anfang: etcd, der controller-manager, der cloud-controller-manager, wie Container wirklich ausgeführt werden – CRI, Runtimes und OCI – und die Leases. Es ist der einzige Anhang mit eigenem Lab, auf einem echten kubeadm-Cluster.

  • Praxis-Lab
Anhang E

kubectl-Spickzettel

Die ganze Befehlsreferenz, sortiert nach dem, was du tun willst, und nicht nach Verb: sich orientieren, den Cluster anschauen, in einen Pod hineinschauen, von Hand ändern, mit Dateien ändern, Nodes und Wartung, Berechtigungen und Audit, und Helm.

Im Buch enthalten

Der Praxisteil: 55 Labs in 15 Modulen

15 Module, 53 Einheiten und 7 Challenges: Schritt-für-Schritt-Tutorials mit erklärtem YAML, und Challenges, bei denen du einen Cluster bekommst, in dem etwas kaputt ist, und ihn reparieren musst.

Ein echter Kubernetes-Cluster im Browser, in Sekunden bereit. Nichts zu installieren, nichts zu konfigurieren und keine Zusatzkosten. Der Praxisteil ist öffentlich und kostenlos: kein Code, kein Gutschein, nichts zu validieren. Du brauchst das Buch nicht, um anzufangen: Die Labs erklären sich selbst. Was das Buch hinzufügt, ist das Warum – woher jede Entscheidung kommt und was still kaputtgeht, wenn du sie nicht triffst – plus die 54 Diagramme und die fünf Anhänge, die in kein Terminal passen.

Ein Blick hinein

Diagramme aus dem Buch

Jedes Konzept wird mit einem Diagramm erklärt, das zeigt, wer was tut und warum. Sechs der vierundfünfzig, die du drinnen findest; klick auf eines, um es in voller Größe zu sehen.

  • Diagramm der Architektur eines Clusters: links die Control Plane mit kube-apiserver, etcd, kube-scheduler und kube-controller-manager; rechts die Worker-Nodes mit kubelet, kube-proxy und der Container-Runtime. Alle Pfeile von den Nodes zeigen auf den kube-apiserver, und nur der kube-apiserver spricht mit etcd.

    Grundlagen · Diagramm 1 von 6

    Cluster-Architektur

    Control Plane und Worker-Nodes: wer mit wem spricht, und warum der kube-apiserver die einzige Eingangstür zu etcd ist.

  • Hierarchisches Diagramm: oben ein Deployment, darunter zwei ReplicaSets (die alte Revision schrumpft auf null, die neue wächst) und unter jedem seine Pods. Die Pfeile zeigen das Rolling Update und den Rollback auf die vorherige Revision.

    Workloads · Diagramm 2 von 6

    Deployments, Rollout und Rollback

    Ein Deployment verwaltet ein ReplicaSet pro Revision: So macht es Rolling Updates und geht ohne Downtime zurück.

  • Vergleichsdiagramm der Service-Typen: ClusterIP, NodePort und LoadBalancer. Es zeigt den Weg des Traffics von außen bis zu den Pods, über kube-proxy und die EndpointSlices, die angeben, welche Pods bereit sind.

    Netzwerk · Diagramm 3 von 6

    Services und Routing

    ClusterIP, NodePort und LoadBalancer: wie der Traffic über kube-proxy und die EndpointSlices zu den Pods gelangt.

  • Diagramm mit mehreren Nodes, die mit Taints markiert sind, und Pods mit und ohne Tolerations. Es zeigt das Ergebnis jeder Kombination je nach Effekt des Taints: NoSchedule, PreferNoSchedule und NoExecute.

    Scheduling · Diagramm 4 von 6

    Taints und Tolerations

    Wie du Pods zu bestimmten Nodes hin- oder von ihnen weglenkst, mit den drei möglichen Effekten eines Taints.

  • Diagramm der Observability-Architektur: Die Pods stellen Metriken bereit, die Prometheus im Pull-Modus einsammelt, die Logs wandern im Push-Modus zu Loki und die Traces werden in Spans gruppiert. Die drei Flüsse laufen in Grafana als Visualisierungsschicht zusammen.

    Observability · Diagramm 5 von 6

    Metriken, Logs und Traces

    Die drei Säulen werden getrennt gesammelt und laufen in Grafana zusammen, mit Prometheus, Loki und Traces.

  • Diagramm der Kontrollschleife eines Operators: Der Watch meldet eine Änderung an der Ressource, der Operator liest Soll-Zustand und Ist-Zustand erneut, handelt, um sie einander anzunähern, und schreibt das Ergebnis in den status. Die Meldung und das Lesen des Zustands sind zwei verschiedene Pfeile.

    Erweiterbarkeit · Diagramm 6 von 6

    Die Kontrollschleife

    Warum ein Operator nicht auf die Meldung hin handelt, sondern erneut liest: Es ist egal, ob zwei Meldungen zusammen ankommen oder eine verloren geht.

1 / 6

Wie sich eine Seite liest

239 Fragen, direkt unter dem YAML

Fast alle Fachbücher zeigen das Manifest, erklären drei Felder und machen weiter. Die anderen neun bleiben einfach stehen. Hier steht unter jedem Manifest, was man sich beim ersten Lesen fragt, samt Antwort: kein Test am Kapitelende, sondern die Antwort dort, wo die Frage auftaucht. Vier Seiten der spanischen Druckausgabe, genau so, wie sie gedruckt sind.

  • Seite 48 der spanischen Druckausgabe. Oben das Ende des YAML-Manifests des Pods web. In der Mitte die Erklärung Feld für Feld: apiVersion, kind, metadata.name, metadata.namespace, metadata.labels, spec und spec.containers. Unten drei Fragen in Fettdruck mit ihrer Antwort: warum apiVersion v1 ist und nicht apps/v1, was passiert, wenn der namespace nicht angegeben wird, und ob zwei Objekte denselben name haben können.

    Kapitel 4 · Kubernetes-Objekte · Seite 48

    Das erste Manifest, Zeile für Zeile

    Zwölf Zeilen YAML, Feld für Feld erklärt, und dann drei Fragen: warum ist apiVersion v1 und nicht so etwas wie apps/v1? · was passiert, wenn ich den namespace nicht angebe? · kann ich zwei Objekte mit demselben name haben?

  • Seite 49 der spanischen Druckausgabe. Oben zwei Fragen mit Antwort zum status und zu den Labels. Danach der Abschnitt Namespaces, mit den vier Namespaces, die Kubernetes ab Werk mitbringt, dem YAML-Manifest des Namespace tienda und der Frage, welche Ressourcen nicht namespaced sind.

    Kapitel 4 · Kubernetes-Objekte · Seite 49

    Namespaces, und was sie nicht isolieren

    Die Frage, die die meisten falsch beantworten, steht auf dieser Seite: isolieren Namespaces den Netzwerk-Traffic? Nein. Sie trennen Namen und Berechtigungen, keine Pakete; um Traffic zu isolieren, brauchst du eine NetworkPolicy, und die kommt drei Kapitel später.

  • Seite 132 der spanischen Druckausgabe. Oben das Ende eines Manifests, das 2 CPU und 4 GiB reserviert. Danach drei Fragen mit Antwort dazu, wo der Fehler steckt, wenn das Manifest keinen Fehler auslöst, warum es eine Rolle spielt, wenn im Cluster Platz übrig ist, und warum man die Zahlen nicht von Hand korrigiert. Unten das YAML-Manifest des VerticalPodAutoscalers des Deployments holgazan.

    Kapitel 6 · Skalierung · Seite 132

    Das Manifest, das keinen Fehler auslöst

    Es fordert 2 CPU und 4 GiB an und nutzt ein Zehntel davon. Kein rotes Event, kein Pod in Pending: nur ein Drittel der Quota des Namespace, verpulvert für nichts. Es ist der teuerste Fehler in Kubernetes, gerade weil er nicht wie ein Fehler aussieht.

  • Seite 261 der spanischen Druckausgabe. YAML-Manifest eines PodDisruptionBudgets für das Deployment web, gefolgt von zwei Fragen mit Antwort: warum das PDB nicht innerhalb des Deployments deklariert wird, und was passiert, wenn man minAvailable gleich der Anzahl der Replikate setzt.

    Kapitel 12 · Scheduling · Seite 261

    Der Schutz, der die Wartung blockiert

    Was passiert, wenn ich minAvailable: 3 mit nur 3 Replikaten setze? Du blockierst jede freiwillige Eviction, das Leerräumen von Nodes eingeschlossen, und landest bei festgefahrenen Cluster-Upgrades.

1 / 4

Das Kapitel Workloads hat 45 Fragen und das Kapitel Sicherheit 42. Alle 239 verteilen sich auf die fünfzehn Kapitel, immer direkt beim Manifest, das sie auslöst.

Der Praxisteil

So funktionieren die Labs

  1. Schritt 1

    Lies das Kapitel

    Das Konzept, erklärt mit seinem Diagramm und seinen Beispielen, ohne etwas vorauszusetzen.

  2. Schritt 2

    Öffne das Lab

    Ein echter Cluster im Browser, in Sekunden bereit. Nichts auf deinem Rechner zu installieren.

  3. Schritt 3

    Repariere den kaputten Cluster

    Du diagnostizierst, du reparierst, und das Lab prüft deine Lösung. Du lernst durch Tun, nicht durch Auswendiglernen.

Eine Verschnaufpause

Was die Komponenten des Clusters sagen

Hier gibt es keine Rezensionen: Die hier unterschreiben die Kubernetes-Komponenten, die seit Jahren einiges aushalten. Es ist ein Scherz, aber jede Beschwerde stimmt.

  • „Seit Jahren bin ich die einzige Tür zu etcd, und niemand hat mich verstanden. Nach diesem Buch wissen sogar die neuen Pods, wie sie Dinge bei mir mit dem richtigen Namen anfordern.“
    kube-apiserver, Hüter des Clusters
  • „Ich speichere alles, aber den Raft-Konsens zu erklären war unmöglich. Das Grundlagenkapitel erzählt endlich meine Geschichte, ohne dass ein einziger Datensatz verloren geht.“
    etcd, Gedächtnis des Clusters
  • „Früher habe ich Pods blind platziert und bekam die Schuld für alles. Jetzt verstehen die Leser meine Affinitäten, Taints und Tolerations … und sogar die Challenge, mich abzuschalten.“
    kube-scheduler, der entscheidet, wo du wohnst
  • „Ich starte die ganze Nacht Container neu, ohne dass sich jemand bedankt. Dieses Buch erklärt meine Probes so gut, dass man mich jetzt besser behandelt.“
    kubelet, Wächter auf jedem Node
  • „Service-Namen in IPs zu übersetzen war mein stilles Kreuz. Mit dem Kapitel Netzwerk lösen sie endlich meine Fragen auf, bevor ich ihre auflöse.“
    CoreDNS, das Adressbuch des Clusters
1 / 5

Kostenlos, jetzt

Lade den Anfang des Buchs herunter

Abonniere den Blog und du bekommst den Anfang des Buchs komplett: „Bevor es losgeht“, das Kapitel Kubernetes-Architektur und den Anhang D: Der Cluster von innen.

Einunddreißig Seiten und alle acht Diagramme, genau so, wie sie im Buch stehen (vorerst die Seiten der spanischen Ausgabe; das deutsche PDF ersetzt sie). Es ist keine gekürzte Leseprobe: Es ist die Stelle, an der du anfängst, es zu lesen, und die, an der du den Maschinenraum endgültig verstehst.

Es ist die ehrlichste Art herauszufinden, ob dir das Buch etwas bringt, bevor du etwas bezahlst.

Wenn das Formular nicht lädt, abonniere auf blog.javivela.dev.

Bevor es losgeht

Häufige Fragen

Nein. Das Buch beginnt mit den Grundlagen von Containern und Orchestrierung, bevor es zu Kubernetes kommt, und setzt nichts voraus.

Nichts. Jedes Lab startet einen echten Kubernetes-Cluster im Browser; du brauchst nur eine Internetverbindung und ein Konto bei iximiuz Labs.

Ja. Es ist auch für alle gedacht, die die Technologie täglich benutzen und wirklich verstehen wollen, was unter der Haube passiert, mit den Diagrammen und den Challenges als Sicherheitsnetz.

Beides. Der Praxisteil ist in beiden Formaten derselbe und außerdem öffentlich zugänglich: Du kannst den Leitfaden zum Praxisteil öffnen, ohne das Buch zu besitzen. Kindle-Ausgabe und Taschenbuch gibt es bei Amazon.de und Amazon.com; von überall sonst bestellst du das Taschenbuch bei Amazon.com mit internationalem Versand.

Nein. Der Praxisteil ist öffentlich und kostenlos und erfordert keinen zusätzlichen Kauf. Er wird auf iximiuz Labs gehostet.

Die 15 Kapitel und die 5 Anhänge, ja. Es gibt nur einen Block, der ausschließlich als Lab existiert und kein Kapitel hat: die finale Challenge, und sie ist in der Inhaltsübersicht so markiert. Die Erweiterbarkeit hat sehr wohl ein eigenes Kapitel, Kapitel 14: Das Buch definiert die CRD und erklärt, was ein Operator tut; im Lab schreibst du ihn komplett, in Go.

Das Buch ist die Ausgabe 1.37. Kubernetes veröffentlicht drei Versionen im Jahr, kein Buch wird also je auf der neuesten sein: Deshalb enthält es den Anhang C, der Kapitel für Kapitel den Stand jeder Funktion festhält und seit welcher Version es sie gibt, damit du auf einen Blick prüfen kannst, ob das, was du gerade liest, in deinem Cluster noch gilt. Was die 1.37 mitbringt, ist in den Neuerungen von Kubernetes 1.37 (auf Spanisch) zusammengefasst, und spätere Korrekturen erscheinen auf der Errata-Seite.

Über den Autor

Javier Vela Aylón

Vom .NET-Entwickler zum Senior Software & Platform Engineer, mit über 20 Jahren Erfahrung im Aufbau und Betrieb von Plattformen. Zertifiziert in Azure und im CNCF-Ökosystem, Speaker bei DotNetters.

Ich schreibe über DevOps, Azure, AWS, CI/CD, Kubernetes, Container und Architektur auf blog.javivela.dev.

Code

Alle Manifeste des Buchs, auf GitHub

Das Repository versammelt die YAML-Dateien, die Beispiele und den Operator in Go genau so, wie sie in den Kapiteln und in den Labs vorkommen. Klon es, mach es kaputt und schick einen Pull Request, wenn du etwas findest, das sich verbessern lässt.

Kubernetes 101

Von einem nackten Pod zu einem System, das du verstehst

381 Seiten, 15 Kapitel, 5 Anhänge und 55 Labs auf einem echten Cluster. Auf Basis von Kubernetes 1.37, der Referenzversion des Buchs.