Informationen zum Lastausgleich für Apps über die Kubernetes -Service-Erkennung

Die Kubernetes Service-Erkennung stellt Apps mit einer Netzverbindung unter Verwendung von Netzservices und eines lokalen Kubernetes-Proxys zur Verfügung.

Alle Pods, die auf einem Workerknoten bereitgestellt werden, erhalten im Bereich 172.30.0.0/16 eine private IP-Adresse und werden nur zwischen den Workerknoten weitergeleitet. Vermeiden Sie Konflikte, indem Sie diesen IP-Bereich nicht auf Knoten verwenden, die mit Ihren Workerknoten kommunizieren. Workerknoten und Pods können im privaten Netz durch die Verwendung von privaten IP-Adressen sicher kommunizieren. Wenn ein Pod ausfällt oder ein Workerknoten neu erstellt werden muss, wird jedoch eine neue private IP-Adresse zugewiesen.

Anstatt zu versuchen, sich ändernde private IP-Adressen für Apps nachzuverfolgen, die hoch verfügbar sein müssen, können Sie die integrierten Kubernetes Service-Erkennungsfunktionen nutzen, um Apps als Services zugänglich zu machen. Ein Kubernetes Service fasst eine Gruppe von Pods zusammen und stellt diesen Pods eine Netzverbindung zur Verfügung. Der Service wählt die Ziel-Pods aus, an die er den Datenverkehr über Bezeichnungen weiterleitet.

Ein Service stellt Konnektivität zwischen Ihren App-Pods und anderen Services im Cluster bereit, ohne hierbei die tatsächlichen privaten IP-Adressen der einzelnen Pods preiszugeben. Services wird eine Cluster-interne IP-Adresse zugeordnet, die clusterIP, die nur innerhalb des Clusters zugänglich ist. Diese IP-Adresse ist für die gesamte Lebensdauer des Service an diesen gebunden und ändert sich nicht, solange der Service besteht. Services wird eine IP aus einer der 65.000 IPs im Bereich 172.21.0.0/16 zugeordnet.

Vermeiden Sie Konflikte, indem Sie diesen IP-Bereich nicht auf Knoten verwenden, die mit Ihren Workerknoten kommunizieren. Es wird auch ein Eintrag für die DNS-Suche für den Service erstellt und in der Komponente kube-dns des Clusters gespeichert. Der DNS-Eintrag enthält den Namen des Service, den Namensbereich, in dem der Service erstellt wurde, und den Link zu der zugeordneten IP-Adresse, die im Cluster enthalten ist.

Wenn Sie planen, Ihren Cluster mit lokalen Netzen über IBM Cloud oder einen VPN-Service zu verbinden, können Teilnetzkonflikte mit dem Standardbereich 172.30.0.0/16 für Pod und dem Standardbereich 172.21.0.0/16 für Services auftreten. Sie können Subnetzkonflikte beim Erstellen eines Clusters vermeiden, indem Sie in der Option --pod-subnet ein benutzerdefiniertes Subnetz-CIDR für Pods und in der Option --service-subnet ein benutzerdefiniertes Subnetz-CIDR für Dienste angeben.

Um einen grundlegenden Lastausgleich für den gesamten TCP- und UDP-Netzverkehr für Services bereitzustellen, wird ein lokaler Kubernetes-Netzproxy, kube-proxy, als Dämon auf jedem Workerknoten im kube-system-Namensbereich ausgeführt. kube-proxy verwendet Iptables-Regeln (ein Linux-Kernelfeature), um Anforderungen an den Pod hinter einem Service unabhängig von den clusterinternen IP-Adressen der Pods und dem Workerknoten, auf dem sie bereitgestellt werden, gleichmäßig weiterzuleiten.

Apps innerhalb des Clusters können beispielsweise auf einen Pod hinter einem Cluster-Service zugreifen, indem sie die Cluster-interne IP des Service verwenden oder eine Anforderung an den Namen des Service senden. Wenn Sie den Namen des Service verwenden, sucht kube-proxy nach dem Namen im DNS-Provider des Clusters und leitet die Anforderung an die Cluster-interne IP-Adresse des Service weiter.

Wenn Sie einen Service verwenden, der sowohl eine interne Cluster-IP-Adresse als auch eine externe IP-Adresse bereitstellt, können Clients außerhalb des Clusters Anforderungen an die externe öffentliche oder private IP-Adresse des Service senden. kube-proxy leitet die Anforderungen an die clusterinterne IP-Adresse des Service weiter und verteilt die Lastverteilung zwischen den App-Pods hinter dem Service.

Informationen über Kubernetes Service-Typen

Kubernetes unterstützt vier grundlegende Typen von Netzservices: ClusterIP, NodePort, LoadBalancer und Ingress. ClusterIP-Services machen Ihre Apps intern zugänglich, sodass nur die Kommunikation zwischen Pods in Ihrem Cluster möglich ist. NodePort-, LoadBalancer- und Ingress-Services machen Ihre Apps extern über das öffentliche Internet oder ein privates Netz zugänglich.

In der folgenden Tabelle werden die Features der einzelnen Netzservicetypen verglichen.

* Ein SSL-Zertifikat für den HTTPS-Lastausgleich wird durch ibmcloud ks nlb-dns-Befehle bereitgestellt. In klassischen Clustern werden diese Befehle nur für öffentliche NLBs unterstützt.

NodePort

Wenn Sie Apps über einen Dienst NodePort bereitstellen, wird dem Dienst ein NodePort-Adressbereich von 30000 bis 32767 sowie eine interne Cluster-IP-Adresse zugewiesen. Um von außerhalb des Clusters auf den Dienst zuzugreifen, verwenden Sie die öffentliche oder private IP-Adresse eines beliebigen Worker-Knotens und den NodePort im Format <IP_address>:<nodeport>. Die öffentliche und private IP-Adresse des Workerknotens sind jedoch keine permanenten Adressen. Wenn ein Workerknoten entfernt oder neu erstellt wird, werden ihm eine neue öffentliche und eine neue private IP-Adresse zugewiesen.

Knotenports eignen sich auch ideal zum Testen des öffentlichen oder privaten Zugriffs oder zum Bereitstellen von Zugriff nur für kurze Zeit. Hinweis: Da Workerknoten in VPC-Clustern nicht über eine öffentliche IP-Adresse verfügen, können Sie nur dann über einen Knotenport auf eine App zugreifen, wenn Sie mit Ihrem privaten VPC-Netz verbunden sind (z. B. durch eine VPN-Verbindung).

LoadBalancer

Der LoadBalancer-Servicetyp wird in Abhängigkeit vom Infrastrukturprovider Ihres Clusters unterschiedlich implementiert.

LoadBalancer-Services in Classic-Clustern

Klassische Infrastruktur

Netzlastausgleichsfunktion(NLB). Jeder Standardcluster wird mit 4 portierbaren öffentlichen IP-Adressen und 4 portierbaren privaten IP-Adressen bereitgestellt, mit denen Sie eine Layer 4-TCP/UDP-Netzlastausgleichsfunktion (NLB) für Ihre App erstellen können. Diese NLB kann durch Zugänglichmachen jedes beliebigen Ports, den Ihre App benötigt, entsprechend angepasst werden. Die portierbaren öffentlichen und privaten IP-Adressen, die dem NLB zugeordnet sind, sind permanent und ändern sich nicht, wenn ein Workerknoten im Cluster erneut erstellt wird. Sie können eine Unterdomäne für Ihre App erstellen, die öffentliche NLB-IP-Adressen in einem DNS-Eintrag registriert. Sie können außerdem Statusprüfmonitore für die NLB-IP-Adressen für jede Unterdomäne aktivieren.

LoadBalancer-Services in VPC-Clustern

Virtual Private Cloud

Lastausgleichsfunktion für VPC. Wenn Sie einen Kubernetes-Lastausgleichsservice für eine App in Ihrem Cluster erstellen, wird automatisch eine Layer 7-VPC-Lastausgleichsfunktion in Ihrer VPC außerhalb Ihres Clusters erstellt. Die VPC-Lastausgleichsfunktion arbeitet mit mehreren Zonen und leitet Anforderungen für Ihre App über die privaten Knotenports (NodePorts) weiter, die automatisch auf Ihren Workerknoten geöffnet werden. Standardmäßig wird die Lastausgleichsfunktion auch mit einem Hostnamen erstellt, über den Sie auf Ihre App zugreifen können.

Ingress

Stellen Sie mehrere Anwendungen in einem Cluster bereit, indem Sie das Routing mit dem Ingress-Anwendungs-Load-Balancer (ALB) einrichten. Diese ALB verwendet einen geschützten und eindeutigen öffentlichen oder privaten Einstiegspunkt, eine Ingress-Unterdomäne, für die Weiterleitung eingehender Anforderungen an Ihre Apps. Sie können eine Unterdomäne verwenden, um mehrere Apps in Ihrem Cluster als Services zugänglich zu machen. Ingress besteht aus drei Komponenten:

• Die Ingress-Ressource definiert die Regeln, die festlegen, wie die Weiterleitung der eingehenden Anforderungen für eine App und deren Lastausgleich erfolgen soll.
• Die ALB ist für eingehende HTTP-, HTTPS- oder TCP-Serviceanforderungen empfangsbereit. Sie leitet Anforderungen über die Pods der App in Übereinstimmung mit den für jede Ingress-Ressource definierten Regeln weiter.
• Der Lastausgleichsfunktion für mehrere Zonen (MZLB) für klassische Cluster bzw. die VPC-Lastausgleichsfunktion für VPC-Cluster verarbeitet alle eingehenden Anforderungen an Ihre Apps und verteilt diese an die ALBs in den verschiedenen Zonen. Sie aktiviert außerdem Statusprüfungen für die öffentlichen Ingress-IP-Adressen.

Öffentlichen externen Lastausgleich planen

Stellen Sie eine App in Ihrem Cluster öffentlich für das Internet bereit.

In klassischen Clustern können Sie Workerknoten mit einem öffentlichen VLAN verbinden. Das öffentliche VLAN bestimmt die öffentliche IP-Adresse, die dem jeweiligen Workerknoten zugeordnet ist. Diese Adresse stellt jedem Workerknoten eine öffentliche Netzschnittstelle bereit. Öffentliche Netzbetriebsservices stellen eine Verbindung zu dieser öffentlichen Netzschnittstelle her, indem sie Ihre App mit einer öffentlichen IP-Adresse und wahlweise einer öffentlichen URL bereitstellen.

In VPC-Clustern werden Ihre Workerknoten nur mit privaten VPC-Teilnetzen verbunden. Wenn Sie öffentliche Netzbetriebsservices erstellen, wird jedoch automatisch eine VPC-Lastausgleichsfunktion erstellt. Die VPC-Lastausgleichsfunktion kann öffentliche Anforderungen an Ihre App weiterleiten, indem sie eine öffentliche URL für Ihre App bereitstellt. Wenn eine App öffentlich zugänglich gemacht wird, kann jeder, der über die öffentliche URL verfügt, eine Anforderung an Ihre App senden.

Wenn eine App öffentlich zugänglich gemacht wird, kann jeder, der über die öffentliche Service-IP-Adresse oder die URL verfügt, die Sie für Ihre App eingerichtet haben, eine Anforderung an Ihre App senden. Aus diesem Grund machen Sie so wenige Apps wie möglich zugänglich. Machen Sie eine App nur dann der Öffentlichkeit zugänglich, wenn Ihre App bereit ist, Datenverkehr von externen Web-Clients oder Benutzern zu akzeptieren.

Die öffentliche Netzschnittstelle für Workerknoten wird durch vordefinierte Calico-Netzrichtlinieneinstellungen geschützt, die bei der Clustererstellung auf jedem Workerknoten konfiguriert werden. Standardmäßig wird der gesamte ausgehende Netzverkehr für alle Workerknoten zugelassen. Eingehender Netzverkehr wird abgesehen von bestimmten Ports blockiert. Diese Ports werden geöffnet, damit IBM den Netzverkehr überwachen und Sicherheitsupdates für den Kubernetes-Master automatisch installieren kann und damit Verbindungen zu NodePort-, LoadBalancer- und Ingress-Services hergestellt werden können. Weitere Informationen zu diesen Richtlinien und zur Vorgehensweise bei der Änderung dieser Richtlinien finden Sie in Netzrichtlinien.

Bereitstellungsmuster für klassische Cluster auswählen

Um eine App öffentlich für das Internet in einem klassischen Cluster verfügbar zu machen, wählen Sie ein Bereitstellungsmuster für Lastausgleich aus, das öffentliche NodePort-, LoadBalancer- oder Ingress-Services verwendet. In der folgenden Tabelle werden die einzelnen möglichen Bereitstellungsmuster beschrieben sowie die Gründe für ihre Verwendung und ihre Einrichtung erläutert. Basisinformationen zu den Netzbetriebsservices, die diese Bereitstellungsmuster verwenden, finden Sie unter Informationen über Kubernetes Service-Typen.

Bereitstellungsmuster für VPC-Cluster auswählen

Um eine App öffentlich für das Internet in einem VPC-Cluster verfügbar zu machen, wählen Sie ein Bereitstellungsmuster für Lastausgleich aus, das öffentliche Services vom Typ LoadBalancer oder Ingress verwendet. In der folgenden Tabelle werden die einzelnen möglichen Bereitstellungsmuster beschrieben sowie die Gründe für ihre Verwendung und ihre Einrichtung erläutert. Basisinformationen zu den Netzbetriebsservices, die diese Bereitstellungsmuster verwenden, finden Sie unter Informationen über Kubernetes Service-Typen.

Privaten externen Lastausgleich planen

Stellen Sie eine App privat in Ihrem Cluster nur für das private Netz bereit.

Wenn Sie eine App in einem Kubernetes-Cluster in IBM Cloud Kubernetes Service bereitstellen, haben Sie die Möglichkeit, die App nur für solche Benutzer und Services zugänglich zu machen, die sich in demselben privaten Netz wie Ihr Cluster befinden. Der private Lastausgleich eignet sich ideal, um Ihre App für Anforderungen von außerhalb des Clusters verfügbar zu machen, ohne die App der allgemeinen Öffentlichkeit zugänglich zu machen. Sie können den privaten Lastausgleich auch verwenden, um den Zugriff, das Anforderungsrouting und andere Konfigurationen für Ihre App zu testen, bevor Sie Ihre App später mit öffentlichen Netzservices der Öffentlichkeit zugänglich machen.

Nehmen Sie zum Beispiel an, dass Sie eine private Lastausgleichsfunktion für Ihre App erstellen. Auf diese private Lastausgleichsfunktion kann wie folgt zugegriffen werden:

• Von einem beliebigen Pod im selben Cluster.
• Von einem beliebigen Pod in einem beliebigen Cluster im selben IBM Cloud-Konto.
• Von allen Systemen über eine VPN-Verbindung zu dem Teilnetz, in dem sich die IP-Adresse der Lastausgleichsfunktion befindet (wenn Sie sich nicht im IBM Cloud-Konto, aber dennoch hinter der Unternehmensfirewall befinden).
• Von einem beliebigen System über eine VPN-Verbindung zu dem Teilnetz, in dem sich die IP-Adresse der Lastausgleichsfunktion befindet (wenn Sie sich in einem anderen IBM Cloud-Konto befinden).
• In klassischen Clustern: Von jedem System, das mit einem beliebigen der privaten VLANs im selben IBM Cloud-Konto verbunden ist (wenn eine VRF-Funktion oder VLAN Spanning aktiviert ist).
• In VPC-Clustern:
  • Wenn Sie Datenverkehr zwischen VPC-Teilnetzen zulassen, wird jedes System in derselben VPC zugelassen.
  • Wenn Sie Datenverkehr zwischen VPCs zulassen, jedes System mit Zugriff auf die VPC, in der sich der Cluster befindet.