Kubernetes Networking Vertiefung — Service Discovery, DNS und Ingress-Pfadregeln

Dieses Modul setzt das Aufbaumodul Kubernetes Workloads & Konfiguration — die Objekte für den Alltag voraus. Service-Grundlagen (die vier Service-Typen ClusterIP/ NodePort/LoadBalancer/ExternalName) sowie readinessProbe als Konzept werden dort erklärt und hier nicht erneut eingeführt – dieses Vertiefungsmodul beginnt direkt bei dem, was hinter einem Service steckt.

Einfaches Host-basiertes Routing wird hier nicht wiederholt, siehe Kursseite Docker & Kubernetes: Vom Compose-Stack zum lokalen Cluster, wo es bereits live ist. Dieses Modul vertieft ausschließlich Pfad-basiertes Routing, die Kombination aus Host und Pfad sowie die pathType-Semantik.

Wer stattdessen die Betreiber-Perspektive einnehmen will – Namespace/ResourceQuota, RBAC, Cluster-Netzwerk-Grundmodell (CNI/kube-proxy/CoreDNS/NetworkPolicy), Node-Administration und High Availability als Konzept – findet das im gleichrangigen, unabhängigen Schwestermodul Kubernetes Administration — RBAC, Node-Betrieb und Cluster-Netzwerk. Wer stattdessen die Anwendungsdesign-Perspektive einnehmen will – Multi-Container-Pod-Patterns, Job/CronJob für Batch-Workloads sowie securityContext und ServiceAccount – findet das im weiteren Schwestermodul Kubernetes Anwendungsdesign — Multi-Container-Patterns, Jobs & Security Context. Wer stattdessen die Storage-Perspektive einnehmen will – emptyDir und hostPath im Vergleich zu PersistentVolume, PersistentVolumeClaim mit Binding-Regel, AccessModes und StorageClass – findet das im weiteren Schwestermodul Kubernetes Storage — Volumes, PersistentVolumes & Claims. Wer stattdessen wissen will, wie sich eine bereits laufende Anwendung diagnostizieren lässt – Prometheus-Scrape-Annotationen, Ephemeral Containers per kubectl debug und die dreistufige Service-Troubleshooting-Kette Port-Forward → Endpoints → DNS-Test-Pod – findet das im weiteren Schwestermodul Kubernetes: Monitoring & Troubleshooting. Dieses Modul liest kubectl get endpoints dort nur als Diagnose-Schritt, ohne die hier behandelten EndpointSlice-Interna zu vertiefen. Wer stattdessen wissen will, wie viel ein Container verbrauchen darf – requests/limits, die drei QoS-Klassen sowie der HorizontalPodAutoscaler – findet das im weiteren Schwestermodul Kubernetes Ressourcenmanagement & Autoscaling — Requests, Limits und HorizontalPodAutoscaler. Wer stattdessen wissen will, wie sich diese Objekte als wiederverwendbares Paket versionieren und verteilen lassen – Chart-Struktur, values.yaml und Release-Verwaltung – findet das im weiteren Schwestermodul Helm — Paketmanagement für Kubernetes. Alle sieben Vertiefungsmodule setzen nur “Kubernetes Workloads & Konfiguration” voraus, nicht sich gegenseitig.

Wer Headless Services und SRV-Records aus diesem Modul mit einem Workload-Typ kombinieren will, der genau darauf aufbaut – stabile, geordnete Pod-Identität statt austauschbarer Pods, automatisches Pro-Replica-PVC-Provisioning über volumeClaimTemplates und geordnetes Scaling über podManagementPolicy – findet das im Aufbaumodul Kubernetes StatefulSets — Stabile Identität für zustandsbehaftete Workloads, das dieses Modul und “Kubernetes Storage” gemeinsam voraussetzt.

Wer stattdessen wissen will, wie sich Layer-7-Traffic exakt und pod-zahl-unabhängig steuern lässt – ein Service Mesh mit Envoy-Sidecar-Proxy statt kube-proxy-Routing auf Layer 4 – findet das im Aufbaumodul Kubernetes Service Mesh — Traffic-Management mit Istio, das dieses Modul und “Kubernetes Progressive Delivery — Canary & Blue-Green mit Argo Rollouts” gemeinsam voraussetzt.