Créer et utiliser des réseaux virtuels pour l'environnement d'exécution des VM sur GDC

Ce document est destiné aux propriétaires d'applications et aux administrateurs de plate-forme qui exécutent GKE sur une solution Bare Metal. Ce document explique comment créer et utiliser des réseaux virtuels pour gérer les charges de travail de VM qui utilisent l'environnement d'exécution de VM sur GDC.

Avant de commencer

Pour suivre les instructions de ce document, vous devez disposer des ressources suivantes :

Accès à GKE sur un cluster Bare Metal version 1.12.0 (anthosBareMetalVersion: 1.12.0) ou ultérieure. Vous pouvez utiliser n'importe quel type de cluster capable d'exécuter des charges de travail. Si nécessaire, essayez GDCV pour Bare Metal sur Compute Engine ou consultez la présentation de la création de clusters.
L'outil client virtctl, installé en tant que plug-in de kubectl. Si nécessaire, installez l'outil client virtctl.

Présentation des réseaux virtuels

Les réseaux sont créés à l'aide de ressources personnalisées. Un réseau peut être créé à tout moment après la création de votre cluster. S'ils sont définis, les paramètres réseau de l'interface hôte et l'attribution d'ID de VLAN ne peuvent pas être modifiés après la création d'un réseau.

La suppression de réseaux est soumise à certaines conditions. Par exemple, le contrôleur réseau rejette la suppression d'un réseau lorsqu'il est utilisé par des ressources, telles que des VM ou des interfaces réseau.

La définition du réseau peut inclure la passerelle, les routes et les informations DNS. Vous pouvez également activer l'utilisation d'un serveur DHCP externe. Ces paramètres réseau sont attribués de manière statique ou dynamique en fonction de la définition de certaines options de configuration réseau.

Réseau du pod par défaut

Chaque cluster dispose d'un réseau pod-network créé par défaut. Ce réseau ne peut pas être modifié. Les routes CIDR des pods et des services, ainsi que la configuration DNS, sont automatiquement renseignées. La configuration DNS utilise les mêmes valeurs que le cluster.

Le réseau pod-network peut être utilisé par des charges de travail qui ont besoin d'une interface pour accéder au réseau du pod du cluster et n'ont pas besoin d'options de configuration spécifiques. Les routes du réseau pod-network sont toujours configurées pour garantir l'accès du cluster et du service aux charges de travail, même si la passerelle par défaut ne se trouve pas dans l'interface pod-network.

Cette valeur pod-network par défaut vous permet de tester l'environnement d'exécution de la VM sur GDC sans étapes supplémentaires pour créer vos propres réseaux virtuels. De nombreux documents utilisent ce pod-network par défaut pour réduire la complexité des exemples. Les besoins de vos charges de travail de VM déterminent si ce pod-network par défaut est suffisant, ou si vous devez créer et utiliser vos propres réseaux virtuels.

Le fichier manifeste YAML suivant montre un exemple de configuration pour le pod-network. Les valeurs des routes, du DNS et du nom de l'interface ont été renseignées par le cluster :

  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

Créer et utiliser des réseaux virtuels

Pour gérer les charges de travail de production, créez des réseaux compatibles avec les fonctionnalités dont vous avez besoin, telles que l'utilisation d'un serveur DHCP externe ou l'utilisation d'un ID de VLAN. Ces réseaux fournissent une connectivité de couche 2 (L2) pour vos VM.

Utiliser un serveur DHCP externe

L'environnement d'exécution de VM sur GDC ne fournit pas de serveurs DHCP. Vous devez spécifier manuellement les adresses IP des VM ou configurer l'utilisation de serveurs DHCP externes. Lorsque vous activez l'utilisation d'un serveur DHCP externe, vous pouvez ignorer la configuration des paramètres DNS et de la passerelle s'ils sont fournis par DHCP.

Pour créer un réseau utilisant un serveur DHCP externe, procédez comme suit :

Créez un fichier manifeste Network, tel que use-dhcp-network.yaml, dans l'éditeur de votre choix :
```
nano use-dhcp-network.yaml
```
Copiez et collez le fichier manifeste YAML suivant :
```
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: NETWORK_NAME
spec:
  type: L2
  nodeInterfaceMatcher:
    interfaceName: INTERFACE_NAME
  externalDHCP4: true
```
Remplacez les valeurs suivantes :
- NETWORK_NAME : nom de votre réseau.
- INTERFACE_NAME: nom de l'interface de votre nœud GKE sur Bare Metal à laquelle associer le réseau. Indiquez le nom de l'interface physique à utiliser sur le nœud. Tous les nœuds de votre cluster doivent avoir le même nom d'interface.
Dans ce fichier manifeste Network, les valeurs suivantes sont définies :
- La propriété type est définie sur L2. Avec ce paramètre, les charges de travail ne peuvent avoir un rattachement de couche 2 que pour ce réseau. Il s'agit du seul réseau type que vous pouvez créer dans l'environnement d'exécution de VM sur GDC.
- La propriété externalDHCP4 est définie sur true. Ce paramètre active le serveur DHCP externe pour le réseau. Le serveur DHCP externe est responsable de l'allocation d'adresses IPv4, des routes, de la passerelle et de la configuration DNS pour les charges de travail connectées à ce réseau.
Enregistrez et fermez le fichier manifeste Network dans votre éditeur.
Créez le réseau à l'aide de kubectl :
```
kubectl apply -f use-dhcp-network.yaml
```

Définir manuellement les paramètres réseau

L'environnement d'exécution de VM sur GDC ne fournit pas de serveurs DHCP. Vous devez spécifier manuellement les adresses IP des VM ou configurer l'utilisation de serveurs DHCP externes. Si vous spécifiez manuellement des adresses IP, vous devez définir les paramètres réseau pour le DNS, les routes et la passerelle par défaut.

Pour créer un réseau avec des paramètres réseau spécifiés manuellement pour les VM, procédez comme suit :

Créez un fichier manifeste Network, tel que manual-network.yaml, dans l'éditeur de votre choix :
```
nano manual-network.yaml
```
Copiez et collez le fichier manifeste YAML suivant :
```
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
```
Remplacez les valeurs suivantes :
- NETWORK_NAME : nom de votre réseau.
- INTERFACE_NAME: nom de l'interface de votre nœud GKE sur Bare Metal à laquelle associer le réseau. Indiquez le nom de l'interface physique à utiliser sur le nœud. Tous les nœuds de votre cluster doivent avoir le même nom d'interface.
- ROUTE_ADDRESS : routes facultatives au format CIDR à configurer sur chaque VM qui se connecte à ce réseau.
- GATEWAY_ADDRESS : adresse IP de la passerelle que vos VM doivent utiliser.
- NAMESERVER_ADDRESS : une ou plusieurs adresses IP de serveur de noms DNS que vos VM doivent utiliser.
Enregistrez et fermez le fichier manifeste Network dans votre éditeur.
Créez le réseau à l'aide de kubectl :
```
kubectl apply -f manual-network.yaml
```

Utiliser un ID de VLAN

Lorsque vous créez des réseaux virtuels, vous pouvez définir des VLAN associés. Ces attributions de VLAN vous permettent d'isoler le trafic réseau en fonction des exigences de votre charge de travail et de vos besoins en matière d'isolation. Dans un réseau AnthosManaged, le cluster est autorisé à créer et à supprimer l'interface VLAN sur chaque nœud.

Pour créer un réseau qui définit une attribution de VLAN, procédez comme suit :

Créez un fichier manifeste Network, tel que vlan-network.yaml, dans l'éditeur de votre choix :
```
nano vlan-network.yaml
```
Copiez et collez le fichier manifeste YAML suivant :
```
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
```
Remplacez les valeurs suivantes :
- NETWORK_NAME : nom de votre réseau.
- INTERFACE_NAME: nom de l'interface de votre nœud GKE sur Bare Metal à laquelle associer le réseau. Indiquez le nom de l'interface physique à utiliser sur le nœud. Tous les nœuds de votre cluster doivent avoir le même nom d'interface.
- VLAN_ID : ID de VLAN pour lequel vous souhaitez ajouter un tag au trafic.
Dans ce fichier manifeste Network, les valeurs suivantes sont définies :
- Les charges de travail ne peuvent être associées qu'à un rattachement L2 (de couche 2) sur ce réseau.
- Le réseau est AnthosManaged. Ce paramètre correspond au cycle de vie par défaut s'il n'est pas spécifié.
  - Dans ce mode, le cluster est autorisé à créer et à supprimer l'interface VLAN sur chaque nœud, telle que INTERFACE_NAME.VLAN_ID.
  - Si vous souhaitez créer ou vous avez déjà créé les interfaces VLAN sur les nœuds, définissez la valeur networkLifecycle sur UserManaged, comme indiqué dans la section suivante.
- Le serveur DHCP externe est activé sur le réseau. Le serveur DHCP externe est responsable de l'allocation d'adresses IPv4, des routes, de la passerelle et de la configuration DNS pour les charges de travail connectées à ce réseau.
Enregistrez et fermez le fichier manifeste Network dans votre éditeur.
Créez le réseau à l'aide de kubectl :
```
kubectl apply -f vlan-network.yaml
```

Créer un réseau géré par l'utilisateur

Dans l'exemple de réseau virtuel suivant, le réseau est géré par l'utilisateur et non par Anthos comme dans l'exemple précédent. Dans les réseaux gérés par l'utilisateur, vous êtes responsable de la création ou de la suppression de l'interface VLAN sur l'hôte.

Pour créer un réseau géré par l'utilisateur et définir manuellement la configuration d'interface VLAN, procédez comme suit :

Créez un fichier manifeste Network, tel que user-managed-network.yaml, dans l'éditeur de votre choix :
```
nano user-managed-network.yaml
```
Copiez et collez la définition YAML suivante :
```
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
```
Remplacez les valeurs suivantes :
- NETWORK_NAME : nom de votre réseau.
- INTERFACE_NAME : interface hôte à laquelle associer le réseau.
- VLAN_ID : ID de VLAN pour lequel vous souhaitez ajouter un tag au trafic.
Dans ce fichier manifeste Network, les valeurs suivantes sont définies :
- Les charges de travail ne peuvent être associées qu'à un rattachement L2 (de couche 2) sur ce réseau.
- Le réseau est UserManaged. Vous devez créer ou supprimer l'interface VLAN VLAN_ID sur chaque nœud avant la création du réseau ou après sa suppression.
- Le serveur DHCP externe est activé sur le réseau. Le serveur DHCP externe est responsable de l'allocation d'adresses IPv4, des routes, de la passerelle et de la configuration DNS pour les charges de travail connectées à ce réseau.
Enregistrez et fermez le fichier manifeste Network dans votre éditeur.

Créez le réseau à l'aide de kubectl :

kubectl apply -f user-managed-network.yaml

Connecter une VM à un réseau

Les paramètres réseau de votre VM, tels que DNS et DHCP, sont attribués de manière statique ou dynamique en fonction de la définition de certaines options de configuration réseau :

Si vous configurez une adresse IP statique sur la VM, aucune requête n'est envoyée à un serveur DHCP. Les informations supplémentaires pour la configuration des passerelles et des routes doivent provenir de la ressource réseau.
Si vous ne configurez pas d'adresse IP statique sur la VM, une requête est envoyée au serveur DHCP. La VM obtient toutes les informations du serveur DHCP et ignore toute configuration définie dans la ressource réseau.
Si le serveur DHCP externe n'est pas défini sur true dans la ressource réseau, vous devez configurer une adresse IP statique pour la VM. Toutes les autres informations proviennent de la configuration que vous définissez dans la ressource réseau.

Pour créer une VM qui se connecte à un réseau, procédez comme suit :

CLI

Pour créer une VM à l'aide de kubectl, procédez comme suit :
```
kubectl virt create vm VM_NAME \
  --image ubuntu20.04 \
  --network NETWORK_NAME
```
Remplacez les valeurs suivantes :
- VM_NAME : nom de votre VM.
- NETWORK_NAME : nom du réseau auquel vous souhaitez vous connecter.
  - Si le réseau est configuré pour autoriser l'utilisation de serveurs DHCP externes, la VM obtient automatiquement une attribution d'adresses IP. Si vous devez définir une adresse IP statique, ajoutez le paramètre et la valeur --ip IP_ADDRESS facultatifs.
Remarque : Dans le répertoire ~/google-virtctl, un fichier VM_NAME.yaml est créé. Vous pouvez afficher le contenu de ce fichier pour voir la définition des ressources Kubernetes créées par l'environnement d'exécution de VM sur GDC.

Manifest

Pour créer une VM à l'aide d'un fichier manifeste YAML, procédez comme suit :

Créez un fichier manifeste VirtualMachine, tel que my-vm.yaml, dans l'éditeur de votre choix :
```
nano my-vm.yaml
```
Copiez et collez le fichier manifeste YAML suivant :
```
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
```
Dans ce fichier manifeste, définissez les paramètres suivants :
- VM_NAME : nom de votre VM.
- NETWORK_NAME : nom du réseau auquel vous souhaitez vous connecter.
- IP_ADDRESS : adresse IP au format CIDR à attribuer à votre VM, telle que 192.0.2.10/24.
  - Si votre réseau est configuré pour autoriser l'utilisation de serveurs DHCP externes, supprimez ce champ du fichier manifeste VirtualMachine.
Le disque de démarrage nommé VM_NAME-boot-dv doit déjà exister. Pour en savoir plus, consultez la section Créer un disque de démarrage de VM.
Enregistrez et fermez le fichier manifeste VirtualMachine dans votre éditeur.
Créez la VM en utilisant kubectl :
```
kubectl apply -f my-vm.yaml
```

Étapes suivantes

Modifiez une VM dans GDCV pour une solution Bare Metal.