KubeVirt est un projet open source qui permet aux machines virtuelles d’être déployées, consommées et gérées par Kubernetes comme des containers. Le fait de disposer d’un plan de déploiement et de gestion unique pour les containers et les machines virtuelles permet d’obtenir une plate-forme unifiée pour les applications natives du cloud, quelles que soient les exigences. Par exemple, l’application peut-être principalement composée de micro-services basés sur des containers, mais il y a ce service existant qui ne peut fonctionner que dans une machine virtuelle. Avec KubeVirt, on peut faire fonctionner cette VM dans un container, géré par Kubernetes, avec les containers qui hébergent les autres services/microservices.

La technologie KubeVirt permet à des équipes de développement qui ont adopté ou veulent adopter Kubernetes mais qui possèdent des charges de travail existantes basées sur des machines virtuelles qui ne peuvent pas être facilement conteneurisées. Plus précisément, la technologie fournit une plateforme de développement unifiée où les développeurs peuvent construire, modifier et déployer des applications résidant à la fois dans des containers et des machines virtuelles dans un environnement commun et partagé :

• KubeVirt.io
• Getting Started with KubeVirt Containers and Virtual Machines Together - Red Hat OpenShift Blog

Pour cette expérience, je repars d’un Scale Set d’instances Ubuntu 18.04 LTS dans Azure de type Ev3 (qui autorise la virtualisation imbriquée) :

via ce script pour cloud-init :

Les noeuds sont liés à un réseau dans ZeroTier :

J’utilise Kubespray pour déployer un cluster Kubernetes v1.17.0 avec ces noeuds :

kubernetes-sigs/kubespray

via ce fichier d’inventaire :

et cette configuration :

Lancement du playbook Ansible :

Le cluster est opérationnel :

Suivi de MetalLB pour bénéficier du service de Load Balancing dans ce cluster :

Afin de faciliter l’installation de KubeVirt, l’opérateur unifié appelé HCO est déployé dans ce cluster. L’objectif de l’hyperconverged-cluster-operator (HCO) est de fournir un point d’entrée unique pour plusieurs opérateurs — kubevirt, cdi, réseau, etc… — où les utilisateurs peuvent les déployer et les configurer dans un seul objet.

kubevirt/hyperconverged-cluster-operator

HCO est publié en tant qu’opérateur communautaire dans Operatorhub.io. Déploiement dans ce cluster via cette ligne de commande :

$ curl https://raw.githubusercontent.com/kubevirt/hyperconverged-cluster-operator/master/deploy/deploy.sh | bash

Le résultat est un nouveau namespace appelé kubevirt-hyperconverged avec tous les opérateurs, les ressources personnalisées (CR) et les objets nécessaires à KubeVirt :

Deploiement ensuite de la console web OKD qui va être liée au cluster Kubernetes existant. En effet, la console web est livrée avec un plugin spécifique qui détecte une installation de KubeVirt par la présence de CRD (Custom Resource Definition) KubeVirt dans le cluster. Pour cela création d’un compte de service dédié pour cette console :

$ kubectl create serviceaccount console -n kube-system
$ kubectl create clusterrolebinding console --clusterrole=cluster-admin --serviceaccount=kube-system:console -n kube-system

Et je lance le déploiement de la console OKD via l’image fournie dans Quay.io.

Au préalable, j’ai récuperé le nom secret du jeton associé au compte de service de la console :

$ kubectl get serviceaccount console --namespace=kube-system -o jsonpath='{.secrets[0].name}'

Une fois détectée, elle affiche automatiquement une nouvelle option dans le menu de gauche de la fenêtre “Charge de travail” pour gérer les ressources KubeVirt :

Je récupère le client Virtctl depuis Github :

kubevirt/kubevirt

Ce qui me permet de lancer une petite machine virtuelle de test dans ce cluster :

La machine virtuelle Cirros apparaît dans la console OKD :

Je peux également utiliser Octant comme alternative :

vmware-tanzu/octant

En complément je peux également utiliser un client NoVNC déployé dans le cluster de cette manière :

Via une adresse IP fournie par ZeroTier, je peux accéder à la console VNC de la VM de test :

Pour la suite ce cette expérience, lancement de trois VMs CentOS 7 via KubeVirt :

et cet exemple de manifeste YAML :

Ces VMs sont liées au même réseau ZeroTier que précédemment :

Les trois VMs apparaissent dans la console OKD :

ainsi que via NoVNC :

Dans ces VMs j’y ai installé Docker et Kubeadm pur initier un nouveau cluster Kubernetes : initialisation du noeud maître …

Et des Workers :

Le nouveau cluster (imbriqué dans ces VMs) est opérationnel :

Je rédéploie MetalLB pour bénéficier de nouveau du service de LoadBalancing dans ce nouveau cluster :

Pour terminer ce test (et comme dans le précédent article), installation d’OpenFaaS via Helm :

$ kubectl apply -f [https://raw.githubusercontent.com/openfaas/faas-netes/master/namespaces.yml](https://raw.githubusercontent.com/openfaas/faas-netes/master/namespaces.yml)

$ helm repo add openfaas [https://openfaas.github.io/faas-netes/](https://openfaas.github.io/faas-netes/)

$ helm repo update \
 && helm upgrade openfaas --install openfaas/openfaas \
    --namespace openfaas \
    --set functionNamespace=openfaas-fn \
    --set generateBasicAuth=true \
    --set serviceType=LoadBalancer

• openfaas/faas-netes
• helm/helm

Une adresse IP est retournée via le service de Load Balancing pour accéder au portail d’OpenFaaS :

Lancement d’une première fonction de test dans le portail d’OpenFaaS :

Je réutilise la fonction qui permet de flouter les visages détectés dans une image avec cet exemple :

Invocation de cette fonction via l’URL de cette image test :

qui me retourne cette dernière avec les visages floutés :

L’exécution de la console web OKD doit permettre de créer, gérer et de supprimer des machines virtuelles fonctionnant dans un cluster Kubernetes. Cela permet aussi de déléguer aux développeurs ou à d’autres utilisateurs la création et la maintenance de leurs machines virtuelles sans avoir une connaissance approfondie de Kubernetes. Pour le moment seule la console web OKD s’avère profondément intégrée à KubeVirt mais d’autres interfaces utilisateur pourraitent voir le jour dans ce projet de la Cloud Native Computing Foundation (CNCF) :

• KubeVirt Joins Cloud Native Computing Foundation - Red Hat OpenShift Blog
• KubeVirt user interface options | KubeVirt.io

A suivre !