Virtuelle Netzwerke für die VM-Laufzeit in GDC erstellen und verwenden

Dieses Dokument richtet sich an Anwendungsinhaber und Plattformadministratoren, die GKE on Bare Metal ausführen. In diesem Dokument erfahren Sie, wie Sie virtuelle Netzwerke zur Unterstützung von VM-Arbeitslasten erstellen und verwenden, die die VM-Laufzeit auf GDC verwenden.

Hinweise

Um dieses Dokument abzuschließen, benötigen Sie Zugriff auf die folgenden Ressourcen:

Zugriff auf den Cluster GKE on Bare Metal Version 1.12.0 (anthosBareMetalVersion: 1.12.0) oder höher. Sie können einen beliebigen Clustertyp verwenden, der Arbeitslasten ausführen kann. Versuchen Sie es bei Bedarf mit GDCV für Bare Metal in Compute Engine oder sehen Sie sich die Übersicht über die Clustererstellung an.
Das virtctl-Clienttool, das als Plug-in für kubectl 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 dieser Standard-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

VM-Laufzeit auf GDC bietet keine DHCP-Server. 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 wie use-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 Netzwerks
- INTERFACE_NAME: der Schnittstellenname auf Ihrem GKE on Bare-Metal-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 auf L2 gesetzt. Mit dieser Einstellung können Arbeitslasten nur einen Ebene-2-Anhang an dieses Netzwerk haben. Dies ist das einzige Netzwerk type, das Sie in der VM-Laufzeit auf GDC erstellen können.
- externalDHCP4 ist auf true 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

VM-Laufzeit auf GDC bietet keine DHCP-Server. 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 wie manual-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 Netzwerks
- INTERFACE_NAME: der Schnittstellenname auf Ihrem GKE on Bare-Metal-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 wie vlan-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 Netzwerks
- INTERFACE_NAME: der Schnittstellenname auf Ihrem GKE on Bare-Metal-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 auf UserManaged fest, wie im nächsten Abschnitt gezeigt.
- 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 wie user-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 Netzwerks
- INTERFACE_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.
Hinweis: Im Verzeichnis ~/google-virtctl wird eine VM_NAME.yaml-Datei erstellt. Sie können den Inhalt dieser Datei aufrufen, um die Definition der Kubernetes-Ressourcen aufzurufen, die von der VM-Laufzeit auf GDC erstellt wurden.

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 wie my-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.
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
```

Nächste Schritte

VM in GDCV für Bare Metal bearbeiten