Virtualisation OpenShift (projet amont - Kubernetes : KubeVirt, voir. и ), alias Container-native Virtualization, a été introduit en tant que fonctionnalité de la plate-forme OpenShift, conçue pour déployer et gérer des machines virtuelles (VM) en tant qu'entités Kubernetes de base. Ce type de tâche est techniquement difficile en raison de différences technologiques fondamentales. Pour atteindre cet objectif, nous avons utilisé des technologies familières basées sur Red Hat Enterprise Linux et KVM, qui nous accompagnent depuis de nombreuses années et ont prouvé leur efficacité.
Dans cet article, nous examinerons les aspects techniques de la virtualisation OpenShift qui permettent aux VM et aux conteneurs de cohabiter au sein d'une seule plateforme qui les gère comme une seule entité.
Tâches informatiques
Les conteneurs utilisent les mécanismes du noyau Linux tels que les espaces de noms et les groupes de contrôle pour isoler les processus et gérer les ressources. Habituellement, les processus sont compris comme des applications Python, Java ou des fichiers exécutables, mais en fait, il peut s'agir de n'importe quel processus, tel que bash, Emacs ou vim.
Qu'est-ce qu'une machine virtuelle ? Du point de vue de l’hyperviseur, c’est aussi un processus. Mais pas le processus de candidature, mais le processus KVM chargé d'exécuter une VM spécifique.
L'image du conteneur contient tous les outils, bibliothèques et fichiers nécessaires à la machine virtuelle KVM. Si nous inspectons le pod d'une VM en cours d'exécution, nous y verrons des assistants et des processus qemu-kvm. De plus, nous avons accès à des outils KVM pour gérer les machines virtuelles tels que qemu-img, qemu-nbd et virsh.
Puisqu’une machine virtuelle est un pod, elle hérite automatiquement de toutes les fonctionnalités d’un pod dans Kubernetes. Les pods de VM, tout comme les pods classiques, sont soumis à des schémas de planification et à des critères tels que les contaminations, les tolérances, l'affinité et l'anti-affinité. Vous bénéficiez également des avantages de la haute disponibilité, etc. Cependant, il existe une différence importante : les pods classiques ne migrent pas d'un hôte à l'autre au sens habituel du terme. Si un nœud se déconnecte, le pod qu'il contient est terminé et réaffecté à un autre nœud du cluster. Et dans le cas d’une machine virtuelle, nous nous attendons à une migration en direct.
Pour combler cette lacune, une définition de ressource personnalisée (CDR) a été créée pour décrire le mécanisme de migration en direct responsable de l'initialisation, de la surveillance et de la gestion des migrations en direct des machines virtuelles entre les nœuds de travail.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Lorsqu'un nœud est désactivé, des tâches de migration sont automatiquement créées pour les machines virtuelles pour lesquelles Live Migration est définie comme stratégie d'expulsion. De cette façon, vous pouvez contrôler le comportement des machines virtuelles lors du déplacement entre les nœuds du cluster. Vous pouvez à la fois configurer Live Migration et gérer la VM, comme tous les autres pods.
Réseau
Tout système Kubernetes assure la communication entre les nœuds et les pods à l'aide de réseaux logiciels SDN. OpenShift ne fait pas exception et, à partir de la version 3, utilise OpenShiftSDN par défaut pour cela. De plus, OpenShift 4 dispose d'une autre nouvelle fonctionnalité appelée Multus, qui vous permet de rendre plusieurs réseaux disponibles et d'y connecter des pods simultanément.
À l'aide de Multus, l'administrateur peut définir des réseaux CNI supplémentaires, qui seront ensuite déployés et configurés sur le cluster par un opérateur de réseau de cluster spécial. Les pods sont ensuite connectés à un ou plusieurs de ces réseaux, généralement le standard OpenShiftSDN et une interface supplémentaire. Les appareils SR-IOV, Linux Bridge standard, MACVLAN et IPVLAN peuvent tous être utilisés si votre VM en a besoin. La figure ci-dessous montre comment configurer Multus CNI pour le réseau pont sur l'interface eth1 :
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
name: cluster
spec:
additionalNetworks:
- name: multus1
rawCNIConfig: '{ "cniVersion": "0.3.1", "type": "bridge", "master": "eth1", "ipam":
{ "type": "static", "addresses": [ { "address": "191.168.1.1/24" } ] } }'
type: Raw
En ce qui concerne la virtualisation OpenShift, cela signifie qu'une VM peut être connectée directement à un réseau externe, en contournant le SDN. Ceci est important pour les machines virtuelles migrées vers OpenShift depuis Red Hat Virtualization ou VMware vSphere, car si vous avez accès à la deuxième couche OSI, il n'y aura aucun changement dans les paramètres réseau. Cela signifie également que la VM peut avoir une adresse réseau qui contourne le SDN. Ainsi, nous pouvons utiliser efficacement des adaptateurs réseau spécialisés, ou nous connecter directement au système de stockage via le réseau...
Vous pouvez en savoir plus sur la façon de créer et de connecter des machines virtuelles de virtualisation OpenShift au réseau. . En outre, , déployé dans le cadre de la virtualisation OpenShift, offre un autre moyen familier de créer et de gérer des configurations réseau sur des nœuds physiques utilisés sous des hyperviseurs.
stockage
La connexion et la gestion des disques de machines virtuelles dans la virtualisation OpenShift sont effectuées à l'aide des concepts Kubernetes tels que StorageClasses, PersistentVolumeClaims (PVC) et PersistentVolume (PV), ainsi que des protocoles de stockage standard pour l'environnement Kubernetes. Cela donne aux administrateurs Kubernetes et aux équipes d'applications un moyen commun et familier de gérer à la fois les conteneurs et les machines virtuelles. Et pour de nombreux administrateurs d'environnements de virtualisation, ce concept peut sembler familier car il utilise le même principe de séparation des fichiers de configuration et des disques de VM que celui utilisé dans OpenStack et de nombreuses autres plates-formes cloud.
Cependant, nous ne pouvons pas simplement créer un nouveau disque pour la VM à chaque fois, car lors de la migration de l'hyperviseur vers OpenShift, nous devons sauvegarder les données. Oui, même lorsque l’on déploie une nouvelle VM, il est toujours plus rapide de le faire à partir d’un modèle que de la créer de toutes pièces. Ainsi, nous avons besoin d'une fonctionnalité pour importer des disques existants.
Pour simplifier cette tâche, la virtualisation OpenShift déploie le projet Containerized Data Importer (CDI), qui réduit l'importation d'images disque de disques provenant de plusieurs sources à la création d'une entrée PVC.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: "fedora-disk0"
labels:
app: containerized-data-importer
annotations:
cdi.kubevirt.io/storage.import.endpoint: "http://10.0.0.1/images/Fedora-Cloud-Base-31-1.9.x86_64.qcow2"
spec:
storageClassName: ocs-gold
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
C'est cette entrée qui active le CDI, déclenchant la séquence d'actions illustrée dans la figure ci-dessous :
Une fois le CDI terminé, le PVC contiendra le disque de la machine virtuelle prêt à l'emploi et converti au format standard OpenShift...
Lorsque vous travaillez avec la virtualisation OpenShift, OpenShift Container Storage (OCS), une solution Red Hat basée sur le système de fichiers Ceph qui implémente une fonctionnalité de stockage persistant pour les conteneurs, est également utile. En plus des méthodes d'accès PVC standard - RWO (bloc) et RWX (fichier) - OCS fournit RWX pour les périphériques en bloc brut, ce qui est très utile pour partager l'accès en bloc pour les applications ayant des exigences de performances élevées. De plus, OCS prend en charge la nouvelle norme Object Bucket Claim, qui permet aux applications d'utiliser directement le stockage de données objet.
Machines virtuelles dans des conteneurs
Si vous souhaitez vérifier son fonctionnement, sachez que la virtualisation OpenShift est déjà disponible dans la version Tech Preview dans le cadre d'OpenShift 3.11 et supérieur. Les propriétaires d'un abonnement OpenShift existant peuvent utiliser la virtualisation OpenShift entièrement gratuitement et sans aucune étape supplémentaire. Au moment de la rédaction de cet article, OpenShift 4.4 et OpenShift virtualization 2.3 sont à jour ; si vous utilisez des versions précédentes, vous devez effectuer une mise à niveau pour obtenir les dernières fonctionnalités. Une version entièrement prise en charge de la virtualisation OpenShift devrait être publiée au cours du second semestre 2020.
Pour plus d'informations, veuillez consulter pour les instructions d'installation, y compris , qui fournit des informations sur la configuration de réseaux externes.
Source: habr.com