Déployer la prise en charge du plan de données Kubevirt DPDK pour les machines virtuelles
RÉSUMÉ Cloud-Native Contrail® Networking prend en™ charge le déploiement du plan de données vRouter DPDK (Kubevirt) pour les vm et les réseaux de conteneurs hautes performances dans Kubernetes.
Présentation de Kubevirt
Kubevirt est un projet Kubernetes open source qui permet la gestion (planification) des charges de travail de machines virtuelles (VM) ainsi que des charges de travail de conteneur au sein d’un cluster Kubernetes. Kubevirt fournit une plate-forme de développement unifiée où les développeurs créent, modifient et déploient des applications résidant à la fois dans des conteneurs d’applications et des vm dans un environnement commun et partagé. Kubevirt fournit les fonctions supplémentaires suivantes à votre cluster Kubernetes :
- Kubevirt ajoute des types supplémentaires de pods ou des définitions de ressources personnalisées (CRD) au serveur d’API Kubernetes
- Contrôleurs supplémentaires pour la logique à l’échelle du cluster pour prendre en charge les nouveaux types de pods
- Daémons supplémentaires pour la logique spécifique aux nœuds pour prendre en charge les nouveaux types de pods
Grâce à cette nouvelle fonctionnalité, Kubevirt crée et gère des VirtualMachineInstance objets (VMI). Les VMIs contiennent un contrôleur de charge de travail appelé VirtualMachine (VM). La VM maintient l’état persistant de sa VMI. Cela permet aux utilisateurs d’arrêter et de lancer des machines virtuelles à un autre moment, sans modification des données ou de l’état. En outre, vous pouvez déployer Kubevirt sur un cluster Kubernetes qui vous permet de gérer les charges de travail de conteneurs traditionnelles avec des VMIs gérées par Kubevirt. Les machines virtuelles ont accès aux fonctionnalités du cluster Kubernetes sans autorisation supplémentaire requise.
Implémentation kubevirt DPDK
Kubevirt ne prend généralement pas en charge la mise en réseau de l’espace utilisateur pour un traitement rapide des paquets. Dans Cloud-Native Contrail Networking, les améliorations permettent toutefois à Kubevirt de prendre en charge vhostuser les types d’interface pour les VM. Ces interfaces assurent la mise en réseau de l’espace utilisateur avec le vRouter DPDK et permettent aux pods d’accéder aux performances accrues et au traitement des paquets qu’offre le vRouter DPDK.
Voici quelques-uns des avantages de l’application VRouter DPDK :
- Le traitement des paquets se fait dans l’espace utilisateur et contourne l’espace du noyau. Cela augmente l’efficacité du traitement des paquets.
- Le noyau est interrompu et les commutateurs de contexte ne se produisent pas, car les paquets contournent l’espace du noyau. Cela se traduit par une baisse des coûts de processeur et un débit de données accru.
- DPDK améliore le plan de transfert du vRouter dans l’espace utilisateur, augmentant ainsi les performances.
- Les Lcores DPDK s’exécutent en mode sondage. Les Lcores peuvent ainsi recevoir et traiter les paquets immédiatement après leur réception.
Déployer Kubevirt
Conditions préalables
Vous devez disposer d’un cluster Kubernetes actif et de la capacité d’utiliser le kubectl client pour déployer Kubevirt.
Déployer la solution Cloud-Native Contrail Networking Kubevirt Fork
La version actuelle de Kubevirt (v0.48.0) ne prend pas en charge les améliorations permettant d’activer l’interface vhostuser . Juniper gère un fork Kubevirt qui prend en charge cette interface DPDK. Ce fork Kubevirt est destiné aux environnements exécutant Cloud-Native Contrail Networking. Les modifications apportées à la fourchette sont engagées en plus de la version de Kubevirt (v0.40.0) et étiquetées/publiées en tant que version (v.0.40.0-jnpr) à partir de la fourchette.
L’opérateur Kubevirt et Kubevirt CR sont également libérés du référentiel fork. L’opérateur Kubevirt gère le cycle de vie des composants kubevirt centraux. L’opérateur Kubevirt et le CR permettent la virtualisation de votre cluster.
Utilisez les commandes suivantes pour déployer l’opérateur Kubevirt fork, Kubevirt CR et Kubevirt. Notez la version de version (v0.40.0) et les chemins d’installation des fichiers.
export RELEASE=v0.40.0-jnpr
kubectl apply -f https://github.com/cijohnson/kubevirt/releases/download/${RELEASE}/kubevirt-operator.yaml
kubectl apply -f https://github.com/cijohnson/kubevirt/releases/download/${RELEASE}/kubevirt-cr.yaml
kubectl -n kubevirt wait kv kubevirt --for condition=Available
Lancer une VM à côté d’un conteneur
Avec Kubevirt, le lancement et la gestion d’une VM dans Kubernetes s’apparentent au déploiement d’un pod. Vous pouvez créer un objet VM à l’aide de kubectl. Après avoir créé un objet VM, cette VM est active et s’exécute dans votre cluster.
Pour lancer une VM en parallèle d’un conteneur, suivez les étapes suivantes :
- Créer un
VirtualNetwork - Lancer une VM
Lancer une VM
Les spécifications suivantes VirtualMachine sont des exemples d’instances VirtualMachine avec un nombre variable d’interfaces.
- VM d’interface unique
vhostuser:apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: name: vm-single-virtio namespace: contrail spec: running: true template: metadata: labels: kubevirt.io/size: small kubevirt.io/domain: vm-single-virtio app: vm-single-virtio-app spec: nodeSelector: master: master terminationGracePeriodSeconds: 30 domain: cpu: sockets: 1 cores: 8 threads: 2 #dedicatedCpuPlacement: true memory: hugepages: pageSize: "2Mi" resources: requests: memory: "512Mi" devices: disks: - name: containerdisk disk: bus: virtio - name: cloudinitdisk disk: bus: virtio interfaces: - name: default bridge: {} - name: vhost-user-vn-blue vhostuser: {} useVirtioTransitional: true networks: - name: default pod: {} - name: vhost-user-vn-blue multus: networkName: vn-blue volumes: - name: containerdisk containerDisk: image: svl-artifactory.juniper.net/atom-docker/dpdk-pktgen/vmdisks/dpdk-pktgen-auto:latest - name: cloudinitdisk cloudInitNoCloud: userDataBase64: SGkuXG4= - Multi-interface
vhostuser:apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: name: vm-multi-virtio namespace: contrail spec: running: true template: metadata: labels: kubevirt.io/size: small kubevirt.io/domain: vm-multi-virtio app: vm-multi-virtio-app spec: nodeSelector: worker: worker terminationGracePeriodSeconds: 30 domain: cpu: sockets: 1 cores: 8 threads: 2 #dedicatedCpuPlacement: true memory: hugepages: pageSize: "2Mi" resources: requests: memory: "512Mi" devices: disks: - name: containerdisk disk: bus: virtio - name: cloudinitdisk disk: bus: virtio interfaces: - name: default bridge: {} - name: vhost-user-vn-blue vhostuser: {} - name: vhost-user-vn-green vhostuser: {} useVirtioTransitional: true networks: - name: default pod: {} - name: vhost-user-vn-blue multus: networkName: vn-blue - name: vhost-user-vn-green multus: networkName: vn-green volumes: - name: containerdisk containerDisk: image: svl-artifactory.juniper.net/atom-docker/dpdk-pktgen/vmdisks/dpdk-pktgen-auto:latest - name: cloudinitdisk cloudInitNoCloud: userDataBase64: SGkuXG4= - VM pont/
vhostuserinterface :apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: name: vm-virtio-veth namespace: contrail spec: running: true template: metadata: labels: kubevirt.io/size: small kubevirt.io/domain: vm-virtio-veth app: vm-virtio-veth-app spec: nodeSelector: master: master terminationGracePeriodSeconds: 30 domain: cpu: sockets: 1 cores: 8 threads: 2 #dedicatedCpuPlacement: true memory: hugepages: pageSize: "2Mi" resources: requests: memory: "512Mi" devices: disks: - name: containerdisk disk: bus: virtio - name: cloudinitdisk disk: bus: virtio interfaces: - name: default bridge: {} - name: vhost-user-vn-blue vhostuser: {} - name: vhost-user-vn-green bridge: {} useVirtioTransitional: true networks: - name: default pod: {} - name: vhost-user-vn-blue multus: networkName: vn-blue - name: vhost-user-vn-green multus: networkName: vn-green volumes: - name: containerdisk containerDisk: image: svl-artifactory.juniper.net/atom-docker/dpdk-pktgen/vmdisks/dpdk-pktgen-auto:latest - name: cloudinitdisk cloudInitNoCloud: userDataBase64: SGkuXG4=
Créer un réseau virtuel
L’objet suivant net-attach-def est un exemple de réseau virtuel.
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: vn-blue
namespace: contrail
annotations:
juniper.net/networks: '{
"ipamV4Subnet": "19.1.1.0/24"
}'
labels:
vn: vn-blue-vn-green
spec:
config: '{
"cniVersion": "0.3.1",
"name": "nad-blue",
"type": "contrail-k8s-cni"
}'
Lancer une VM
Les spécifications suivantes VirtualMachine sont des exemples d’instances VirtualMachine avec un nombre variable d’interfaces.
- VM d’interface unique
vhostuser:apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: name: vm-single-virtio namespace: contrail spec: running: true template: metadata: labels: kubevirt.io/size: small kubevirt.io/domain: vm-single-virtio app: vm-single-virtio-app spec: nodeSelector: master: master terminationGracePeriodSeconds: 30 domain: cpu: sockets: 1 cores: 8 threads: 2 #dedicatedCpuPlacement: true memory: hugepages: pageSize: "2Mi" resources: requests: memory: "512Mi" devices: disks: - name: containerdisk disk: bus: virtio - name: cloudinitdisk disk: bus: virtio interfaces: - name: default bridge: {} - name: vhost-user-vn-blue vhostuser: {} useVirtioTransitional: true networks: - name: default pod: {} - name: vhost-user-vn-blue multus: networkName: vn-blue volumes: - name: containerdisk containerDisk: image: svl-artifactory.juniper.net/atom-docker/dpdk-pktgen/vmdisks/dpdk-pktgen-auto:latest - name: cloudinitdisk cloudInitNoCloud: userDataBase64: SGkuXG4= - Multi-interface
vhostuser:apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: name: vm-multi-virtio namespace: contrail spec: running: true template: metadata: labels: kubevirt.io/size: small kubevirt.io/domain: vm-multi-virtio app: vm-multi-virtio-app spec: nodeSelector: worker: worker terminationGracePeriodSeconds: 30 domain: cpu: sockets: 1 cores: 8 threads: 2 #dedicatedCpuPlacement: true memory: hugepages: pageSize: "2Mi" resources: requests: memory: "512Mi" devices: disks: - name: containerdisk disk: bus: virtio - name: cloudinitdisk disk: bus: virtio interfaces: - name: default bridge: {} - name: vhost-user-vn-blue vhostuser: {} - name: vhost-user-vn-green vhostuser: {} useVirtioTransitional: true networks: - name: default pod: {} - name: vhost-user-vn-blue multus: networkName: vn-blue - name: vhost-user-vn-green multus: networkName: vn-green volumes: - name: containerdisk containerDisk: image: svl-artifactory.juniper.net/atom-docker/dpdk-pktgen/vmdisks/dpdk-pktgen-auto:latest - name: cloudinitdisk cloudInitNoCloud: userDataBase64: SGkuXG4= - VM pont/
vhostuserinterface :apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: name: vm-virtio-veth namespace: contrail spec: running: true template: metadata: labels: kubevirt.io/size: small kubevirt.io/domain: vm-virtio-veth app: vm-virtio-veth-app spec: nodeSelector: master: master terminationGracePeriodSeconds: 30 domain: cpu: sockets: 1 cores: 8 threads: 2 #dedicatedCpuPlacement: true memory: hugepages: pageSize: "2Mi" resources: requests: memory: "512Mi" devices: disks: - name: containerdisk disk: bus: virtio - name: cloudinitdisk disk: bus: virtio interfaces: - name: default bridge: {} - name: vhost-user-vn-blue vhostuser: {} - name: vhost-user-vn-green bridge: {} useVirtioTransitional: true networks: - name: default pod: {} - name: vhost-user-vn-blue multus: networkName: vn-blue - name: vhost-user-vn-green multus: networkName: vn-green volumes: - name: containerdisk containerDisk: image: svl-artifactory.juniper.net/atom-docker/dpdk-pktgen/vmdisks/dpdk-pktgen-auto:latest - name: cloudinitdisk cloudInitNoCloud: userDataBase64: SGkuXG4=