Kubernetes, OpenShift und Container-Plattform

Fachliche Perspektive

Eine Container-Plattform verkürzt Bereitstellung und erhöht Standardisierung. Teams bekommen Namespaces/Projects, Deployments, Services, Secrets, ConfigMaps, Routes, Pipelines und Observability, ohne jede Infrastrukturkomponente selbst bauen zu müssen.

Kubernetes-Grundmodell

Control Plane entscheidet über gewünschten Zustand. Worker Nodes führen Pods aus. Deployments verwalten Replikate, Services stabilisieren interne Erreichbarkeit, Ingress/Routes veröffentlichen Dienste, Volumes binden persistente Daten ein.

OpenShift-Erweiterungen

OpenShift baut auf Kubernetes auf und ergänzt Enterprise-Features wie Projects, Routes, BuildConfig/S2I, integrierte Registry, Security Context Constraints, Operators, Monitoring und Konsolenfunktionen.

Cluster als Produkt

Ein Cluster braucht Lifecycle: Installation, Upgrade, Node-Skalierung, Zertifikate, Policies, Netzwerk, Storage, Backup, Monitoring, Logging, Tenant-Onboarding und Kostenmodell.

Stateful Workloads

Datenbanken und Messaging können auf Kubernetes laufen, benötigen aber gute Operatoren, Storage-Klassen, Backup/Restore und klare Verantwortlichkeiten. Nicht jeder Legacy-State passt sofort in Container.

Ausführliche Beispiele

Deployment mit Readiness/Liveness

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-api
  labels:
    app: order-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-api
  template:
    metadata:
      labels:
        app: order-api
    spec:
      containers:
        - name: order-api
          image: registry.example.com/order/order-api:1.4.2
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /actuator/health/readiness
              port: 8080
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /actuator/health/liveness
              port: 8080
            periodSeconds: 20
          resources:
            requests:
              cpu: "250m"
              memory: "512Mi"
            limits:
              cpu: "1"
              memory: "1Gi"

Service und Route

apiVersion: v1
kind: Service
metadata:
  name: order-api
spec:
  selector:
    app: order-api
  ports:
    - name: http
      port: 8080
      targetPort: 8080
---
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: order-api
spec:
  to:
    kind: Service
    name: order-api
  tls:
    termination: edge

Namespace-Governance

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: orders-prod
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 32Gi
    limits.cpu: "16"
    limits.memory: 64Gi
    pods: "80"

Prüf- und Verständnis-Checkliste

• Projects/Namespaces haben Owner und Quotas.
• Deployments haben Health Checks und Ressourcen.
• Routes/TLS sind standardisiert.
• Operatoren sind bewertet und versioniert.
• Backup/Restore ist für Cluster-Objekte und Daten geklärt.

Merksatz

Eine Infrastrukturkomponente ist erst enterprise-tauglich, wenn sie geplant, automatisiert, überwacht, geschützt, wiederherstellbar und fachlich begründet ist.