Ce document est destiné aux administrateurs informatiques, aux opérateurs et aux spécialistes de la mise en réseau 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. Pour en savoir plus sur les rôles courants et découvrir des exemples de tâches référencées dans le contenu Google Cloud, consultez la page Rôles utilisateur et tâches courants dans GKE Enterprise.
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 GKE sur 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 dekubectl
. 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 queuse-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 surL2
. 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éseautype
que vous pouvez créer dans l'environnement d'exécution de VM sur GDC. - La propriété
externalDHCP4
est définie surtrue
. 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 quemanual-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 quevlan-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
surUserManaged
, comme indiqué dans la section suivante.
- Dans ce mode, le cluster est autorisé à créer et à supprimer l'interface VLAN sur chaque nœud, telle que
- 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 queuser-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 VLANVLAN_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.
- 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
Manifest
Pour créer une VM à l'aide d'un fichier manifeste YAML, procédez comme suit :
Créez un fichier manifeste
VirtualMachine
, tel quemy-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 que192.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
.
- Si votre réseau est configuré pour autoriser l'utilisation de serveurs DHCP externes, supprimez ce champ du fichier manifeste
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