Einrichten eines Private Path- Network Load Balancer for VPC s

Virtual Private Cloud4.16 und höher

In vollständig privaten VPC-Umgebungen ohne öffentlichen Internetzugang können Sie einen Private Path Network Load Balancer verwenden, um den Netzwerkverkehr auszugleichen, der zu den in Ihren VPC-Clustern ausgeführten Anwendungen fließt. Weitere Informationen finden Sie in den Anwendungsfällen des Dienstes Private Trasse.

Voraussetzungen

  1. Rufen Sie Ihren Red Hat OpenShift-Cluster auf.

  2. Wenn Sie noch keine laufende Anwendung haben, stellen Sie eine Anwendung in Ihrem Cluster bereit. Stellen Sie sicher, dass Sie im Metadatenabschnitt der Konfigurationsdatei für die Bereitstellung eine Bezeichnung hinzufügen. Mit dieser angepassten Bezeichnung werden alle Pods gekennzeichnet, in denen Ihre App ausgeführt wird und die in den Lastausgleich einbezogen werden sollen.

Konfigurieren des Dienstes LoadBalancer

  1. Kopieren Sie die LoadBalancer Konfiguration und speichern Sie sie in einer Datei mit dem Namen lb.yaml.

    apiVersion: v1
kind: Service
metadata:
  name: <app_name>-vpc-nlb-<VPC_zone>
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "private-path" # Required
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private" # Required
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet_ID>"
spec:
  type: LoadBalancer
  selector:
    <selector_key>: <selector_value>
  ports:
   - name: http
     protocol: TCP
     port: 8080
     targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
   - name: https
     protocol: TCP
     port: 443
     targetPort: 443 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
  externalTrafficPolicy: Local # Specify Local or Cluster.

  2. Passen Sie die Felder für Ihren Anwendungsfall an. Eine vollständige Liste der Anmerkungen finden Sie unter Anmerkungen und Spezifikationen.

  3. Speichern Sie Ihre Änderungen.

  4. Stellen Sie den Load Balancer-Dienst in Ihrem Cluster bereit.

    oc apply -f lb.yaml

Erstellen eines Private Path-Dienstes

Folgen Sie den Anweisungen zum Erstellen eines Dienstes "Private Path".

Einrichten eines virtuellen privaten Endpunkt-Gateways

Nachdem Sie nun einen Load Balancer-Dienst konfiguriert haben, müssen Sie ein Virtual Private Endpoint (VPE)-Gateway für den Zugriff auf die Anwendungen in Ihrem Cluster einrichten.

Weitere Informationen finden Sie unter Erstellen eines Endpunkt-Gateways in der Benutzeroberfläche.

Verbinden mit Ihren Anwendungen über Ihr VPE

Informationen zum Herstellen einer Verbindung zu Ihren Anwendungen über Ihren VPE finden Sie unter Zugriff auf Ihren virtuellen privaten Endpunkt nach dem Einrichten Ihres Endpunkt-Gateways.

Anmerkungen und Spezifikationen

Überprüfen Sie die erforderlichen und optionalen VPC NLB-Anmerkungen und Spezifikationen.

Erforderliche Vermerke und Spezifikationen

externalTrafficPolicy
Geben Sie Local oder Cluster an.
Definieren Sie diesen Parameter mit Local, um die Quellen-IP-Adresse von Clientanforderungen an Ihre Apps beizubehalten. Diese Einstellung verhindert, dass der eingehende Verkehr an einen anderen Knoten weitergeleitet wird. Diese Option konfiguriert auch HTTP-Statusprüfungen.
Wenn der Wert Cluster festgelegt ist, wird DSR nur über den ersten Workerknoten implementiert, an den die VPC-NLB die eingehende Anforderung zu Anfang weiterleitet. Nachdem die eingehende Anfrage eingetroffen ist, wird sie an einen Arbeitsknoten weitergeleitet, der den App-Pod enthält, der sich in einer anderen Zone befinden kann. Die Antwort des App-Pods wird an den ursprünglichen Workerknoten gesendet und dieser Workerknoten verwendet DSR, um die Antwort direkt unter Umgehung der VPC-NLB an den Client zu senden. Diese Option konfiguriert auch TCP-Statusprüfungen.

Optionale Anmerkungen und Spezifikationen

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name
Geben Sie einen eindeutigen Namen an, um Ihren VPC-Loadbalancer beständig zu machen. Persistente VPC-Loadbalancer werden nicht gelöscht, wenn der Cluster, zu dem sie gehören, gelöscht wird. Weitere Informationen finden Sie unter Persistente VPC-Loadbalancer. Dieser Vermerk kann nur bei der Erstellung des Load Balancers gesetzt werden. Sie kann nicht in einem Aktualisierungsvorgang verwendet werden.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol
Diese Anmerkung legt das Protokoll für die Zustandsprüfung der VPC-Load-Balancer-Ressource fest, die mit dem Kubernetes verbunden ist. Verfügbare Optionen sind http, https, oder tcp. Normalerweise wird das VPC LB-Zustandsprüfungsprotokoll durch den Wert der externalTrafficPolicy in der Kubernetes bestimmt. Mit dieser Anmerkung wird diese Logik jedoch außer Kraft gesetzt. Diese Anmerkung ändert nicht, wie sich Kubernetes und insbesondere kube-proxy in Bezug auf die verschiedenen Einstellungen von externalTrafficPolicy verhält.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port
Der Port „ TCP “, der für die Zustandsprüfungen verwendet wird. Dieser Vermerk gilt nur, wenn auch ibm-load-balancer-cloud-provider-vpc-health-check-protocol angegeben ist. Liegt der angegebene „ TCP “-Port außerhalb des Portbereichs der „ Kubernetes “-Knoten (30.000–32.767), muss die auf die Cluster-Worker-Knoten angewendete VPC-Sicherheitsgruppe angepasst werden, um eingehenden Datenverkehr auf diesem Port zuzulassen. Wird diese Anmerkung auf einen „ Kubernetes “-Load-Balancer-Dienst angewendet, der mit einem VPC-ALB verknüpft ist, müssen die ausgehenden Regeln der dem VPC-ALB zugewiesenen Sicherheitsgruppe geändert werden, um ausgehenden Datenverkehr zum angegebenen „ TCP “-Port zuzulassen. Weitere Informationen finden Sie unter Verstehen von standardmäßig sicheren Cluster-VPC-Netzwerken und Erstellen und Verwalten von VPC-Sicherheitsgruppen.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets
Anmerkung zur Angabe, welches Subnetz für die Zuweisung der IP-Adressen für den ppNLB verwendet werden soll. Diese IP-Adressen werden nur intern verwendet. Der Wert kann eine VPC-Subnetz-ID, ein VPC-Subnetz-Name oder ein VPC-Subnetz-CIDR sein. Sie müssen nur ein Teilnetz angeben. Der gesamte eingehende Verkehr scheint von diesen IP-Adressen zu kommen. Auch wenn sich alle Adressen in einer einzigen Zone befinden, verarbeitet der ppNLB den eingehenden Verkehr aus allen Zonen. Wenn diese spezielle Zone ausfällt, funktioniert der eingehende Verkehr aus den anderen Zonen weiterhin. Wenn Sie diese Anmerkung nicht angeben, wird das Teilnetz automatisch ausgewählt und das Teilnetz des Clusterknotens mit den meisten freien IP-Adressen verwendet. Um Teilnetze in allen Ressourcengruppen anzuzeigen, führen Sie ibmcloud oc subnets --provider vpc-gen2 --vpc-id VPC_ID --zone ZONE aus.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector
Anmerkung zur Festlegung eines Selektors für Worker-Knoten-Labels. Sie können bestimmte Arbeitsknoten in Ihrem Cluster für den Empfang von Datenverkehr konfigurieren, indem Sie Label-Selektorschlüssel angeben. Sie dürfen nur einen Label-Selektor in die Anmerkung aufnehmen, und dieser Selektor muss im Format "key=value" angegeben werden. Wenn diese Anmerkung nicht angegeben ist, sind alle Worker-Knoten in Ihrem Cluster so konfiguriert, dass sie Datenverkehr vom VPC-NLB empfangen. Diese Anmerkung hat Vorrang vor der Anmerkung service.kubernetes.io/ibm-load-balancer-cloud-provider-zone, und alle Labels dedicated: edge auf Worker-Knoten werden ignoriert. Um den Datenverkehr auf eine bestimmte Zone zu beschränken, können Sie diese Anmerkung verwenden, um Arbeitsknoten in dieser Zone anzugeben. Beachten Sie, dass das Festlegen eines neuen Labels auf einem Cluster-Arbeitsknoten den Arbeitsknoten nicht automatisch für den Empfang von Datenverkehr konfiguriert; Sie müssen den VPC NLB neu erstellen oder aktualisieren, damit der neu gelabelte Arbeitsknoten Datenverkehr empfangen kann.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path
Der Pfad für die Gesundheitsprüfung URL für HTTP und HTTPs Gesundheitsprüfungen. Dieser Vermerk gilt nur, wenn ibm-load-balancer-cloud-provider-vpc-health-check-protocol auf http oder https gesetzt ist. Der Pfad URL muss das Format eines origin-form request target haben. Wenn diese Anmerkung nicht angegeben wird und die ibm-load-balancer-cloud-provider-vpc-health-check-protocol Anmerkung auf http oder https gesetzt ist, wird der Standardwert / verwendet.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay
Optional. Die Anzahl der Sekunden, die zwischen den Gesundheitsprüfungen gewartet wird. Standardmäßig ist dieser Wert auf 5 gesetzt und hat einen Mindestwert von 2 und einen Höchstwert von 60. Dieser Wert muss größer sein als der ibm-load-balancer-cloud-provider-vpc-health-check-timeout Wert, der standardmäßig auf 2 gesetzt ist.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout
Optional. Die Anzahl der Sekunden, die auf eine Antwort auf eine Gesundheitsprüfung gewartet wird. Standardmäßig ist dieser Wert auf 2 gesetzt und hat einen Mindestwert von 1 und einen Höchstwert von 59. Dieser Wert muss kleiner sein als der ibm-load-balancer-cloud-provider-vpc-health-check-delay, der standardmäßig auf 5 gesetzt ist.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries
Die maximale Anzahl der Wiederholungen der Zustandsprüfung für den VPC-Loadbalancer. Standardmäßig ist dieser Wert auf 2 gesetzt und hat einen Mindestwert von 1 und einen Höchstwert von 10.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota
Optional. Die Anzahl der Arbeitsknoten pro Zone, zu denen der Load Balancer leitet. Der Standardwert ist '8'. Bei einem Cluster mit Worker-Knoten in drei Zonen führt dies dazu, dass der Load Balancer die Last auf insgesamt 24 Worker-Knoten verteilt. Die Gesamtzahl der Arbeitsknoten in allen Zonen, zu denen der Load Balancer leitet, darf 50 nicht überschreiten. Wenn der Cluster weniger als 50 Arbeitsknoten in allen Zonen hat, geben Sie 0 an, um zu allen Arbeitsknoten in einer Zone zu leiten.
selector
Der Bezeichnungsschlüssel (<selector_key>) und der Wert (<selector_value>), die Sie im Abschnitt spec.template.metadata.labels Ihrer YAML-Datei für die App-Bereitstellung verwendet haben. Mit dieser angepassten Bezeichnung werden alle Pods gekennzeichnet, in denen Ihre App ausgeführt wird und die in den Lastausgleich einbezogen werden sollen.
port
Der Port, den der Service überwacht.
targetPort
Optional: Der Port, an den der Datenverkehr vom Service weitergeleitet wird. Die im Pod ausgeführte Anwendung muss auf eingehenden TCP-Datenverkehr an diesem Zielport warten. Der Zielport ist oft statisch im Image definiert, das im Anwendungs-Pod läuft. Der im Pod konfigurierte Zielport unterscheidet sich vom Knotenport für den Dienst und kann sich auch vom externen Port unterscheiden, der auf der VPC LB konfiguriert ist.