Dieses Dokument richtet sich an IT-Administratoren, Operatoren und Netzwerkspezialisten, die Google Distributed Cloud ausführen. In diesem Dokument erfahren Sie, wie Sie virtuelle Netzwerke erstellen und verwenden, um VM-Arbeitslasten mit VM-Laufzeit auf GDC zu unterstützen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud verweisen, finden Sie unter Allgemeine GKE Enterprise-Nutzerrollen und -Aufgaben.
Hinweise
Um dieses Dokument abzuschließen, benötigen Sie Zugriff auf die folgenden Ressourcen:
- Zugriff auf Google Distributed Cloud-Cluster Version 1.12.0 (
anthosBareMetalVersion: 1.12.0
) oder höher. Sie können einen beliebigen Clustertyp verwenden, der Arbeitslasten ausführen kann. Probieren Sie bei Bedarf Google Distributed Cloud in Compute Engine aus oder lesen Sie die Übersicht zum Erstellen von Clustern. - Das
virtctl
-Clienttool, das als Plug-in fürkubectl
installiert wurde. Installieren Sie bei Bedarf das virtctl-Clienttool.
Übersicht über virtuelle Netzwerke
Netzwerke werden mit benutzerdefinierten Ressourcen erstellt. Ein Netzwerk kann jederzeit nach der Clustererstellung erstellt werden. Netzwerkeinstellungen für die Hostschnittstelle und VLAN-ID-Zuweisung können nach dem Erstellen eines Netzwerks nicht mehr geändert werden, sofern vorhanden.
Das Löschen von Netzwerken unterliegt einigen Bedingungen. Beispielsweise lehnt der Netzwerkcontroller das Löschen eines Netzwerks ab, wenn es von Ressourcen wie VMs oder Netzwerkschnittstellen verwendet wird.
Die Netzwerkdefinition kann das Gateway, die Routen und die DNS-Informationen enthalten. Sie können auch die Verwendung eines externen DHCP-Servers aktivieren. Diese Netzwerkeinstellungen werden statisch oder dynamisch zugewiesen, je nachdem, wie bestimmte Optionen für die Netzwerkkonfiguration definiert sind.
Standard-Pod-Netzwerk
In jedem Cluster wurde standardmäßig ein pod-network
erstellt. Dieses Netzwerk kann nicht geändert werden. Routen für die Pod-CIDR und den Dienst-CIDR sowie die DNS-Konfiguration werden automatisch ausgefüllt. Die DNS-Konfiguration verwendet dieselben Werte wie der Cluster.
Der pod-network
kann von Arbeitslasten verwendet werden, die eine Schnittstelle benötigen, um auf das Pod-Netzwerk des Clusters zuzugreifen, und keine bestimmten Konfigurationsoptionen benötigen.
Die Routen von pod-network
sind immer so konfiguriert, dass der Cluster- und Dienstzugriff für die Arbeitslasten sichergestellt ist, obwohl sich das Standardgateway nicht auf der Schnittstelle pod-network
befindet.
Mit diesem Standardwert für pod-network
können Sie die VM-Laufzeit auf GDC ohne zusätzliche Schritte zum Erstellen eigener virtueller Netzwerke testen. Viele unserer Dokumente verwenden dieses Standard-pod-network
, um die Komplexität der Beispiele zu reduzieren. Die Anforderungen Ihrer VM-Arbeitslasten bestimmen, ob dieses Standard-pod-network
ausreicht oder ob Sie Ihre eigenen virtuellen Netzwerke erstellen und verwenden müssen.
Das folgende YAML-Manifest zeigt eine Beispielkonfiguration für das pod-network
.
Die Werte für Routen, DNS und den Schnittstellennamen wurden vom Cluster ausgefüllt:
apiVersion: networking.gke.io/v1
kind: Network
metadata:
name: pod-network
spec:
routes:
- to: 192.168.0.0/16
- to: 10.96.0.0/12
dnsConfig:
nameservers:
- 10.96.0.10
Virtuelle Netzwerke erstellen und verwenden
Erstellen Sie zur Unterstützung von Produktionsarbeitslasten Netzwerke, die die benötigten Features unterstützen, z. B. die Verwendung eines externen DHCP-Servers oder die Verwendung einer VLAN-ID. Diese Netzwerke bieten Ebene-2-Verbindungen (L2) für Ihre VMs.
Externen DHCP-Server verwenden
Die VM-Laufzeit auf GDC stellt keine DHCP-Server bereit. Sie müssen die IP-Adressen für VMs manuell angeben oder die Verwendung externer DHCP-Server konfigurieren. Wenn Sie die Verwendung eines externen DHCP-Servers aktivieren, können Sie die Konfiguration der DNS- und Gateway-Einstellungen überspringen, sofern diese von DHCP bereitgestellt werden.
Führen Sie die folgenden Schritte aus, um ein Netzwerk zu erstellen, das einen externen DHCP-Server verwendet:
Erstellen Sie in einem Editor Ihrer Wahl ein
Network
-Manifest wieuse-dhcp-network.yaml
.nano use-dhcp-network.yaml
Kopieren Sie das folgende YAML-Manifest und fügen Sie es ein:
apiVersion: networking.gke.io/v1 kind: Network metadata: name: NETWORK_NAME spec: type: L2 nodeInterfaceMatcher: interfaceName: INTERFACE_NAME externalDHCP4: true
Ersetzen Sie die folgenden Werte:
NETWORK_NAME
: Name des NetzwerksINTERFACE_NAME
: der Schnittstellenname auf Ihrem Google Distributed Cloud-Knoten, an den das Netzwerk angehängt werden soll. Geben Sie den Namen der physischen Schnittstelle auf Ihrem Knoten an, die verwendet werden soll. Alle Knoten in Ihrem Cluster sollten denselben Schnittstellennamen haben.
In diesem
Network
-Manifest werden die folgenden Werte festgelegt:type
ist aufL2
gesetzt. Mit dieser Einstellung können Arbeitslasten nur einen Ebene-2-Anhang an dieses Netzwerk haben. Dies ist das einzige Netzwerktype
, das Sie in der VM-Laufzeit auf GDC erstellen können.externalDHCP4
ist auftrue
gesetzt. Diese Einstellung aktiviert externes DHCP für das Netzwerk. Der externe DHCP-Server ist für die Zuweisung von IPv4-Adressen, die Routen, das Gateway und die DNS-Konfiguration für mit diesem Netzwerk verbundene Arbeitslasten verantwortlich.
Speichern und schließen Sie das Manifest
Network
in Ihrem Editor.Erstellen Sie das Netzwerk mit
kubectl
:kubectl apply -f use-dhcp-network.yaml
Netzwerkeinstellungen manuell definieren
Die VM-Laufzeit auf GDC stellt keine DHCP-Server bereit. Sie müssen die IP-Adressen für VMs manuell angeben oder die Verwendung externer DHCP-Server konfigurieren. Wenn Sie IP-Adressen manuell angeben, müssen Sie Netzwerkeinstellungen für DNS, Routen und Standardgateway definieren.
Führen Sie die folgenden Schritte aus, um ein Netzwerk mit manuell angegebenen Netzwerkeinstellungen für VMs zu erstellen:
Erstellen Sie in einem Editor Ihrer Wahl ein
Network
-Manifest wiemanual-network.yaml
.nano manual-network.yaml
Kopieren Sie das folgende YAML-Manifest und fügen Sie es ein:
apiVersion: networking.gke.io/v1 kind: Network metadata: name: NETWORK_NAME spec: type: L2 nodeInterfaceMatcher: interfaceName: INTERFACE_NAME routes: - to: "ROUTE_ADDRESS" gateway4: GATEWAY_ADDRESS dnsConfig: nameservers: - NAMESERVER_ADDRESS
Ersetzen Sie die folgenden Werte:
NETWORK_NAME
: Name des NetzwerksINTERFACE_NAME
: der Schnittstellenname auf Ihrem Google Distributed Cloud-Knoten, an den das Netzwerk angehängt werden soll. Geben Sie den Namen der physischen Schnittstelle auf Ihrem Knoten an, die verwendet werden soll. Alle Knoten in Ihrem Cluster sollten denselben Schnittstellennamen haben.ROUTE_ADDRESS
: Optionale Routen in CIDR-Schreibweise, die auf jeder VM konfiguriert werden sollen, die eine Verbindung zu diesem Netzwerk herstellt.GATEWAY_ADDRESS
: Gateway-IP-Adresse, die von Ihren VMs verwendet werden soll.NAMESERVER_ADDRESS
: Eine oder mehrere IP-Adressen des DNS-Nameservers, die von Ihren VMs verwendet werden sollen.
Speichern und schließen Sie das Manifest
Network
in Ihrem Editor.Erstellen Sie das Netzwerk mit
kubectl
:kubectl apply -f manual-network.yaml
VLAN-ID verwenden
Beim Erstellen von virtuellen Netzwerken können Sie getaggte VLANs definieren. Mit diesen VLAN-Zuweisungen können Sie den Netzwerkverkehr basierend auf Ihren Arbeitslast- und Isolationsanforderungen isolieren. In einem AnthosManaged
-Netzwerk hat der Cluster die Berechtigung, auf jedem Knoten die VLAN-Schnittstelle zu erstellen und zu löschen.
Führen Sie die folgenden Schritte aus, um ein Netzwerk zu erstellen, das eine VLAN-Zuweisung definiert:
Erstellen Sie in einem Editor Ihrer Wahl ein
Network
-Manifest wievlan-network.yaml
.nano vlan-network.yaml
Kopieren Sie das folgende YAML-Manifest und fügen Sie es ein:
apiVersion: networking.gke.io/v1 kind: Network metadata: name: NETWORK_NAME spec: type: L2 networkLifecycle: AnthosManaged l2NetworkConfig: vlanID: VLAN_ID nodeInterfaceMatcher: interfaceName: INTERFACE_NAME externalDHCP4: true
Ersetzen Sie die folgenden Werte:
NETWORK_NAME
: Name des NetzwerksINTERFACE_NAME
: der Schnittstellenname auf Ihrem Google Distributed Cloud-Knoten, an den das Netzwerk angehängt werden soll. Geben Sie den Namen der physischen Schnittstelle auf Ihrem Knoten an, die verwendet werden soll. Alle Knoten in Ihrem Cluster sollten denselben Schnittstellennamen haben.VLAN_ID
ist die VLAN-ID, für die Sie Traffic taggen möchten.
In diesem
Network
-Manifest werden die folgenden Werte festgelegt:- Arbeitslasten können an dieses Netzwerk nur einen
L2
-Anhang haben. - Das Netzwerk ist
AnthosManaged
. Diese Einstellung ist der Standardlebenszyklus, wenn nicht angegeben.- In diesem Modus ist der Cluster berechtigt, die VLAN-Schnittstelle auf jedem Knoten zu erstellen und zu löschen, z. B.
INTERFACE_NAME.VLAN_ID
. - Wenn Sie die VLAN-Schnittstellen auf den Knoten erstellen oder bereits erstellt haben, legen Sie den
networkLifecycle
-Wert aufUserManaged
fest, wie im nächsten Abschnitt gezeigt.
- In diesem Modus ist der Cluster berechtigt, die VLAN-Schnittstelle auf jedem Knoten zu erstellen und zu löschen, z. B.
- Im Netzwerk ist externes DHCP aktiviert. Der externe DHCP-Server ist für die Zuweisung von IPv4-Adressen, die Routen, das Gateway und die DNS-Konfiguration für mit diesem Netzwerk verbundene Arbeitslasten verantwortlich.
Speichern und schließen Sie das Manifest
Network
in Ihrem Editor.Erstellen Sie das Netzwerk mit
kubectl
:kubectl apply -f vlan-network.yaml
Nutzerverwaltetes Netzwerk erstellen
Im folgenden Beispiel für ein virtuelles Netzwerk ist das Netzwerk vom Nutzer verwaltet, im Gegensatz zu dem von Anthos verwalteten in einem vorherigen Beispiel. In vom Nutzer verwalteten Netzwerken sind Sie für das Erstellen oder Löschen der VLAN-Schnittstelle auf dem Host verantwortlich.
Führen Sie die folgenden Schritte aus, um ein Netzwerk in einem vom Nutzer verwalteten Modus zu erstellen und die Konfiguration der VLAN-Schnittstelle manuell zu definieren:
Erstellen Sie in einem Editor Ihrer Wahl ein
Network
-Manifest wieuser-managed-network.yaml
.nano user-managed-network.yaml
Kopieren Sie die folgende YAML-Definition und fügen Sie sie ein:
apiVersion: networking.gke.io/v1 kind: Network metadata: name: NETWORK_NAME spec: type: L2 networkLifecycle: UserManaged l2NetworkConfig: vlanID: VLAN_ID nodeInterfaceMatcher: interfaceName: INTERFACE_NAME externalDHCP4: true
Ersetzen Sie die folgenden Werte:
NETWORK_NAME
: Name des NetzwerksINTERFACE_NAME
ist die Hostschnittstelle, an die das Netzwerk angehängt wird.VLAN_ID
ist die VLAN-ID, für die Sie Traffic taggen möchten.
In diesem
Network
-Manifest werden die folgenden Werte festgelegt:- Arbeitslasten können an dieses Netzwerk nur einen
L2
-Anhang haben. - Das Netzwerk ist
UserManaged
. Sie müssen die VLAN-VLAN_ID
-Schnittstelle auf jedem Knoten erstellen oder löschen, bevor das Netzwerk erstellt wird oder nachdem das Netzwerk gelöscht wurde. - Im Netzwerk ist externes DHCP aktiviert. Der externe DHCP-Server ist für die Zuweisung von IPv4-Adressen, die Routen, das Gateway und die DNS-Konfiguration für mit diesem Netzwerk verbundene Arbeitslasten verantwortlich.
Speichern und schließen Sie das Manifest
Network
in Ihrem Editor.Erstellen Sie das Netzwerk mit
kubectl
:kubectl apply -f user-managed-network.yaml
VM mit einem Netzwerk verbinden
Netzwerkeinstellungen für Ihre VM wie DNS und DHCP werden statisch oder dynamisch zugewiesen, je nachdem, wie bestimmte Netzwerkkonfigurationsoptionen definiert sind:
- Wenn Sie eine statische IP-Adresse auf der VM konfigurieren, wird keine Abfrage an einen DHCP-Server gesendet. Zusätzliche Informationen zum Konfigurieren des Gateways und der Route müssen von der Netzwerkressource stammen.
- Wenn Sie keine statische IP-Adresse auf der VM konfigurieren, wird eine Abfrage an den DHCP-Server gesendet. Die VM ruft alle Informationen vom DHCP-Server ab und ignoriert jede Konfiguration, die Sie in der Netzwerkressource definieren.
- Wenn das externe DHCP in der Netzwerkressource nicht auf
true
gesetzt ist, müssen Sie eine statische IP-Adresse für die VM konfigurieren. Alle anderen Informationen stammen aus der Konfiguration, die Sie in der Netzwerkressource definieren.
Führen Sie die folgenden Schritte aus, um eine VM zu erstellen, die eine Verbindung zu einem Netzwerk herstellt:
CLI
Führen Sie die folgenden Schritte aus, um eine VM mit
kubectl
zu erstellen:kubectl virt create vm VM_NAME \ --image ubuntu20.04 \ --network NETWORK_NAME
Ersetzen Sie die folgenden Werte:
VM_NAME
: der Name Ihrer VM.NETWORK_NAME
: der Name Ihres Netzwerks, zu dem eine Verbindung hergestellt werden soll.- Wenn das Netzwerk so konfiguriert ist, dass die Verwendung externer DHCP-Server zugelassen wird, erhält die VM automatisch eine IP-Adresszuweisung. Wenn Sie eine statische IP-Adresse definieren müssen, fügen Sie den optionalen Parameter und den Wert
--ip IP_ADDRESS
hinzu.
- Wenn das Netzwerk so konfiguriert ist, dass die Verwendung externer DHCP-Server zugelassen wird, erhält die VM automatisch eine IP-Adresszuweisung. Wenn Sie eine statische IP-Adresse definieren müssen, fügen Sie den optionalen Parameter und den Wert
Manifest
Führen Sie die folgenden Schritte aus, um eine VM mit einem YAML-Manifest zu erstellen:
Erstellen Sie in einem Editor Ihrer Wahl ein
VirtualMachine
-Manifest wiemy-vm.yaml
.nano my-vm.yaml
Kopieren Sie das folgende YAML-Manifest und fügen Sie es ein:
apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachine metadata: name: VM_NAME spec: interfaces: - name: eth0 networkName: NETWORK_NAME ipAddresses: - IP_ADDRESS default: true disks: - virtualMachineDiskName: VM_NAME-boot-dv boot: true
Legen Sie in diesem YAML-Manifest die folgenden Einstellungen fest:
VM_NAME
: der Name Ihrer VM.NETWORK_NAME
: der Name Ihres Netzwerks, zu dem eine Verbindung hergestellt werden soll.IP_ADDRESS
: die IP-Adresse in CIDR-Notation, die Ihrer VM zugewiesen werden soll, z. B.192.0.2.10/24
.- Wenn Ihr Netzwerk für die Verwendung externer DHCP-Server konfiguriert ist, entfernen Sie dieses Feld aus dem Manifest
VirtualMachine
.
- Wenn Ihr Netzwerk für die Verwendung externer DHCP-Server konfiguriert ist, entfernen Sie dieses Feld aus dem Manifest
Das Bootlaufwerk mit dem Namen
VM_NAME-boot-dv
muss bereits vorhanden sein. Weitere Informationen finden Sie unter VM-Bootlaufwerk erstellen.Speichern und schließen Sie das Manifest
VirtualMachine
in Ihrem Editor.Erstellen Sie die VM mit
kubectl
:kubectl apply -f my-vm.yaml