Registrierung eines privaten DNS-Eintrags für einen privaten VPC ALB

In Version 4.15 oder später können Sie die folgenden optionalen Anmerkungen verwenden, um einen eigenen DNS instance, der einen benutzerdefinierten DNS zone bedient, mit einem privaten VPC ALB zu verknüpfen. Hierfür müssen beide optionalen Anmerkungen gesetzt werden. Wenn keine Angaben gemacht werden, werden DNS- A-Einträge für die Eigenschaft „ hostname “ dieses Load Balancers zur öffentlichen DNS-Zone „ lb.appdomain.cloud “ hinzugefügt.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn"

Die DNS- instance, die diesem Load Balancer zugeordnet werden soll. Die angegebene Instanz kann sich in einer anderen Region oder einem anderen Konto befinden und unterliegt den IAM-Richtlinien. Mögliche Werte: 9 ≤ Länge ≤ 512

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id"

Die DNS- zone, die diesem Load Balancer zugeordnet werden soll. Die angegebene Zone kann sich in einer anderen Region oder einem anderen Konto befinden, abhängig von den IAM-Richtlinien. Mögliche Werte: 1 ≤ Länge ≤ 128, Wert muss dem regulären Ausdruck ^[1]*[a-z0-9]$ entsprechen

Bevor Sie diese Funktion nutzen können, müssen Sie die folgenden Voraussetzungen erfüllen:

• Erstellen der DNS-Zone, die an einen Load Balancer gebunden werden kann
• Aktivieren der Dienst-zu-Dienst-Autorisierung zwischen VPC LBs und DNS Services
• Hinzufügen der VPC des Clusters zu den zulässigen Netzwerken der Zone

Detaillierte Informationen finden Sie in den Dokumenten Integration eines Application Load Balancers mit IBM Cloud DNS Services und Hinzufügen einer VPC als zugelassenes Netzwerk zur DNS-Zone.

Beispiel:

apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "crn:v1:bluemix:public:dns-svcs:global:a/bb1b52262f7441a586f49068482f1e60:f761b566-030a-4696-8649-cc9d09889e88::"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "d66662cc-aa23-4fe1-9987-858487a61f45"
spec:
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 169.60.115.164
...

Erforderliche Vermerke und Spezifikationen

service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "alb"

Anmerkung, um eine VPC ALB zu erstellen. Wenn Sie service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features nicht angeben, wird standardmäßig ein VPC ALB bereitgestellt.

service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"

(Erforderlich für private VPC ALBs) Anmerkung zur Angabe eines Dienstes, der öffentliche oder private Anfragen annimmt. Wenn diese Anmerkung nicht enthalten ist, wird eine öffentliche VPC ALB erstellt.

externalTrafficPolicy

Geben Sie Cluster an, um eine Anfrage an einen Arbeitsknoten weiterzuleiten, der den App-Pod enthält. Dieser Arbeitsknoten kann sich in einer anderen Zone befinden. Standardmäßig ist diese Anmerkung auf gesetzt Cluster.

Geben Sie Local an, um die Weiterleitung des eingehenden Datenverkehrs an einen anderen Knoten zu verhindern. Diese Option konfiguriert auch HTTP-Statusprüfungen.

Um die ursprüngliche Client-Quell-IP für VPC ALBs zu verwenden, müssen Sie das PROXY-Protokoll mit der service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"-Anmerkung aktivieren.

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-enable-features: "proxy-protocol"

Aktivieren Sie das PROXY-Protokoll. Die Lastausgleichsfunktion übergibt Clientverbindungsinformationen, einschließlich der Client-IP-Adresse, der Proxy-Server-IP-Adresse und der beiden Portnummern, in Anforderungsheadern an Ihre Back-End-App. Dabei ist zu beachten, dass Ihre Back-End-App so konfiguriert sein muss, dass sie das PROXY-Protokoll akzeptiert. Beispielsweise können Sie eine NGINX-App so konfigurieren, dass sie das PROXY-Protokoll akzeptiert, indem Sie die folgenden Schritte ausführen.

service.kubernetes.io/ibm-load-balancer-cloud-provider-zone

Annotation zur Angabe einer VPC-Zone, der Ihr Cluster zugeordnet ist. Wenn Sie eine Zone in dieser Anmerkung angeben, laufen zwei Prozesse ab: (1) Der VPC ALB wird in demselben Subnetz in dieser Zone bereitgestellt, mit dem Ihre Arbeitsknoten verbunden sind, und (2) nur die Arbeitsknoten in Ihrem Cluster in dieser Zone sind so konfiguriert, dass sie Verkehr vom VPC ALB empfangen. Wenn Sie die Lastausgleichsfunktion in einer bestimmten Zone platzieren möchten, müssen Sie diese Annotation beim Erstellen der Lastausgleichsfunktion angeben. Wenn Sie diese Anmerkung später in eine andere Zone ändern, werden die Abhör- und Backend-Arbeitsknoten automatisch an die neue Zone angepasst. Wenn das Label dedicated: edge auf Worker-Knoten gesetzt ist und Sie diese Anmerkung angeben, werden nur Edge-Knoten in der angegebenen Zone so konfiguriert, dass sie Datenverkehr empfangen. Edge-Knoten in anderen Zonen und Nicht-Edge-Knoten in der angegebenen Zone empfangen keinen Datenverkehr von der Lastausgleichsfunktion. Führen Sie zum Anzeigen von Zonen den Befehl ibmcloud ks zone ls --provider vpc-gen2 aus.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets

Anmerkung zur Angabe eines oder mehrerer Subnetze, in denen der VPC-ALB-Dienst bereitgestellt wird. Ist diese Annotation angegeben, hat sie Vorrang vor der Annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-zone. Ohne diese Anmerkung werden die Subnetze, die der VPC ALB einsetzt, automatisch aktualisiert, um mit den Zonen eines Clusters übereinzustimmen, wenn der Cluster von einer Einzelzonenregion zu einer Multizonenregion oder umgekehrt aktualisiert wird. Dabei ist zu beachten, dass Sie ein Teilnetz in derselben VPC angeben können, bei dem es sich nicht um eines der Teilnetze handelt, mit dem Ihr Cluster verbunden ist. In diesem Fall kann die VPC-ALB, auch wenn sie in einem anderen Teilnetz in derselben VPC bereitgestellt wird, dennoch Datenverkehr an Ihre Workerknoten in den Clusterteilnetzen derselben Zone weiterleiten. Um Teilnetze in allen Ressourcengruppen anzuzeigen, führen Sie ibmcloud oc subnets --provider vpc-gen2 --vpc-id VPC_ID --zone ZONE aus. Dieser Vermerk kann für bestehende VPC ALBs hinzugefügt oder geändert werden.

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. Wird diese Annotation nicht angegeben, werden alle Workerknoten, die sich in derselben Zone wie Ihr Cluster befinden, so konfiguriert, dass sie Datenverkehr von der VPC-ALB 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 ALB neu erstellen oder aktualisieren, damit der neu gelabelte Arbeitsknoten Datenverkehr empfangen kann.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol

Das Zustandsprüfungsprotokoll für die VPC-Load-Balancer-Ressource, die mit dem Kubernetes-Load-Balancer-Dienst verbunden ist. Verfügbare Optionen sind http, https, oder tcp. Normalerweise wird das VPC LB-Zustandsprüfungsprotokoll durch den Wert der externalTrafficPolicy-Einstellung in der Kubernetes-Load-Balancer-Service-Spezifikation bestimmt, aber diese Anmerkung setzt diese Logik außer Kraft. Diese Anmerkung ändert nicht, wie Kubernetes, und insbesondere kube-proxy, sich 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.

Wenn Ihr Cluster nicht Secure by Default ausführt, müssen Sie möglicherweise die folgenden Änderungen an den angewandten VPC-Sicherheitsgruppen vornehmen. Wenn Ihr Cluster mit Secure by Default arbeitet, werden diese Änderungen automatisch übernommen.

• 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.

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. Diese Bemerkung 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

Die Anzahl der Sekunden, die zwischen den Gesundheitsprüfungen gewartet wird. Standardmäßig ist dieser Wert auf 5 gesetzt und hat ein Minimum von 2 und ein Maximum 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

Die Anzahl der Sekunden, die auf eine Antwort auf eine Gesundheitsprüfung gewartet wird. Standardmäßig ist dieser Wert auf 2 gesetzt und hat ein Minimum von 1 und ein Maximum 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 ein Minimum von 1 und ein Maximum von 10.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout

Das Zeitlimit für inaktive Verbindungen des Listeners in Sekunden. Die standardmäßige Leerlaufzeit hängt von Ihren Kontoeinstellungen ab. Normalerweise ist dieser Wert 50. Einige Konten auf der Zulassen-Liste haben jedoch größere Timeout-Einstellungen. Wenn Sie den Vermerk nicht setzen, verwenden Ihre Lastverteiler die Zeitüberschreitungseinstellung in Ihrem Konto. Sie können die Zeitüberschreitung explizit angeben, indem Sie diesen Vermerk setzen. Der Mindestwert ist 50. Das Maximum beträgt 7200.

service.kubernetes.io/ibm-load-balancer-cloud-provider-dns-name: "example-ingress-domain.<region>.containers.appdomain.cloud"

Versionen- 4.17 oder höher.

Registrieren Sie die IP-Adresse des Load Balancer mit der angegebenen Ingress-Domäne. Wenn die angegebene Domäne nicht existiert, wird eine Domäne erstellt, die den internen, IBM verwalteten Anbieter (IBM NS1) verwendet. Um eine neue Domäne zu erstellen, muss der Name in allen vorhandenen Domänen (nicht nur in denen Ihres Clusters) eindeutig sein. Durch das Löschen des Load Balancer-Dienstes wird die IP-Adresse aus der Domäne entfernt. Durch das Entfernen der Anmerkung wird die IP-Adresse jedoch nicht aus der Domäne entfernt.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn"

Versionen- 4.15 oder höher.

Die DNS-Einträge, die diesem Load Balancer zugeordnet werden instance sollen. Weitere Informationen finden Sie unter Registrieren eines privaten DNS-Eintrags.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id"

Versionen- 4.15 oder höher.

Die DNS-Einträge, die diesem Load Balancer zugeordnet werden zone sollen. Weitere Informationen finden Sie unter Registrieren eines privaten DNS-Eintrags.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota

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.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group

Versionen- 1.30 oder höher.

Eine vom Kunden verwaltete Sicherheitsgruppe, die dem VPC-Loadbalancer hinzugefügt wird. Wenn Sie die IBM Sicherheitsgruppe nicht verwenden möchten, geben Sie eine Sicherheitsgruppe an, die Sie besitzen und verwalten. Diese Option entfernt die IBM Sicherheitsgruppe und ersetzt sie durch die von Ihnen angegebene Sicherheitsgruppe. Wenn Sie die Anmerkung von einem vorhandenen Load Balancer entfernen, wird die von Ihnen hinzugefügte Sicherheitsgruppe durch die IBM Sicherheitsgruppe ersetzt. Sie können diesen Vermerk jederzeit hinzufügen oder entfernen. Sie sind für die Verwaltung Ihrer Sicherheitsgruppe verantwortlich und halten sie auf dem neuesten Stand.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-allow-outbound-traffic

Verfügbar für Cluster, die Secure by Default ausführen. Anmerkung, um Sicherheitsgruppen für jede IP-Adresse eines ALB zu erstellen, die mit einem von Ihnen angegebenen externen Port verbunden ist. Diese Regeln werden in der Clustersicherheitsgruppe erstellt und automatisch aktualisiert, wenn sich die IP-Adresse des VPC ALB ändert. Geben Sie gültige externe Ports in einer kommagetrennten Liste an, z. B. 80,443. Wenn in diesem Beispiel jeder öffentliche ALB, der mit jedem externen Portwert verbunden ist, zwei IP-Adressen hat, wird eine ausgehende Regel pro IP-Adresse erstellt, was insgesamt 4 neue Regeln ergibt. Sie können diesen Vermerk jederzeit hinzufügen oder entfernen.

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

Der Port, an den der Service den Datenverkehr leitet. 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.