Dies ist die Dokumentation für eine frühere Version von Anthos GKE On-Prem. Aktuelle Dokumentation ansehen

Netzwerk

GKE On-Prem verwendet Kubernetes-Netzwerkkonzepte wie Service und Ingress. In diesem Dokument wird die standardmäßige Konfiguration von GKE On-Prem-Netzwerken beschrieben.

Clusterdienstvorgänge und Inselmodus

GKE On-Prem verwendet eine Inselmodus-Konfiguration, bei der Pods innerhalb eines Clusters direkt miteinander kommunizieren können, aber von außerhalb des Clusters nicht erreichbar sind. Diese Konfiguration bildet eine "Insel" innerhalb des Netzwerks, die nicht mit dem externen Netzwerk verbunden ist. Cluster bilden ein vollständiges Knoten-zu-Knoten-Mesh-Netzwerk über die Clusterknoten hinweg, sodass ein Pod andere Pods im Cluster direkt erreichen kann.

Für den gesamte ausgehenden Traffic vom Pod zu Zielen außerhalb des Clusters wird durch die Knoten-IP-Adresse die NAT durchgeführt. GKE On-Prem enthält einen L7-Load-Balancer mit einem Envoy-basierten Ingress-Controller, der Ingress-Objektregeln für ClusterIP-Dienste verarbeitet, die im Cluster bereitgestellt werden. Der Ingress-Controller selbst wird als NodePort-Service im Cluster bereitgestellt.

Der Ingress-NodePort-Service kann über einen L3/L4-F5-Load-Balancer erreicht werden. Bei der Installation wird eine virtuelle IP-Adresse (VIP) mit den Ports 80 und 443 auf dem Load-Balancer konfiguriert. Die VIP verweist auf die Ports im NodePort-Service für den Ingress-Controller. So können externe Clients auf Services im Cluster zugreifen.

Nutzercluster können Services vom Typ LoadBalancer ausführen, solange in der Service-Spezifikation ein loadBalancerIP-Feld konfiguriert ist. Geben Sie im Feld loadBalancerIP die VIP ein, die Sie verwenden möchten. Diese wird in F5 konfiguriert und verweist auf die NodePorts des Service.

Als Alternative zur Verwendung des F5-Load-Balancers können Sie den manuellen Load-Balancing-Modus aktivieren. Wenn Sie manuelles Load-Balancing verwenden, können Sie keine Services vom Typ LoadBalancer ausführen. Stattdessen können Sie Services des Typs NodePort erstellen und Ihren Load-Balancer manuell konfigurieren, um sie als Back-Ends zu verwenden. Außerdem können Sie Services mithilfe eines Ingress-Objekts für externe Clients verfügbar machen.

Unterstützung für VMware NSX-T

Ab Version 1.2.0-gke.6 unterstützt GKE On-Prem die Version 2.4.2 von VMware NSX-T.

Netzwerkarchitektur

Diagramm zur Beschreibung der GKE On-Prem-Architektur GKE On-Prem-Netzwerk

Knoten-IP-Adressen
DHCP oder statisch zugewiesene IP-Adressen für die Knoten (alternativ als virtuelle Maschinen oder VMs bezeichnet). Müssen innerhalb des Rechenzentrums routingfähig sein. Sie können manuell statische IP-Adressen zuweisen.
Pod-CIDR-Block
Nicht routingfähiger CIDR-Block für alle Pods im Cluster. Aus diesem Bereich werden kleinere /24-Bereiche pro Knoten zugewiesen. Wenn Sie einen Cluster mit N Knoten benötigen, achten Sie darauf, dass dieser Block groß genug ist, um N /24-Blöcke zu unterstützen.
Services-CIDR-Block
Im Inselmodus, ähnlich wie der Pod-CIDR-Block. Wird also nur im Cluster verwendet. Jeder private CIDR-Block, der sich nicht mit den Knoten, VIPs oder dem Pod-CIDR-Block überschneidet. Sie können denselben Block für mehrere Cluster verwenden. Die Blockgröße bestimmt die Anzahl der Services. Eine Service-IP-Adresse wird für den Ingress-Service benötigt und zehn oder mehr IP-Adressen für Kubernetes-Services wie Cluster-DNS usw.
Service-VIPs
Anzahl N der routingfähigen IP-Adressen, die auf F5 für L4-Ingress konfiguriert werden sollen, wenn Sie einen Service verfügbar machen. Diese VIPs sind dieselben wie die loadBalancerIP-Werte, die Sie beim Erstellen von Services vom Typ LoadBalancer festlegen.
VIP der Steuerungsebene
Eine routingfähige IP-Adresse, die im F5-Load-Balancer für den Kubernetes API-Server konfiguriert werden soll.
Ingress-VIP
Eine routingfähige IP-Adresse, die auf dem F5-Load-Balancer für L7-Ingress in Verbindung mit den auf jedem Knoten ausgeführten Envoy-Proxys konfiguriert werden soll.

Konfigurationsoptionen für das Netzwerk

Sie haben mehrere Möglichkeiten, das Netzwerk Ihrer Cluster zu konfigurieren:

  • Sie können ein globales vCenter-Netzwerk auswählen oder ein anderes vCenter-Netzwerk für Administrator- und Nutzercluster verwenden.
  • Sie können einen HTTP-Proxy verwenden und auswählen, welche Adressen Sie von der Proxysuche ausschließen möchten.
  • Sie können die Zuweisung über DHCP oder statische IP-Adressen auswählen.
  • Sie können den integrierten oder manuellen Load-Balancing-Modus auswählen.

Während der Installation geben Sie Ihre Einstellungen in der GKE On-Prem-Konfigurationsdatei an.

vCenter-Netzwerkkonfigurationen

Das Feld network der Konfiguration bestimmt, welches vCenter-Netzwerk für die Cluster verwendet wird:

  • Das globale Feld vcenter.network gibt ein bestimmtes Netzwerk an.
  • admincluster.vcenter.network überschreibt das globale Feld und gibt das Netzwerk an, das für den Administratorcluster verwendet werden soll.
  • usercluster.vcenter.network überschreibt das globale Feld und gibt das Netzwerk an, das für den Nutzercluster verwendet werden soll.

Beispiel: Zugriff auf eine Webanwendung über URL

Angenommen, in Ihrem Cluster wird eine Gästebuch-Webanwendung als Deployment mit dem Namen frontend ausgeführt. Sie möchten eine Verbindung zur Anwendung über die URL www.guestbook.com herstellen. Sie müssen die URL des Deployments zuordnen, das in Ihrem Cluster ausgeführt wird. Dazu können Sie ein Kubernetes Ingress-Objekt verwenden.

Erstellen Sie zuerst einen Platzhalter-DNS-Eintrag für *.guestbook.com, der auf die vorhandene Ingress-VIP des Clusters verweist:

*.guestbook.com    A   [INGRESS_VIP]

Als Nächstes müssen Sie einen Service für das Front-End-Deployment erstellen. Durch das Ausführen von kubectl expose wird ein Service erstellt, der die Pods des Deployments logisch gruppiert und für sie eine gemeinsame IP-Adresse innerhalb des Clusters bereitstellt:

kubectl expose deployment frontend

Dadurch wird ein Service vom Typ ClusterIP erstellt:

apiVersion: v1
kind: Service
metadata:
  labels:
    app: guestbook
  name: frontend
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: guestbook
  type: ClusterIP

Sie müssen die URL www.guestbook.com dem soeben erstellten Front-End-Service zuordnen. Wenn Sie das Ingress-Objekt unten anwenden, wird diese Zuordnung erstellt:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: frontend
  labels:
    app: guestbook
spec:
  rules:
    - host: www.guestbook.com
      http:
        paths:
          - backend:
              serviceName: frontend   # name of the frontend Service
              servicePort: 80

Wenn Sie nun www.guestbook.com aufrufen, wird die Webanwendung in Ihrem Browser geöffnet.

So funktioniert das genau:

  • Da Sie diesen Platzhalter-DNS-Eintrag erstellt haben, greifen Sie beim Aufrufen der URL auf die Ingress-VIP des Clusters zu.
  • Der Cluster sucht anhand des Hostnamens nach dem richtigen Ingress-Objekt, in diesem Fall www.guestbook.com.
  • Der Traffic wird an einen Front-End-Pod weitergeleitet.

Beispiel: Zugriff auf eine Webanwendung über IP-Adresse

Wenn es sich bei Ihrer Anwendung nicht um eine Webanwendung handelt oder wenn Sie Netzwerkbeschränkungen haben, können Sie eine VIP speziell für Ihren Service erstellen. Dazu können Sie einen Kubernetes-Service vom Typ LoadBalancer verwenden.

Der folgende Service erstellt eine VIP speziell für die guestbook-Anwendung:

apiVersion: v1
kind: Service
metadata:
  labels:
    app: guestbook
  name: frontend
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: guestbook
  type: LoadBalancer
  loadBalancerIP: [IP_ADDRESS]
  

Nachdem Sie diesen Service angewendet haben, sehen Sie die VIP in Ihrer F5-Konsole und im Menü Pools der Konsole sehen Sie die IP-Adressen der Knoten. Wenn Sie die IP-Adresse aufrufen, wird die Anwendung geladen.