Kubernetes Enterprise

KAPITEL 10 · ENTERPRISE IT

Kubernetes Enterprise

Container-Orchestrierung für produktive Enterprise-Umgebungen – von Cluster-Architektur über Helm und GitOps bis zu Service Mesh, Security und Monitoring. Alles, was Sie für skalierbare, resiliente Anwendungen brauchen.

Pods & Services Helm Charts Service Mesh Security Observability

Was ist Kubernetes?

Definition

Kubernetes (oft abgekürzt als K8s) ist eine Open-Source-Plattform zur Orchestrierung von Container-Anwendungen. Ursprünglich von Google entwickelt und 2014 veröffentlicht, automatisiert Kubernetes das Deployment, die Skalierung und den Betrieb von containerisierten Anwendungen über Cluster von Host-Maschinen hinweg.

Im Enterprise-Umfeld ist Kubernetes der De-facto-Standard für die Verwaltung mikroservicebasierter Architekturen. Es bietet Selbstheilung (Self-Healing), automatische Skalierung, Rolling Updates ohne Downtime und deklarative Konfiguration. Unternehmen wie Netflix, Spotify, Airbnb und die NASA setzen auf Kubernetes für ihre kritischen Produktionsworkloads.

Warum Kubernetes im Enterprise? Traditionelle Deployment-Modelle stoßen bei hunderten von Microservices an Grenzen. Kubernetes löst dieses Problem durch Abstraktion der Infrastruktur – Entwickler definieren den gewünschten Zustand (Desired State), und Kubernetes sorgt kontinuierlich dafür, dass der tatsächliche Zustand (Actual State) diesem entspricht.

Wann lohnt sich Kubernetes?

  • Microservices-Architektur: Viele unabhängige Services orchestrieren
  • Skalierungsbedarf: Automatisch horizontal skalieren basierend auf Last
  • Multi-Cloud/Hybrid: Portabilität zwischen AWS, Azure, GCP und On-Premise
  • DevOps-Kultur: Self-Service-Plattform für Entwicklungsteams
  • Resilienz: Selbstheilende Systeme mit automatischem Failover

Nicht geeignet für: Einfache Monolithen, kleine Teams ohne DevOps-Expertise, statische Websites oder wenn Operational Overhead die Vorteile übersteigt.

Inhaltsverzeichnis

Schnellübersicht

Auf dieser Seite lernen Sie alles über Kubernetes im Enterprise-Einsatz:

  • Architektur: Control Plane, Worker Nodes, etcd, API Server
  • Core Concepts: Pods, Services, Deployments, ConfigMaps, Secrets
  • Enterprise Tools: Helm, ArgoCD, Istio, Prometheus, OPA
  • GitOps: Deklarative Infrastruktur mit Git als Single Source of Truth
  • Service Mesh: Traffic Management, Security, Observability
  • Security: RBAC, Network Policies, Pod Security Standards
  • Best Practices: Ressourcen, Scaling, Monitoring, Storage
  • FAQ: Häufige Fragen zu Kubernetes im Enterprise

1. Kubernetes-Architektur

Kubernetes besteht aus einer Control Plane (Master-Komponenten) und mehreren Worker Nodes, auf denen die Anwendungen laufen.

Kubernetes Cluster-Architektur

Control Plane

API Server

Zentrale Schnittstelle für alle Cluster-Operationen. Validiert und verarbeitet REST-Anfragen.

etcd

Verteilter Key-Value-Store. Speichert den gesamten Cluster-Zustand (Single Source of Truth).

Scheduler

Weist Pods basierend auf Ressourcen, Affinität und Constraints auf Nodes zu.

Controller Manager

Überwacht Cluster-Zustand und reconciliert Desired State mit Actual State.

Worker Node 1

kubelet

Agent auf jedem Node. Startet/stoppt Pods, meldet Status.

kube-proxy

Verwaltet Netzwerkregeln für Service-Routing (iptables/IPVS).

Container Runtime

containerd/CRI-O – führt Container aus.

Pods

Anwendungs-Container mit Shared Network/Storage.

Worker Node 2

kubelet

Agent auf jedem Node. Startet/stoppt Pods, meldet Status.

kube-proxy

Verwaltet Netzwerkregeln für Service-Routing (iptables/IPVS).

Container Runtime

containerd/CRI-O – führt Container aus.

Pods

Anwendungs-Container mit Shared Network/Storage.

Worker Node N

kubelet

Agent auf jedem Node. Startet/stoppt Pods, meldet Status.

kube-proxy

Verwaltet Netzwerkregeln für Service-Routing (iptables/IPVS).

Container Runtime

containerd/CRI-O – führt Container aus.

Pods

Anwendungs-Container mit Shared Network/Storage.

Enterprise-Architektur-Tipps

  • High Availability: Mindestens 3 Control Plane Nodes für etcd-Quorum
  • Multi-Zone: Worker Nodes über mehrere Availability Zones verteilen
  • Dedicated Nodes: Separate Node-Pools für System-Workloads und Anwendungen
  • Managed Kubernetes: EKS, GKE, AKS reduzieren Operational Overhead

2. Core Kubernetes Concepts

Die fundamentalen Bausteine, aus denen jede Kubernetes-Anwendung besteht.

Pod

Kleinste deploybare Einheit

Ein oder mehrere Container mit shared Network Namespace und optional shared Storage. Die atomare Einheit in Kubernetes.

  • Shared IP und Port Space
  • Shared Volumes (optional)
  • Lifecycle: Pending → Running → Succeeded/Failed
  • Immer ephemeral – nie direkt managen!

Service

Stabile Netzwerk-Abstraktion

Bietet eine stabile IP und DNS-Namen für eine Gruppe von Pods. Ermöglicht Load Balancing und Service Discovery.

  • ClusterIP (intern), NodePort, LoadBalancer
  • Label Selector für Pod-Auswahl
  • Automatische Endpoints-Aktualisierung
  • DNS: <service>.<namespace>.svc.cluster.local

Deployment

Deklarative Updates & Rollbacks

Verwaltet ReplicaSets und ermöglicht deklarative Updates, Rollbacks und Scaling von stateless Anwendungen.

  • Rolling Updates (zero downtime)
  • Automatische Rollbacks bei Fehlern
  • Horizontal Pod Autoscaler (HPA)
  • Revision History für Auditing

ConfigMap

Externe Konfiguration

Speichert nicht-sensitive Konfigurationsdaten als Key-Value-Paare oder Dateien. Trennt Config vom Code.

  • Environment Variables Injection
  • Volume Mounts als Dateien
  • Hot Reload (mit SubPath)
  • Namespace-scoped

Secret

Sensitive Daten

Speichert sensitive Daten wie Passwörter, Tokens, Zertifikate. Base64-encoded (nicht verschlüsselt!).

  • Opaque, TLS, Docker Registry
  • Env Var oder Volume Mount
  • External Secrets Operator empfohlen
  • RBAC für Zugriffskontrolle

Ingress

HTTP/HTTPS Routing

Definiert Regeln für externen HTTP(S)-Zugriff auf Services. Benötigt Ingress Controller (nginx, Traefik).

  • Host-based & Path-based Routing
  • TLS Termination (cert-manager)
  • Rate Limiting, Auth
  • Rewrite Rules, Redirects

3. Enterprise Tool Stack

Für produktive Kubernetes-Umgebungen benötigen Sie mehr als nur Vanilla K8s. Hier der bewährte Enterprise-Stack.

Helm – Package Manager

Der Standard-Package-Manager für Kubernetes. Verpackt Manifeste in wiederverwendbare Charts mit Templating.

Enterprise Use Cases:
  • Standardisierte Application-Charts
  • Environment-spezifische Values
  • Chart Versioning & Repository
  • Helmfile für Multi-Cluster-Management

ArgoCD / Flux – GitOps

Deklarative Continuous Delivery. Git als Single Source of Truth, automatisches Sync zum Cluster.

Enterprise Use Cases:
  • Automatisches Deployment nach Merge
  • Drift Detection & Auto-Sync
  • Multi-Cluster Orchestration
  • Audit Trail via Git History

Istio / Linkerd – Service Mesh

Infrastruktur-Layer für Service-to-Service-Kommunikation. Traffic Management, Security, Observability.

Enterprise Use Cases:
  • mTLS für Zero Trust Networking
  • Canary Releases, Traffic Splitting
  • Circuit Breaking, Retries, Timeouts
  • Distributed Tracing Integration

Prometheus + Grafana

De-facto Standard für Kubernetes-Monitoring. Metrics Collection, Alerting, Visualisierung.

Enterprise Use Cases:
  • kube-prometheus-stack (Helm Chart)
  • Custom Metrics & SLIs/SLOs
  • Alertmanager für Paging
  • Thanos/Cortex für Long-Term Storage

OPA / Kyverno – Policy Engine

Policy-as-Code für Governance und Compliance. Validiert und enforced Cluster-Richtlinien.

Enterprise Use Cases:
  • Pod Security Standards Enforcement
  • Image Registry Whitelisting
  • Resource Quotas & Limits
  • Compliance Reporting (SOC2, ISO)

Tekton / GitHub Actions

Cloud-native CI/CD Pipelines. Container-basierte Build- und Deploy-Workflows.

Enterprise Use Cases:
  • Container Image Building (Kaniko)
  • Security Scanning (Trivy, Snyk)
  • Automated Testing in Pods
  • GitOps Trigger nach Build

4. Enterprise Best Practices

Ressourcen-Management

  • Immer Requests UND Limits setzen
  • Quality of Service (QoS) Klassen verstehen
  • Vertical Pod Autoscaler (VPA) für Rightsizing
  • Horizontal Pod Autoscaler (HPA) für Scaling
  • ResourceQuotas pro Namespace
  • LimitRanges für Default-Werte

Security Hardening

  • Pod Security Standards (Restricted)
  • Non-root Container erzwingen
  • Read-only Root Filesystem
  • Network Policies für Microsegmentation
  • Image Scanning in CI/CD Pipeline
  • Secrets extern verwalten (Vault, ESO)

Skalierung & Resilienz

  • Pod Disruption Budgets (PDB)
  • Anti-Affinity für HA-Verteilung
  • Topology Spread Constraints
  • Readiness/Liveness Probes korrekt konfigurieren
  • Graceful Shutdown Handling
  • Chaos Engineering testen

Observability

  • Three Pillars: Metrics, Logs, Traces
  • SLIs/SLOs definieren und tracken
  • Structured Logging (JSON)
  • Distributed Tracing (Jaeger, Zipkin)
  • Alerting auf Symptome, nicht Ursachen
  • Runbooks für On-Call dokumentieren

Networking

  • CNI Plugin bewusst wählen (Calico, Cilium)
  • Service Mesh nur wenn nötig
  • Ingress Controller hochverfügbar
  • DNS Caching optimieren (NodeLocal DNS)
  • ExternalDNS für automatische DNS-Einträge
  • LoadBalancer IPs reservieren

Storage

  • StatefulSets für stateful Workloads
  • CSI Driver für Cloud Storage
  • PersistentVolumeClaims mit StorageClasses
  • Backup-Strategie für PVs (Velero)
  • ReadWriteMany nur wenn nötig (NFS, Ceph)
  • Local Persistent Volumes für Performance

Production Readiness Checklist

  • ✅ Multi-Node Cluster mit HA Control Plane
  • ✅ Resource Requests/Limits für alle Pods
  • ✅ Liveness/Readiness Probes konfiguriert
  • ✅ Pod Disruption Budgets gesetzt
  • ✅ Network Policies aktiviert
  • ✅ Monitoring & Alerting eingerichtet
  • ✅ Backup-Strategie (Velero) getestet
  • ✅ RBAC mit Least Privilege
  • ✅ Image Scanning in Pipeline
  • ✅ GitOps Workflow etabliert

5. FAQ – Häufige Fragen & Antworten

Häufige Fragen zu Kubernetes Enterprise

Wann lohnt sich Kubernetes im Enterprise?

Kubernetes ist sinnvoll, wenn:

  • Microservices-Architektur: Viele unabhängige Services orchestrieren
  • Skalierungsbedarf: Automatisch horizontal skalieren
  • Multi-Cloud/Hybrid: Portabilität zwischen Clouds
  • DevOps-Kultur: Self-Service für Entwicklungsteams
  • Resilienz: Selbstheilende Systeme erforderlich

Nicht geeignet für: Einfache Monolithen, kleine Teams ohne DevOps-Expertise, statische Websites.

Managed Kubernetes vs. Self-Managed – was wählen?

Managed (EKS, GKE, AKS):

  • ✅ Control Plane wird vom Provider betrieben
  • ✅ Automatische Upgrades und Patches
  • ✅ Integrierte Cloud-Services (Load Balancer, Storage)
  • ❌ Höhere Kosten, Vendor Lock-in

Self-Managed (kubeadm, kOps):

  • ✅ Volle Kontrolle, keine Vendor-Abhängigkeit
  • ✅ Kosteneffizient bei großer Scale
  • ❌ Hoher Operational Overhead
  • ❌ Eigenes Expertise-Team nötig

Empfehlung: Starten Sie mit Managed K8s, wechseln Sie zu Self-Managed nur bei spezifischen Anforderungen oder >50 Nodes.

Wie viele Nodes brauche ich für Production?

Mindestanforderungen für Production:

  • Control Plane: 3 Nodes (HA, etcd-Quorum)
  • Worker Nodes: Mindestens 3 (für Rolling Updates und Ausfallsicherheit)
  • System Nodes: Dedizierte Nodes für Monitoring, Logging, Ingress

Faustregel: Planen Sie 30% Overhead für Wartung, Updates und Failover. Bei 10 Anwendungs-Pods starten Sie mit 5-7 Worker Nodes.

Brauche ich ein Service Mesh?

Ja, wenn:

  • mTLS für Zero Trust erforderlich
  • Advanced Traffic Management (Canary, Blue/Green)
  • Distributed Tracing über Services
  • Fine-grained Authorization (OPA Integration)
  • >20 Microservices mit komplexer Kommunikation

Nein, wenn:

  • Einfache Request/Routing-Anforderungen
  • <10 Services
  • Team hat keine Service Mesh Expertise
  • Performance-Overhead kritisch (Sidecar-Proxies kosten ~10% CPU/RAM)

Empfehlung: Starten Sie ohne Service Mesh, führen Sie es ein, wenn die Komplexität steigt. Linkerd ist einfacher als Istio.

Wie sichere ich Secrets in Kubernetes?

Kubernetes Secrets sind NICHT verschlüsselt! Nur Base64-encoded. Für Production:

  • External Secrets Operator (ESO): Sync von Vault, AWS Secrets Manager, Azure Key Vault
  • Sealed Secrets: Verschlüsselte Secrets im Git (nur Controller kann entschlüsseln)
  • Vault Agent Injector: Dynamische Secrets zur Laufzeit
  • Encryption at Rest: etcd-Verschlüsselung aktivieren
  • RBAC: Strikte Zugriffskontrolle auf Secrets

Best Practice: Niemals Secrets im Git committen! Nutzen Sie ESO + Vault für Enterprise-Security.

Wie monitore ich Kubernetes richtig?

Three Pillars of Observability:

  • Metrics: Prometheus + kube-prometheus-stack (Node Exporter, kube-state-metrics)
  • Logs: Fluent Bit/Fluentd → Elasticsearch/Loki
  • Traces: Jaeger/Zipkin für Distributed Tracing

Wichtige Metriken:

  • Pod Restarts, OOMKills, Evictions
  • CPU/Memory Utilization vs. Limits
  • API Server Latency & Error Rate
  • etcd Leader Elections & Compaction
  • Ingress Request Rate & Latency

Alerting: Alarmieren Sie auf Symptome (hohe Error Rate), nicht auf Ursachen (CPU hoch). Definieren Sie SLIs/SLOs.

Was ist GitOps und warum ist es wichtig?

GitOps ist ein Operating Model, bei dem Git die Single Source of Truth für Infrastruktur und Anwendungen ist.

Prinzipien:

  • Deklarativ: Gewünschter Zustand in YAML/Helm
  • Versioniert: Alle Änderungen in Git History
  • Automatisiert: ArgoCD/Flux synced automatisch
  • Drift Detection: Abweichungen werden erkannt und korrigiert

Vorteile: Audit Trail, Reproducibility, Collaboration via PRs, Automated Rollbacks.

Tools: ArgoCD (empfohlen), Flux, Rancher Fleet.

Wie skaliere ich Kubernetes horizontal?

Drei Ebenen der Skalierung:

  • Pod-Level: Horizontal Pod Autoscaler (HPA) basierend auf CPU/Memory/Custom Metrics
  • Node-Level: Cluster Autoscaler fügt Nodes hinzu/entfernt sie
  • Vertical: Vertical Pod Autoscaler (VPA) passt Requests/Limits an

HPA Beispiel:

YAML apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: my-app-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70

Best Practice: Kombinieren Sie HPA mit Cluster Autoscaler und PDBs für resiliente Skalierung.

Zusammenfassung

Die wichtigsten Punkte

  • Definition: Kubernetes orchestriert Container – automatisiert Deployment, Skalierung und Betrieb
  • Architektur: Control Plane (API Server, etcd, Scheduler, Controller) + Worker Nodes (kubelet, kube-proxy, Runtime)
  • Core Concepts: Pods, Services, Deployments, ConfigMaps, Secrets, Ingress
  • Enterprise Tools: Helm (Packaging), ArgoCD (GitOps), Istio (Service Mesh), Prometheus (Monitoring), OPA (Policy)
  • Security: Pod Security Standards, Network Policies, RBAC, External Secrets
  • Scaling: HPA (Pods), Cluster Autoscaler (Nodes), VPA (Resources)
  • Observability: Metrics (Prometheus), Logs (Loki), Traces (Jaeger)
  • Best Practices: Resources setzen, Probes konfigurieren, PDBs, GitOps, Security Hardening
  • Production Ready: HA Control Plane, Monitoring, Backups, RBAC, Image Scanning

Nächste Schritte

Kubernetes ist mächtig, aber komplex. Starten Sie mit Managed K8s, etablieren Sie GitOps früh, investieren Sie in Monitoring und Security von Anfang an. Nutzen Sie die Enterprise-Tools, um Operational Overhead zu reduzieren.

Zu Helm Zu GitOps Zu Service Mesh Zu Observability

Weiterführende Themen

Helm Enterprise

Package Management für Kubernetes – Charts, Repositories, Helmfile.

Zu Helm
GitOps

Deklarative Continuous Delivery mit ArgoCD und Flux.

Zu GitOps
Service Mesh

Istio, Linkerd – Traffic Management, mTLS, Observability.

Zu Service Mesh
Observability

Prometheus, Grafana, Loki, Jaeger – Full Stack Monitoring.

Zu Observability