Load Balancer und Network Load Balancer konfigurieren

Sie können Oracle Cloud Infrastructure Load Balancer und Network Load Balancer erstellen, um den Zugriff auf Services zu kontrollieren, die in einem Cluster ausgeführt werden:

• Wenn Sie ein Cluster im Workflow "Benutzerdefinierte Erstellung" erstellen, wählen Sie ein vorhandenes VCN mit den Netzwerkressourcen aus, die von dem neuen Cluster verwendet werden sollen. Wenn Sie den Traffic in das VCN mit einem Load Balancer oder Network Load Balancer kontrollieren möchten, wählen Sie ein vorhandenes öffentliches oder privates Subnetz in diesem VCN als Host aus.
• Wenn Sie ein Cluster im Workflow "Schnellerstellung" erstellen, enthält das automatisch erstellte VCN ein öffentliches regionales Subnetz zum Hosten eines Load Balancers oder eines Network Load Balancers. Wenn Sie einen Load Balancer oder einen Network Load Balancer in einem privaten Subnetz hosten möchten, können Sie dem VCN später ein privates Subnetz hinzufügen.

Alternativ können Sie einen internen Kubernetes-Service des Typs LoadBalancer (oft auch als "interner Load Balancer" bezeichnet) in einem Cluster definieren, damit andere Programme, die im selben VCN wie das Cluster ausgeführt werden, auf Services im Cluster zugreifen können. Ein interner Load Balancer kann bereitgestellt werden:

• als Load Balancer oder als Network Load Balancer
• mit einer öffentlichen IP-Adresse oder mit einer privaten IP-Adresse (von dem Load-Balancer-Service oder dem Network Load Balancer-Service zugewiesen)
• in einem öffentlichen Subnetz oder in einem privaten Subnetz

Ein Load Balancer oder Network Load Balancer mit einer öffentlichen IP-Adresse wird als öffentlich bezeichnet. Ein öffentlicher Load Balancer oder Network Load Balancer kann in einem öffentlichen Subnetz oder in einem privaten Subnetz gehostet werden.

Ein Load Balancer oder Network Load Balancer mit einer privaten IP-Adresse wird als privat bezeichnet. Ein privater Load Balancer oder Network Load Balancer kann in einem öffentlichen Subnetz oder in einem privaten Subnetz gehostet werden.

Standardmäßig werden interne Load Balancer mit öffentlichen IP-Adressen bereitgestellt und in öffentlichen Subnetzen gehostet.

Weitere Informationen:

• Informationen zu öffentlichen und privaten Load Balancer von Oracle Cloud Infrastructure finden Sie unter Load-Balancer-Typen.
• Informationen zu öffentlichen und privaten Network Load Balancern von Oracle Cloud Infrastructure finden Sie unter Network Load Balancer-Typen

service.beta.kubernetes.io/oci-load-balancer-internal: "true"

service.beta.kubernetes.io/oci-load-balancer-internal: "true"

service.beta.kubernetes.io/oci-load-balancer-subnet1: "ocid1.subnet.oc1..aaaaaa....vdfw"

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-internal: "true"
    service.beta.kubernetes.io/oci-load-balancer-subnet1: "ocid1.subnet.oc1..aaaaaa....vdfw"
spec:
  type: LoadBalancer
  ports:
  - port: 8100
  selector:
    app: nginx

oci-network-load-balancer.oraclecloud.com/internal: "true"

oci-network-load-balancer.oraclecloud.com/internal: "true"

oci-network-load-balancer.oraclecloud.com/subnet: "ocid1.subnet.oc1..aaaaaa....vdfw"

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
    oci-network-load-balancer.oraclecloud.com/internal: "true"
    oci-network-load-balancer.oraclecloud.com/subnet: "ocid1.subnet.oc1..aaaaaa....vdfw"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Wenn ein Kubernetes-Service des Typs LoadBalancer in einem Cluster bereitgestellt wird, erstellt die Kubernetes-Engine einen öffentlichen Oracle Cloud Infrastructure-Load Balancer oder Network Load Balancer, um Traffic in das Cluster zu akzeptieren. Standardmäßig wird dem öffentlichen Load Balancer oder Network Load Balancer von Oracle Cloud Infrastructure eine ephemere öffentliche IP-Adresse zugewiesen. Eine ephemere öffentliche IP-Adresse ist jedoch temporär und dauert nur für die Lebensdauer des öffentlichen Load Balancers oder Network Load Balancers.

Wenn der von der Kubernetes-Engine erstellte öffentliche Oracle Cloud Infrastructure-Load Balancer oder Network Load Balancer dasselbe Deployment der öffentlichen IP-Adresse nach dem Deployment aufweisen soll, können Sie ihm eine reservierte öffentliche IP-Adresse aus dem Pool der reservierten öffentlichen IP-Adressen zuweisen. Weitere Informationen zum Erstellen und Anzeigen reservierter öffentlicher IP-Adressen finden Sie unter Öffentliche IP-Adressen.

Um dem von Kubernetes Engine erstellten öffentlichen Oracle Cloud Infrastructure-Load Balancer oder Network Load Balancer eine reservierte öffentliche IP-Adresse zuzuweisen, fügen Sie die Eigenschaft LoadBalancerIP im Spezifikationsabschnitt der Manifestdatei hinzu, die den Service vom Typ LoadBalancer definiert, und geben Sie die reservierte öffentliche IP-Adresse an.

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
spec:
  loadBalancerIP: 144.25.97.173
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
spec:
  loadBalancerIP: 144.25.97.173
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Beachten Sie Folgendes:

• Wenn Sie die Eigenschaft loadBalancerIP des LoadBalancer-Service festlegen, können Sie die IP-Adresse des öffentlichen Oracle Cloud Infrastructure-Load Balancers oder Network Load Balancers, den Kubernetes Engine erstellt, später nicht direkt ändern. Wenn Sie die IP-Adresse ändern möchten, löschen Sie den Service LoadBalancer, geben Sie eine andere reservierte öffentliche IP-Adresse in der Manifestdatei an, und stellen Sie den Service LoadBalancer erneut bereit.
• Wenn Sie die Eigenschaft loadBalancerIP des LoadBalancer-Service nicht festlegen, können Sie die IP-Adresse des öffentlichen Oracle Cloud Infrastructure-Load Balancers oder Network Load Balancers, den Kubernetes Engine von einer flüchtigen IP-Adresse erstellt, später nicht direkt in eine reservierte öffentliche IP-Adresse umschalten. Wenn Sie die flüchtige IP-Adresse in eine reservierte öffentliche IP-Adresse umschalten möchten, löschen Sie den Service vom Typ LoadBalancer, setzen Sie die Eigenschaft loadBalancerIP auf eine reservierte öffentliche IP-Adresse in der Manifestdatei, und stellen Sie den Service vom Typ LoadBalancer erneut bereit.
• Sie können den Service vom Typ LoadBalancer löschen und die reservierte öffentliche IP-Adresse für andere Zwecke freigeben (z.B. um ihn einem anderen Service vom Typ LoadBalancer zuzuweisen).
• Sie können keine reservierte öffentliche IP-Adresse für einen Service vom Typ LoadBalancer angeben, wenn dieselbe IP-Adresse bereits einer anderen Ressource zugewiesen ist (z.B. einer Compute-Instanz oder einem anderen Service vom Typ LoadBalancer).
• Sie können die Eigenschaft loadBalancerIP nicht der Manifestdatei für einen internen Load-Balancer-Service hinzufügen (d.h. einer Manifestdatei, die die Annotation service.beta.kubernetes.io/oci-load-balancer-internal: "true" oder oci-network-load-balancer.oraclecloud.com/internal: "true" enthält).

• Standardmäßig wird erwartet, dass die reservierte öffentliche IP-Adresse, die Sie als Eigenschaft loadBalancerIP eines Service des Typs LoadBalancer in der Manifestdatei angeben, eine Ressource in demselben Compartment wie das Cluster ist. Wenn Sie eine reservierte öffentliche IP-Adresse in einem anderen Compartment angeben möchten:

  • für öffentliche Load Balancer die folgende Policy zum Mandanten hinzufügen:

    ALLOW any-user to read public-ips in tenancy where request.principal.type = 'cluster'
    ALLOW any-user to manage floating-ips in tenancy where request.principal.type = 'cluster'

  • Fügen Sie für Network Load Balancer die folgende Policy zum Mandanten hinzu:

    ALLOW any-user to use private-ips in TENANCY where ALL {request.principal.type = 'cluster', request.principal.compartment.id = 'target.compartment.id'}
    ALLOW any-user to manage public-ips in TENANCY where ALL {request.principal.type = 'cluster', request.principal.compartment.id = 'target.compartment.id'}

Mit Netzwerksicherheitsgruppen (NSGs) von Oracle Cloud Infrastructure können Sie den Traffic in und aus Ressourcen sowie zwischen Ressourcen kontrollieren. Die für eine NSG definierten Sicherheitsregeln stellen sicher, dass alle Ressourcen in dieser NSG denselben Sicherheitsstatus aufweisen. Weitere Informationen finden Sie unter Netzwerksicherheitsgruppen.

Mit NSGs können Sie den Zugriff auf den Oracle Cloud Infrastructure-Load Balancer oder Network Load Balancer kontrollieren, den Kubernetes Engine für einen Kubernetes-Service des Typs LoadBalancer bereitstellt.

Wenn Sie NSGs zur Kontrolle des Zugriffs verwenden, müssen entsprechende Sicherheitsregeln vorhanden sein, um eingehenden und ausgehenden Traffic zum und vom Subnetz des Load Balancers oder des Network Load Balancers zuzulassen. Siehe Sicherheitsregeln für Load Balancer und Network Load Balancer.

Wenn Sie NSGs verwenden, um den Zugriff auf Load Balancer oder Network Load Balancer zu kontrollieren:

• Sie können die NSGs und Sicherheitsregeln vom OCI-Cloud-Controller-Manager vollständig für Sie verwalten lassen (siehe Sicherheitsregelverwaltungsoptionen für Load Balancer und Network Load Balancer angeben).
• Sie können die NSGs und Sicherheitsregeln selbst verwalten und den Load Balancer oder Network Load Balancer zu den vorhandenen NSGs hinzufügen (wie in diesem Abschnitt beschrieben).
• Der OCI-Cloud-Controller-Manager kann einige Sicherheitsregeln in einer NSG verwalten, während Sie andere Sicherheitsregeln in einer anderen NSG verwalten.

Um den Zugriff mit einer von Ihnen verwalteten NSG zu kontrollieren, nehmen Sie Annotationen in die Manifestdatei auf, um die NSG anzugeben, der Sie den Load Balancer oder Network Load Balancer hinzufügen möchten.

oci.oraclecloud.com/oci-network-security-groups: "<nsg-ocid>"

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/oci-network-security-groups: "ocid1.networksecuritygroup.oc1.phx.aaaaaa....vdfw"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

oci-network-load-balancer.oraclecloud.com/oci-network-security-groups: "<nsg-ocid>"

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
    oci-network-load-balancer.oraclecloud.com/oci-network-security-groups: "ocid1.networksecuritygroup.oc1.phx.aaaaaa....vdfw"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Beachten Sie Folgendes:

• Die angegebene NSG muss sich im selben VCN wie der Oracle Cloud Infrastructure-Load Balancer oder Network Load Balancer befinden.
• Wenn die angegebene NSG zu einem anderen Compartment als dem Cluster gehört, müssen Sie eine Policy-Anweisung wie die folgende in eine IAM-Policy aufnehmen:

  ALLOW any-user to use network-security-groups in TENANCY where ALL { request.principal.type = 'cluster' }

  Wenn Sie diese Policy-Anweisung als zu permissiv erachten, können Sie die Berechtigung einschränken, das Compartment, zu dem die NSG gehört, explizit anzugeben und/oder das Cluster explizit anzugeben. Beispiel:

  Allow any-user to use network-security-groups in compartment <compartment-ocid> where all { request.principal.id = '<cluster-ocid>' }

• Sie können bis zu fünf NSGs in einer kommagetrennten Liste im folgenden Format angeben:

  oci.oraclecloud.com/oci-network-security-groups: "<nsg1-ocid>,<nsg2-ocid>,<nsg3-ocid>,<nsg4-ocid>,<nsg5-ocid>"

• Um einen Load Balancer oder Network Load Balancer aus einer NSG zu entfernen oder die NSG zu ändern, in der sich der Load Balancer oder Network Load Balancer befindet, aktualisieren Sie die Annotation, und wenden Sie das Manifest erneut an.

• Wenn Sie den Zugriff auf einen Oracle Cloud Infrastructure-Load Balancer oder Network Load Balancer mit einer von Ihnen verwalteten NSG kontrollieren möchten, empfiehlt Oracle, das Kubernetes-Sicherheitslistenmanagement zu deaktivieren, indem Sie eine der folgenden Annotationen im Metadatenabschnitt der Manifestdatei für den Load Balancer bzw. Network Load Balancer hinzufügen:

  service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode: "None"

  oci-network-load-balancer.oraclecloud.com/security-list-management-mode:  "None"

  Alternativ können Sie die folgende äquivalente Anmerkung hinzufügen:

  oci.oraclecloud.com/security-rule-management-mode: "None" 

  Wenn Sie der Empfehlung folgen und die Anmerkung hinzufügen, ist die Verwaltung der Kubernetes-Sicherheitsliste nicht aktiviert. Sie müssen NSGs mit Ingress- und Egress-Sicherheitsregeln für Knotenpools und den Kubernetes-API-Endpunkt einrichten (weitere Informationen finden Sie unter Sicherheitsregelkonfiguration in Netzwerksicherheitsgruppen und/oder Sicherheitslisten und Beispielkonfigurationen für Netzwerkressourcen). Außerdem müssen Sie NSGs mit Ingress- und Egress-Sicherheitsregeln für den Health-Port "kube-proxy", für den Health-Check-Portbereich und für Load Balancer einrichten.

Sicherheitsregeln steuern den Zugriff auf die Oracle Cloud Infrastructure-Load Balancer und Network Load Balancer, die für Kubernetes-Services des Typs LoadBalancer bereitgestellt werden. Die Sicherheitsregeln können wie folgt verwaltet (d.h. erstellt, aktualisiert und gelöscht) werden:

• In einer Netzwerksicherheitsgruppe oder NSG (empfohlen) Die Sicherheitsregeln in einer NSG gelten für alle Kubernetes-Ressourcen, die der NSG hinzugefügt werden. Daher können NSGs eine fein granulierte Zugriffskontrolle für einzelne Ressourcen bereitstellen.
• In einer Sicherheitsliste. Die Sicherheitsregeln in einer Sicherheitsliste gelten für alle Kubernetes-Ressourcen in einem Subnetz. Sicherheitslisten bieten keine feingranulierte Zugriffskontrolle für einzelne Ressourcen im Subnetz.

Wichtige Informationen zur Funktionsweise von Sicherheitsregeln und einen allgemeinen Vergleich von Sicherheitslisten und Netzwerksicherheitsgruppen finden Sie unter Sicherheitsregeln.

Sie können die Sicherheitsregeln selbst verwalten, Regeln nach Bedarf erstellen, aktualisieren und löschen. Alternativ können Sie angeben, dass der oci-cloud-controller-manager (der auf der Cluster-Control Plane ausgeführt wird) einige oder alle Sicherheitsregeln für Sie verwalten soll. Kubernetes Engine verwendet den oci-cloud-controller-manager, um Load Balancer und Network Load Balancer für Kubernetes-Services des Typs LoadBalancer bereitzustellen.

Mit verschiedenen Annotationen können Sie wie folgt angeben, ob der OCI-Cloud-Controller-Manager Sicherheitsregeln für einen Load Balancer oder Network Load Balancer in einer NSG oder in einer Sicherheitsliste verwaltet:

• Um Sicherheitsregeln in einer NSG zu verwalten, verwenden Sie die Annotation oci.oraclecloud.com/security-rule-management-mode: "NSG" (empfohlen).

  Wenn der OCI-Cloud-Controller-Manager Sicherheitsregeln in einer NSG verwalten soll (wie von Oracle empfohlen), müssen Sie die oci.oraclecloud.com/security-rule-management-mode: "NSG"-Annotation verwenden. Weitere Informationen zur Verwendung dieser Annotation finden Sie unter Sicherheitsregeln in NSGs und Sicherheitslisten mit der Annotation oci.oraclecloud.com/security-rule-management-mode verwalten.

• Um Sicherheitsregeln in einer Sicherheitsliste zu verwalten, verwenden Sie entweder die oci.oraclecloud.com/security-rule-management-mode-Annotation oder die service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode- und oci-network-load-balancer.oraclecloud.com/security-list-management-mode-Annotationen.

  Wenn der OCI-Cloud-Controller-Manager Sicherheitsregeln in der Sicherheitsliste eines Load Balancers oder eines Network Load Balancers verwalten soll, führen Sie einen der folgenden Schritte aus:

  • Verwenden Sie die Annotation oci.oraclecloud.com/security-rule-management-mode, die auf "SL-All" oder "SL-Frontend" gesetzt ist. Weitere Informationen zur Verwendung dieser Annotation finden Sie unter Sicherheitsregeln in NSGs und Sicherheitslisten mit der Annotation oci.oraclecloud.com/security-rule-management-mode verwalten.
  • Verwenden Sie die Annotationen service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode bzw. oci-network-load-balancer.oraclecloud.com/security-list-management-mode, die auf "All" oder "Frontend" gesetzt sind. Weitere Informationen zur Verwendung dieser beiden Annotationen finden Sie unter Verwaltungsoptionen für Sicherheitslisten beim Provisioning eines OCI Load Balancers angeben und Verwaltungsoptionen für Sicherheitslisten beim Provisioning eines OCI Network Load Balancers angeben.

Unabhängig von den verwendeten Annotationen und unabhängig davon, ob Sie oder der oci-cloud-controller-manager Sicherheitsregeln in einer Sicherheitsliste oder in einer NSG verwalten, können Sie auch die OCID einer oder mehrerer zusätzlicher NSGs angeben, denen der oci-cloud-controller-manager den Load Balancer oder Network Load Balancer hinzufügen soll. In diesem Fall verwenden Sie die Annotation oci.oraclecloud.com/oci-network-security-groups oder oci-network-load-balancer.oraclecloud.com/oci-network-security-groups. Beachten Sie, dass der oci-cloud-controller-manager die Sicherheitsregeln in den zusätzlichen NSGs, die in diesen Annotationen angegeben werden, nicht verwaltet. Daher liegt es in Ihrer Verantwortung, die Sicherheitsregeln zu verwalten. Weitere Informationen zur Verwendung der Annotationen oci.oraclecloud.com/oci-network-security-groups oder oci-network-load-balancer.oraclecloud.com/oci-network-security-groups finden Sie unter Netzwerksicherheitsgruppen angeben (empfohlen).

Oracle Cloud Infrastructure-Load Balancer und Network Load Balancer wenden eine Health Check Policy an, um Backend-Server kontinuierlich zu überwachen. Ein Health Check ist ein Test zur Bestätigung der Verfügbarkeit des Backend-Servers und kann eine Anforderung oder ein Verbindungsversuch sein. Wenn ein Server die Health-Check-Bedingungen nicht erfüllt, nimmt der Load Balancer oder Network Load Balancer den Server vorübergehend aus der Rotation. Wenn der Server die Health-Check-Bedingungen erfüllt, lässt ihn der Load Balancer oder Network Load Balancer wieder in die Rotation zurück.

Health Check Policys enthalten eine Reihe von Parametern mit jeweils einem Standardwert. Wenn die Kubernetes-Engine einen OCI-Load Balancer oder Network Load Balancer für einen Kubernetes-Service des Typs LoadBalancer bereitstellt, können Sie Standardwerte für Health-Check-Parameter außer Kraft setzen, indem Sie Annotationen in den Metadatenabschnitt der Manifestdatei aufnehmen. Sie können diese Anmerkungen später hinzufügen, ändern und löschen. Wenn Sie eine Anmerkung löschen, die einen Wert für einen Health-Check-Parameter angegeben hat, verwendet der Load Balancer oder Network Load Balancer stattdessen den Standardwert des Parameters.

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-health-check-retries: "5"
    service.beta.kubernetes.io/oci-load-balancer-health-check-interval: "15000"
    service.beta.kubernetes.io/oci-load-balancer-health-check-timeout: "4000"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
    oci-network-load-balancer.oraclecloud.com/health-check-retries: "5"
    oci-network-load-balancer.oraclecloud.com/health-check-interval: "15000"
    oci-network-load-balancer.oraclecloud.com/health-check-timeout: "4000"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Beachten Sie, dass die folgenden Standardwerte verwendet werden, wenn Sie keine Health-Check-Parameterwerte explizit angeben, indem Sie Annotationen in den Metadatenabschnitt der Manifestdatei aufnehmen:

Weitere Informationen zu den Health Check Policys von Oracle Cloud Infrastructure-Load Balancer und Network Load Balancer finden Sie unter:

• Health Checks für Load Balancer
• Health Check Policys für Network Load Balancer

Eingehender Traffic zu einem Oracle Cloud Infrastructure-Load Balancer oder Network Load Balancer wird zwischen den Backend-Servern in einem Backend-Set verteilt. Wenn Kubernetes Engine einen Oracle Cloud Infrastructure-Load Balancer oder Network Load Balancer für einen Kubernetes-Service vom Typ LoadBalancer bereitstellt, sind standardmäßig alle Worker-Knoten im Cluster im Backend-Set enthalten.

Sie können jedoch nur eine Teilmenge von Worker-Knoten in einem Cluster auswählen, die in das Backend-Set eines bestimmten Load Balancers oder Network Load Balancers aufgenommen werden sollen. Wenn Sie Teilmengen der Worker-Knoten eines Clusters in die Backend-Sets verschiedener Load Balancer und Network Load Balancer aufnehmen, können Sie ein einzelnes Kubernetes-Cluster als mehrere logische Cluster (Services) darstellen.

oci.oraclecloud.com/node-label-selector: <label>

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/node-label-selector: lbset=set1
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

oci-network-load-balancer.oraclecloud.com/node-label-selector: <label>

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
    oci-network-load-balancer.oraclecloud.com/node-label-selector: lbset=set1
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Verwenden Sie die standardmäßige Kubernetes-Labelselektornotation, um die Labelschlüssel und -werte in den Annotationen im Metadatenabschnitt der Manifestdatei anzugeben. Weitere Informationen zur standardmäßigen Kubernetes-Labelselektornotation finden Sie unter Labelselektoren in der Kubernetes-Dokumentation.

Die Tabelle enthält einige Beispiele für die standardmäßige Kubernetes-Labelauswahl.

Wenn die Kubernetes-Engine einen Load Balancer oder Network Load Balancer für einen Kubernetes-Service des Typs LoadBalancer bereitstellt, können Sie eine Policy für das Backend-Set definieren, um anzugeben, wie eingehender Traffic auf die Backend-Server verteilt werden soll.

Weitere Informationen:

• Informationen zu Load Balancern und Backend-Set-Policys finden Sie unter Load-Balancer-Policys.
• Informationen zu Network Load Balancern und Backend-Set-Policys finden Sie unter Network Load Balancer Policys

oci.oraclecloud.com/loadbalancer-policy: <value>

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/loadbalancer-policy: "LEAST_CONNECTIONS"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

oci-network-load-balancer.oraclecloud.com/backend-policy: <value>

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
    oci-network-load-balancer.oraclecloud.com/backend-policy: "THREE_TUPLE"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Wenn Kubernetes Engine einen Oracle Cloud Infrastructure-Load Balancer oder Network Load Balancer für einen Kubernetes-Service des Typs LoadBalancer bereitstellt, können Sie mit einem Pod Readiness Gate sicherstellen, dass Traffic nur an Pods weitergeleitet wird, die erfolgreich zum Backend-Set hinzugefügt wurden und Traffic empfangen können. Beachten Sie, dass Sie Podbereitschaftsgates für Pods angeben können, die auf virtuellen Knoten ausgeführt werden, aber nicht für Pods, die auf verwalteten Knoten ausgeführt werden. Definieren Sie keine Podbereitschaftsgates für Pods, die auf verwalteten Knoten ausgeführt werden.

Podbereitschaftsgates sind zusätzliche Bedingungen, um anzuzeigen, dass ein Pod für den Empfang von Traffic bereit ist. Mit Podbereitschaftsgates können Sie komplexe benutzerdefinierte Bereitschaftsprüfungen implementieren und bei rollierenden Deployments Ausfallzeiten vermeiden. Weitere Informationen finden Sie unter Details zur Podbereitschaft in der Kubernetes-Dokumentation.

Beim Provisioning eines Load Balancers oder eines Network Load Balancers umfasst das Backend-Set die IP-Adressen der Podreplikate eines Deployments mit der Bedingung Ready. Wenn Sie das Deployment aktualisieren (z.B. um ein neues Image zu verwenden), werden vorhandene Podreplikate durch neue Podreplikate ersetzt. Das Ersetzen aller Podreplikate kann jedoch einige Zeit in Anspruch nehmen und zu einer Nichtverfügbarkeit des Backends führen, da:

• Die vorhandenen Podreplikate können beendet werden, bevor das Backend-Set mit den IP-Adressen der neuen Podreplikate aktualisiert wurde.
• Das Backend-Set kann mit den IP-Adressen der neuen Podreplikate aktualisiert werden, bevor die neuen Podreplikate für den Empfang von Traffic bereit sind.

Durch die Angabe der Verwendung eines Podbereitschaftsgate wird sichergestellt, dass Backends immer für den Load Balancer oder Network Load Balancer verfügbar sind. Vorhandene Pods werden erst beendet, wenn dem Backend-Set neue Pods hinzugefügt wurden und die neuen Pods bereit sind, Traffic zu empfangen.

Um anzugeben, dass die Kubernetes-Engine ein Podbereitschaftsgate in die Podspezifikation jedes in einem bestimmten Namespace erstellten Pods einfügen soll, fügen Sie das Label loadbalancer.oci.oraclecloud.com/pod-readiness-gate-inject=enabled dem Namespace hinzu, indem Sie Folgendes eingeben:

kubectl label ns <namespace> loadbalancer.oci.oraclecloud.com/pod-readiness-gate-inject=enabled

Im folgenden Beispiel wird gezeigt, wie Sie einen Load Balancer mit einem Pod Readiness Gate erstellen.

Beschriften Sie zunächst den pdr-Namespace, um das Podreife-Gate für den Namespace anzugeben, indem Sie Folgendes eingeben:

kubectl label ns pdr loadbalancer.oci.oraclecloud.com/pod-readiness-gate-inject=enabled

Die Ausgabe des Befehls bestätigt, dass der Namespace beschriftet wurde:

namespace/pdr labeled

Stellen Sie dann Nginx im Namespace pdr bereit, indem Sie Folgendes eingeben:

kubectl apply -f https://raw.githubusercontent.com/oracle-devrel/oci-oke-virtual-nodes/main/nginx-svc/nginx.yaml -n pdr

Listen Sie die Pods im Namespace pdr auf, indem Sie Folgendes eingeben:

kubectl get pods -n pdr

Jetzt können Sie die Verwendung des Podreife-Gate demonstrieren, indem Sie die Imageversion im Nginx-Manifest aktualisieren und das Manifest erneut anwenden, sodass vorhandene Pods durch neue Pods ersetzt werden.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25.1
...

Wenden Sie das Manifest erneut an, indem Sie Folgendes eingeben:

kubectl apply -f ./nginx.yaml -n pdr

Beobachten Sie die neuen Pods, die eingeführt werden, indem Sie Folgendes eingeben:

kubectl get pods -o wide -n pdr

Beispiel:

NAME                     READY   STATUS    RESTARTS   AGE   IP            NODE          NOMINATED NODE   READINESS GATES
nginx-678976847c-8bqs7   1/1     Running   0          44m   10.0.10.153   10.0.10.253   <none>           1/1
nginx-678976847c-ttqms   1/1     Running   0          47m   10.0.10.201   10.0.10.253   <none>           1/1

Beobachten Sie den Status eines der neuen Pods, indem Sie Folgendes eingeben:

kubectl describe pod <pod-name> -n pdr

Beispiel:

kubectl describe pod nginx-678976847c-ttqms  -n pdr

Die Ausgabe des Befehls bestätigt den Status des podreadiness.loadbalancer.oraclecloud.com-Bereitschaftsgate. Beispiel:

...
Readiness Gates:
  Type                                                             Status
  podreadiness.loadbalancer.oraclecloud.com/f913fe603a9be9b5d51f   True 
Conditions:
  Type                                                             Status
  podreadiness.loadbalancer.oraclecloud.com/f913fe603a9be9b5d51f   True 
  PodScheduled                                                     True 
  Initialized                                                      True 
  Ready                                                            True 
  ContainersReady                                                  True 

Wenn die Kubernetes-Engine einen Oracle Cloud Infrastructure-Load Balancer oder Network Load Balancer für einen Kubernetes-Service des Typs LoadBalancer bereitstellt, können Sie angeben, wie Traffic, der aus einem Cluster stammt, an die IP-Adresse des Load Balancers oder Network Load Balancers weitergeleitet wird.

In Clustern, auf denen Kubernetes-Version 1.30 oder höher ausgeführt wird, ist das Kubernetes-Feature-Gate LoadBalancerIPMode aktiviert, und das Feld ipMode eines Service vom Typ LoadBalancer hat den Standardwert "VIP". Wenn ipMode den Wert "VIP" aufweist, wird der Traffic, der von einem Pod innerhalb des Clusters an die IP-Adresse eines Service des Typs LoadBalancer gesendet wird, direkt an Anwendungspods weitergeleitet, um die Performance zu optimieren, wobei der LoadBalancer-Service umgangen wird. Weitere Informationen finden Sie unter IPMode des Load-Balancer-Status angeben in der Kubernetes-Dokumentation.

In einigen Situationen können Sie jedoch entscheiden, dass das Routing des Traffics direkt an Anwendungspods nicht geeignet ist. Beispiel: Wenn Traffic, der aus einem Cluster stammt, direkt an Anwendungspods weitergeleitet wird, können Sie die SSL-Beendigung nicht auf Load-Balancer-Ebene implementieren.

Um anzugeben, wie Traffic, der an die IP-Adresse des Load Balancers oder Network Load Balancers gesendet wird, aus dem Cluster heraus weitergeleitet werden soll, fügen Sie die folgende Annotation im Metadatenabschnitt der Manifestdatei hinzu:

oci.oraclecloud.com/ingress-ip-mode: <value>

Hierbei ist <value> einer der folgenden Werte:

• "VIP": Der gesamte Traffic, der aus dem Cluster stammt und an die IP-Adresse eines Service des Typs LoadBalancer gesendet wird, wird direkt an die Anwendungspods weitergeleitet, um die Performance zu optimieren. Dabei wird der LoadBalancer-Service umgangen.
• "proxy": Der gesamte Traffic, der aus dem Cluster stammt und an die IP-Adresse eines Service des Typs LoadBalancer gesendet wird, wird an den Oracle Cloud Infrastructure-Load Balancer oder Network Load Balancer weitergeleitet, der für den LoadBalancer-Service bereitgestellt wurde. Der Load Balancer oder Network Load Balancer leitet den Traffic dann an die Anwendungspods weiter.

Beispiel:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/ingress-ip-mode: "proxy"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Wenn Sie die oci.oraclecloud.com/ingress-ip-mode-Annotation nicht angeben oder die Annotation anschließend entfernen, hat die Eigenschaft ipMode eines Service vom Typ LoadBalancer den Standardwert "VIP".

Beachten Sie außerdem, dass der Network Load Balancer bei Verwendung eines privaten Network Load Balancers, bei dem die Annotation oci-network-load-balancer.oraclecloud.com/is-preserve-source auf true gesetzt ist, eine bekannte Einschränkung aufweist, die keinen Traffic zulässt, bei dem der Quellknoten und der Ziel-Backend-Knoten denselben Knoten aufweisen. Diese Einschränkung verhindert die Kommunikation zwischen Pods auf demselben Knoten über den Network Load Balancer, wenn die folgenden Bedingungen erfüllt sind:

• Die oci.oraclecloud.com/ingress-ip-mode-Annotation ist auf proxy gesetzt.
• Die oci-network-load-balancer.oraclecloud.com/is-preserve-source-Annotation ist auf true gesetzt.
• Der Network Load Balancer ist privat.

Wenn die Kubernetes-Engine einen Oracle Cloud Infrastructure-Load Balancer oder Network Load Balancer für einen Kubernetes-Service des Typs LoadBalancer bereitstellt, bestimmt das Load-Balancer-Subnetz die Kontrolle über die IP-Adressfamilie der IP-Adresse, über die der Load Balancer oder Network Load Balancer Traffic empfängt.

• Wenn das Subnetz ein IPv4-Einzelstacksubnetz ist, ist das Subnetz nur für die IPv4-Adressierung konfiguriert. Dem Load Balancer oder Network Load Balancer wird nur eine IPv4-Adresse zugewiesen, für die externer Traffic empfangen werden soll. Sie können die IP-Adressfamilie der IP-Adresse, an der der Load Balancer oder Network Load Balancer externen Traffic empfängt, nicht ändern.
• Wenn das Subnetz ein IPv4/IPv6-Subnetz mit dualem Stack ist, ist das Subnetz sowohl für die IPv4- als auch für die IPv6-Adressierung konfiguriert. Dem Load Balancer oder Network Load Balancer kann entweder eine IPv4-Adresse oder eine IPv6-Adresse zugewiesen werden, an die der externe Traffic gesendet werden soll. In diesem Fall können Sie mit den Kubernetes-Feldern spec.ipFamilyPolicy und spec.ipFamilies im Servicemanifest angeben, ob der Load Balancer oder Network Load Balancer externen Traffic nur an der IPv4-Adresse oder nur an der IPv6-Adresse oder sowohl an der IPv4-Adresse als auch an der IPv6-Adresse empfängt.

Beachten Sie, dass die IP-Adressfamilie, die für den Traffic zwischen dem Listener und dem Backend-Set verwendet wird, für Load Balancer und Network Load Balancer unterschiedlich bestimmt wird:

• Load Balancer: Der Traffic zwischen einem Load Balancer Listener und dem Backend-Set verwendet immer IPv4-Adressen.
• Network Load Balancer: Der Traffic zwischen einem Network Load Balancer Listener und dem Backend-Set verwendet dieselbe IP-Adressfamilie wie die IP-Adresse, an der der Network Load Balancer Listener externen Traffic empfängt.

Die Tabelle zeigt die Interaktion zwischen der IP-Adressfamilie des Load-Balancer-Subnetzes, den Einstellungen von spec.ipFamilyPolicy und spec.ipFamilies, der IP-Adressfamilie, aus der IP-Adressen dem Load Balancer oder Network Load Balancer zugewiesen werden, und dem IP-Protokoll zwischen dem Listener und dem Backend-Set. Beachten Sie, dass nur gültige Kombinationen angezeigt werden.

Wenn Sie mit der service.beta.kubernetes.io/oci-load-balancer-subnet1-Annotation ein alternatives Subnetz zum Subnetz angeben, das bei der Erstellung des Clusters für Load Balancer angegeben wurde, stellen Sie sicher, dass die Adressfamilie des alternativen Subnetzes mit den Feldern spec.ipFamilyPolicy und spec.ipFamilies im Servicemanifest kompatibel ist.

Weitere Informationen zur Unterstützung von IPv4 und IPv6 in Kubernetes finden Sie in der Kubernetes-Dokumentation unter IPv4/IPv6 dual-stack.

apiVersion: v1
kind: Service
metadata:
  name: nginx-lb
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb" 
spec:
  type: LoadBalancer
  ipFamilyPolicy: RequireDualStack
  ipFamilies:
  - IPv6
  - IPv4
  ports:
  - name: http
    port: 80
    targetPort: 80
  selector:
    app: nginx

apiVersion: v1
kind: Service
metadata:
  name: nginx-lb
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-subnet1: "ocid1.subnet.oc1..aaaaaa....vdfw"  
spec:
  type: LoadBalancer
  ipFamilyPolicy: PreferDualStack
  ipFamilies:
  - IPv4
  - IPv6
  ports:
  - name: http
    port: 80
    targetPort: 80
  selector:
    app: nginx

Wenn Kubernetes Engine einen Oracle Cloud Infrastructure-Network Load Balancer für einen Kubernetes-Service vom Typ LoadBalancer bereitstellt, weist der Network Load Balancer-Service dem Network Load Balancer mindestens eine IP-Adresse zu.

Der Network Load Balancer-Service weist eine private IPv4-Adresse zu und weist im Fall eines externen Network Load Balancers außerdem eine zusätzliche öffentliche IPv4-Adresse zu. Wenn das Subnetz des Network Load Balancers kompatibel ist, kann der Network Load Balancer-Service auch eine IPv6-Adresse zuweisen (siehe IP-Adressfamilien für Load Balancer und Network Load Balancer angeben).

In Clustern, auf denen Kubernetes-Version 1.29 oder höher ausgeführt wird, können Sie die IP-Adresse angeben, die dem Network Load Balancer zugewiesen werden soll, anstatt dass der Network Load Balancer-Service die zuzuweisende IP-Adresse wählt. Die IP-Adresse, die Sie zuweisen können, hängt wie folgt von der IP-Adressfamilie des Network Load Balancer-Subnetzes ab:

• IPv4: Wenn das Subnetz des Network Load Balancers ein IPv4-Einzelstapelsubnetz oder ein IPv4/IPv6-Dual-Stack-Subnetz ist, können Sie dem Network Load Balancer eine private IPv4-Adresse zuweisen.
• IPv4 und IPv6: Wenn das Subnetz des Network Load Balancers ein Dual-Stack-Subnetz IPv4/IPv6 ist, können Sie dem Network Load Balancer entweder eine private IPv4-Adresse und eine IPv6-Adresse zuweisen.

Um eine private IPv4-Adresse anzugeben, die einem Network Load Balancer zugewiesen werden soll, fügen Sie die folgende Annotation im Metadatenabschnitt der Manifestdatei hinzu:

oci-network-load-balancer.oraclecloud.com/assigned-private-ipv4: "<ipv4-address>"

wobei <ipv4-address> eine gültige IPv4-Adresse aus dem IPv4 CIDR-Block ist, der für das Subnetz des Network Load Balancers angegeben wurde. Beispiel:

oci-network-load-balancer.oraclecloud.com/assigned-private-ipv4: "10.0.0.1"

Um eine IPv6-Adresse anzugeben, die einem Network Load Balancer zugewiesen werden soll, fügen Sie die folgende Annotation im Metadatenabschnitt der Manifestdatei hinzu:

oci-network-load-balancer.oraclecloud.com/assigned-ipv6: "<ipv6-address>"

wobei <ipv6-address> eine gültige ULA- oder GUA-Adresse IPv6 aus dem IPv6-CIDR-Block ist, der für das Subnetz des Network Load Balancers angegeben wurde. Beispiel:

• oci-network-load-balancer.oraclecloud.com/assigned-ipv6: "fd8a:4b3c:7d91:abcd::1"
• oci-network-load-balancer.oraclecloud.com/assigned-ipv6: "2607:9b80:9a0a:9a7e:abcd:ef01:2345:6789"

Beispiel:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
    oci-network-load-balancer.oraclecloud.com/assigned-private-ipv4: "10.0.0.1"
    oci-network-load-balancer.oraclecloud.com/assigned-ipv6: "fd8a:4b3c:7d91:abcd::1"
spec:
  type: LoadBalancer
  ipFamilyPolicy: RequireDualStack
  ipFamilies:
  - IPv6
  - IPv4
  ports:
  - port: 80
  selector:
    app: nginx

Es liegt in Ihrer Verantwortung, eine gültige IP-Adresse anzugeben. Damit eine IP-Adresse gültig ist, müssen die folgenden Bedingungen erfüllt sein:

• Die IP-Adresse muss das richtige Format für die von Ihnen verwendete Anmerkung aufweisen (IPv4 oder IPv6).
• Die IP-Adresse muss aus dem entsprechenden CIDR-Block stammen, der für das Subnetz des Network Load Balancers angegeben ist.
• Die IP-Adresse darf nicht bereits von einer anderen Ressource verwendet werden.

Beachten Sie Folgendes:

• Wenn die IP-Adresse nicht das richtige Format hat oder nicht aus dem entsprechenden CIDR-Block stammt, wird die Anforderung zum Erstellen des Network Load Balancers nicht akzeptiert.
• Wenn die IP-Adresse das richtige Format und den entsprechenden CIDR-Block aufweist, die IP-Adresse jedoch bereits von einer anderen Ressource verwendet wird, wird die Anforderung zum Erstellen des Network Load Balancers akzeptiert. Die verknüpfte Arbeitsanforderung ist jedoch nicht erfolgreich, und das Compartment enthält einen Network Load Balancer mit dem Status "Nicht erfolgreich".
• Wenn die IP-Adresse gültig ist, wird der Network Load Balancer mit der angegebenen IP-Adresse erstellt, die ihm zugewiesen ist.

Wenn Kubernetes Engine einen öffentlichen Oracle Cloud Infrastructure-Network Load Balancer für einen Kubernetes-Service des Typs LoadBalancer bereitstellt, weist der Network Load Balancer-Service dem Network Load Balancer sowohl eine öffentliche IP-Adresse als auch eine private IP-Adresse zu. Die private IP-Adresse wird für Health Checks und Port Address Translation (PAT) verwendet, kann jedoch keinen externen Traffic von außerhalb des VCN (einschließlich aus dem öffentlichen Internet) empfangen.

Um die öffentlichen und privaten IP-Adressen anzuzeigen, die der Network Load Balancer-Service dem Network Load Balancer zugewiesen hat, geben Sie den Befehl kubectl get service (oder Ähnliches) ein. Beispiel:

kubectl get service my-nginx-svc -o json | jq .status

{
  "loadBalancer": {
    "ingress": [
      {
        "ip": "203.0.113.2"
      },
      {
        "ip": "10.30.3.24"
      }
    ]
  }
}

In einigen Situationen möchten Sie möglicherweise nur die öffentliche IP-Adresse des Network Load Balancers angeben und die private IP-Adresse ausblenden. Beispiel:

• Sie können einen benutzerfreundlichen DNS-Namen für den Network Load Balancer angeben, wenn Sie das Add-on ExternalDNS verwenden, indem Sie die Annotation external-dns.alpha.kubernetes.io/hostname in das Manifest des Kubernetes-Service vom Typ LoadBalancer aufnehmen. ExternalDNS erstellt einen DNS-Datensatz für den Network Load Balancer im externen DNS-Provider, den Sie für das Cluster konfiguriert haben. Der DNS-Datensatz ordnet den DNS-Namen sowohl der öffentlichen IP-Adresse als auch der privaten IP-Adresse zu. Wenn also externer Traffic den DNS-Namen verwendet, besteht die Möglichkeit, dass Traffic an die private IP-Adresse des Network Load Balancers weitergeleitet wird, obwohl die private IP-Adresse keinen externen Traffic empfangen kann.
• Sie können eine Automatisierung einrichten, die den Befehl kubectl get service (oder ähnliches) verwendet, um die IP-Adresse des Network Load Balancers abzurufen. Wenn Ihr Anwendungsfall das Routing von externem Traffic enthält, möchten Sie nur die öffentliche IP-Adresse des Network Load Balancers. Standardmäßig gibt der Befehl kubectl get service jedoch sowohl die öffentliche IP-Adresse des Network Load Balancers als auch die zugehörige private IP-Adresse zurück.

Um anzugeben, dass der Befehl kubectl get service (oder ein ähnliches) nur die öffentliche IP-Adresse des Network Load Balancers zurückgibt, fügen Sie die folgende Annotation im Metadatenabschnitt der Manifestdatei hinzu:

oci-network-load-balancer.oraclecloud.com/external-ip-only: "true"

Beachten Sie, dass "false" der Standardwert der oci-network-load-balancer.oraclecloud.com/external-ip-only-Annotation ist. Wenn Sie die Annotation nicht explizit in die Servicedefinition aufnehmen, gibt der Befehl kubectl get service (oder ähnlich) sowohl die öffentliche IP-Adresse des Network Load Balancers als auch die private IP-Adresse zurück.

Beispiel:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
    oci-network-load-balancer.oraclecloud.com/external-ip-only: "true"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Wenn Sie die oci-network-load-balancer.oraclecloud.com/external-ip-only: "true"-Annotation in das Manifest aufnehmen und den Befehl kubectl get service (oder ähnlich) eingeben, wird nur die öffentliche IP-Adresse zurückgegeben. Beispiel:

kubectl get service my-nginx-svc -o json | jq .status

{
  "loadBalancer": {
    "ingress": [
      {
        "ip": "203.0.113.2"
      }
    ]
  }
}

Sie können bestimmte Worker-Knoten aus der Liste der Backend-Server im Backend-Set eines Oracle Cloud Infrastructure-Load-Balancers oder Network Load Balancers ausschließen. Weitere Informationen finden Sie unter node.kubernetes.io/exclude-from-external-load-balancers.

Sie können einem Load Balancer oder Network Load Balancer Tags hinzufügen, die von der Kubernetes-Engine für einen Kubernetes-Service des Typs LoadBalancer bereitgestellt werden. Mit Tagging können Sie verschiedene Ressourcen über Compartments hinweg gruppieren. Außerdem können Sie Ressourcen mit Ihren eigenen Metadaten annotieren. Siehe Tags auf Load Balancer anwenden.

Wenn Kubernetes Engine einen Oracle Cloud Infrastructure-Load Balancer oder Network Load Balancer für einen Kubernetes-Service des Typs LoadBalancer bereitstellt, können Sie angeben, ob das Proxyprotokollfeature mit TCP-basierten Listenern aktiviert werden soll. Wenn Sie das Proxyprotokoll aktivieren, können Transportverbindungsinformationen wie die IP-Adresse eines Clients sicher über mehrere Proxylayer an den Backend-Server übertragen werden. Die folgenden Proxyprotokollversionen sind verfügbar:

• Version 1, die einen textbasierten Header verwendet, um Informationen über Proxys weiterzuleiten, und ist am besten für kleine Implementierungen geeignet.
• Version 2, die einen textbasierten und binären Header für mehr Effizienz beim Erstellen und Parsen verwendet und am besten für größere Implementierungen geeignet ist.

Load Balancer, die von der Kubernetes Engine bereitgestellt werden, unterstützen Proxyprotokollversion 1 und Version 2. Network Load Balancer, die von der Kubernetes Engine bereitgestellt werden, unterstützen Proxyprotokollversion 2.

Weitere Informationen:

• Informationen zu Load Balancern und dem Proxyprotokollfeature finden Sie unter Proxyprotokoll für Load Balancer.
• Informationen zu Network Load Balancern und der Proxyprotokollfunktion finden Sie unter Proxy Protocol für Network Load Balancer.

service.beta.kubernetes.io/oci-load-balancer-connection-proxy-protocol-version: "<value>"

oci-network-load-balancer.oraclecloud.com/is-ppv2-enabled: "<value>"