Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Contrôleur DHCP VM (Expérimental)

harvester-vm-dhcp-controller est un produit complémentaire expérimental. Il n’est pas inclus dans l’ISO, mais vous pouvez le télécharger depuis le experimental-addons dépôt. Pour plus d’informations sur les fonctionnalités expérimentales, consultez Étiquettes de Fonctionnalités.

Vous pouvez configurer les informations du pool IP et attribuer des adresses IP aux VM fonctionnant sur des SUSE Virtualization clusters en utilisant la fonctionnalité DHCP gérée intégrée. Cette fonctionnalité, qui est une alternative au serveur DHCP autonome, utilise le produit complémentaire vm-dhcp-controller pour simplifier le déploiement des clusters invités.

SUSE Virtualization utilise le réseau d’infrastructure prévu, vous devez donc vous assurer que la connectivité réseau est disponible et planifier les pools IP à l’avance.

Fonctionnalités uniques

Les baux DHCP sont stockés dans etcd comme la seule source de vérité à travers l’ensemble du cluster.
Chacun des baux est statique par nature et fonctionne bien avec votre infrastructure réseau actuelle.
Les agents DHCP gérés peuvent toujours servir des demandes DHCP pour des entités existantes même si le plan de contrôle du cluster cesse de fonctionner, garantissant que le réseau de votre charge de travail de machine virtuelle reste disponible.

limites

La fonctionnalité DHCP gérée ne fonctionne qu’avec les interfaces réseau spécifiées dans les CR VirtualMachine. Les interfaces réseau créées dans la machine virtuelle ne sont pas prises en charge.
Les adresses IP ne sont pas allouées ou désallouées lorsque vous ajoutez ou supprimez des interfaces réseau après la création de la machine virtuelle. Les adresses MAC réelles sont enregistrées dans les CR VirtualMachineNetworkConfig.
L’opération DHCP RELEASE n’est actuellement pas prise en charge.
Les mises à jour de configuration du pool IP prennent effet uniquement après que vous ayez redémarré manuellement les pods d’agents concernés.

Installation et activation du produit complémentaire

Vous pouvez installer le produit complémentaire en exécutant la commande suivante :

kubectl apply -f https://raw.githubusercontent.com/harvester/experimental-addons/main/harvester-vm-dhcp-controller/harvester-vm-dhcp-controller.yaml

Le produit complémentaire ne peut pas détecter dynamiquement les CIDR de service spécifiques au cluster et utilise 10.53.0.0/16 par défaut.

Lorsque votre cluster utilise un CIDR de service différent, vous devez le configurer explicitement dans la section valuesContent du CR Addon pour éviter des problèmes. En particulier, les tentatives de création de ressources de pool IP (IPPools) peuvent échouer lorsque les CIDR se chevauchent avec le CIDR de service par défaut 10.53.0.0/16.

Exemple :

apiVersion: harvesterhci.io/v1beta1
kind: Addon
metadata:
  ...
  name: harvester-vm-dhcp-controller
  namespace: harvester-system
spec:
  ...
  valuesContent: |
    serviceCIDR: <your-cluster-service-cidr> # for instance, 10.96.0.0/16

Vous pouvez vérifier le CIDR de service de votre cluster en utilisant la commande suivante :

kubectl -n kube-system get pods -l component=kube-apiserver -o yaml | grep "service-cluster-ip-range"

Après l’installation, activez le produit complémentaire sur l’écran Dashboard de l’interface SUSE Virtualization ou en utilisant l’outil de ligne de commande kubectl.

Utilisation du produit complémentaire

Sur l’écran Dashboard de l’interface, créez un réseau VM.

Créez un objet IPPool en utilisant l’outil de ligne de commande kubectl.

 cat <<EOF | kubectl apply -f -
 apiVersion: network.harvesterhci.io/v1alpha1
 kind: IPPool
 metadata:
   name: net-48
   namespace: default
 spec:
   ipv4Config:
     serverIP: 192.168.48.77
     cidr: 192.168.48.0/24
     pool:
       start: 192.168.48.81
       end: 192.168.48.90
       exclude:
       - 192.168.48.81
       - 192.168.48.90
     router: 192.168.48.1
     dns:
     - 1.1.1.1
     leaseTime: 300
   networkName: default/net-48
 EOF

Créez une VM qui est connectée au réseau VM que vous avez précédemment créé.
Attendez que l’objet VirtualMachineNetworkConfig correspondant soit créé et que l’adresse MAC de l’interface réseau de la VM soit appliquée à l’objet.

Vérifiez le champ .status des objets IPPool et VirtualMachineNetworkConfig, et vérifiez que l’adresse IP est allouée et assignée à l’adresse MAC.

 $ kubectl get ippools.network net-48 -o yaml
 apiVersion: network.harvesterhci.io/v1alpha1
 kind: IPPool
 metadata:
   creationTimestamp: "2024-02-15T13:17:21Z"
   finalizers:
   - wrangler.cattle.io/vm-dhcp-ippool-controller
   generation: 1
   name: net-48
   namespace: default
   resourceVersion: "826813"
   uid: 5efd44b7-3796-4f02-947e-3949cb4c8e3d
 spec:
   ipv4Config:
     cidr: 192.168.48.0/24
     dns:
     - 1.1.1.1
     leaseTime: 300
     pool:
       end: 192.168.48.90
       exclude:
       - 192.168.48.81
       - 192.168.48.90
       start: 192.168.48.81
     router: 192.168.48.1
     serverIP: 192.168.48.77
   networkName: default/net-48
 status:
   agentPodRef:
     name: default-net-48-agent
     namespace: harvester-system
   conditions:
   - lastUpdateTime: "2024-02-15T13:17:21Z"
     status: "True"
     type: Registered
   - lastUpdateTime: "2024-02-15T13:17:21Z"
     status: "True"
     type: CacheReady
   - lastUpdateTime: "2024-02-15T13:17:30Z"
     status: "True"
     type: AgentReady
   - lastUpdateTime: "2024-02-15T13:17:21Z"
     status: "False"
     type: Stopped
   ipv4:
     allocated:
       192.168.48.81: EXCLUDED
       192.168.48.84: ca:70:82:e6:84:6e
       192.168.48.90: EXCLUDED
     available: 7
     used: 1
   lastUpdate: "2024-02-15T13:48:20Z"

 $ kubectl get virtualmachinenetworkconfigs.network test-vm -o yaml
 apiVersion: network.harvesterhci.io/v1alpha1
 kind: VirtualMachineNetworkConfig
 metadata:
   creationTimestamp: "2024-02-15T13:48:02Z"
   finalizers:
   - wrangler.cattle.io/vm-dhcp-vmnetcfg-controller
   generation: 2
   labels:
     harvesterhci.io/vmName: test-vm
   name: test-vm
   namespace: default
   ownerReferences:
   - apiVersion: kubevirt.io/v1
     kind: VirtualMachine
     name: test-vm
     uid: a9f8ce12-fd6c-4bd2-b266-245d8e77dae3
   resourceVersion: "826809"
   uid: 556440c7-eeeb-4daf-9c98-60ab39688ba8
 spec:
   networkConfig:
   - macAddress: ca:70:82:e6:84:6e
     networkName: default/net-48
   vmName: test-vm
 status:
   conditions:
   - lastUpdateTime: "2024-02-15T13:48:20Z"
     status: "True"
     type: Allocated
   - lastUpdateTime: "2024-02-15T13:48:02Z"
     status: "False"
     type: Disabled
   networkConfig:
   - allocatedIPAddress: 192.168.48.84
     macAddress: ca:70:82:e6:84:6e
     networkName: default/net-48
     state: Allocated

Vérifiez la console série de la VM et vérifiez que l’adresse IP est correctement configurée sur l’interface réseau (via DHCP).

Pods et CRDs

Lorsque le produit complémentaire est activé, les types de pods suivants s’exécutent :

Contrôleur : Réconcilie les objets CRD pour déterminer l’allocation et la correspondance entre les adresses IP et MAC. Les résultats sont persistés dans les objets IPPool.
Webhook : Valide et modifie les objets CRD lors de la réception de demandes (création, mise à jour et suppression)
Agent : Sert les demandes DHCP et s’assure que le magasin de baux DHCP interne est à jour. Cela est accompli en synchronisant l’objet IPPool spécifique auquel l’agent est associé. Les agents sont générés à la demande chaque fois que vous créez de nouveaux objets IPPool.

Le produit complémentaire introduit les nouveaux CRD suivants :

IPPool (ippl)
VirtualMachineNetworkConfig (vmnetcfg)

`IPPool` CRD

Le IPPool CRD vous permet de définir des informations sur le pool d’adresses IP. Vous devez mapper chaque objet IPPool à un objet NetworkAttachmentDefinition (NAD) spécifique, qui doit être créé au préalable.

Plusieurs CRD nommés IPPool sont utilisés dans l’écosystème SUSE Virtualization, y compris un CRD de nom similaire dans le groupe d’API loadbalancer.harvesterhci.io. Pour éviter des problèmes, assurez-vous de travailler avec le CRD IPPool dans le groupe d’API network.harvesterhci.io. Pour plus d’informations sur les opérations de CRD IPPool en relation avec les équilibreurs de charge, voir Pool d’IP.

Exemple :

apiVersion: network.harvesterhci.io/v1alpha1
kind: IPPool
metadata:
  name: example
  namespace: default
spec:
  ipv4Config:
    serverIP: 192.168.100.2 # The DHCP server's IP address
    cidr: 192.168.100.0/24 # The subnet information, must be in the CIDR form
    pool:
      start: 192.168.100.101
      end: 192.168.100.200
      exclude:
      - 192.168.100.151
      - 192.168.100.187
    router: 192.168.100.1 # The default gateway, if any
    dns:
    - 1.1.1.1
    domainName: example.com
    domainSearch:
    - example.com
    ntp:
    - pool.ntp.org
    leaseTime: 300
  networkName: default/example # The namespaced name of the NAD object

Après la création de l’objet IPPool, le processus de réconciliation du contrôleur initialise le module d’allocation d’IP et génère le pod agent pour le réseau.

$ kubectl get ippools.network example
NAME      NETWORK           AVAILABLE   USED   REGISTERED   CACHEREADY   AGENTREADY
example   default/example   98          0      True         True         True

`VirtualMachineNetworkConfig` CRD

Le VirtualMachineNetworkConfig CRD ressemble à une demande d’émission d’adresse IP et est associé aux objets NetworkAttachmentDefinition (NAD).

Un objet VirtualMachineNetworkConfig d’exemple ressemble à ce qui suit :

apiVersion: network.harvesterhci.io/v1alpha1
kind: VirtualMachineNetworkConfig
metadata:
  name: test-vm
  namespace: default
spec:
  networkConfig:
  - macAddress: 22:37:37:82:93:7d
    networkName: default/example
  vmName: test-vm

Après la création de l’objet VirtualMachineNetworkConfig, le contrôleur tente de récupérer une liste d’adresses IP inutilisées à partir du module d’allocation d’IP pour chaque adresse MAC enregistrée. La correspondance IP-MAC est ensuite mise à jour dans l’objet VirtualMachineNetworkConfig et les objets IPPool correspondants.

La création manuelle d’objets VirtualMachineNetworkConfig pour les VM n’est pas nécessaire dans la plupart des cas car le produit complémentaire gère cette tâche lors du processus de réconciliation VirtualMachine. Les objets VirtualMachineNetworkConfig créés automatiquement sont supprimés lorsque les objets VirtualMachine sont supprimés.