OCI Load Balancer für Kubernetes-Services vom Typ LoadBalancer bereitstellen

oci.oraclecloud.com/load-balancer-type: "lb"

Beachten Sie, dass lb der Standardwert der Annotation oci.oraclecloud.com/load-balancer-type ist. Wenn Sie die Annotation nicht explizit in die Servicedefinition aufnehmen, wird der Standardwert der Annotation verwendet.

Beispiel: Beachten Sie die folgende Konfigurationsdatei: nginx_lb.yaml. Sie definiert ein Deployment (kind: Deployment) für die nginx-App, gefolgt von einer Definition eines Service vom Typ LoadBalancer (type: LoadBalancer), der HTTP-Traffic an Port 80 für die nginx-App verteilt.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Der erste Teil der Konfigurationsdatei definiert ein Nginx-Deployment, wobei angefordert wird, dass es auf 3 Pods gehostet wird, auf denen das nginx:latest-Image ausgeführt wird. Außerdem muss der Traffic zu den Containern an Port 80 akzeptiert werden.

Der zweite Teil der Konfigurationsdatei definiert den Nginx-Service, der mit dem LoadBalancer-Typ den Nginx-Traffic an Port 80 auf die verfügbaren Pods verteilt.

Um bei bestehender Verbindung mit dem Kubernetes-Cluster das Deployment und den Service zu erstellen, die in nginx_lb.yaml definiert sind, geben Sie folgenden Befehl ein:

kubectl apply -f nginx_lb.yaml

Nach erfolgreicher Erstellung des Deployments und des Load Balancers gibt dieser Befehl Folgendes aus:

deployment "my-nginx" created
service "my-nginx-svc" created

Es kann einige Minuten dauern, bis der Load Balancer vom Status "Ausstehend" zur vollständigen Betriebsbereitschaft wechselt. Sie können den aktuellen Status Ihres Clusters anzeigen, indem Sie Folgendes eingeben:

kubectl get all

Die Ausgabe des obigen Befehls zeigt den aktuellen Status an:

NAME                                  READY     STATUS    RESTARTS   AGE
po/my-nginx-431080787-0m4m8           1/1       Running   0          3m
po/my-nginx-431080787-hqqcr           1/1       Running   0          3m
po/my-nginx-431080787-n8125           1/1       Running   0          3m

NAME               CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
svc/kubernetes     203.0.113.1     <NONE>           443/TCP        3d
svc/my-nginx-svc   203.0.113.7     192.0.2.22       80:30269/TCP   3m

NAME                      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deploy/my-nginx           3         3         3            3           3m

NAME                            DESIRED   CURRENT   READY     AGE
rs/my-nginx-431080787           3         3         3         3m

Die Ausgabe zeigt, dass das my-nginx-Deployment auf 3 Pods (den po/my-nginx-Einträgen) ausgeführt wird, dass der Load Balancer ausgeführt wird (svc/my-nginx-svc) und über eine externe IP (192.0.2.22) verfügt, mit der Clients eine Verbindung zu der auf den Pods bereitgestellten App herstellen können.

Wenn die Kubernetes-Engine einen Load Balancer für einen Kubernetes-Service des Typs LoadBalancer bereitstellt, können Sie angeben, dass Sie SSL am Load Balancer beenden möchten. Diese Konfiguration wird als Frontend-SSL bezeichnet. Um Frontend-SSL zu implementieren, definieren Sie einen Listener an einem Port wie 443 und verknüpfen ein SSL-Zertifikat mit dem Listener.

Beachten Sie, dass Sie die vollständige Punkt-zu-Punkt-SSL-Verschlüsselung zwischen Clients und Anwendungspods implementieren können, die auf Worker-Knoten ausgeführt werden. Erstellen Sie dazu einen Load Balancer mit SSL-Beendigung (wie in diesem Abschnitt beschrieben), und verknüpfen Sie ein SSL-Zertifikat mit dem Backend-Set des Load Balancers (siehe SSL/TLS zwischen Load Balancer- und Worker-Knoten implementieren).

Dieses Beispiel bietet eine Schritt-für-Schritt-Anleitung der Konfiguration und Erstellung eines Load Balancers mit SSL-Unterstützung.

Mit der Konfigurationsdatei nginx-demo-svc-ssl.yaml wird ein Nginx-Deployment definiert und über einen Load Balancer bereitgestellt, der HTTP auf Port 80 und HTTPS auf Port 443 verwendet. Dieses Beispiel erstellt einen Oracle Cloud Infrastructure-Load Balancer, indem ein Service mit dem Typ LoadBalancer (type: LoadBalancer) definiert wird.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
  name: nginx-service
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-ssl-ports: "443"
    oci.oraclecloud.com/oci-load-balancer-listener-ssl-config: '{"CipherSuiteName":"oci-default-http2-tls-12-13-ssl-cipher-suite-v1", "Protocols":["TLSv1.3"]}'
    service.beta.kubernetes.io/oci-load-balancer-tls-secret: ssl-certificate-secret
spec:
  selector:
    app: nginx
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    targetPort: 80
  - name: https
    port: 443
    targetPort: 80

Die Annotationen des Load Balancers sind von besonderer Bedeutung, wie hier beschrieben.

Die Ports, auf denen HTTPS-Traffic unterstützt werden soll, werden durch den Wert der Annotation service.beta.kubernetes.io/oci-load-balancer-ssl-ports definiert. Sie können mehrere SSL-Ports deklarieren, indem Sie eine durch Komma getrennte Liste für den Wert der Annotation verwenden. Beispiel: Sie können den Wert der Annotation auf "443, 3000" setzen, um SSL auf den Ports 443 und 3000 zu unterstützen.

Die mit dem Load Balancer zu verwendende Cipher Suite wird durch den Wert der Annotation oci.oraclecloud.com/oci-load-balancer-listener-ssl-config definiert. Cipher Suites bestimmen die Sicherheit, Kompatibilität und Geschwindigkeit des HTTPS-Traffics (weitere Informationen finden Sie unter Cipher Suites für Load Balancer). Sie geben sowohl den Namen der Cipher Suite (z.B. oci-default-http2-TLS-12-13-ssl-cipher-suite-v1) als auch die TLS-Version (z.B. TLSv1.3) an. Sie können eine vordefinierte Cipher Suite angeben, die von Oracle Cloud Infrastructure vorkonfiguriert ist (siehe Vordefinierte Cipher Suites für Load Balancer) oder eine Cipher Suite, die Sie selbst erstellt haben. Wenn Sie die Annotation oci.oraclecloud.com/oci-load-balancer-listener-ssl-config nicht einschließen, aber die Annotation service.beta.kubernetes.io/oci-load-balancer-tls-secret einschließen, wird die Cipher Suite "oci-default-ssl-cipher-suite-v1" verwendet.

Das erforderliche TLS-Secret ssl-certificate-secret muss in Kubernetes erstellt werden. In diesem Beispiel wird ein selbstsigniertes Zertifikat erstellt und verwendet. Das häufigste Szenario in einer Produktionsumgebung besteht jedoch darin, ein öffentliches Zertifikat zu verwenden, das von einer Certificate Authority signiert wurde.

Der folgende Befehl erstellt ein selbstsigniertes Zertifikat tls.crt mit dem entsprechenden Schlüssel tls.key:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=nginxsvc/O=nginxsvc"

Nachdem Sie das Zertifikat erstellt haben, müssen Sie es mit seinem Schlüssel als Secret in Kubernetes speichern. Der Name des Secrets muss mit dem Namen aus der service.beta.kubernetes.io/oci-load-balancer-tls-secret-Annotation der Load-Balancer-Definition übereinstimmen. Mit dem folgenden Befehl können Sie ein TLS-Secret in Kubernetes erstellen, dessen Schlüssel- und Zertifikatwerte durch --key bzw. --cert festgelegt werden.

kubectl create secret tls ssl-certificate-secret --key tls.key --cert tls.crt

Sie müssen das Kubernetes-Secret erstellen, bevor Sie den Service erstellen können, da der Service in seiner Definition auf das Secret verweist. Erstellen Sie den Service mit dem folgenden Befehl:

kubectl create -f manifests/demo/nginx-demo-svc-ssl.yaml

Sie können den Service beobachten und warten, bis dem Nginx-Service (nginx-service) eine öffentliche IP-Adresse (EXTERNAL-IP) zugewiesen wird. Geben Sie dazu Folgendes ein:

kubectl get svc --watch

In der Ausgabe des obigen Befehls wird die Load-Balancer-IP angezeigt, mit der die Verbindung zum Service hergestellt werden soll.

NAME            CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
nginx-service   192.0.2.1      198.51.100.1     80:30274/TCP   5m

Der Load Balancer wird jetzt ausgeführt, d.h. der Service kann jetzt wie folgt aufgerufen werden:

• Mit HTTP, indem Sie Folgendes eingeben:

  curl http://198.51.100.1

• Mit HTTPS, indem Sie Folgendes eingeben:

  curl --insecure https://198.51.100.1

  Aufgrund der Verwendung von selbstsignierten Zertifikaten in diesem Beispiel wird mit dem "--insecure"-Kennzeichen über HTTPS auf den Service zugegriffen. Verwenden Sie dieses Kennzeichen nicht in einer Produktionsumgebung, in der das öffentliche Zertifikat von einer Certificate Authority signiert wurde.

Hinweis: Wenn ein Cluster gelöscht wird, wird ein beim Erstellen eines Service dynamisch erstellter Load Balancer nicht entfernt. Bevor Sie ein Cluster löschen, löschen Sie den Service. Dadurch wird der Load Balancer wiederum entfernt. Die Syntax für diesen Befehl lautet:

kubectl delete svc SERVICE_NAME

Beispiel: Um den Service aus dem vorherigen Beispiel zu löschen, geben Sie Folgendes ein:

kubectl delete svc nginx-service

Wenn die Kubernetes-Engine einen Load Balancer für einen Kubernetes-Service des Typs LoadBalancer bereitstellt, können Sie angeben, dass Sie SSL zwischen dem Load Balancer und den Backend-Servern (Workerknoten) im Backend-Set implementieren möchten. Diese Konfiguration wird als Backend-SSL bezeichnet. Um Backend-SSL zu implementieren, verknüpfen Sie ein SSL-Zertifikat mit dem Backend-Set des Load Balancers.

Beachten Sie, dass Sie die vollständige Punkt-zu-Punkt-SSL-Verschlüsselung zwischen Clients und Anwendungspods implementieren können, die auf Worker-Knoten ausgeführt werden. Verknüpfen Sie dazu ein SSL-Zertifikat mit dem Backend-Set des Load Balancers (wie in diesem Abschnitt beschrieben), und erstellen Sie einen Load Balancer mit SSL-Beendigung (siehe SSL/TLS am Load Balancer beenden).

Cipher Suites bestimmen die Sicherheit, Kompatibilität und Geschwindigkeit des HTTPS-Traffics (weitere Informationen finden Sie unter Cipher Suites für Load Balancer). Um die Cipher Suite anzugeben, die mit dem Backend-Set des Load Balancers verwendet werden soll, fügen Sie die folgende Annotation im Metadatenabschnitt der Manifestdatei hinzu:

oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config: '{"CipherSuiteName":"<cipher-suite-name>", "Protocols":["<tls-version>"]}'

Hierbei gilt:

• "CipherSuiteName":"<cipher-suite-name>" ist der Name einer vordefinierten Cipher Suite, die von Oracle Cloud Infrastructure vorkonfiguriert ist (siehe Vordefinierte Cipher Suites für Load Balancer) oder einer Cipher Suite, die Sie selbst erstellt haben. Beispiel: "CipherSuiteName":"oci-default-http2-tls-12-13-ssl-cipher-suite-v1"
• "Protocols":["<tls-version>"] gibt eine oder mehrere TLS-Versionen in einer durch Komma getrennten Liste an. Beispiel: "Protocols":["TLSv1.2", "TLSv1.3"]

Beispiel:

oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config: '{"CipherSuiteName":"oci-default-http2-tls-12-13-ssl-cipher-suite-v1", "Protocols":["TLSv1.2", "TLSv1.3"]}'

Wenn Sie die oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config-Annotation nicht einschließen, aber die service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret-Annotation einschließen, wird die Cipher Suite "oci-wider-compatible-ssl-cipher-suite-v1" verwendet.

Um das Zertifikat anzugeben, das mit dem Backend-Set verknüpft werden soll, fügen Sie die folgende Annotation im Metadatenabschnitt der Manifestdatei hinzu:

service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret: <value>

Dabei ist <value> der Name eines Kubernetes-Secrets, das Sie zur Aufnahme eines signierten Zertifikats und des Private Keys für das Zertifikat erstellt haben. Beachten Sie, dass Sie das Kubernetes-Secret erstellen müssen, bevor Sie den Service erstellen können, da der Service in seiner Definition auf das Secret verweist.

Im folgenden Beispiel wird ein selbstsigniertes Zertifikat erstellt und verwendet, das in der Regel für die interne Kommunikation zwischen dem Load Balancer und dem Backend-Set akzeptabel ist. Auf Wunsch können Sie jedoch ein öffentliches Zertifikat verwenden, das von einer Certificate Authority signiert wurde.

Beispiel:

1. Generieren Sie einen Private Key, indem Sie Folgendes eingeben:

   openssl genrsa -out ca.key 2048

2. Generieren Sie ein Zertifikat, indem Sie Folgendes eingeben:

   openssl req -x509 -new -nodes -key ca.key -subj "/CN=nginxsvc/O=nginxsvc" -days 10000 -out ca.crt

3. Speichern Sie das Zertifikat und den Schlüssel als Secret in Kubernetes, indem Sie Folgendes eingeben:

   kubectl create secret generic ca-ser-secret --from-file=tls.crt=tls.crt --from-file=tls.key=tls.key --from-file=ca.crt=ca.crt
4. Definieren Sie ein Nginx-Deployment, und stellen Sie es über einen Load Balancer bereit, der HTTP auf Port 80 und HTTPS auf Port 443 bedient.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
---
apiVersion: v1
metadata:
  name: nginx-service
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config: '{"CipherSuiteName":"oci-default-http2-tls-12-13-ssl-cipher-suite-v1", "Protocols":["TLSv1.2", "TLSv1.3"]}'
    service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret: ca-ser-secret
    service.beta.kubernetes.io/oci-load-balancer-ssl-ports: "443" 
spec:
  selector:
    app: nginx
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    targetPort: 80
  - name: https
    port: 443
    targetPort: 443

Die Kommunikation zwischen dem Load Balancer und den Worker-Knoten im Backend-Set wird mit dem Schlüssel und Zertifikat verschlüsselt, das im zuvor erstellten Kubernetes-Secret ca-ser-secret gespeichert ist.

Die Ausprägung eines Oracle Cloud Infrastructure Load Balancers gibt die maximale Gesamtbandbreite an (d.h. Ingress plus Egress). Standardmäßig werden Load Balancer mit einer Ausprägung von 100 Mbit/s erstellt. Andere Ausprägungen sind verfügbar, einschließlich 400 Mbit/s und 8000 Mbit/s.

Um eine alternative Ausprägung für einen Load Balancer anzugeben, fügen Sie die folgende Annotation im Metadatenabschnitt der Manifestdatei hinzu:

service.beta.kubernetes.io/oci-load-balancer-shape: <value>

Hierbei ist value die Bandbreite der Ausprägung (Beispiel: 100 Mbit/s, 400 Mbit/s, 8000 Mbit/s).

Beispiel:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-shape: 400Mbps
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

In der Region für die angegebene Ausprägung muss eine ausreichende Quota für den Load Balancer verfügbar sein. Geben Sie den folgenden kubectl-Befehl ein, um sicherzustellen, dass das erfolgreiche Erstellen des Load Balancers nicht aufgrund einer unzureichenden Quota verhindert wurde:

kubectl describe service <service-name>

Beachten Sie, dass Oracle empfiehlt, Kubernetes-Services des Typs LoadBalancer als kosteneffiziente flexible Load Balancer und nicht als (dynamische) Load Balancer mit fester Ausprägung zu implementieren (siehe Flexible Load Balancer-Ausprägungen angeben).

Die Ausprägung eines Oracle Cloud Infrastructure Load Balancers gibt die maximale Gesamtbandbreite an (d.h. Ingress plus Egress). Wie unter Alternative Load-Balancer-Ausprägungen angeben beschrieben, können Sie verschiedene Ausprägungen für Load Balancer angeben.

Darüber hinaus können Sie eine flexible Ausprägung für einen Oracle Cloud Infrastructure Load Balancer angeben, indem Sie eine minimale und eine maximale Bandbreite für den Load Balancer definieren.

Um eine flexible Ausprägung für einen Load Balancer anzugeben, fügen Sie die folgenden Annotationen im Metadatenabschnitt der Manifestdatei hinzu:

service.beta.kubernetes.io/oci-load-balancer-shape: "flexible"
service.beta.kubernetes.io/oci-load-balancer-shape-flex-min: "<min-value>"
service.beta.kubernetes.io/oci-load-balancer-shape-flex-max: "<max-value>"

Hierbei gilt:

• "<min-value>" ist die minimale Bandbreite für den Load Balancer in Mbps (z.B. "10")
• "<max-value>" ist die maximale Bandbreite für den Load Balancer in Mbps (z.B. "100")

Hinweis: Die Angabe von Bandbreitenwerten für flexible Load-Balancer-Ausprägungen enthält keine Maßeinheit (im Gegensatz zu vordefinierten Ausprägungen). Geben Sie beispielsweise die minimale Bandbreite als 10 und nicht als 10Mbps an.

Beispiel:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-shape: "flexible"
    service.beta.kubernetes.io/oci-load-balancer-shape-flex-min: "10"
    service.beta.kubernetes.io/oci-load-balancer-shape-flex-max: "100"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Beim Provisioning eines Oracle Cloud Infrastructure-Load Balancers für einen Kubernetes-Service des Typs LoadBalancer können Sie die maximal zulässige Leerlaufzeit (in Sekunden) zwischen zwei aufeinanderfolgenden Empfangsvorgängen oder zwei aufeinanderfolgenden Sendevorgängen zwischen Client- und Backend-Servern angeben.

Um explizit eine maximale Leerlaufzeit anzugeben, fügen Sie die folgende Annotation im Metadatenabschnitt der Manifestdatei hinzu:

service.beta.kubernetes.io/oci-load-balancer-connection-idle-timeout: <value>

Hierbei gibt value die Anzahl der Sekunden an.

Beispiel:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-connection-idle-timeout: 100
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Wenn Sie nicht explizit eine maximale Leerlaufzeit angeben, wird ein Standardwert verwendet. Der Standardwert hängt vom Listener-Typ ab:

• Für TCP-Listener beträgt die standardmäßige maximale Leerlaufzeit 300 Sekunden.
• Für HTTP-Listener beträgt die maximale Standardleerlaufzeit 60 Sekunden.

Wenn die Kubernetes-Engine einen Load Balancer für einen Kubernetes-Service des Typs LoadBalancer bereitstellt, können Sie die maximale Größe des HTTP-Headers angeben, der von den Listenern des Load Balancers akzeptiert wird. Sie geben die maximale Größe des HTTP-Headers an, indem Sie mit einer Annotation die Größe (in KB) des Puffers angeben, der zum Lesen des Headers verwendet wird. Die zulässigen Werte für die Puffergröße sind 8, 16, 32 und 64. Mit der Annotation wird eine HTTP-Headerregel für den Load Balancer definiert. Die HTTP-Headerregel gilt für alle Listener des Load Balancers auf allen Ports.

Weitere Informationen zu HTTP-Headerregeln finden Sie unter HTTP-Headerregeln.

Um die maximale Größe des HTTP-Headers anzugeben, der von den Listenern des Load Balancers akzeptiert wird, fügen Sie die Annotation oci.oraclecloud.com/oci-load-balancer-rule-sets im Metadatenabschnitt der Manifestdatei hinzu. Beachten Sie, dass Sie den Wert der Annotation wie folgt als formatierte JSON angeben:

oci.oraclecloud.com/oci-load-balancer-rule-sets:  |
      {
        "<rule-set-name>": {
          "items": [
            {
              "action": "HTTP_HEADER",
              "httpLargeHeaderSizeInKB": <value>
            }
          ]
        }
      }

Hierbei gilt:

• <rule-set-name> ist der Name Ihrer Wahl für das Regelset (zwischen 1 und 32 Zeichen). Beispiel: header-size.
• <value> ist die maximale Größe des HTTP-Headers in KB. Dabei handelt es sich um 8, 16, 32 oder 64.

Beispiel:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/oci-load-balancer-rule-sets: |
      {
        "header-size": {
          "items": [
            {
              "action": "HTTP_HEADER",
              "httpLargeHeaderSizeInKB": 16
            }
          ]
        }
      }
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Um anschließend die maximale Größe des HTTP-Headers zu ändern, aktualisieren Sie die Annotation, und wenden Sie das Manifest erneut an.

Wenn Sie ein Manifest anwenden, das die Annotation oci.oraclecloud.com/oci-load-balancer-rule-sets enthält, beachten Sie, dass die Kubernetes-Engine die Verwaltung aller Regelsets des Load Balancers übernimmt. Die Kubernetes-Engine fügt nicht nur das in der Annotation angegebene HTTP-Headerregelset hinzu, sondern löscht auch alle anderen Regelsets, die derzeit mit dem Load Balancer verknüpft sind. Beachten Sie Folgendes:

• Wenn Sie das HTTP-Headerregelset des Load Balancers später löschen möchten, geben Sie wie folgt ein leeres JSON-Objekt als Wert der oci.oraclecloud.com/oci-load-balancer-rule-sets-Annotation an:

  oci.oraclecloud.com/oci-load-balancer-rule-sets: "{}"

  Wenn Sie ein leeres JSON-Objekt als Wert der Annotation angeben, löscht die Kubernetes-Engine alle Regelsets, die mit dem Load Balancer verknüpft sind, und gibt die Verwaltung der Regelsets des Load Balancers auf.

• Wenn Sie die oci.oraclecloud.com/oci-load-balancer-rule-sets-Annotation einfach aus dem Manifest entfernen und das Manifest anwenden, gibt die Kubernetes-Engine die Verwaltung der Regelsets des Load Balancers auf. Wenn Sie die Annotation entfernen, löscht die Kubernetes-Engine keine der Regelsets, die mit dem Load Balancer verknüpft sind.

Wenn Sie direkte Änderungen an den Regelsets des Load Balancers vornehmen (was nicht empfohlen wird), anstatt die Annotation oci.oraclecloud.com/oci-load-balancer-rule-sets zu verwenden, beachten Sie den folgenden Punkt. Wenn Sie anschließend ein Manifest anwenden, das die oci.oraclecloud.com/oci-load-balancer-rule-sets-Annotation enthält, fügt Kubernetes Engine das in der Annotation angegebene HTTP-Headerregelset hinzu und löscht alle anderen Regelsets, die mit dem Load Balancer verknüpft sind. Wenn Sie also direkte Änderungen beibehalten möchten, die Sie an den Regelsets des Load Balancers vorgenommen haben, nehmen Sie die Annotation oci.oraclecloud.com/oci-load-balancer-rule-sets nicht in das Manifest auf.

Wenn die Kubernetes-Engine einen Load Balancer für einen Kubernetes-Service des Typs LoadBalancer bereitstellt, können Sie den vom Listener akzeptierten Traffictyp definieren, indem Sie das Protokoll angeben, auf dem der Listener Verbindungsanforderungen akzeptiert.

Wenn Sie nicht explizit ein Protokoll angeben, wird "TCP" als Standardwert verwendet.

Um das Load Balancer Listener-Protokoll explizit anzugeben, wenn Kubernetes Engine einen Load Balancer für einen Kubernetes-Service des Typs LoadBalancer bereitstellt, fügen Sie die folgende Anmerkung im Metadatenabschnitt der Manifestdatei hinzu:

service.beta.kubernetes.io/oci-load-balancer-backend-protocol: <value>

Hierbei ist <value> das Protokoll, das den Traffictyp definiert, der vom Listener akzeptiert wird. Beispiel: "HTTP". Gültige Protokolle sind "HTTP", "TCP" und "GRPC".

Beispiel:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-backend-protocol: "HTTP"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Wenn Sie GRPC als Protokoll angeben, müssen Sie Folgendes konfigurieren:

• Frontend-SSL mit den Annotationen service.beta.kubernetes.io/oci-load-balancer-SSL-ports, oci.oraclecloud.com/oci-load-balancer-SSL-listener-config und service.beta.kubernetes.io/oci-load-balancer-tls-secret. Weitere Informationen finden Sie unter SSL/TLS im Load Balancer beenden.
• Backend-SSL mit den Annotationen oci.oraclecloud.com/oci-load-balancer-backendset-SSL-config und service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret. Weitere Informationen finden Sie unter SSL/TLS zwischen Load Balancer und Worker-Knoten implementieren.

Beispiel:

apiVersion: v1
kind: Service
metadata:
  name: hello-grpc-service
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-ssl-ports: "443"
    service.beta.kubernetes.io/oci-load-balancer-tls-secret: ssl-certificate-secret
    service.beta.kubernetes.io/oci-load-balancer-backend-protocol: "GRPC"
    oci.oraclecloud.com/oci-load-balancer-listener-ssl-config: '{"CipherSuiteName":"oci-default-http2-ssl-cipher-suite-v1", "Protocols":["TLSv1.2"]}'
    oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config: '{"CipherSuiteName":"oci-default-http2-ssl-cipher-suite-v1", "Protocols":["TLSv1.2"]}'
    service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret: ca-ser-secret
spec:
  type: LoadBalancer
  selector:
    app: hello-grpc
  ports:
    - port: 443
      name: grpc
      targetPort: 50051

Mit dem Feature zur Verwaltung von Sicherheitslisten können Sie konfigurieren, wie Sicherheitslistenregeln für einen Oracle Cloud Infrastructure-Load Balancer verwaltet werden, den Kubernetes Engine für einen Kubernetes-Service des Typs LoadBalancer bereitstellt. Dieses Feature ist hilfreich, wenn Sie neu in Kubernetes sind, oder für einfache Deployments.

Um anzugeben, wie Sicherheitslisten vom Kubernetes-Feature zur Verwaltung von Sicherheitslisten verwaltet werden, wenn die Kubernetes-Engine einen Load Balancer für einen Kubernetes-Service des Typs LoadBalancer bereitstellt, fügen Sie im Metadatenabschnitt der Manifestdatei die folgende Annotation hinzu:

service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode: <value>

Hierbei ist <value> einer der folgenden Werte:

• "None": (empfohlen) Es ist keine Verwaltung der Sicherheitsliste aktiviert. Sie müssen eine Sicherheitsregel einrichten, die eingehenden Traffic an die entsprechenden Ports für Knotenportbereiche, den Port für den kube-proxy-Zustand und die Health-Check-Portbereiche zulässt. Außerdem müssen Sie Sicherheitsregeln einrichten, damit eingehender Traffic an Load Balancer zulässig ist (siehe Sicherheitsregeln für Load Balancer und Network Load Balancer).
• "All": (Standard) Alle erforderlichen Sicherheitslistenregeln für Load-Balancer-Services werden verwaltet.
• "Frontend": Nur Sicherheitslistenregeln für Ingress für Load-Balancer-Services werden verwaltet. Sie müssen eine Sicherheitsregel einrichten, die eingehenden Traffic an die entsprechenden Ports für Knotenportbereiche, den Port für den kube-proxy-Zustand und die Health-Check-Portbereiche zulässt.

Oracle empfiehlt, dass Sie service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode explizit auf None setzen.

Wenn Sie in Clustern mit verwalteten Knoten nicht explizit einen Verwaltungsmodus angeben oder einen ungültigen Wert angeben, werden alle Sicherheitslistenregeln verwaltet (entspricht "All"). Beachten Sie, dass in diesem Fall die Kubernetes-Engine eine Sicherheitsregel erstellt, die eingehenden Traffic von 0.0.0.0/0 (oder von den in der Manifestdatei angegebenen Quellportbereichen) zu Listener-Ports zulässt. In Clustern mit virtuellen Knoten ist die Sicherheitslistenverwaltung nie aktiviert, und Sie müssen Sicherheitsregeln immer manuell konfigurieren (entspricht "None").

Beachten Sie, dass die Anzahl der Ingress- und Egress-Regeln, die in einer Sicherheitsliste zulässig sind, begrenzt ist (siehe Limits für Sicherheitslisten). Wenn die Anzahl der Ingress- oder Egress-Regeln das Limit überschreitet und <value> auf "All" oder "Frontend" gesetzt ist, verläuft das Erstellen oder Aktualisieren des Load Balancers nicht erfolgreich.

Beispiel:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode: "Frontend"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx