Kubernetes LoadBalancer und Octavia

Wenn Sie eine Kubernetes-Anwendung ins Internet freigeben, verwenden Sie typischerweise einen Service vom type: LoadBalancer. Auf unserer Plattform erstellt dies automatisch einen echten Octavia-Loadbalancer in Ihrem OpenStack-Projekt. Dieses Integration zu verstehen ist entscheidend für die Fehlersuche bei Netzwerkproblemen und das Quota-Management.

Wie es funktioniert

Wenn Sie einen Service mit type: LoadBalancer in Ihrem Shoot-Cluster erstellen, provisioniert der Cloud-Controller-Manager — der in der Control Plane des Shoots auf dem Seed läuft — einen Octavia-Loadbalancer in OpenStack und verbindet ihn mit Ihren Worker-Nodes.

%%{init: {'themeVariables': {'textColor': '#333333', 'edgeLabelBackground': '#ffffff', 'clusterBkg': 'transparent', 'clusterBorder': '#999999'}}}%%
flowchart LR
    Internet["Internet"]
    FIP["Floating IP<br>(öffentliches Netzwerk)"]

    subgraph OS ["OpenStack"]
        LB["Octavia-Loadbalancer<br>Listener · Pool · Health Monitor"]
    end

    subgraph K8s ["Kubernetes Shoot-Cluster"]
        W1["Worker-Node 1"]
        W2["Worker-Node 2"]
        Pod1["Pod: nginx"]
        Pod2["Pod: nginx"]
    end

    Internet --> FIP
    FIP --> LB
    LB --> W1
    LB --> W2
    W1 --> Pod1
    W2 --> Pod2

    classDef ext fill:#fce4ec,stroke:#c62828,color:#b71c1c;
    classDef fip fill:#e3f2fd,stroke:#1565c0,color:#0d47a1;
    classDef lb fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20;
    classDef worker fill:#fff3e0,stroke:#e65100,color:#bf360c;
    classDef pod fill:#f3e5f5,stroke:#6a1b9a,color:#4a148c;
    class Internet ext;
    class FIP fip;
    class LB lb;
    class W1,W2 worker;
    class Pod1,Pod2 pod;
    linkStyle 0,1 stroke:#c62828,stroke-width:2px;
    linkStyle 2,3 stroke:#2e7d32,stroke-width:2px;
    linkStyle 4,5 stroke:#e65100,stroke-width:2px;

%%{init: {'themeVariables': {'textColor': '#e0e0e0', 'edgeLabelBackground': '#2a2a2a', 'clusterBkg': 'transparent', 'clusterBorder': '#666666'}}}%%
flowchart LR
    Internet["Internet"]
    FIP["Floating IP<br>(öffentliches Netzwerk)"]

    subgraph OS ["OpenStack"]
        LB["Octavia-Loadbalancer<br>Listener · Pool · Health Monitor"]
    end

    subgraph K8s ["Kubernetes Shoot-Cluster"]
        W1["Worker-Node 1"]
        W2["Worker-Node 2"]
        Pod1["Pod: nginx"]
        Pod2["Pod: nginx"]
    end

    Internet --> FIP
    FIP --> LB
    LB --> W1
    LB --> W2
    W1 --> Pod1
    W2 --> Pod2

    classDef ext fill:#3e1e1e,stroke:#ef5350,color:#ffcdd2;
    classDef fip fill:#1a3a5c,stroke:#64b5f6,color:#e3f2fd;
    classDef lb fill:#1b3a2a,stroke:#66bb6a,color:#c8e6c9;
    classDef worker fill:#3e2723,stroke:#ff9800,color:#ffe0b2;
    classDef pod fill:#2a1a3a,stroke:#ab47bc,color:#e1bee7;
    class Internet ext;
    class FIP fip;
    class LB lb;
    class W1,W2 worker;
    class Pod1,Pod2 pod;
    linkStyle 0,1 stroke:#ef5350,stroke-width:2px;
    linkStyle 2,3 stroke:#66bb6a,stroke-width:2px;
    linkStyle 4,5 stroke:#ff9800,stroke-width:2px;

Der Provisioning-Ablauf

1. Sie erstellen einen Service mit type: LoadBalancer in Ihrem Shoot-Cluster.
2. Der Cloud-Controller-Manager (CCM) erkennt den neuen Service.
3. Der CCM ruft die OpenStack-Octavia-API auf und provisioniert:
   • Einen Loadbalancer mit einer VIP im Worker-Node-Netzwerk.
   • Einen Listener für den im K8s-Service angegebenen Port.
   • Einen Pool mit den Worker-Nodes als Members.
   • Einen Health Monitor zur Überwachung der Worker-Node-Gesundheit.
4. Eine Floating IP wird im öffentlichen Netzwerk erstellt und mit der Loadbalancer-VIP verknüpft.
5. Der CCM schreibt die Floating IP als EXTERNAL-IP in den Service-Status zurück.
6. kubectl get svc zeigt nun die externe IP — Ihre Anwendung ist aus dem Internet erreichbar.

Was in OpenStack erscheint

Der Octavia-Loadbalancer ist eine echte OpenStack-Ressource in Ihrem Projekt. Sie sehen ihn in:

• OpenStack Horizon → Network → Load Balancers
• OpenStack CLI: openstack loadbalancer list

Jeder K8s-LoadBalancer-Service erstellt:

Praktisches Beispiel

Deployen Sie nginx mit einem LoadBalancer-Service:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.27
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: nginx

Anwenden und den Service prüfen:

kubectl apply -f nginx.yaml
kubectl get svc nginx

Während Octavia provisioniert, wird die externe IP als <pending> angezeigt:

NAME    TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
nginx   LoadBalancer   10.97.246.12   <pending>     80:31234/TCP   5s

Sobald Octavia bereit ist (in der Regel 30–60 Sekunden):

NAME    TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)        AGE
nginx   LoadBalancer   10.97.246.12   192.0.2.50     80:31234/TCP   45s

Die EXTERNAL-IP ist die von Octavia zugewiesene Floating IP. Ihre Anwendung ist nun unter http://192.0.2.50 erreichbar.

openstack loadbalancer list
openstack floating ip list

NodePort vs LoadBalancer vs Ingress

Quota-Überlegungen

Jeder Service vom Typ LoadBalancer erstellt einen Octavia-Loadbalancer in Ihrem OpenStack-Projekt. Dies verbraucht:

• Octavia-Loadbalancer — prüfen Sie Ihre Projekt-Quota.
• Floating IPs — eine pro LoadBalancer-Service.
• Ports — im Worker-Node-Netzwerk.

Wenn Sie das Quota-Limit erreichen, bleiben neue LoadBalancer-Services im Status <pending>. Prüfen Sie Ihre Quota im Cloud Services Portal oder mit:

openstack quota show

Aufräumen

Wenn Sie einen Kubernetes-Service vom Typ LoadBalancer löschen, löscht der Cloud-Controller-Manager automatisch den entsprechenden Octavia-Loadbalancer und gibt die Floating IP frei:

kubectl delete svc nginx

Manuelle Octavia-Loadbalancer

Sie können Octavia-Loadbalancer auch manuell für Nicht-Kubernetes-Workloads erstellen (z.B. OpenStack-VMs). Siehe den OpenStack-Loadbalancer-Leitfaden für CLI-Beispiele inklusive HTTP, HTTPS-Terminierung und Health Monitors.

Nächster Schritt

Erfahren Sie, wie Sie persistente Service-Accounts erstellen oder kehren Sie zur Cluster-Verwaltung zurück.