Home

Déployer des VMs dans et via Kubernetes

Les applications sont souvent composées de PODs Kubernetes et de VMs. L’exemple le plus commun que l’on retrouve est, une base de données sous forme de VM et le reste de l’application sous forme de PODs. Par reflexe, à tort ou à raison, ce qui nécessite de la persistance de données est mis sous forme de VMs.

La plateforme vSphere with Tanzu est une plateforme permetant elle aussi d’héberger simultanément et nativement des PODs Kubernetes et des VMs.

Jusqu’à présent les VMs et les PODs étaient déployées via des méthodes différentes et connectés sur des réseaux différents, ce qui pouvait engendrer pour les développeurs un délai de mise à disposition d’environnement de développement et des risques d’échecs de connexion. En effet, les développeurs devaient demander à l’équipe qui gère l’infrastructure, le déploiement d’une VM avec une expression de besoin.

Pour diminuer l’impact temps et les risques d’erreur, les équipes d’infrastructure ont mis en place des outils d’automatisation via un système de ticketing ou via un portail self-service pour donner ainsi une certaine autonomie. Le déploiement est bien simplifié mais ce n’est pas encore suffisant car ça implique au développeur l’apprentissage et l’utilisation d’outils supplémentaires et de récupérer les modalités de connexions à la VM déployée. Le portail self-service n’est pas désuet pour autant, il a beaucoup d’autres valeurs comme la gestion de la gouvernance, j’espère avoir l’occasion d’écrire un article dessus pour les détaillées.

Schéma de principe montrant un développeur qui click sur son portail pour déployer une VM qui sera connectée à un réseau.
Ce même développeur utilise la commande Kubernetes kubectl pour déployer ses PODs. Kubernetes utilise son propre réseau.

Depuis vSphere 7U2a il est désormais possible de provisionner des VMs de la même manière que l’on déploie des PODs, en utilisant la commande kubectl de Kubernetes. Pour être plus précis, depuis le début de vSphere with Tanzu (à l’origine ça s’appelait Projet Pacific) il était possible de déployer des Machines virtuelles à partir de Kubernetes, elles étaient cependant réservées aux usages internes de Kubernetes comme pour la création de Tanzu Kubernetes Cluster.

Désormais le développeur peut lui aussi déployer ses propres machines virtuelles, elles seront en plus connectées au même réseau que les pods. La perte de temps et les risques d’erreur sont ainsi éliminés. J’ai fait le test sur mon environnement de démonstration qui est mutualisé avec mes autres collègues, ça prend moins de 3 minutes pour avoir une base MongoDB fraîchement installée à partir d’un Linux Ubuntu complètement vierge.

Schéma de principe montrant un développeur qui utilise fois la commande Kubernetes kubectl pour déployer ses PODs et ses VMs.
Le tout sera connecté au même réseau Kubernetes

 

Quels sont les périmètres de chaque persona ?

Il y en a deux, le fournisseur de ressources et le consommateur. Le fournisseur est l’administrateur de l’infrastructure qui va présenter les ressources à consommer et si nécessaire les caper. Le consommateur est le développeur qui va utiliser ces ressources via Kubernetes pour développer son application.

La personne de l’infrastructure avec son outil habituel (vSphere client), créé un Namespace de ressources, octroi les droits d’accès au développeur, définir les classes de service (nb de CPU, quantité de RAM) auquel le développeur aura le droit d’utiliser et la librairie d’image de VM qu’il pourra utiliser.

Le développeur se connecte via son compte au Namespace fourni et créé ainsi ses fichiers YAML afin de définir ses besoins en ressources pour sa ou ses machines virtuelles et s’ils le souhaitent, il peut la ou les personnaliser afin d’y installer ses outils et les services dont il a besoin.

En résumé, vSphere with Tanzu laisse le choix au développeur d’avoir ses composant applicatifs développés et hébergés sur des PODs ou sur des VMs et ce en utilisant le même outil, le même réseau et la même plateforme. Il y gagne ainsi en temps de déploiement, de développement et en agilité.

 

Si vous souhaitez soulevez le capot, je vous invite à lire cet article : Etapes pour la création de VM via kubectl

Quelle plateforme pour les applications « Share Nothing Architecture » ?

Les entreprises cherchent de l’agilité pour aller de plus en plus vite dans leur croissance. Lorsqu’elles développent des applications à destination de l’interne ou de l’externe c’est pour accompagner cette croissance de manière à avoir un impact direct ou indirect. Il faut donc tout faire pour que les développeurs puissent développer ces applications en ayant eux aussi l’agilité attendue. D’où l’attrait des services du cloud public, en effet tout est déjà prêt à être consommé, il déploie simplement un service de données (type base de données ou objet) et interconnecte l’application avec, ils se focalisent sur leur développement. Avoir cette souplesse dans son datacenter permettrait d’allier agilité et sécurité maîtrisée.

La plate-forme VMware Cloud Foundation withTanzu (anciennement vSphere with Kubernetes ou encore Projet Pacific) est une plate-forme mixte capable d’héberger simultanément des applications fonctionnant sur des machines virtuelles et des applications fonctionnant sur des PODs Kubernetes (des containers). Elle permet aussi de fournir d’ores et déjà les services réseau, les services de stockage, le service de registry et le service de sauvegarde/restauration. La plate-forme se dote désormais de services autour de la donnée. Au moment de la rédaction de cet article, deux solutions y sont déjà intégrées : Minio et Cloudian, solutions de stockage objets compatible avec l’API S3, deux autres sont en cours d’intégration : Dell EMC ObjectScale lui aussi un stockage objet compatible S3 et Datastax une base de données NoSQL à base de Cassandra. D’autres viendront rapidement.

 

En quoi est-ce révolutionnaire ?

Contrairement à la majorité des applications dites traditionnelles/classiques/monolithique, les applications dites modernes/Cloud Native/scalable, elles, ne comptent pas sur les artifices de l’infrastructure pour optimiser leur performance ou pour assurer leur résilience, elles utilisent leurs propres mécanismes de manière à être disponible, performante autant que possible et ce quelle que soit l’infrastructure. Elles ont bien sûr besoin de cette infrastructure mais brute, juste pour consommer directement les ressources telles quelles, brutes (les processeurs, de la mémoire et des axes d’IO). Ces applications sont bien souvent des applications SNA (Shared Nothing Architecture), chaque instance servant une même application utilise ses propres ressources sur un serveur distinct et répartissent les données entres ces serveurs, les lectures et  les écritures des données sont ainsi distribuées pour de meilleur performances et une meilleure résilience en prenant en compte la perte potentiel d’un serveur voire d’un site complet.

Sur une infrastructure physique (sans virtualisation), chaque instance à son propre serveur et ses propres ressources. Il n’y a donc pas de problème de placement, une instance sur chaque serveur, cependant, cela induit un problème financier car les serveurs sont dédiés à cet usage, ce n’est pas optimum à moins de consommer toutes les ressources et tout le temps, ce qui est rarement le cas.

Sur une infrastructure virtuelle, les ressources sont partagées, par conséquent celles non utilisées le sont par d’autres applications, elle permet aussi de s’affranchir des problèmes de comptabilité avec le matériel et de bénéficier de tous les autres avantages maintenant connus apportés par la virtualisation. Cependant elle apporte une contrainte pour les applications SNA, comme les instances sont virtualisées, comment s’assurer que ces instances et surtout les données générées sont bien réparties sur des serveurs de virtualisation distincts et donc pouvoir se prémunir de la perte de l’un d’entres eux ?

C’est là que la plateforme VMware Cloud Foundation with Tanzu couplée au module vSAN Data Persistence plateforme (vDPp) entre en jeux. Elle permet aux éditeurs partenaire de tirer le meilleur parti de la plateforme en fournissant leur solution « as a Service ». Cela passe par le développement d’un opérateur qui va automatiser l’installation, la configuration et simplifier le maintien en condition opérationnelle de l’application.

Il suffit de cliquer pour que le service soit opérationnel

 

vDPp connait l’infrastructure, l’application, elle, sait comment assurer sa disponibilité et obtenir ses meilleures performance. L’opérateur va ainsi répartir le nombre d’instance nécessaire sur différents serveurs de virtualisation.

Cette politique de stockage vSAN permet

de garder l’instance applicative sur le même serveur de virtualisation où sont stockées les données.

 

Lors d’opérations de maintenance, l’application est tenue informée afin qu’elle puisse prendre en compte le décommissionnement à chaud d’un serveur de virtualisation.

vDPp tient également informée l’application de manière pro-active si des disques commencent à donner des signes de défaillance.

Les développeurs quant à eux, n’ont qu’à consommer ces services via les APIs habituelles et se consacrer au développement de leur application sans se soucier de rien d’autre. Ils ont un service de données activable à la demande, résiliant, performance.

 

En résumé :

La plateforme VMware Cloud Foundation with Tanzu couplée avec vSAN Data Persistence platform offre une agilité unique pour faciliter le maintien en condition opérationnelle des services de données. Grace à cela, les développeurs se focalisent sur le développement de leur application en continuant d’utiliser leurs outils traditionnels, ils ont une plate-forme souple à l’instar de ce qui se fait sur le cloud public.

Il faut voir la plateforme Cloud Foundation with Tanzu comme une plateforme complète pour développer et héberger les applications traditionnelles comme les applications modernes avec les services intégrés disponible à la demande que cela nécessite.

Passer du code source à une image container en une seule commande

Le passage d’un code source à une image container prête à être consommée est une étape indispensable et l’effort que cela nécessite est souvent sous-estimé. Pour synthétiser, ce passage consiste à créer un fichier de configuration pour renseigner sur quel image de système d’exploitation doit fonctionner le container, comment télécharger le compilateur, comment compiler l’application et comment exécuter l’application. Ensuite, il faut lancer la commande de construction du container puis le charger dans une registry pour un téléchargement et une exécution ultérieurs. Sur un petit environnement avec quelques containers, quelques fichiers de configuration et quelques commandes à exécuter, c’est faisable. Cependant, ça devient vite plus compliqué à mesure où le nombre de container croît. Ça sera d’autant plus compliqué avec l’inévitable gestion du cycle de vie des applications, celle-ci est induite par la mise à jour du code applicatif et par les mises à jour de sécurité des composants liés au système d’exploitation. C’est une tâche fastidieuse et chronophage.

L’agilité étant l’objectif premier de l’utilisation des containers, l’automatisation du processus de création d’image container est vite devenue indispensable. Dans la majorité des cas, l’utilisation d’un pipe-line est privilégiée pour enchaîner les commandes de création et de mise à jour. La mise en place et le maintien en condition opérationnel de ce pipeline n’est pas non plus à négliger.

J’ai récemment testé VMware Tanzu Build Service (TBS), je me suis vite rendu compte qu’il simplifie drastiquement ce processus et j’ai été séduit par sa facilité d’utilisation. En effet en une seule commande, le code source est transformé en image container puis stockée dans une registry et ce sans que le développeur n’ait à générer de fichier de configuration.

Les containers sont créés au format OCI (Open Container Initiative, lancée en 2015 par Docker) assurant leur fonctionnement sur l’ensemble des runtime container du marché à condition qu’ils respectent cette initiative.

D’un point de vu macro, l’image container générée est découpée en 3 parties indépendantes : la Stack, le buildpack et l’Application qui permettent une modification granulaire.

La stack (appelée aussi Cloudstack) concerne la partie liée au système d’exploitation, le Buildpack concerne la partie qui permet de construire et d’exécuter l’application (java, nodejs, php, …), la partie Application concerne le code source de l’application. Cela permet de mettre à jour granulairement chaque partie de manière indépendante. Ainsi, si par exemple une faille de sécurité est détectée sur la partie stack, TBS permettra de mettre à jour que cette partie en appliquant un patch de sécurité.

Voyons le fonctionnement principal :

En entrée TBS a besoin d’un code source (les langages pris en charge sont fonctions des buildpack installés (Java, go, php, …)), ce code source peut être, dans un répertoire local, sur un repository git ou encore sur un blob store http au format zip, tgz ou tar.

En sortie, TBS va stocker le container image dans une registry de type Harbor, GCRIO ou autre.

Comme exemple, la commande ci-dessous avec en entrée un repository git et en sortie un lien vers une registry privée Harbor :

kp image create spring-music –tag harbor.cpod-velocity.az-fkd.cloud-garage.net/tanzu/spring-music:1 –git https://github.com/fbenrejdal/spring-music.git –git-revision master

TBS détecte automatiquement les buildpacks dont l’application a besoin pour construire et exécuter l’image.

L’option –git-revision master indique à TBS de surveiller les modifications de la version master et d’enclencher automatiquement une mise à jour de l’image container si une nouvelle version a été “commitée”. dans ce cas, seule la partie Application de l’image container est modifiée.

 

La solution TBS vient déjà avec un certain nombre de buildpack mais il est possible de construire ses propres buildpacks. La commande ci-dessous permet de visualiser les buildpacks déjà installés.

$ kp clusterstore status default
Status: Ready

BUILDPACKAGE ID VERSION HOMEPAGE
paketo-buildpacks/procfile 2.0.2 https://github.com/paketo-buildpacks/procfile
tanzu-buildpacks/dotnet-core 0.0.5
tanzu-buildpacks/go 1.0.6
tanzu-buildpacks/httpd 0.0.38
tanzu-buildpacks/java 3.8.0 https://github.com/pivotal-cf/tanzu-java
tanzu-buildpacks/java-native-image 3.6.0 https://github.com/pivotal-cf/tanzu-java-native-image
tanzu-buildpacks/nginx 0.0.46
tanzu-buildpacks/nodejs 1.2.1
tanzu-buildpacks/php 0.0.3

 

Pour résumer, Tanzu Build Service permet de réduire drastiquement le temps et les opérations de création ainsi que les mises à jour des images containers, le développeur n’a plus à se soucier à gérer des fichiers de configuration, il se focalise juste sur son code. TBS détecte tout seul en fonction du code source les dépendances dont il a besoin et est capable aussi de détecter les mises à jour qui ont été “commitées” pour générer une nouvelle image container. TBS découpe l’image container en couche : Stack, Buildpack et Application afin de pouvoir mettre à jour unitairement chaque partie.

Pour voir comment créer une image et la mettre à jour, j’ai créé deux courtes vidéos :

TBS creation d’une image container à partir de github

TBS détection automatique d’une mise à jour

Mes collègues spécialistes Alexandre et Guillaume ont animé un webinar en Français plus détaillé sur ce sujet :

Cloud Native Buildpack : La formule pour transformer vos applications en conteneurs avec Kubernetes

Webinar déployer Kubernetes à l’échelle sur tous les clouds

 

Mon collègue Erwan et moi-même avons animé un webinar en Français sur la gestion du cycle de vie des cluster Kubernetes.

Vous trouverez ci le lien : Vidéo gestion du cycle de vie des cluster Kubernetes

 Ci-dessous le découpage par thématique et par solution  :

    • De 0 à 23:00 Présentation générale des attentes autour de Kubernetes
    • De 23:00 à 34:35 Introduction à TKG (Tanzu Kubernetes Grid), runtime Kubernetes multi-cloud ainsi que la gestion de son cycle de vie
    • De 34:15 à 55:30 Démonstration (TKG)
    • De 55:30 à 1:03:35 Introduction à vSphere with Kubernetes (aka Projet Pacific), plate-forme pour fournir nativement des PODs Kubenetes et les services associés (réseaux, firewall, loadbalancer, stockage, …)
    • De 1:03:35 à 1:21:07 démonstration de vSphere with Kubernetes
    • De 1:21:07 à 1:26:01 Introduction à Tanzu Mission Control (TMC), solution de management unifiée de runtine kubernetes multi-cluster, multi-cloud et multi-vendors
    • De 1:26:01 à 1:36:00 Démonstration de TMC
    • De 1:36:00 à 1:42:06 Introduction et démonstration à Tanzu Service Mesh (TSM), solution de service réseau au niveau applicatif, multi-cluster, multi-cloud et multi-vendor
    • De 1:42:06 à 1:44:04 Présentation de Tanzu Observability (TO), solution de monitoring de l’infrastructure et des applications hébergées
    • De 1:44:04 à 1:50:37 Démonstration de TO
    • De 1:50:37 Conclusion

Une solution Kubernetes as a Service pour tous les Clouds

Kubernetes est l’orchestrateur de containers en vogue. Il est disponible sous différentes formes, à installer et à gérer soit même ou complètement géré par un tiers comme c’est le cas pour les solutions Google GKE, Microsoft AKS ou Amazon EKS.

Comme pour les anciennes applications qui étaient majoritairement monolithiques et difficile à faire évoluer, elles deviennent maintenant micro-services pour être plus agile dans leur cycle de vie. Les clusters Kubernetes “historiques” déjà en place ont une stratégie monolithique avec un gros cluster compliqué à déployer et à faire évoluer. De ce constat VMware a adopté une toute autre stratégie. Avoir une solution simple à déployer, simple à maintenir, simple à faire évoluer modulaire et ce sans être verrouillé à une plate-forme. De cette manière, il est possible d’avoir un cluster Kubernetes en 5 mn sur du OnPremise ou dans le cloud public. (Aujourd’hui sur vSphere et AWS, les autres plateformes telles qu’Azure ou GCP vont rapidement arriver).

Cette stratégie a été élaborée sous l’impulsion des équipes issues du rachat de la société Heptio en 2018. Heptio a été fondée par 2 des créateurs de Kubernetes et font toujours parti des effectifs de VMware. L’ADN d’Heptio était exclusivement basée sur Kubernetes, vendre du conseil, développer des outils open source, contribuer à des projets open source existants et dispenser gratuitement des formations en ligne. Cette ADN a été conservée et VMware est désormais le deuxième contributeur sur Kubernetes, juste derrière Google. Une partie de ces contributions figure ici : https://github.com/vmware-tanzu.

C’est avec cet esprit que la solution Tanzu Kubernetes Grid (TKG) est née, à base d’open source, elle est dotée du moteur Kubertenes upstream et du gestionnaire Cluster API pour gérer le cycle de vie. Les binaires sont vérifiés par VMware pour parer aux failles de sécurité et pour une meilleure stabilité afin d’être en mesure d’en assurer le support. Plutôt que d’avoir une grosse solution tout intégrée difficile à maintenir, TKG est modulaire, vous pouvez y ajouter les modules que vous voulez, qu’ils soient développés par un tiers ou ceux développés par VMware.

Modules intégrables non exhaustifs. (En gris projet où VMware était à l’origine ou est principal contributaire)

Le Life-cycle Manager Cluster API fait partie intégrante de TKG

En résumé, s’il y a une chose à retenir : TKG c’est du Kubernetes As a Service, modulaire et multi-cloud, basé sur des solutions Opensources upstream.

Bénéfice principal : Avoir une infrastructure de développement et d’hébergement de container aussi agile que les applications qui y vont être développées et hébergées !

 

je vais maintenant rentrer un peu dans la technique.


Comment TKG fonctionne ?

C’est vraiment très simple à installer et à utiliser et c’est assez bluffant.

A partir d’un point d’administration (Linux, Mac ou Windows) vous installez le binaire TKG CLI pour initialiser le cluster Kubernetes management de TKG, ça prend environ 10 minutes. Une fois initialiser, toujours via TKG CLI, vous créez des clusters Kubenetes TKG pour les worloads applicatifs, ça prend environ 5 minutes.

 

Ensuite, il est très simple de faire évoluer à chaud (à la baisse ou à la hausse) la taille des clusters kubernetes de workload, ça prend environ 2 minutes.

TKG intègre nativement la CSI (Container Storage Interface) pour pouvoir provisionner des PVC (Persistent Volume Claim) utiles aux PODs statefull. Ces volumes seront automatiquement fournis par l’infrastructure sur laquelle réside TKG.

 

J’ai testé TKG sur une palte-forme vSphere à partir de laquelle je fais des démonstrations à mes clients. J’ai mis ci-dessous les étapes à respecter.

Il faut télécharger à partir du site VMware, le binaire TKG CLI et deux images (OVA). L’une des images servira pour les serveurs Kubernetes (Control Plane et Workers) et l’autre pour le serveur de Load Balancer HA Proxy pour servir les Control Planes.

A partir d’un cluster vSphere 6.7U3 minimum, activez DRS, créez un Ressource Pool et un VM Folder, chargez les deux images OVA.

Une fois les deux OVA chargées, faire un snapshot (étape nécessaire pour pouvoir utiliser les Instant Clone) et les convertir en template.

C’est tout ce qu’il y a à faire coté vSphere.

A partir d’un point d’administration Windows, Linux ou Mac (Linux dans mon exemple), copier le binaire TKG CLI puis lancer la commande : tkg init –infrastructure=vsphere –ui et remplir les champs demandés comme dans l’exemple ci-dessous, cette étape peut aussi se faire en ligne de commande en configurant le fichier config.yaml à placer de préférence dans le répertoire $HOME/.tkg :

(Screenshots issues de la version beta que j’ai testée)

Choix de la plate-forme (vSphere et AWS pour la première version les autres suivront très vite)

 

Information de connexion à la plateforme

 

Type de plan de deploiement et localisation du cluster de management

 

CIDR du réseau Kubernetes et type d’OS pour les control plane et worker nodes

 

Récapitulatif des informations renseignées

 

Suivi du déploiement

 

Une fois le cluster de management déployé, vous pouvez créer des clusters de wokload via la commande ci-dessous :

$ tkg create cluster prod1 -p prod -w 5 (5 pour 5 workers)

En moins de 5mn vous avez un cluster à votre disposition, vous pouvez “scaler” à chaud en modifiant à la hausse ou à la baisse le nombre de control plane ou de worker via la commande ci-dessous :

$ tkg scale cluster prod1 -w 4 -c3 (-w pour les workers et -c pour le control plane)

TKG surveille les VMs Kubernetes, si une est amenée à s’arrêter, TKG va la redémarrer automatiquement.

Pour utiliser un cluster déployé, il faut utiliser la commande Kubernetes kubectl :

Lancer la commande sans changer de contexte :

$ kubectl <commande> –context <context-tkg>

Pour changer de context et lancer les commandes sans spécifier de contexte :

$ kubectl config get-contexts (pour connaitre le nom du contexte)

$ kubectl config use-context <context-tkg>

Pour effacer le cluster :

$ tkg delete cluster prod1

C’est vraiment très simple à utiliser.

 

Pour en savoir un peu plus, je vous invite à consulter les articles d’Alex et Mika, deux personnes avec qui j’ai plaisir à travailler quotidiennement :

Alex : https://hackmd.io/@ac09081979

Mika : https://myvmworld.fr/vmware-tanzu/

vSphere avec Kubernetes

VMware vSphere with Kubernetes connu sous le nom de projet Pacific a été annoncé à VMworld US 2019. Il fait partie des nombreuses nouvelles fonctionnalités de vSphere 7. Au moment de la rédaction de cet article il est encore en Beta mais j’ai eu l’occasion de l’installer à plusieurs reprises et de faire une dizaine démonstration internes et à des clients. Le retour des profils administrateur d’infrastructure et des profils de développeur sont positifs, la solution est bien accueillie et ils y trouvent une vraie valeur ajoutée dans leur métier respectif.

Le message de valeur mis en avant par VMware est la faculté à l’hyperviseur d’héberger nativement des pods kubernetes et des VMs proposant ainsi une plate-forme unique. Les hyperviseurs vSphere forment un cluster Kubernetes où ils jouent le rôle de worker node Kubernetes (serveurs qui exécutent les pods applicatif). Le control plane est quant à lui sous forme de VMs. Aucune compétence Kubernetes n’est requise pour l’administrateur vSphere, tout est intégré et configuré automatiquement. Pour avoir installé plusieurs fois Kubernetes, je peux vous dire qu’avoir une plate-forme prête à l’emploi est un vrai gain de temps au moment de l’installation et lors du maintien en condition opérationnel.

 

C’est vrai qu’héberger nativement des pods Kubernetes c’est une innovation unique mais personnellement, je me mettrai plutôt en avant la capacité de cette plate-forme à provisionner des cluster Kubernetes à la demande en une seule ligne de commande kubectl et ce directement par le développeur. Il pourra aussi bénéficier toujours via la commande kubectl des services de loadblancer, de volumes de stockage persistants, de réseau et des règles de sécurité et ce sans avoir à configurer quoique ce soit. D’autres fonctionnalité comme la création de VM ou de services applicatifs lui seront aussi offertes.

 

vSphere with Kubernetes peut être divisé en deux parties logiques, l’une pour la partie infrastructure et l’autre pour la partie développement (Namespace et Managed Cluster). La partie infrastructure est gérée par l’administrateur vSphere avec ses outils habituels et l’autre par le développeur ou encore par le DevOps avec ses APIs ou la commande habituelle kubectl.

 

 

 

 

L’administrateur vSphere créé des Namespace via son interface habituelle, il autorise quelles sont les personnes qui auront le droit de consommer ces Namespace, indique quelle classe de stockage à utiliser et si besoin, affecte des quotas aux ressources mémoire, CPU et stockage. Ca prend à tout casser 2 minutes. Une fois cette opération terminée, le Namespace est prêt à consommer. Le Namespace apparait automatiquement comme projet dans la registry privée Harbor ainsi que les utilisateurs associés.

Le développeur se connecte au Namespace et peut immédiatement y déployer des Pods Kubernetes.

kubectl vsphere login –server 10.40.14.33 -u devops@vsphere.local –insecure-skip-tls-verify

S’il le souhaite, il peut aussi y créer lui-même d’autres cluster Kubernetes via la commande Kubernetes kubectl apply, s’il veut par exemple une version de cluster différente :

$ cat CreateCluster-guest.yaml
apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
  name: l-oeil-du-se
  namespace: projets
spec:
  topology:
    controlPlane:
      count: 1
      class: guaranteed-xsmall
      storageClass: projectpacific-storage-policy
    workers:
      count: 2
      class: guaranteed-xsmall
      storageClass: projectpacific-storage-policy
  distribution:
    version: v1.16.8
  settings:
    network:
      cni:
        name: calico
      services:
        cidrBlocks: [“10.43.0.0/16”]
      pods:
        cidrBlocks: [“10.44.0.0/16”]

Ces clusters apparaissent aussi dans l’interface graphique de l’administrateur vSphere

 

Et aussi en ligne de commande

$ kubectl get TanzuKenertesCluster
NAME         CONTROL PLANE WORKER DISTRIBUTION                  AGE
l-oeil-du-se 1             2     v1.16.8+vmware.1-tkg.3.60d2ffd 5m

 

Le développeur peut faire évoluer la taille de son cluster en modifiant le nombre de master et/ou de worker directement en changeant la configuration de son cluster via la commande kubectl.

$ kubectl get TanzuKerbernetesCluster
NAME          CONTROL PLANE WORKER DISTRIBUTION                   AGE
l-oeil-du-se  1             3      v1.16.8+vmware.1-tkg.3.60d2ffd 109m

 

Les pods, les volumes persistants, les network policy et les services sont directement visible par l’interface vSphere :

 

En résumé, vSphere with Kubernetes (Projet Pacific) est une plate-forme permettant d’héberger nativement des pods (containers) kubernetes, des VMs et des clusters Kubernetes à la demande, offrant ainsi la possibilité de concilier les exigences de sécurité, de performance, de résilience et d’évolutivité souhaitée par l’administrateur de l’infrastructure et les exigences d’agilité, de rapidité et de simplicité souhaitée par le développeur. Cette plate-forme peut héberger une application complète même si elle est composée de VM et de containers. Les investissements en terme financier et de compétence sur la plate-forme vSphere sont ainsi pérennisés.

Les développeurs et les administrateurs continuent à utiliser leurs outils habituels avec lesquels ils sont à l’aise tout en travaillant sur une même plate-forme.

Cette plate-forme unique évolue en fonction des besoins en VM et en container. Les développeurs bénéficient de l’automatisation, de l’agilité et la souplesse qu’ils trouvent sur le cloud public et les administrateurs n’ont pas à gérer la complexité de gestion du cycle de vie inhérente à Kubernetes. C’est du Kubernetes as a Service intégrant les services de loadbalancing, de volumes persistants, de réseau et de sécurité.

Le Cloud Hybrid comble les inconvénients du Cloud Public

C’est un constat personnel que j’ai fait, dans certains secteurs d’activité notamment là où c’est économiquement très tendu comme dans la distribution ou l’industrie, il y a une plus grande appétence au cloud public. Ils ont mis en place une stratégie Cloud Public First ou Cloud Public Only. Quand je pose la question à mes interlocuteurs habituels quelle est la raison de cette stratégie, la réponse est souvent la même, ça vient d’en haut, de la direction informatique et/ou des finances. En effet un gros contrat signé avec l’un des trois acteurs du Cloud Public à savoir Amazon pour AWS, Microsoft pour Azure ou Google pour GCP, promettant de faire de grosses économies financières. Les opérationnels eux, ne sont pas consultés dans cette décision mais ont tout de même la charge de devoir mettre en place une campagne de migration massive pour suivre cette stratégie.  Pour la majorité de ces entreprises cette stratégie est récente, d’autres ont été précurseurs et cela permet d’avoir un peu de recul sur les bénéfices et les déficits qu’elle apporte :

  • L’aspect économique doit être scruté à la loupe car il y aura des mauvaises surprises, c’est sûr. Les éléments à prendre en compte :
    • Le gabarit des machines virtuelles. Un certain gabarit de machine virtuelle en ressource processeur et mémoire sera plus favorable au Cloud Public. Ce gabarit permet à l’hébergeur de faire fonctionner un nombre optimal de machine virtuelle sur un hôte physique et donc mieux amortir le coût de la machine physique. Alors que d’autres gabarits seront plus favorables au cloud privé. Il faut bien vérifier le coût du gabarit à migrer avant de faire le transfert.
    • La saisonnalité. Si votre application a des saisonnalités comme par exemple en période de solde, elles vont nécessiter des ressources physiques à la hausse durant cette période puis à la baisse une fois cette période terminée. L’élasticité native présente dans le Cloud Public évite des investissements en matériel et en logiciel d’infrastructure pour une utilisation périodique faible.
    • La périodicité. Si des environnements peuvent fonctionner sur une plage horaire partielle comme par exemple, la journée ou la nuit, ils permettent de payer l’infrastructure uniquement durant ces périodes d’utilisation et non pas tout le temps comme ça serait le cas sur un environnement On-Premise.
    • Les flux réseau. Les flux entrants vers le cloud public sont gratuits par contre les flux sortants sont dans la plupart des cas facturés, c’est un élément à prendre en compte si vous avez des échanges inter application ou si vous devez faire des exports de model de données volumineux.
    • Les services additionnels. Certains services comme une adresse IP publique ou encore des load balancer peuvent être commander (donc payés) à la demande puis associés à des VMs. Lorsque que la VM est détruite, les services associés ne sont pas “décommissionés” pour autant et continueront à être facturés.
    • Pour éviter les surprises il faut se doter d’un outil (eg : CloudHealth) qui vous donnera une visibilité pertinente de la consommation à l’instar d’un tableau de bord d’un d’avion. Il proposera ainsi des économies en identifiant les ressources mal, peu ou pas utilisées.
  • L’aspect services à valeur ajoutée comme l’intelligence artificielle ou le machine learning apportent un bénéfice indéniable car ce genre de service est difficile à obtenir On-Premise.
  • L’aspect agilité est là aussi un point fort au cloud public, avoir des ressources à la demande et les libérer quand on en a plus besoin.
  • L’aspect couverture géographique international est intéressant mais ne pourra pas se faire avec un hébergeur unique car pour des raisons réglementaires et/ou politiques, les trois acteurs principaux ne sont pas présents dans certains pays comme en Russie.

Il y a plusieurs possibilités pour aller dans le cloud public, il faut soit développer ses applications directement dessus, soit avoir une application basée sur des containers pour les transférer sans les retoucher, mais pour les autres qui sont la grande majorité des cas, il faudra les transformer. En effet il y a une forte chance que le format des VMs qui hébergent les applications dans vos Data Center On-Premise soit différent de celui des VMs du cloud public, il faudra donc les transformer. Il existe des outils pour les transformer mais ils fonctionnent correctement que si ce sont des applications simples.

Une fois que vous êtes dans le cloud public, êtes-vous sûr d’y rester ? Que faire si les coûts d’hébergement augmentent ou si les éditeurs des applications changent leur mode de tarification lorsqu’elles sont hébergées sur le Cloud Public ? Que faire si l’hébergeur devient un concurrent dans votre secteur d’activité, si les performances, le niveau de service ou les services ne sont pas au rendez-vous ? Comment faire des retours arrière, car cela nécessiterait une deuxième transformation pour revenir sur l’On-Premise et voire une troisième si c’est pour aller ensuite vers un autre hébergeur ?

La transformation n’est pas si simple, elle comporte des indisponibilités de service, des risques techniques et financiers et est très chronophage. Le coût de cette transformation et l’évaluation des risques associés ne sont pas pris en compte dans le coût de cette stratégie.

Alors comment éviter une telle transformation et pouvoir être libre de changer d’hébergeur tout en respectant la stratégie de son entreprise exigeant d’aller vers le Cloud Public ?

Il existe une solution moins radicale et plus agile, si vos applications sont hébergées sur l’hyperviseur vSphere ce qui doit représenter environs plus de 80% des cas, vous pouvez commander directement un SDDC VMware (Software Defined Data Center : Data Center virtualisé) chez l’hébergeur de votre choix, Atos, AWS, Azure, GCP, Oracle, OVH et bien d’autres avec pas loin de 4500 partenaires (VMware Cloud Verified Partner). Cela se fait en général directement à partir de la Market Place de l’hébergeur (Exemple : Azure VMware Solutions), ou directement chez VMware dans le cas d’AWS seulement (VMware Cloud On AWS) Ce processus prend environs 2 heures et vous avez ensuite un environnement complet serveur, stockage, réseau et sécurité qui vous ait dédié. Cet environnement est aussi basé sur l’hyperviseur vSphere, ce qui permet d’exécuter vos applications sans avoir à les transformer. La virtualisation du réseau permet de reproduire la topologie de votre réseau actuel sans avoir à modifier les adresses IP des serveurs et des applications. Vos applications s’exécutent ainsi comme chez vous mais dans le Data Center d’un Cloud Public à proximité des services natifs de l’hébergeur, comme montré dans le schéma qui suit, exemple sur AWS :

Vous avez ainsi le meilleur des deux mondes. Vos applications consomment des services natifs via les APIs et si vous souhaitez changer d’hébergeur, vous déplacez votre application vers le nouvel hébergeur et modifiez uniquement les appels API à ces services natifs. Et même cette partie peut être éviter en utilisant un “Wrapper” qui sera adresser les spécificités des APIs de chaque fournisseur. Il n’est donc pas nécessaire de transformer l’application complète. 

Maintenant que vous avez un SDDC chez un cloud public, comment déplacer simplement ses applications ?

Il est possible d’utiliser la méthode classique, c’est à dire faire un vMotion entre les deux environnements comme il est possible de le faire On-Premise depuis plusieurs années, ce qui fut une des forces de l’hyperviseur vSphere, ou utiliser l’outil de migration HCX qui permet de faire des migrations à chaud ou à froid, en masse, planifiable tout en bénéficiant d’une optimisation réseau pour que les migrations durent moins longtemps.

Le Cloud Public offre beaucoup de services innovants qu’il ne faut pas hésiter à utiliser. Par contre, il ne faut pas vous “verrouiller” avec un acteur, il faut que vos applications soient mobiles. La meilleure approche pour cela est de minimiser au maximum les dépendances. Cela passe par la modification partielle du code de l’application, en modifiant uniquement l’appel aux services natifs (ou passer par un “wrapper” d’API) et de garder son hébergement sur un format de VM qui garantira sa mobilité. Il n’y aura pas de “verrouillage” commercial avec VMware car les SDDC se contractualisent directement avec les fournisseurs des Cloud Public, sauf pour AWS où vous avez le choix de contractualiser avec VMware ou AWS.

Des containers physiques ou virtuels ?

Se poser la question d’exécuter des containers directement sur des serveurs physiques dit “Bare Metal” versus sur des serveurs virtuels dit des VMs est légitime, surtout lorsqu’on utilise un orchestrateur de container comme Kubernetes. Pour chaque nouvelle architecture applicative on me pose la question : est-il nécessaire de mettre en place une architecture virtuelle pour ces types d’application ou pour d’autres : SAP HANA, HADOOP, MONGO DB, CASSANDRA, …. et donc aussi Kubernetes ? L’élément déclencheur de cette réflexion est de vouloir faire l’économie du coût de l’hyperviseur. Mais ce dernier à beaucoup d’avantages opérationnel, sécuritaire, d’extensibilité et de souplesse.  Si vous êtes déjà convaincu par la nécessité de s’appuyer sur une architecture de virtualisation et vous pensez partir sur un hyperviseur dit gratuit, je vous invite à lire cet article : “C’est gratuit ! ?”.

Les portes containers vont s’exécuter sur un porte containers. Un porte container est un système d’exploitation en général Linux sur lequel vont s’exécuter les container. Sur du Bare Metal, on va maximiser le nombre d’exécution de containers alors que dans une VM on va à l’inverse plutôt minimiser le nombre d’exécution de containers voire 1 container par VM. Pour que ce soit efficace ou pertinent, il ne faut pas partir sur des VMs classiques mais sur des micros VMs sur lesquels est installé un systèmes d’exploitation épuré de services inutiles, durci (sécurité renforcée) et optimisé pour les containers de sortes à ce qu’ils consomment très peu de ressources et démarrent en quelques millisecondes.

Tout système d’exploitation a ses contraintes, ses limites et ses faiblesses :

  • Sur un système d’exploitation, le nombre de container est limité (Exemple pour Kubernetes : https://kubernetes.io/docs/setup/best-practices/cluster-large/), la règle est la même pour un porte container basé sur une machine virtuelle. Par contre, un serveur de virtualisation hébergera plusieurs VMs soit autant de porte container à hauteur des ressources physiques disponibles soit : Max Container par OS x Nombre de VM porte containers par serveur de virtualisation.
  • En Bare Metal, le porte containers est en contact directe avec le matériel. Les composants physiques du serveur doivent être compatibles avec le système d’exploitation et ses drivers. La virtualisation elle, fait abstraction et le porte container n’a plus à se soucier de la compatibilité du matériel et des drivers associés, vous pouvez changer de fournisseurs de serveurs et des composants.
  • Le système d’exploitation du porte container doit être maintenu à jour et les opérations de maintenance auront un impact sur tous les containers qui y sont hébergés. Avec une approche VM, l’impact sera limité car comme expliqué juste avant, on privilégie peu de container par VM porte container voire même 1 container par VM.
  • Le porte container est dédié à un usage : dev, prod, pré-prod, …, donc si toutes les ressources ne sont pas utilisées pour cet usage, il y aura beaucoup de perte (€€€). Avec la virtualisation, les serveurs physiques peuvent héberger des VMs porte containers de différents usages et la consommation des ressources sont ainsi optimales.
  • En Bare Metal, le porte container exécutera un seul système d’exploitation. Avec une infrastructure virtualisée, un serveur physique peut héberger des porte containers, Windows et différents types de Linux.
  • Les solutions d’orchestration comme Kubernetes orchestre des containers mais pas le provisionnement de porte containers. L’orchestrateur utilise les ressources physiques qu’il a à sa disposition à un instant T et s’il en manque, il faut rajouter un serveur, mais ce n’est pas lui qui va le faire, il va s’appuyer sur un IaaS (Infrastructure As A Service). En environnement virtualisé le déploiement de porte containers consiste au déploiement de VMs. Les IaaS basés sur des VMs sont beaucoup plus commun que ceux basés sur des serveurs physiques.
  • Quid des performances ? Et bien là aussi un bon hyperviseur permet de gagner en performance, vSphere tire mieux parti des architecture NUMA que les systèmes d’exploitation du marché et permet ainsi d’avoir un gain de performance. Un test comparatif a été effectué par VMware sur des applications Web : https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/docker-vsphere65-weathervane-perf.pdf
  • L’isolation des containers entres eux, même si elle fonctionne correctement, elle peut avoir un gros impact sur tous les containers en cas de faille de sécurité. La virtualisation offre en plus, une isolation inter VMs donc inter porte containers beaucoup plus robuste et plus vous limitez le nombre de containers par VM plus la sécurité sera renforcée.
  • Ne vous inquiétez pas sur la consommation des ressources par un porte container VM. Si un OS classique consomme des ressources et met du temps à démarrer, un OS optimisés pour l’hébergement des containers (Micro OS comme Photon OS), consomment peut de ressources et démarre en quelques millisecondes. De plus un bon hyperviseur à des optimisations de consommation de ressources lorsque des OS identiques sont exécutés en même temps.
  • Un container doit pouvoir démarrer sur n’importe quel porte container d’un cluster (regroupement des ressources de plusieurs serveurs), s’il a besoin de persistance des données, il doit pouvoir y a accéder depuis n’importe où et pour cela, il faut un système de fichiers partagé en général un export NFS externe qu’il faut maintenir. La virtualisation propose un système de fichier partagé natif qui est complètement intégré. Sur vSphere ce système de fichiers peut s’appuyer sur pratiquement n’importe quelle baie de stockage du marché. L’utilisation de la solution hyper convergée vSAN offre néanmoins beaucoup plus d’avantages qui sont détaillés dans cet article : Pourquoi vSAN (HCI : Hyper Convergence Infrastructure)

J’ai apporté une liste non exhaustive des avantages à utiliser la virtualisation pour des containers, si vous avez encore des doutes, je vous invite à vérifier sur quel type d’architecture s’exécute les offres de containers as a service proposées par les grands acteurs du Cloud Publics. D’ailleurs RedHat et VMware ont annoncé lors du Red Hat Summit de mai 2019 une architecture de référence pour la solution Red Hat OpenShift basée sur le SDDC VMware : https://octo.vmware.com/vmware-red-hat-bring-red-hat-openshift-vmware-sddc/.

Les offres autour de Kubernetes ne cessent d’évoluer, VMware vient d’annoncer à VMworld 2019 le Projet Pacific, une nouvelle évolution de l’hyperviseur vSphere qui intégra nativement l’orchestrateur Kubernetes et les portes containers, ca fera l’objet d’un nouvel article 🤔😉.

VeloCloud, le SD-WAN par VMware

Souvent les sites distants sont “délaissés” par rapport au Data Center principal et pourtant ils sont bien souvent nombreux et ont une part prépondérante dans l’activité des entreprises, Ils sont la partie “production” : Aéroports, agence, magasins, laboratoires, usines, entrepôts, hôtels, … Ils ont besoins d’accéder à des applications et des données hébergées en central et/ou sur des cloud publics, cela nécessite donc d’avoir un réseau de communication fiable, résiliant, performant ainsi qu’une administration simple et centralisée.

Le Software Defined WAN (SD-WAN) permet au-dessus d’un réseau physique existant, de créer un réseau WAN virtuel à l’instar d’un vrai Software Defined Network (SDN). La solution VeloCloud (acquise par VMware en 2017), agrège les capacités de plusieurs liens réseaux de différentes technologies (Internet, ADSL, MPLS, …) pour les utiliser comme un seul lien et ainsi gagner en performance et en résilience. Ils sont “monitorés” en temps réels et de manière continue (Bande Passante, Latence, Jitter , paquets perdus, …) cela permet ainsi à une application de bénéficier à tout moment du ou des meilleurs liens en fonction de sa criticité .

Les sites distants peuvent bénéficier de nouveaux services auxquels ils n’avaient pas droit auparavant comme des vidéos pour des conférences, des formations, des voeux de fin d’année ou tout autre message d’entreprise.

Il est possible de prioriser certains flux par rapport à d’autres de façon à garantir une qualité de service. il est même possible de spécifier quelles applications ont droit d’utiliser plusieurs liens réseaux et celles qui ont le droit d’en utiliser qu’un. Tout se fait par application de politique de niveau de service définies en central.

Concernant les applications en mode SaaS ou hébergées chez des Cloud Public, les sites distants peuvent y accéder directement sans avoir à repasser par un site central. Cela se fait grâce à des gateway hébergées directement dans les data center où sont installées ces applications, comme le montre l’exemple ci-dessous où il est possible de télécharger les gateway pour AWS et Azure via leur marketplace.

 

Les performances sont ainsi optimales sans compromettre la sécurité car les règles de sécurité restent gérées en centrale par l’administrateur.

 

Vous avez même la possibilité de la renforcer en la couplant avec le partenaire avec qui vous avez l’habitude de travailler : https://www.velocloud.com/partners

 

 

Concernant les déploiements, ils sont de type Zero Touch, que l’on opte pour des boitiers physiques ou virtuels, la configuration se fait par application automatique de profils. Il n’est plus nécessaire d’envoyer des compétences pointues sur chaque site, les déploiements sont ainsi beaucoup plus rapides et beaucoup moins couteux.

 

 

En résumé

  • Utilisation de plusieurs types de liens réseau pour augmenter la bande passante et la résilience
  • Accès aux applications Cloud optimisé sans repasser par le site central
  • Réduction du temps de déploiement avec le zéro touch et par application de profile, pas besoin d’envoyer de compétences pointues
  • Visibilité sur la performance des applications et sur les défaillances des liens réseau
  • Application de politique en fonction du niveau de service attendu, exemple : Bronze 1 seule ligne utilisée, gold 2 lignes utilisées
  • Segmentation des flux réseaux par type d’application et application de priorités

Une histoire virtuelle sur la transformation digitale

Pour changer, j’ai écrit cet article sous la forme d’un petit “roman photo” qui explique comment une chaine de pizzeria est confrontée à la digitalisation de son métier. En roles principaux, il y a : le client, le boss, ceux qui réfléchissent à une solution, ceux qui trouvent la solution, le responsable informatique, le responsable de sécurité, le développeur et l’avant-vente VMware. Je tiens à remercier mes collègues qui se sont prêtés au jeu en posant ou en prenant les photos.

L’IOT a besoin d’une infrastructure et elle existe !

Les objets sont de plus en plus présents dans les entreprises et sous diverses formes (Caméra, capteur de température, ventilateur, ….). Ces objets génèrent énormément de données qui sont traitées par une ou plusieurs applications. Prenons un exemple simple de parking, avant d’y rentrer vous pouvez savoir le nombre de places de stationnement disponibles, puis une fois rentré le nombre de places par étage et enfin par rangée, ceci grâce à des capteurs qui sont généralement fixés au plafond à quelques dizaines de centimètres au-dessus des voitures. Dans ce même parking vous avez des caméras un peu partout pour enregistrer les mouvements des personnes, vous avez des capteurs pour mesurer le taux de monoxyde de carbone et enclencher des extracteurs pour évacuer ces particules. Tous ces objets vont générer des données et Il y aura une application provenant de différents constructeurs et par activité pour les traiter, une application pour les places de parking, une pour les caméras et une pour la détection des particules. Par contre comment gérer ces objets ? Comment connaitre leur santé, mettre à jour leur firmware ? Pour cela, il est pertinent d’avoir une infrastructure commune hétérogène.

La solution VMware IOT Pulse Center permet à l’IOT d’avoir à la fois son infrastructure basée sur le SDDC VMware et aussi de gérer le cycle de vie des objets comme le fait VMware Workspace One avec les périphériques utilisateur. 

Cependant il y a un élément nouveau dans l’IOT par rapport à une infrastructure classique, c’est la gateway, comme les objets sont nombreux et utilisent souvent un protocole et une connectique qui leurs sont propres, ils passent par cette gateway qui servira de concentrateur et permettra la communication avec les applications via le réseau classique IP.

 

En 2016 VMware a développé l’agent LIOTA (Little Internet Of Things Agent) qui est un SDK Open source installé sur ces gateway permettant la communication avec les objets et ainsi de les gérer, de les monitorer et d’orchestrer les données en provenance et allant vers le Data Center et/ou Cloud Public. LIOTA découple aussi l’application du type/marque/model d’objet, l’application communique ainsi via LIOTA qui lui retranscrira aux objets en fonction de leurs spécificités.

 

Pour les grosses architectures ou les solutions nécessitant des prises de décisions rapides, un élément intermédiaire sera ajouté entre la gateway et l’application qui va permettre de faire des pré/post traitements et être ainsi plus réactif, ces traitements sont hébergés et exécutés sur du Edge Computing. Le Edge Computing est au bout de la chaine au plus près des gateways et objets. Sur ces Edge Computing est installé le SDDC de VMware.

 

 

Les objets sont enregistrés dans Pulse IOT Center, ce qui permet de connaitre leur états de santé, de les sécuriser en sécurisant les mot de passe (bien souvent les mots de passe par défaut ne sont pas remplacés) et de gérer les cycles de vie des firmwares. Pulse IOT Center permet aussi de classifier les objets de manière à avoir des vues pertinentes et prendre les bonnes décisions rapidement.

 

Les objets ont désormais leur Infrastructure basée sur des solutions existantes et éprouvées depuis de nombreuses années. Cette infrastructure permet de s’affranchir de l’hétérogénéité et la massification induite par ce type de technologie. Les opérationnels ont avec le SDDC de VMware un case d’usage supplémentaire.

Consommer les solutions VMware as a Service via un partenaire Service Provider

Le programme VCPP (VMware Cloud Provider Program) permet aux clients finaux de consommer les solutions VMware comme un service (VMware as a Service) avec une couverture locale ou géographiquement répartie à travers le monde. Il existe environs 4 600 partenaires Service Provider VMware dans le monde qui offrent ces possibilités dont plusieurs centaines en france.  Les services proposés vont de la mise à disposition d’infrastructure nue (Bare Metal) jusqu’à une infrastructure complètement opérée, simplifiant ainsi au maximum leurs usages. La liste complète ainsi que les services proposés sont disponibles via ce lien :https://cloud.vmware.com/providers/search-result.

Ce qui caractérise tous ces partenaires, c’est qu’ils utilisent au moins une technologie VMware, pour la majorité d’entres-eux ils utilisent au minimum l’hyperviseur vSphere, ce qui rassure les clients finaux car c’est une technologie pérenne, largement répandue, fiable et performante leur permettant ainsi d’accroitre leur business.

Les raisons pour lesquels les clients finaux trouvent un(des) intérêt(s) à consommer ces services ?

  • Diminuer les frais d’infrastructures. Pour certains clients, consommer ces services peuvent coûter moins chers s’ils n’ont pas les outils leur permettant d’optimiser l’utilisation des ressources physiques On Premise, n’ont pas la taille critique pour un contexte spécifique ou encore n’ont pas de temps à passer sur des problèmes de sécurité (comme par exemple) le hacking permanent de site web.
  • N’ont pas et ne souhaitent pas acquérir les compétences pour gérer une infrastructure.
  • Ont besoin d’une agilité qu’ils n’ont pas On Premise et ainsi gagner du temps pour développer et déployer les applications.
  • Ne veulent plus gérer le cycle de vie matériel et logiciel, s’affranchir ainsi des mises à jour et des matrices inter-solutions de plus en plus complexe.
  • Avoir des ressources informatiques à travers le monde sans avoir à investir dans des data center.
  • Intégrer plus facilement les nouvelles filiales.
  • Respecter les SLAs et les normes comme par exemple HADS pour la santé, ISO 27000 pour la confidentialité des données ou encore la gestion d’archivage des données publique, SIAF et bien d’autres.
  • Avoir un “réceptacle” pour les sauvegardes et/ou une possibilité de relancer les applications en cas de désastre.
  • Proposer des postes de travail virtuels comme une commodité, accessibles depuis n’importe où pour les populations à risque ou ultra nomade.
  • D’être une extension du Data Center On Premise en permettant un “débordement” sur le cloud public.
  • D’héberger des applications nécessitant de gros serveurs puissants pour les BDD type SAP HANA ou au contraire nécessitant beaucoup de petit serveur pour des cluster Hadoop.
  • De bénéficier de gros tuyaux vers Internet, les applications orientées consommateurs externes seront ainsi au plus proche d’Internet.
  • Avoir un hébergement sécurisé par des services provider dont c’est le métier.
  • Une consommation à l’usage et donc la capacité à changer de type de service ou de volumétrie simplement, réduire les risques projets lié à des volatilités ou non prédictibilité suffisante.

Sur quels critères les clients finaux choisissent leur(s) partenaire(s) VCPP ?

  • Présence locale, régionale et/ou international, un client peut vouloir rechercher de la proximité et choisir un partenaire de sa région, un autre peut vouloir choisir un partenaire ayant une couverture internationale pour par exemple une extension au Brésil, en Chine, en Afrique du sud. Il sera peut-être amené à devoir choisir plusieurs partenaires si un seul n’est pas en mesure de tout couvrir.
  • La possibilité de personnaliser des configurations matériels et/ou de machines virtuelles c’est le  “sur mesure”.
  • Qualité de l’interconnexion entres les plaques géographiques.
  • Standardisation, avoir les mêmes hyperviseurs, les mêmes réseaux, les mêmes outils d’opération….
  • Bien sur le prix, les niveaux de services attendus ainsi que les services proposés

Types d’usages généralement proposés :

  • Bare Metal as a Service : les serveurs physiques sont installés, configurés et maintenus automatiquement par le partenaire.
  • vSphere as a Service / vCenter as a service : Les serveurs physique, vSphere et le vCenter sont installés et configurés automatiquement et maintenus par le partenaire. Le client a accès au vCenter et l’utilise comme habituellement.
  • VM as a Service : Le client dispose d’un portail pour créer des VMs sur une infrastructure déjà opérationnel, elle est en générale mutualisée et partagée par plusieurs clients.
  • SDDC as a Service, tous le composants du SDDC VMware (vSphere, vSAN, NSX et vCenter) sont installés automatiquement.
  • Les postes de travail virtuels.
  • Des Service applicatif.
  • Mise à disposition d’un cloud privé, portail de self service avec un parfaite maîtrise des services , de la sécurité et des coûts.
  • Service avec validation de certification ou contexte (HADS, PCI-DSS, SIAF …).

Il existe donc une multitude de raisons pour travailler avec un partenaire VMware fournisseur de services mais la principale réside sur l’utilisation d’une ou plusieurs solution VMware gage de sécurité, de fiabilité et simplicité .

 

Pourquoi gérer ses nouveaux postes de travail avec des outils anciens ?

Avec le bon outil d’administration il est possible de gérer une flotte de smartphone hétérogène d’environs 15 000 périphériques pour 1 administrateur alors qu’il faut 1 administrateur pour environs 250 postes de travail avec un OS homogène. On peut donc se poser la question, pourquoi continuer à gérer les postes de travail avec des outils anciens, d’autant plus que les OS modernes tels que Windows 10, MacOs et Chrome OS permettent d’être gérés comme des smartphones ?

 

Pourquoi la gestion des postes de travail est importante dans une entreprise :

  • Pour limiter les risques liés à la sécurité informatique : Les postes de travail doivent toujours être au bon niveau de patch souhaité et conforme aux règles définies dans l’entreprise. Le service informatique doit avoir une visibilité précise de son parc de poste de travail et ainsi identifier rapidement ceux qui sont à risque ou qui vont le devenir et ceci sans être obligatoirement sur le réseau d’entreprise.
  • Pour une productivité optimale : L’utilisateur doit pouvoir utiliser le périphérique et le système d’exploitation avec lequel il est le plus à l’aise et doit pouvoir travailler depuis n’importe quel endroit où son métier le lui permet.

 

Quel constat peut-on faire avec la gestion ancienne des postes de travail (et même actuelle pour certains) ?

  • Coté administration :
    • Il y a plusieurs images masters à gérer en fonction du poste physique et du profil de l’utilisateur. 
    • Les politiques de sécurité ne peuvent être poussées que si le poste de travail est connecté au réseau d’entreprise (directement ou via VPN).
    • Pas de visibilité fiable des postes qui ne sont pas souvent connectés au réseau d’entreprise.
    • Pas de gestion hétérogène des postes de travail (matériel et système d’exploitation).
    • Première configuration et gestion du cycle de vie très fastidieuses.

 

  • Coté utilisation :
    • Choix de matériel et de système d’exploitation très restreint, généralement une marque et un seul système d’exploitation.
    • Les postes de travail sont verrouillés avec des droits limités, Ils sont difficilement personnalisables.
    • Connexion au réseau d’entreprise régulièrement requise pour mettre en conformité son poste de travail et/ou installer des applications.
    • Expérience utilisateur différente suivant le périphérique (ordinateur, smartphone, tablette).

 

Quels sont les bénéfices constatés à avoir une gestion moderne de ses postes de travail avec VMware Workspace One ?

  • Des postes de travail toujours sécurisés et conformes aux exigences de l’entreprise.
  • Un seul administrateur gérera énormément plus de postes de travail qu’auparavant.
  • Un choix de matériel plus large pour l’utilisateur, une exploitation hétérogène simplifiée pour l’administrateur et pour les entreprises une plus ample marge de négociation avec les fournisseurs en faisant entrer d’autres acteurs tels que Google Chrome OS et Apple MacOS.
  • Une solution permettant de gérer à la fois les postes de travail ainsi que les smartphones et tablettes.
  • Un enrôlement “Out Of the Box” des nouveaux postes de travail, l’utilisateur reçoit son ordinateur, entre son adresse email d’entreprise et le poste de travail se configure automatiquement comme c’est le cas pour un smartphone.
  • Un déploiement d’applications, une activation de règles de sécurité et de chiffrement par affection de profil(s).
  • Un focus sur l’utilisateur et non plus sur le poste de travail.
  • Une meilleure productivité en pouvant travailler depuis n’importe quel endroit, la connexion au réseau d’entreprise pour assurer la conformité n’est plus requise.
  • Une expérience utilisateur identique quel que soit le système d’exploitation et le périphérique utilisé grâce à une authentification et un catalogue d’applications communs.

 

 

 

 

 

Pourquoi choisirais-je vIDM (alors que j’ai déjà un Identity Manager) ? 🤔

L’objectif d’un IDM (Identity Manager) est :

  • D’un point de vu consommateur/utilisateur : Simplifier le process d’authentification de sorte à ce qu’il n’ait qu’un seul identifiant et mot de passe à retenir et à gérer mais permettant la connexion à différentes applications et services et ce quel que soit le moyen d’accès et le type d’hébergement.
  • D’un point de vu fournisseur/administrateur : Renforcer la sécurité et la conformité d’accès aux applications/services par la mise en place de politique de gestions d’identification multicritères indépendamment des périphériques, des moyens d’accès et des applications/services.

Attention à ne pas confondre un annuaire et un Identity Manager, en général dans chaque entreprise il existe déjà un annuaire type Active Directory ou LDAP où sont créés les comptes des utilisateurs. L’identity Manager va synchroniser les utilisateurs (sans les mots de passe) issus de cet annuaire et l’IDM validera les mots de passe auprès de l’annuaire.

Les utilisateurs ne possédant pas d’IDM trouvent toujours des moyens pour retenir leurs identifiants issus des différentes applications auxquelles ils ont accès, mais ces moyens ne sont pas très sécurisés et/ou pas simple à gérer :

    • Ecrire ses identifiants sur un papier ou dans un fichier.
  • Utiliser le même mot de passe ou la même racine. Attention cependant, le cycle de vie du changement de mot de passe peut-être différent pour les différentes applications et il y se peut que votre identifiant soit différent par application.
  • Sauvegarder ses identifiants/mot de passe dans le navigateur. Cela ne concerne que les applications accessibles en mode Web et nécessite un navigateur multi-périphériques (oubliez Safari sur Android et sous Windows) et avoir un compte chez l’éditeur du navigateur pour les synchroniser.
  • Utiliser un outil de type coffre-fort à installer. Il faut qu’il soit multi-périphériques, que les identifiants/mot de passe soient synchronisés sur tous les périphériques que vous pensez utiliser dans le futur. Ca ne vous prémunie pas d’avoir à changer vos mots de passes quand l’application vous le demandera et d’avoir à respecter sa complexité (nombre de caractère, type de caractère à inclure, ne pas réutiliser x versions antérieurs, …)

vIDM en plus d’un IDM classique renforce la sécurité en permettant des accès conditionnels, Il est par exemple possible de demander uniquement le mot de passe si l’utilisateur est connecté via le réseau d’entreprise et de demander une authentification tierce comme un code RSA si l’utilisateur est connecté via un autre réseau : wifi publique, 4G, …

Il est possible aussi d’accepter l’authentification si le périphérique est conforme aux règles définies comme par exemple, version d’OS, niveau de patch ou bien encore si le périphérique n’est pas “jailbreaké”. Cette vérification de condition peut se faire pour toutes les applications ou par application en fonction de sa criticité.

vIDM couplé à Workspace One donne à l’utilisateur une fois authentifié accès à un catalogue d’applications locales (pour certains systèmes d’exploitation et smartphone), SaaS ou Web. Si l’utilisateur le souhaite, Il peut aussi se connecter directement à l’application sans passer par le catalogue et celle-ci redirigera l’utilisateur vers vIDM pour qu’il s’authentifie.

vIDM propose aussi la possibilité d’utiliser d’autres méthodes d’authentifications en fonction du périphérique comme par exemple l’utilisation d’un lecteur d’empreinte digitale.

Pour résumer, vIDM simplifie l’authentification des utilisateurs quel que soit le périphérique, accroit la sécurité liée à l’authentification, assure la conformité de gestion des mots de passes.

Kubernetes en mode SaaS ?

Comme je le disais dans l’article sur la transformation digitale (http://loeilduse.fr/?p=295), la nouvelle monnaie c’est la rapidité.

Alors comment développer et déployer des Cloud Native Apps rapidement tout en bénéficiant d’un support éditeur de type entreprise sur lequel on peut s’appuyer ? 

VMware propose (pour le moment) deux offres qui intègrent l’orchestrateur de containers Kubernetes. L’une est OnPremise et l’autre en mode SaaS hébergée chez AWS. Les deux solutions ont en commun, le support de VMware et utilisent le Kubernetes issue du CNCF (Cloud Native Computing Foundation https://www.cncf.io) et vous assure que vos développements seront pérennes même si vous les faites fonctionner avec une autre solution Kubernetes compatible CNCF.

La première solution, PKS (VMware Pivotal Containers as a Service : http://loeilduse.fr/?p=158) est une solution généralement installée sur un environnement vSphere même si elle peut aussi s’installer sur environnement GCP ou AWS. Bien qu’elle soit simple à installer et à maintenir, il faut malgré tout le faire.

La dernière née est VKE (pour VMware Kubernetes Engine) VMware Cloud PKS , elle est accessible en mode SaaS et hébergée chez AWS (sera portée sur Azure par la suite). Elle s’adresse aux clients qui ne souhaitent pas avoir à gérer l’installation et le maintien en condition opérationnelle de l’environnement Kubernetes. L’environnement est immédiatement disponible et évolutif à la demande. Là où on aura un gain avec VMware Cloud PKS par rapport à PKS OnPremise ou toute offre OnPremise, c’est la possibilité de créer un cluster Kubernetes en moins de 90 secondes et de l’utiliser immédiatement. Intéressant lorsque l’on veut démarrer un projet rapidement ou que l’on a besoin d’un usage éphémère.

Lors de la création d’un cluster “Smart Cluster” vous avez le choix entre un type Développement et un type Production.

Pour le type Production chaque Smart Cluster bénéficie de son réseau virtuel isolé et dédié, d’une connexion avec les VPC AWS externe et une répartition des Master Kubernetes sur les 3 “Avaibility Zone” d’AWS pour assurer la haute disponibilité.

En plus d’assurer la disponibilité, les Smart Cluster s’occupent aussi de l’élasticité en ajoutant/retirant automatiquement des Worker Nodes en fonction de la charge et des ressources disponibles.

Chaque Smart Cluster bénéficie d’un Ingress Controler et d’un Load Balancer.

Ils bénéficient aussi de volumes de stockage afin d’assurer la persistance des données générées par les applications

VMware Cloud PKS offre un Role-Based Access (RBAC) permettant d’attribuer des permissions et facilite l’organisation des applications développées.

Le paiement du service est à l’usage et peut être interrompu à tout moment.

La Fondation Digitale pour la Transformation Digitale

De nos jours, la nouvelle monnaie c’est la rapidité.

Dans tous les secteurs d’activités les entreprises subissent une nouvelle concurrence venue de la digitalisation, ces entreprises l’ont bien compris mais malheureusement bien souvent trop tard, rares sont celles qui l’ont anticipée, elles sont réactives. Il existe de multitude d’exemples comme Uber avec les taxis et Airbnb avec l’hôtellerie. Ce qui caractérise cette concurrence, c’est l’apport ou l’amélioration d’un service par un nouvel acteur sur un secteur d’activité dominé par des acteurs historiques et qui n’ont pas sus/voulus évolués.

Ces nouveaux services nécessitent d’adapter ou de développer des logiciels à de nouveaux usages et à de nouvelles méthodes de consommation. Pour une entreprise qui vient de se créer c’est simple, elles n’ont pas d’infrastructure et de patrimoine d’applications à faire évoluer, elles peuvent démarrer directement sur un environnement agile et à partir de là développer ces applications. En revanche pour les entreprises existantes ca sera beaucoup plus complexe et cette complexité et proportionnelle à la taille de l’entreprise. Plus les entreprises sont importantes et plus elles auront à faire évoluer un patrimoine d’applications important et auront aussi besoin d’en developper de nouvelles. Pour cela elles devront entreprendre une transformation du personnel et des process mais aussi une Transformation Digitale ! Un “Digital Business” nécessite une “Digital Foundation”

 

La transformation digitale s’opère sur la fourniture des applications, l’hébergement des applications et la consommation des applications tout en renforçant la sécurité. Elle doit résulter d’une foundation unique pour différents usages. Elle repose évidement sur du matériel pour lequel on peut exiger performance, capacité et fiabilité. L’autre partie c’est la part belle du logiciel, c’est elle qui va apporter l’agilité nécessaire à la digitalisation. La fondation peut-être dans le data center privé comme sur une infrastructure cloud public. Elle doit pouvoir héberger des applications classiques comme des Cloud Native Apps qui seront consommées via des desktops, des objets connectés ou des smartphones.

 

 

La transformation digitale doit être impulsée par la direction et répercutée dans toute la chaine managériales car elle implique l’adhésion du personnel qui lui aussi doit être prêt à se “transformer”. C’est la partie la plus compliquée, il faut s’attendre à avoir des résistances, je l’ai souvent constaté. La gestion des couches basses de part l’automatisation nécessitera de moins en moins de personnel qui sera désormais de en plus en plus proche du métier de l’entreprise. L’IT devient partenaire du business voire même partie prenante du business. Cependant c’est difficile de faire comprendre à un administrateur de stockage qu’il n’aura plus de baie de stockage et de réseau SAN à administrer (cf article sur la virtualisation du stockage  http://loeilduse.fr/?p=43). Difficile de faire comprendre à un administrateur réseau que la création de réseaux va être déportée dans une cloud management platform ou un orchestrateur de containers. Ils doivent pourtant comprendre qu’ils tentent de résister à un rouleau compresseur qu’est la tendance du marché et c’est une question de temps avant que la transformation ne s’opère. Ils doivent saisir l’occasion pour s’orienter vers de nouvelles technologies comme le cloud (privé, public et/ou hybride), le DevOps, les containers, la mobilité, l’IOT, les blockchains, …, la liste est longue et il y a quoi bien s’occuper.

Pour être efficiente, la fondation digitale doit être appliquée sur toute la chaine allant des ressources hébergeant les applications jusqu’à l’utilisateur qui va les consommer à l’instar de la sécurité (cf article la sécurité de bout en bout http://loeilduse.fr/?p=249). Très important, cette chaine doit être constituées de composants qui s’intègres les uns aux autres nativement sans effort. Pour diminuer les risques, il est indispensable d’avoir tous ces composants issus du même éditeur.

Commençons par l’hébergement sur le Data Center privé, ensuite le Cloud Hybrid pour finir par la consommation via les terminaux :

 

Le Data Center Privé 

L’agilité va permettre de gagner du temps en étant plus réactif voire proactif.  Pour cela, il faut le moderniser en le rendant agile afin que, le patrimoine d’applications puisse en bénéficier, pour y héberger les nouvelles applications Cloud Native et pour renforcer la sécurité existante (car on ne sécurise pas les Cloud Native Apps et les containers comme on le faisait avec les applications traditionnelles). Cette agilité ne peut être obtenue que par le SDDC (Software Defined Data Center) en virtualisant tous les composants du Data Center. Une fois virtualisés, ils pourront être automatisés presque robotisés! L’infrastructure physique, elle est là pour être capacitive, performante et fiable avec un sas de sécurité pour filtrer tout ce qui y rentre et tout ce qui sort. Le SDDC va utiliser ces ressources pour y exécuter tout type d’applications et sera couplé à une Cloud Management Platform ou un orchestrateur de container comme Kubernetes (cf article sur PKS http://loeilduse.fr/?p=158)

L’architecte peut ainsi en tout autonomie “désigner” son application en y intégrant tous les composants du SDDC dont il a besoin. Ci-dessous un exemple de design d’un service web en cluster, la création du réseau, l’insertion de service Load Balancer et l’application de règle de sécurité. Plus besoin de faire des demandes à différences services pour obtenir les ressources dont il a besoin.

 

Une fois terminé, l’architecte peut soit la déployer ou soit le mettre à disposition via un catalogue de services pour des utilisateurs puissent la déployer ultérieurement :

 

Aboutir à ce résultat n’est pas d’un point de vue technique si compliqué que ça, à condition, j’insiste, que tous les composants logiciels du SDDC soient prévus pour fonctionner nativement ensemble, ainsi les efforts d’intégrations et de maintient en condition opérationnel seront réduits. La mise à jour du SDDC se fait sans avoir à se soucier de l’intéropérabilité des versions des composants, le SDDC Manager se charge de ça.

Il ne faut pas aussi que le SDDC n’est d’adhérence avec la couche matériel, vous devez être libre de choisir et de changer les composants physiques avec un minimum d’impact. Ainsi les switches peuvent être des Cisco, des Arista, des juniper, ou autre, les serveurs peuvent être des HP, des DELL, des Lenovo, ou autre, ça n’a pas d’importance que ce soit à la création du SDDC ou durant son cycle de vie.

 

Le Cloud Hybride

Hybride au sens où on peut transférer des applications du cloud public vers le cloud privé et vice-versa en fonction des besoins. Ce qui est recherché :

  • Ce sont des services innovants utilisables à la demande sans avoir à les installer et à les administrer.
  • Des ressources physiques à la demande sans avoir à anticiper les achats matériels. Si un gros projet nécessitant beaucoup de ressources non disponibles sur le Data Center privé, il faudrait attendre de les commander, de les installer et les configurer avant de pouvoir commencer le projet. Avec le Cloud Hybrid on commande un SDDC et deux heures après il est disponible pour démarrer le projet. Si vous souhaitez le voir au final sur votre Data Center privé vous pourrez le rapatrier une fois les nouvelles ressources disponibles. Pour que ce soit faisable et sans risque, il faut que le SDDC public soit le même que le SDDC privé (à minima le même hyperviseur). Pour en savoir plus je vous conseil cet article : http://loeilduse.fr/?p=74.

 

Les terminaux

Une fois les applications déployées il faut les consommer, le problème c’est qu’elles prolifèrent et c’est difficile de s’y retrouver tellement on en a. En plus maintenant ont a plusieurs terminaux : un smartphone (Android ou IOS), une tablette (Android, IOS ou Windows) ou laptop (Mac, Chrome OS ou Windows).

Pour être efficace, l’utilisateur doit avoir une visibilité directe des applications dont il a besoin et ce quelque soit le terminal qu’il utilise. Ci-dessous une copie d’écran du portail avec les applications que j’utilise le plus souvent sur mon Mac ou mon S8.

En plus d’avoir accès rapidement aux applications, on n’a plus à se soucier d’avoir à gérer la complexité des différentes politiques de mot de passe par application, une fois connecté via son compte principal, l’utilisateur n’a plus besoin de s’authentifier à nouveau pour accéder à ses applications et ce quelque soit son mode d’hébergement (SaaS, Web ou installées sur le terminal) (cf article la sécurité de bout en bout, chapitre sécuriser les accès à distance  http://loeilduse.fr/?p=249).

La sécurité de bout en bout !

Comme on ne vit pas dans le monde des Bisounours, la sécurité est pour nous tous un mal nécessaire je dirais même obligatoire. Elle ne se résume pas à la mis en place d’un firewall pour filtrer tout ce qui entre et qui sort du data center et d’un anti-virus sur le poste de travail, il faut sécuriser toute la chaine allant de l’utilisateur à l’application en passant par l’infrastructure.

Vous avez surement déjà vue l’image à droite lors d’une présentation VMware, elle explique la stratégie de VMware, à droite de cette image, il y a des petits cadenas orange qui correspondent à la sécurité. C’est ce que je vais décrire succinctement dans cet article : les fonctionnalités qui contribuent à améliorer la sécurité. Elles peuvent être utilisées de manière indépendantes ou complémentaires les unes par rapport aux autres. Je vais commencer par le bas (l’infrastructure) pour finir par le haut (l’utilisateur).

 

Sécuriser la base : le boot de l’hyperviseur

Pour être sûr que l’hyversieur est basé sur un code authentifié, celui-ci peut être vérifier dès la première phase de démarrage par le BIOS UEFI du serveur et si le code n’a pas la bonne signature, l’hyperviseur ne pourra pas démarrer. La vérification se fait par un système de clé privé / clé publique.

The UEFI secure boot stack includes multiple elements, explained in the text.

 

“Durcir” les composants

VMware délivre des “Security Hardenig Guides” https://www.vmware.com/security/hardening-guides.html pour sa solution d’hyperviseur vSphere et sa solution de réseau et de sécurité NSX. Ces “Security Hardening Guides” sont des règles de configuration de bonne pratique qui permettent de sécuriser au maximum les solutions VMware et limiter ainsi les surfaces d’attaques. Un exemple de règle sur vSphere parmi les 70 qui existent, le timeout d’accès au shell pour exécuter des lignes de commande, par défaut il n’y en a pas, la recommendation est de 900 minutes.

Pour faciliter la vérification du bon respect de ces règles la solution vRealize Opérations propose des tableaux de bords simples à consulter :

 

Le chiffrement des VMs

Pour éviter que des VMs soient copiées illicitement et ensuite démarrées sur un autre environnement, il est possible de chiffrer les fichiers qui les constitue ainsi que les éventuels déplacement (vMotion) vers d’autres hyperviseurs identifiés, et ce, quel que soit l’OS des VMs. La mise en place nécessite que le vCenter soit relié à un serveur de gestion de clés KMS, ensuite il suffit d’associer les VMs que l’on souhaite chiffrer à une politique de stockage ayant l’attribut chiffrement, cela peut se faire post création.

Il est possible aussi de chiffrer un espace de stockage complet (nécessite d’avoir la solution vSAN), tout ce qui y sera stocké sera sécurisé, pas besoin de sélectionner les VMs à sécuriser. Un autre avantage ce cette possibilité auquel on ne pense pas concerne la partie matériel, ainsi si un disque est défaillant vous n’êtes pas obligé de passer par une société tierce pour le détruire car son contenu est chiffré et donc illisible.

 

Sécuriser le boot des VMs

Pour éviter que des root kits malveillants soient installés dans le système d’exploitation de la VM et ainsi corrompre le système d’exploitation, l’hyperviseur vSphere permet de sécuriser le boot de la VM de façon a ce que seuls les systèmes d’exploitation, le boot loader et les drivers signés par l’éditeur puissent démarrer.

 

Création de réseaux par usage

Pour limiter les surfaces d’attaques, il faut limiter l’exposition des applications sur les réseaux. Idéalement une application devrait venir avec ses propres réseaux de communication. Prenons une architecture applicative composée de plusieurs services comme par exemple un service Web, un serveur d’application et un service de base de données. Seul le service Web doit être exposé aux utilisateurs. Les autres communications doivent se faire par réseau dédiés comme illustré dans le schéma ci-dessous :

Avec ce principe on créé un réseau dédié par canal de communication entre les services applicatifs. Le fait d’avoir des petits réseaux dédiés à chaque communication limite l’utilisation de règles de sécurité. Alors bien sûr avec un réseau classique c’est complexe à mettre en place mais avec la virtualisation du réseau (NSX), c’est un jeu d’enfant.

 

La micro segmentation

La micro segmentation consiste  à améliorer la sécurité de l’infrastructure en étant le plus granulaire possible. Elle permet de filtrer les communications de chaque carte réseau de chaque VM.

Grâce à cela les communications entres les VMs peuvent être filtrées mêmes si elles résident sur le sur un même segment réseau IP. Dans l’exemple ci-dessous la VM qui appartient à l’application Finance et connectée au réseau DMZ mais elle ne peut pas communiquer avec les autres VMs HR et Engineering même si elles aussi sont connectées au même segment réseau IP DMZ.

Alors il est possible de le faire avec une architecture physique classique mais ça devient vite une usine à gaz à mettre en place et à administrer au quotidien.  Avec la virtualisation de la sécurité (NSX), c’est beaucoup plus simple, les règles peuvent être créés dynamiquement, par exemple on peut identifier toutes les VMs (existantes et à venir) Windows sans avoir à spécifier les adresses IPs. De plus si les VMs sont amenées à se déplacer d’un hyperviseur à un autre, les règles restent toujours actives car le firewall est distribué dans le kernel de tous les hyperviseurs concernés.

 

La conformité

Suivant le secteur d’activité de son entreprise, on peut être amené à devoir respecter certaines normes de sécurité et mettre en conformité une partie de son infrastructure.  Comme un de mes clients stockait et traitait des informations relatives aux paiements par carte bancaire, J’ai dû travailler sur la norme de sécurité PCI-DSS ( Payment Card Industry Data Security Standard). Pour PCI-DSS, il faut prendre en compte toute une chaine à sécuriser. L’avantage principal des solutions VMware est qu’elles vont vous permettre de ne pas avoir à dédier une infrastructure physique mais plutôt de segmenter celle existante et dédier un segment à l’environnement PCI-DSS et de le rendre hermétique par rapport au reste. Prenons deux exemples, l’un coté utilisateur et l’autre coté réseau :

  • Coté utilisateur, le poste de travail utilisé par un opérateur manipulant des données de paiement par carte bancaire doit être dédié à cet usage, s’il est amené à travailler avec d’autres données, il doit avoir un autre poste pour cet usage. Grace à la visualisation du poste de travail (VMware Horizon), il a un poste physique avec son environnement classique et un autre environnement virtuel dédié à PCI-DSS, les deux sont complètement isolés et étanches l’un par rapport à l’autre.
  • Coté réseau, le réseau utilisé par l’environnement qui va manipuler des données de paiement par carte bancaire doit être isolé par rapport aux autres réseaux des autres environnements. Grace à la visualisation du réseau et de la sécurité (NSX), vous créez à la demande des réseaux virtuels de confiance dédiés au périmètre PCI-DSS complément isolés et hermétiques du réseau classique d’entreprise

Ce document (en Anglais) : https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/vmware-sddc-euc-product-applicability-guide-for-pci-dss.pdf détail l’apport de chaque solution à chaque recommandation.

 

La sécurité des applications

La devise est : si on sait modéliser le bon comportement d’une application alors on sait aussi identifier un mauvais comportement, un comportement déviant de la normal. La solution AppDefense modélise le bon comportement grace à une capture de l’application, c’est à dire identifier tous les process et communications réseau utilisés. (Tout est plus détaillé dans ce document (en Anglais) : https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/vmware-appdefense-solution-overview.pdf)

La première chose que tente de faire un “malware” est de désactiver les outils de sécurité basés sur des agents. AppDefense bénéfice d’une zone sécurisée fournie par l’hyperviseur qui est inaccessible par le système d’exploitation de la machine virtuelle, AppDefense ne peut ainsi pas être corrompu ou désactivé.

Lorsqu’une menace est détectée, AppDefense peut demander à vSphere d’arrêter une VM, de la suspendre ou d’en faire un snapshot afin de pouvoir la décortiquer. AppDefense peut aussi demander à NSX (solution de virtualisation de réseaux et sécurité) de bloquer les communications réseaux ou de le connecter à un réseau de quarantaine.

 

Sécuriser les accès distants

Il y a plusieurs possibilité d’accéder à distance à des applications d’entreprise, pour chaque méthode il faut une solution sécurisée :

  • Le VPN SSL de NSX permet à des utilisateurs de se connecter depuis n’importe où à un réseau spécifique du Data Center via un canal chiffré, comme si il était directement au réseau de son entreprise.
  • Le VPN IPSEC de NSX permet de connecter deux segments de réseaux IP différents tout en sécurisant les flux de communication.
  • Le VPN L2 permet d’interconnecter deux réseaux physiques de niveau 2 (Ethernet) différents pour qu’ils soient vus comme un seul. Les VMs ainsi connectées se voient toutes comme si elles étaient physiquement connectées sur un même réseau.
  • Les VPNs par application de Workspace One sont utilisés notamment pour les applications smartphone, ils permettent à chaque application d’avoir son propre tunnel sécurisé. Ça offre l’avantage de ne pas avoir un seul gros VPN pour tout le smartphone où il n’y a pas de distinction des communications personnelles et professionnelles. Cela permet aussi de diminuer la consommation de la batterie, le VPN engendrant des cycles CPU n’est activé que quand l’application est utilisée.
  • Le poste de travail virtuel (VMware Horizon anciennement VMware View) permet de donner accès via un réseau à un poste de travail qui est entièrement exécuté sur un Data Center, seuls les flux entrants et sortants comme le clavier, la souris, l’écran ou encore le son sont locaux. Toute la propriété intellectuelle de l’entreprise reste au sein de l’entreprise, les transferts de fichiers, le copier/coller, l’accès à des périphériques USB peuvent être inhibés. Le poste de travail virtuel est souvent utilisé lorsque les entreprise ont recours à des prestataires ou à des sous-traitant.
  • La gestion des terminaux (Android et IOS) et de leurs contenus (VMware Workspace One anciennement Airwatch) permet de sécuriser les accès. En effet quelque soit le model d’attribution choisi : Bring Your Own Device, Choose Your Own Device ou autre, il est possible de créer un espace professionnel distinct du personnel sans compromettre la sécurité. L’utilisateur gère son propre espace avec ses propres contenus et l’administrateur s’occupe de sécuriser l’espace professionnel. Il autorise l’accès aux applications et aux données de l’entreprise par des critères d’authentification multi facteur requis en fonction du réseau de connexion.  Pour simplifier et sécurisé les authentifications, la fédération d’identité est utilisée pour accéder à l’ensemble des applications (SaaS, Web,  Messagerie, …) empêchant ainsi les traditionnels risques liés aux mot de passe faibles et identiques, tout en permettant à l’utilisateur une seule authentification valable pour l’ensemble des applications. Si le terminal est perdu ou volé il est possible de remettre à zéro le contenu de la partie professionnelle.

Et l’écologie ?

Il y a plusieurs moyens d’apporter sa contribution à rendre la planète moins polluée, que ce soit dans sa vie personnelle ou dans sa vie professionnelle.

Dans la vie professionnelle notamment en informatique le choix du matériel (serveur, stockage, switch, …) est important mais pas suffisant. En effet le logiciel a une part plus importante que le matériel à la fois sur la consommation énergétique directe induite par la consommation électrique des équipements (serveur, stockage, switch, … ) et sur la consommation énergétique indirecte induite par la climatisation pour diminuer la dissipation thermique.

Alors pourquoi le choix du logiciel a-t-il un impact plus importante que le choix du matériel ?

Le premier levier est la consolidation des composants du Data Center en les virtualisant (SDDC : Software Defined Data Center). L’hyperviseur de par ses algorithmes d’optimisation et notamment la mémoire, a le meilleur taux de consolidation du marché. Avec vSphere vous hébergerez plus de VMs sur un serveur physique qu’avec tout autre hyperviseur. Ainsi, dans le DC, il y aura moins de serveurs physiques, donc moins de connectiques réseaux, moins de connectiques stockage réduisant ainsi le nombre de switches réseaux et SAN. La consommation électrique est réduite, la dissipation thermique aussi, le DC peut-être plus petit.

En plus du fort taux de consolidation possible, les fonctionnalités intégrées à l’hyperviseur permettent également d’obtenir des gains de consommations. DPM (Distributed Power Management), DRS (Distributed Ressource Scheduler) et vMotion fonctionnent conjointement pour optimiser l’utilisation des ressources sur un minimum d’hyperviseurs. DPM va analyser la demande de ressource et définir combien d’hyperviseurs sont nécessaires pour honorer cette demande, s’il y a trop d’hyperviseurs, il va demander à vMotion de déplacer à chaud les VMs afin de les concentrer sur un nombre réduit d’hyperviseur, ceux qui se retrouve sans VMs seront arrêter physiquement. Si DRS se rend compte que la demande s’accroit et que les ressources risques de ne plus être suffisantes, il va demander à DPM de démarrer le nombre d’hyperviseurs nécessaires et à vMotion et de déplacer certaines VMs afin d’équilibrer les charges entres eux. Pour que cela fonctionne, les serveurs physiques doivent supporter l’un des protocoles suivants : IPMI, ILO ou WOL.

 

Grace à la virtualisation du réseau et de la sécurité, tous les trafics de communication Est-Ouest (trafics intra DC) qui représentent environ 80% du trafic total, se font sans passer par le coeur de réseau car les fonctionnalités de routage, switch et firewall sont directement intégrées dans l’hyperviseur. En évitant ainsi de passer par les équipements physiques (voir illustration ci-dessous), cela permet de réduire en nombre et/ou en taille ces équipements.

 

Et ceci peut encore être optimisé ! Grâce aux tableaux de bord vRealize Operations (vROps) :

Vous pouvez connaitre les VMs qui ont été déployées, démarrées mais pas ou plus utilisées. Elles consomment tout de même de l’espace de stockage et des ressources processeur et mémoire :

 

Vous pouvez lister les VMs déployées mais éteintes depuis un certain temps qui consomment de l’espace stockage :

 

 

Une étude IDC détaillée (en Anglais) explique les calculs qui ont permis de mesurer les gains obtenus grâce à la virtualisation de l’ensemble des composants du Data Center et elle estime que les solutions VMware ont permis d’économiser 450 millions de tonnes de CO2 depuis la création de la société VMware : https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/company/vmw-data-center-energy-and-carbon-emission-reductions-through-compute-storage-and-networking-virtualization.pdf

Pourquoi PKS (VMware Pivotal Container Service)

Après les VMs, les containers, c’est autour des orchestrateurs de containers de rencontrer un vif succès, mais dans ce domaine les modes ont été éphémères, il y en a un qui sort son épingle du jeu c’est Kubernetes et cet engouement à l’air de s’installer. Je n’ai pas rencontré un client qui ne me parle de ça. Ils ne sont pas tous au même niveau de connaissance et d’appétence mais tous y vont, certes à tâtons car c’est un monde nouveau mais ils y vont. Pour être rassurés, les clients souhaitent se reposer sur des éditeurs pérennes, en qui ils ont confiance, qui ont des solutions robustes et un support fiable. C’est une des raisons pour laquelle PKS est rassurante.

PKS est une solution issue du partenariat entre VMware, Pivotal et Google où chacun apporte sa contribution. D’un point de vu macroscopique VMware apporte la partie registre des containers ainsi que la virtualisation du réseau et de la sécurité, Pivotal apporte la partie gestion du cycle de vie des cluster Kubernetes et Google son orchestrateur de containers kubernetes.

PKS ne modifie pas Kubernetes et n’apporte pas de surcouche ou d’interface intermédiaire. Le Kubernetes qui est utilisé n’est pas non plus un “fork” (une sous branche) mais belle est bien celui de Google, toutes les APIs et les lignes de commande ainsi que les applications que vous allez développer seront compatibles avec un Kubernetes hors PKS. A quelques semaines près vous aurez toujours la dernière version stable de Kubernetes qui sera supportée.

Lorsqu’il est hébergé sur le data center privé, PKS repose sur le SDDC (Software Defined Data Center) de VMware, il utilisera à minima les ressources vSphere et idéalement s’appuiera sur vSAN et NSX. Certains éléments de kubernetes seront surveillés est relancés par PKS, certains éléments de PKS quant à eux seront surveillés et relancés par vSphere HA. Grace à PKS, Kubernetes utilisera de manière transparente la partie stockage de vSphere pour le stockage éphémère ou pour le stockage persistant, lorsque vSAN est présent, les classes de stockage Kubernetes ou les volumes Docker pourront bénéficier des politiques de stockage de vSAN comme par exemple définition de la tolérance aux pannes (FTT). PKS couplé à NSX offre un vrai SDN et une sécurité accrue. Les fonctionnalités de routage, switching et sécurité sont intégrées et distribuées aux hyperviseurs ce qui offre de meilleures performances, une meilleure scalabilité et une plus grande sécurité.  Lorsque des pod Kubernetes sont déployés, les réseaux, les routeurs et les services tels que le load balancing sont automatiquement provisionnés. Les Network Policy utilisé par Kubernetes permettent de définir des règles de sécurités qui sont traduites par des règles de firewall NSX (des vraies pas des ACLs). Il est possible de définir des règles de sécurités inter Pod. Encore une fois c’est transparent pour le développeur, il a juste besoin de connaitre les commandes/API kubernetes et Docker.

 

 

Pour connaitre les flux réseaux, la fonctionnalité Traceflow permet de les visualiser entre deux composants parmi les critères suivants logical switch, VM, IP et MAC. 

Si des règles de sécurité firewall ont bloquées les communications, elles seront aussi affichées ce qui permettra de vite identifier quelle règle est en cause.

 

PKS permet de créer des cluster Kubernetes à la demande. Chaque cluster Kubernetes est indépendant et isolé, plusieurs versions de Kubernetes peuvent résider sur une même plate-forme mais aussi pour plusieurs usages, dev, tests, pré-prod, … ou encore plusieurs “tenant” (colocation. Si vous possédez un portail self service tel que vRA (vRealize Automation), vous pouvez proposer un blueprint Kubernetes As A Service et offrir à un développeur ou à une équipe de développeurs de provisionner de manière automatisée des cluster Kubernetes.

PKS permet de gérer le cycle de vie complet des cluster kubernetes et de ses composants allant de l’installation, des mises à jour, de l’application de patches et le “scaling” du cluster, le tout à chaud.

 

PKS intègre un registre des containers privés (Harbor) pour y déposer vos images que vous ne souhaitez pas mettre sur un registre public. Il intègre une gestion des rôles d’accès (RBAC). Harbor peut scanner les images à la recherche de vulnérabilités, signer les images et répliquer les images sur un autre registre de containers. 

 

Si vous utilisez vROps (vRealize Operations) vous aurez la possibilité de surveiller vos clusters Kubernetes ainsi que l’infrastructure qui l’héberge et avoir ainsi des corrélations de performance et d’incidents.

 

 

Pour monitorer le fonctionnement des applications et/ou les métriques métiers comme par exemple le nombre de transaction par seconde, vous pouvez utiliser WaveFront :

 

 

Pour résumer les avantages de PKS :

  • Dernière version stable de Kubernetes natif de Google, même lignes de commandes, même API. Pas de surcouche !
  • Gestion complète du cycle de vie de Kubernetes, installation, mise à jour, application de patch et scalabilité.
  • Kubernetes As A Service, des cluster Kubernetes à la demande indépendant et isolé.
  • Utilisation du SDDC VMware permettant d’avoir un environnement Kubernetes résilient, performant et sécurisé.
  • Provisionnement automatique et natif de load balancer, réseaux, règles de sécurité et niveaux de service stockage.
  • Possibilité de monitorer l’infrastructure complète et les applications.

 

Les avantages non techniques :

  • Gain de temps en formation et en développement : les développeurs non que Kubernetes et Docker à connaitre.
  • Risques réduits : PKS est supportée par VMware et repose une plate-forme SDDC sécurisée.

Pour plus d’information https://cloud.vmware.com/fr/pivotal-container-service/resources

Pour la tester : http://labs.hol.vmware.com/HOL/catalogs/lab/4249 

C’est gratuit ! ?

€€€€

Combien de fois j’ai entendu cette phrase : Hyper-V et OpenStack c’est gratuit ! ? des centaines de fois, ou encore VMware c’est le top mais ça coute cher.

Certe les solutions VMware ont un coût, il est induit principalement par la recherche et développement et par la valeur ajoutée qu’elles apportent. La cherté subsiste s’il n’y a pas de valeur constatée. Pour faire un comparatif objectif, il faut prendre en compte toute la chaine de coûts et non pas seulement la partie CAPEX (acquisition) des licences, il faut intégrer la partie OPEX (opérationnelle) et tous les autres paramètres induits. Il existe beaucoup d’études comparatives qui démontrent la réalité des choses, je vais lister ici les éléments de ce qui m’a été remonté par mes clients.

Sur la partie hyperviseur :

  • vSphere a la meilleure densité VM par serveur sans compromettre sa stabilité. Sur un serveur ça peut-être paraître négligeable mais sur un grand nombre ça ne l’est plus. Un serveur a bien sûr un coût mais aussi, prend de la place en salle machine, consomme de l’énergie électrique et en climatisation, il consomme occupe aussi des ports réseau et éventuellement SAN. Les applications avec une tarification à la CPU nécessitent moins de licences.
  • vSphere à un noyau léger et stable, il consomme très peu stockage et subit très peu de panne ce qui induit beaucoup moins d’incidents à gérer.
  • Les opérations d’administration du quotidien prennent moins de temps, déplacement à chaud de VMs, déploiement de nouveaux hyperviseur, configuration réseau et stockage
  • vSphere fonctionne comme une ferme d’hyperviseur où toutes les ressources sont fédérées, mutualisées, l’équilibrage des charges se fait automatiquement et libère tu temps à l’administrateur pour qu’il se consacre à des tâches plus gratifiantes.

Sur la partie Cloud, on me mettait souvent en compétition avec les solutions Open Source comme OpenStack, il y a quelques années elles avaient le vent en poupe, c’est beaucoup moins le cas maintenant. Les arguments étaient, c’est gratuit et ce n’est pas vendor lock-in. Dans les fait ce n’est pas le cas, force est de constaté, ce qui n’est pas dépensé chez un éditeur doit l’être en ressource humaine pour développer et maintenir toute l’automatisation déjà présente dans les solutions payantes. Quelques exemples de ce qui est à développer sur OpenStack et qui est natif dans vRA (vRealize Automation) :

  • L’installation de vRA est beaucoup plus simple, en quelques heures on a un cloud opérationnel.
  • Nativement vRA intègre de la gouvernance basée sur des “Policies” (qui à le droit de faire quoi), des workflows d’approbation, les baux d’expirations, tout le cycle de vie d’un déploiement, un designer graphique de blueprint, …

Bref rien n’est gratuit, tout à un prix, tout à un coût. Il faut faire des comparaisons en prenant en compte toute la chaine et identifier les éléments qui ont de la valeur pour vous.

Pourquoi VMware

VMware fait partie des rares sociétés informatiques qui proposent à ses clients des solutions qui permettent un retour sur investissement rapide, palpable et mesurable.

Dès la première solution : la virtualisation des serveurs x86, il y a eu un retour sur investissement matériel et opérationnel. En faisant fonctionner simultanément plusieurs serveurs virtuels sur un seul serveur physique, on économise sur le nombre de serveurs physiques et de switches réseau, sur le câblage, sur la consommation électricité, et de climatisation, l’espace salle machine …

VMware investit énormément en recherche et développement pour faire évoluer ses solutions existantes, en créer de nouvelles ou encore en intégrer des nouvelles par acquisition.

VMware aurait pu rester uniquement dans le domaine de la virtualisation où elle était (et l’est encore) leader mais elle a préféré investir aussi dans d’autres domaines tels que le Software Defined Data Center, les containers, la sécurité, le cloud hybrid et la mobilité.

Les solutions sont en général reconnues comme leader dans leur segment et sont fiables.

VMware est une société pérenne avec des solutions pérennes intégrant les dernières technologies, les investissements faits par ses clients sur ces solutions sont eux aussi ainsi pérennisés et évolutifs.

Pourquoi VMware Cloud On AWS (AKA VMC)

VMC on AWS c’est le SDDC (Software Defined Data Center / Data Center logiciel) de VMware hébergée sur les infrastructures physiques d’AWS. Elle permet d’avoir un Data Center agile et programmable sans avoir à le gérer. Lorsqu’il est couplé à un Data Center privé on obtient un réel Cloud Hybrid, c’est à dire une administration centralisée commune des deux, la possibilité de migrer à chaud et à froid les workloads de l’un vers l’autre, de synchroniser les templates de VMs et d’étendre les réseaux (niveau 2 et 3) afin d’avoir le même plan d’adressage. La condition minimale pour avoir un cloud hybrid est d’avoir au moins l’hyperviseur vSphere sur son Data Center privé, sinon on n’a juste un cloud public SDDC VMware hébergé chez AWS (et c’est déjà très bien).

 

Je ne vais pas aborder les avantages du Cloud Public et du SDDC, je pars du principe qu’ils sont connus. Cependant, je vais aborder les points de vigilance auxquels ont fait face certains de mes clients :

 

  • Pour être efficient, il faut connaître l’architecture de l’infrastructure sous-jacente (réseau, stockage, serveur, sécurité, …).
  • Il faut que l’application soit développée en intégrant dans son design la prise en compte de panne des différents éléments constituant l’infrastructure.
  • Pour les applications existantes, il faut transformer les VMs car elles n’auront surement pas le même format.
  • Intégrer un nouveau model opératoire pour lequel il faut prévoir, de nouveaux outils d’administration à acquérir et à connaître, de nouveaux scripts d’administration à écrire ou à adapter, de nouvelles compétences à recruter et former celles existantes.
  • Appréhender une nouvelle gouvernance et de nouvelles règles de sécurité.
  • Il faut prévoir un retour arrière, les intérêts que vous avez trouvé à un hébergeur (notamment tarifaires) peuvent ne plus correspondre dans le futur.

 

Quels sont les principaux avantages techniques que trouvent les clients à utiliser VMC, notamment ceux qui ont déjà une infrastructure à base de vSphere ?

 

  • Une infrastructure qui leur est dédiée, donc une plus grande sécurité car elle n’est pas partagée par d’autres clients et des performances prédictibles car ce sont uniquement ses propres applications qui y fonctionnent.
  • Pas de besoin de transformer les VMs et les applications, le format et le même que sur les hyperviseurs vSphere de leur Data Center privé.
  • Une réversibilité, du fait d’avoir le même format, s’ils changent d’avis ils peuvent (re)transférer leurs VMs sur leur Data Center privé.
  • Un mode opératoire et des compétences identiques à ce qu’ils ont pour leur environnement vSphere sur leur Data Center privé, les investissements antérieurs sont ainsi pérennisés.
  • Être au plus proche des services AWS. Si vos applications hébergées sur votre Data Center privé ont besoin d’accéder aux services AWS, elles doivent passer par Internet ou par un lien direct connecte et les trafics réseaux sortants d’AWS vous seront facturées. Lorsqu’elles sont hébergées sur VMC, elles sont au plus proche des services AWS, vous allez gagner en performance et leurs échanges ne seront plus facturés.

 

Comment bénéficier de VMC et qui contacter en cas de problème ?

 

  • Au moment de la rédaction de cet article, le seul moyen d’y bénéficier et de passer par vos contacts VMware habituels. 
  • En cas d’incident, quel qu’y soit, VMware est votre interlocuteur unique.

 

La création du SDDC hébergé chez AWS, se fait directement via le site de VMware en l’associant à un compte et à un VPC AWS.

 

Contrairement à un Cloud Public, vous n’achetez pas de VMs ou des services applicatifs mais bien des ressources physiques bénéficiant du SDDC de VMware, le minimum pour démarrer c’est un cluster de quatre hyperviseurs puis si besoin des incréments d’au moins un hyperviseur. Un hyperviseur vient avec ses processeurs, sa mémoire et sa capacité de stockage. La tarification est basée sur le même principe.

Les cas d’usages constatés sont ceux d’un Data Center classique plus ceux qui figurent dans le schéma ci-dessous :

 

Les avantages non techniques constatés sont :

  • Ne plus avoir à gérer les acquisitions d’infrastructure bas niveau, le cycle de vie, la gestion des changements, les opérations de maintenance, la formation du personnel.
  • Libérer du temps et du budget aux services plus proche des métiers de l’entreprise.
  • Un accroissement de l’agilité, désormais un projet peut démarrer de zéro en quelque heures et adapter ses besoins en ressources en quelques minutes si nécessaire.
  • Être libre de choisir son hébergeur et d’y changer si besoin.
  • Récupérer les budgets qui auraient dû être alloué à la transformation applicative, à la formation et à l’adaptation d’outils.
  • Diminuer les risques, en utilisant une plate-forme au comportement connu et maitrisé.
  • Garder la gouvernance habituelle.

Pour plus d’information, je vous invite à visiter le site de VMware sur ce sujet : https://cloud.vmware.com/fr/vmc-aws

Pourquoi vSAN (HCI : Hyper Convergence Infrastructure)

vSAN est une solution stockage qui utilise les médias de stockage internes (Disque dur, SSD, NVME, …) de plusieurs hyperviseurs formant un cluster pour qu’ils soient vus par chacun comme un seul espace de stockage partagé.

vSAN a été conçu pour simplifier l’utilisation du stockage et diminuer les coûts opérationnels et d’acquisition. En effet contrairement aux solutions classiques vSAN ne nécessite pas de compétences pointues et de matériels dédiés spécifiques.

Pourquoi est-il important d’avoir besoin d’un espace de stockage partagé par plusieurs hyperviseurs ?

  • Les VMs sont constituées de fichiers persistants, pour qu’elles puissent s’exécuter sur l’ensemble des hyperviseurs il faut que ceux-ci puissent y accéder.

Quelles fonctionnalités de vSphere ont le plus besoin d’un stockage partagé ?

  • High Availability (HA) : Assure la haute disponibilité des VMs et ses applications. Si l’hyperviseur qui exécute la VM subit une panne, la VM est redémarrée sur un autre hyperviseur.
  • Distributed Resources Scheduler (DRS) : Réparti les charges (VMs) entre les hyperviseurs de façon à optimiser l’utilisation des ressources.
  • vMotion : Fonctionnalité qui permet de déplacer à chaud une VM d’un hyperviseur à un autre de façon préventive. Par exemple lors des opérations de maintenance pour éviter des interruptions de service.
  • Fault Tolerant : Une VM est exécutée sur un hyperviseur et les instructions (mémoire, CPU) induites sont envoyées simultanément sur un autre hyperviseur. Si l’hyperviseur qui effectue l’exécution subit une panne, l’autre hyperviseur active la VM immédiatement, il n’y aura pas d’interruption de service.

 

Avec des solutions de stockage traditionnelles, les administrateurs créent plusieurs espaces de stockage en fonction de leur capacité de stockage, de performance et de résilience.

Pour respecter le niveau de service requis par les applications, l’administrateur doit connaître les capacités de ces différents espaces de stockage.

Pour simplifier tout ça, vSAN ne créé lui qu’un seul espace de stockage et bénéficie d’une fonctionnalité intéressante : les politiques de stockage. L’administrateur les créés en fonction du niveau de service souhaité (niveau de tolérance aux pannes, de performance, de réservation, …).

Lorsqu’il crée une VM, il affecte à celle-ci la politique de stockage souhaitée et c’est ensuite l’hyperviseur qui s’assure que la VM sera stockée correctement afin de respecter ce niveau de service.

Si vous utilisez un portail self-service tel que vRealize Automation, celui-ci sera capable aussi d’affecter automatiquement la politique de stockage attendue à la VM à déployer.

Les politiques de stockage de vSAN apportent de la souplesse et un gain de temps non négligeable qui pourra être utilisé à autre chose.

vSAN est directement et complètement intégré dans l’hyperviseur, il ne nécessite pas d’installation. L’administration se fait comme pour l’hyperviseur, directement via le client web de vSphere.

vSAN est la brique principale des offres HCI (Hyper Convergence Infrastructure) qui consiste à créer un cluster de ressources comprenant des serveurs physiques, du stockage interne, un hyperviseur, un logiciel de virtualisation du stockage et de virtualisation du réseau.

Elle peut être « consommée » sous plusieurs formes différentes :

  • Dans des « Appliances Constructeur » comme par exemple VxRAIL ou VxRACK (il en existe d’autres chez plusieurs constructeurs). Le constructeur se charge d’effectuer l’ingénierie d’intégration et assure le support de l’ensemble.
  • Chez les cloud publics : AWS, IBM, OVH, ATOS et bien d’autres. Ici la constitution du cluster de ressources se fait à la volée, l’administrateur choisi le nombre d’hyperviseurs et un configurateur se charge d’interconnecter les serveurs entre eux, installe et configure la partie logicielle.
  • Directement sur vos hyperviseurs à base de serveurs compatibles vSAN Ready Node. Ici tous les composants ont déjà été validés par le constructeur.
  • Sur vos serveurs existants, dans ce cas Il y a un point de vigilance à prendre en compte si vous voulez que la solution fonctionne correctement. Il faut s’assurer que la carte contrôleur des médias, le média de cache et le media de capacité figurent bien dans la matrice de compatibilité.

J’ai des clients dans chaque cas de figure :

  • L’utilisation du modèle Appliance concerne des clients qui ont une certaine maturité et qui ne souhaitent plus avoir à gérer les installations de serveurs et des logiciels mais consacrent leur temps aux besoins plus proches des métiers.
  • L’utilisation du cloud public concerne des clients qui ne veulent plus du tout gérer d’infrastructures physiques et logiciels. Avoir vSAN dans le cloud public permet d’avoir le même mode opérationnel que sur le cloud privé, avec une définition des niveaux de service au travers des politiques de stockage.

Je vous conseille de bien répartir les serveurs dans des racks différents et de créer des « Fault Domain », comme illustré dans l’exemple ci-dessous : une VM est bien sûr stockée sur deux hyperviseurs différents mais surtout dans deux racks différents. Ainsi, si vous perdez un rack complet la VM restera malgré tout accessible. Le placement inter rack est automatique, la seule chose que l’administrateur est amené à faire c’est de définir l’appartenance de chaque hyperviseur à un rack donné.

Ce qui fait aussi la force de vSAN c’est son évolutivité, vous démarrez avec au minimum trois hyperviseurs et vous évoluez en fonction de vos besoins. Vous avez de nouvelles applications à héberger ? Vous ajoutez un hyperviseur (cela se fait à chaud) et votre cluster se retrouve avec plus de ressource processeur, mémoire, stockage et IOPS.

Autre point important si vous avez des sites distants, magasins, usines, agences ou autres qui ne nécessitent pas beaucoup de ressources, vous pouvez partir sur une configuration à deux hyperviseurs. Ces sites sont plus simples à déployer : juste deux serveurs !

Si vous avez des contraintes de licences avec un certain éditeur, grâce à vSAN et son espace de stockage partagé uniquement par les membres d’un cluster, vous pouvez affecter les licences de cet éditeur à ce cluster, et comme le stockage est « étanche », les autres hyperviseurs ne pourront pas accéder aux VMs.

Si vous avez des contraintes de sécurité, sachez que l’espace de stockage vSAN peut être crypté.

Si vous avez besoin de disponibilité, pas de souci, suivant la définition des politiques de stockage vous pouvez perdre un ou plusieurs hyperviseurs ou encore un site complet (configuration stretched cluster).

Dans l’illustration ci-dessous la VM est à la fois protégée sur le site local et sur le site distant, de manière à ce qu’une panne d’un hyperviseur n’entraine pas une bascule distante. Le witness sert d’arbitre en cas de rupture totale des communications inter-sites, les données générées par les VMs ne sont jamais envoyées au Witness.

Vous pouvez aussi augmenter cette disponibilité en ajoutant une réplication sur un troisième site en général beaucoup plus éloigné.

Je n’aborde pas toutes les fonctionnalités comme, la déduplication, la compression ou encore la possibilité de limiter les IOPS, ça serait trop long.

Comme son utilisation est transparente, vSAN ne se cantonne pas à un seul cas d’usage, mes clients l’utilisent comme du stockage traditionnel et ce pour tout type d’application, A titre d’exemple, le premier client vSAN Français a commencé avec un petit périmètre pour de la sauvegarde et maintenant l’utilise pour l’ensemble de ses environnements virtualisés en mode stretched cluster (cluster réparti sur deux sites éloignés de quelques kilomètres à des fins de résilience). Résultat : il ne possède plus de baie de stockage !

Les gains : le coût, la simplicité, la résilience et la performance.

Si je résume :

  • Rien à installer, tout est dans l’hyperviseur.
  • Pas de compétences spécifiques requises.
  • Plus besoin de baie de stockage et de réseau SAN, on utilise les médias internes.
  • Un seul et unique espace de stockage pour un cluster d’hyperviseur.
  • Niveau de service défini par des politiques de stockage.
  • Évolutivité verticale (ajout/retrait de média de stockage) ou horizontale (ajout/retrait d’hyperviseur).
  • Résilience locale ou par site.
  • Configuration deux hyperviseurs pour sites distants.
  • Large support de constructeurs et d’acteurs de cloud public.

Si vous souhaitez en savoir plus sur vSAN :

Créer un certificat auto-signé LDAPS pour Pinniped

Afin de simplifier l’authentification des clusters Kubernetes fonctionnant sur différents clouds, VMware a développé le projet Pinniped accessible en Opensource. Pinniped a été intégré par défaut dans l’offre VMware Tanzu Kubernetes Grid (TKG) depuis la version 1.3  en remplacement de l’extension Gangway. Pinniped permet l’authentification à partir de sources OIDC ou LDAP. Dans le cas de source LDAP, Pinniped ne se connecte pas directement à LDAP mais s’appuie pour le moment sur le composant Dex comme le faisait déjà Gangway.

Lorsqu’un utilisateur exécute une commande Kubernetes pour la première fois ou après une certaine période d’inactivité, il est invité à s’authentifier une seule fois avec son ses identifiants d’entreprise et peut ensuite consommer plusieurs cluster Kubernetes.

J’ai voulu tester cette fonctionnalité dans mon lab avec un serveur LDAPS/Active Directory sous Windows 2019 et je me suis vite confronté à l’éternel problème de certificat non signés par une autorité connue. Il fallait donc que je créé un certificat qui soit reconnu par le serveur Active Directory. En cherchant des heures sur Internet, j’ai fini par trouver un article (en Anglais) de Peter Mescalchin qui a fonctionné du premier coup : Enable LDAP over SSL (LDAPS) for Microsoft Active Directory servers. – bl.ocks.org.

Cependant, quand j’ai voulu utiliser cette procédure avec Pinniped, ça n’a pas fonctionné car les informations SAN (Subject Alternative Name) n’étaient pas présentes dans le certificat. En croisant plusieurs articles sur le sujet, j’ai pu adapter la solution de Peter Mescalchin afin que les certificats intègrent les informations SAN. Ca donne ceci :

Création du certificat Root

Via OpenSSL (j’ai utilisé un Linux Ubuntu) créer une clé privée (ca.key dans mon exemple) pour pouvoir ensuite créer le certificat root (ca.crt dans mon exemple). La première commande vous demandera un mot de passe et la seconde des renseignements sur votre organisation.

$ openssl genrsa -aes256 -out ca.key 4096
$ openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

 Importer le certificat Root sur le serveur AD

A partir du serveur AD, tapez la commande certlm ou via Control Pannel, tapez computer certificates dans la barre de recherche :

Attention à bien choisir “Manage computer certificates” et non “Manage user certificates »

Importez le ca.crt précédemment généré dans la partie « Trusted Root Certification Authorities\Certificates »

 

Création du certificat Client

Toujours à partir du serveur Active Directory, créer un fichier, dans notre exemple il porte le nom request.inf. En rouge, j’ai apporté les modifications par rapport à la procédure initiale afin d’y ajouter les informations SAN. Attention à bien mettre dans CN le FQDN du serveur AD.

Les valeurs de _continue_= « dns » et _continue_= « ip-address » correspondent aux valeurs SAN, les autres valeurs possibles pour référencer le serveur AD.

[Version]
Signature=”$Windows NT$”

[NewRequest]
Subject = “CN=ad-server.cpod-velocity.az-fkd.cloud-garage.net
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = “Microsoft RSA SChannel Cryptographic Provider”
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1 ; Server Authentication

[Extensions]
; SANs can be included in the Extensions section by using the following text format. Note 2.5.29.17 is the OID for a SAN extension.
2.5.29.17 = “{text}”
_continue_ = “dns=ad-server&”
_continue_ = “dns=ad-server.cpod-velocity.az-fkd.cloud-garage.net&”
_continue_ = “dns=cloud-garage.net&”
_continue_ = “ipaddress=172.17.13.9&”

 

Générer le fichier client.csr avec la commande ci-dessous

c:\> certreq -new request.inf client.csr

A partir de la machine Linux :

Créer un fichier d’extension, dans notre exemple, il porte le nom de v3ext.txt. En rouge, j’ai apporté les modifications par rapport à la procédure initiale afin d’y ajouter les informations SAN sous la rubrique v3_ca qui sera référencé dans la prochaine commande.

keyUsage=digitalSignature,keyEncipherment
extendedKeyUsage=serverAuth
subjectKeyIdentifier=hash

 # These extensions are added when ‘ca’ signs a request.
[ v3_ca ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = ad-server.cpod-velocity.az-fkd.cloud-garage.net
DNS.2 = ad-server
IP.1 = 172.17.13.9

Toujours à partir de la machine Linux, créer le certificat client.crt à partir des fichiers générés dans les étapes précédentes ca.crt, ca.key, client.csr et v3ext.txt en rouge ce qui a été rajouté par rapport à la commande issue de la procédure initiale

$ openssl x509 -req -days 3650 -in client.csr -CA ca.crt -CAkey ca.key -extfile v3ext.txt -set_serial 01 -out client.crt -extensions v3_ca

 

Pour vérifier la présence des informations SAN

$ openssl x509 -in client.crt -text
 …..
X509v3 extensions:
      X509v3 Subject Alternative Name:
          DNS:ad-server.cpod-velocity.az-fkd.cloud-garage.net, DNS:ad-server, IP Address:172.17.13.9

 

Importer le certificat Client

A partir du serveur AD

C:\> certreq -accept client.crt

Le certificat devrait ainsi apparaître dans « Personal\Certificates »

Pour que le certificat soit pris en compte, il faut soit redémarrer le serveur AD ou forcer LDAPS à charger le certificat avec la procédure ci-dessous :

Toujours à partir du serveur AD, créer un fichier text, dans notre exemple il se nome ldap-renewservercert.txt avec le contenu ci-dessous (attention la fin du fichier comprend une ligne avec un – (un tiret) :

dn:
changetype: modify
add: renewServerCertificate
renewServerCertificate: 1

Puis tappez la commande ci-dessous :

c:\> ldifde -i -f ldap-renewservercert.txt

Pour tester la prise en compte

Utilisez l’utilitaire ldp.exe en sélectionnant le port 636 (ou un autre s’il est spécifique) et en cochant la case SSL.

Une fois toute la procédure effectuée, il faut récupérer le ca.crt généré à la première étape pour le donner à Pinniped. Cela peut se faire soit au moment de la création du cluster de management TKG ou soit à postériori.

Si le cluster de management n’a pas encore était créé :

$ tanzu management-cluster create –ui
(il y a deux tirets avant l’argument ui mais WordPress n’en n’affiche qu’un seul)

Dans mon test j’ai choisi vSphere comme plate-forme, à l’étape identity manager il faudra copier le certificat dans la partie ROOT CA

 

Si le cluster de management TKG a déjà était créé et que vous souhaitez le mettre à jour :

A partir du contexte Kubernetes du cluster de manager, chiffrez le certificat Root du serveur AD avec la commande base64 et récupérez le résultat :

$ base64 -w 0 ca.crt

Modifier le certificat dans la configmap dex par le résultat de la commande précédente :

$ kubectl edit configmap -n tanzu-system-auth dex
# Please edit the object below. Lines beginning with a ‘#’ will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
  config.yaml: |
    issuer: https://172.17.13.10:30167
    frontend:
        theme: tkg
    web:
        https: 0.0.0.0:5556
        tlsCert: /etc/dex/tls/tls.crt
        tlsKey: /etc/dex/tls/tls.key
    expiry:
        signingKeys: 90m
        idTokens: 5m
    logger:
        level: info
        format: json
    staticClients:
        – id: pinniped-client-id
          name: pinniped-client-id
          redirectURIs:
            – https://172.17.13.10:31234/callback
          secret: 089db7e23b19cb628ba841b17cc32ea4
    connectors:
        – type: ldap
          id: ldap
          name: LDAP
          config:
            host: ad-server.cpod-velocity.az-fkd.cloud-garage.net:636
            insecureSkipVerify: false
bindDN: cn=administrator,cn=Users,dc=velocity,dc=local
            bindPW: $BIND_PW_ENV_VAR
            usernamePrompt: LDAP Username
            rootCAData:
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUdQekNDQkNlZ0F3SUJBZ0lVU2tQd0JPazVYRVFLRlpydXdwZXBoeTlINndzd0RRWUpLb1pJaHZjTkFRRUwKQlFBd2dhNHhDek
KQmdOVkJBWVRBa1pTTVF3d0NnWURWUVFJREFOSlJFWXhEakFNQmdOVkJBY01CVkJoY21segpNUlF3RWdZRFZRUUtEQXRNYjJWcGJDMWtkUzFUUlRFTE1Ba0dBMVVFQ3d3Q1UwVXhPRE
EyQmdOVkJBTU1MMkZrCkxYTmxjblpsY2k1amNHOWtMWFpsYkc5amFYUjVMbUY2TFdaclpDNWpiRzkxWkMxbllYSmhaMlV1Ym1WME1TUXcKSWdZSktvWklodmNOQVFrQkZoVm1ZbVZ1Y
21WcVpHRnNRSFp0ZDJGeVpTNWpiMjB3SGhjTk1qRXdOekEzTURjeQpNekl5V2hjTk16RXdOekExTURjeU16SXlXakNCcmpFTE1Ba0dBMVVFQmhNQ1JsSXhEREFLQmdOVkJBZ01BMGxFClJqRU9NQXdHQTFVRUJ3d0ZVR0Z5YVhNeEZEQVNCZ05WQkFvTUMweHZaV2xzTFdSMUxWTkZNUXN3Q1FZRFZRUUwKREFKVFJURTRNRFlHQTFVRUF3d3ZZV1F0YzJWeWRtVnlMbU53YjJ
RdGRtVnNiMk5wZEhrdVlYb3RabXRrTG1OcwpiM1ZrTFdkaGNtRm5aUzV1WlhReEpEQWlCZ2txaGtpRzl3MEJDUUVXRldaaVpXNXlaV3BrWVd4QWRtMTNZWEpsCkxtTnZiVENDQWlJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dJUEFEQ0NBZ29DZ2dJQkFMaWx0WE81WkxNOFRzZ0YKMXFxRFFURi9xV1EzTGkvalU2ZFJqM1VMLys2YitRL0VUVjdIb2VLMi9hK09UdHlRbzY4c
k9ySTVJRjNNWlJqKwpzU0JuWC9SejczczYvVjArWXhJTFozSmNNenlWUzZtR1ZhNTZBTmFZRFRqSkErUzF5enZJczFpZXdMWDR2YlFzCnJRdFE2NVphb3NYbFlMSWpxdzZCY01TZUlX
NUlUWitlUVF3emlkN2t5ZFBYNDdTBSSm1vR…..1
            ….

Relancer le pod dex dans le namespace tanzu-system-auth pour qu’il prenne en compte la modification.

 

Une fois le cluster de management avec le bon certificat

A partir de là, créer un cluster de workload :

$ tanzu cluster create my-cluster -f <fichier-environnement>

Importer le Kubeconfig d’administration du cluster de workload créé :

$ tanzu cluster kubeconfig get my-cluster –admin
(il y a deux tirets avant l’argument admin mais WordPress n’en n’affiche qu’un seul)

Se connecter au cluster de workload avec le context admin, en tant qu’admin pas besoin de compte :

$ kubectl use-context my-cluster-admin@my-cluster

Créer un cluster rôle binding avec le rôle qui vous intéresse (ici cluster-admin) pour les utilisateurs souhaités, ça permettra à l’utilisateur d’utiliser ce cluster une fois authentifié :

$ kubectl create clusterrolebinding admin-fbenrejdal  –clusterrole cluster-admin –user fbe@velocity.local
(il y a deux tirets avant les arguments clusterrole et user mais WordPress n’en n’affiche qu’un seul)

Exporter le kubeconfig du cluster de workload, c’est ce kubeconfig qu’il faudra transmettre aux utilisateurs, il n’a pas de context admin et demandera à l’utilisateur une authentification. L’utilisateur consommera ce cluster en fonction des droits définis dans clusterrolebinding de l’étape précédente :

$ tanzu cluster kubeconfig get my-cluster –export-file my-cluster-kubeconfig
(il y a deux tirets avant l’argument export mais WordPress n’en n’affiche qu’un seul)

Lancez une commande kubernetes avec le fichier kubeconfig généré, ce qui lancera le navigateur pour permettre l’authtentification :

$ kubectl get pods -A –kubeconfig my-cluster-kubeconfig
(il y a deux tirets avant l’argument kubeconfig mais WordPress n’en n’affiche qu’un seul)

Vous devriez être redirigé vers un navigateur avec une page web vous demandant votre nom d’utilisateur et votre mot de passe :

Une fois saisies, vous obtiendrez le résultat de votre dernière commande :

Le résultat de la commande précédemment passée devrait s’afficher :


NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system antrea-agent-q9xpg 2/2 Running 0 7d15h
kube-system antrea-agent-qlmj8 2/2 Running 0 7d15h
kube-system antrea-controller-6bb57bd84-6cj58 1/1 Running 0 7d15h
kube-system coredns-68d49685bd-bjcps 1/1 Running 0 7d15h
kube-system coredns-68d49685bd-vttdw 1/1 Running 0 7d15h
kube-system etcd-my-cluster-control-plane-48n9f 1/1 Running 0 7d15h
kube-system kube-apiserver-my-cluster-control-plane-48n9f 1/1 Running 0 7d15h
kube-system kube-controller-manager-my-cluster-control-plane-48n9f 1/1 Running 0 7d15h
kube-system kube-proxy-dntrc 1/1 Running 0 7d15h
kube-system kube-proxy-k5m9g 1/1 Running 0 7d15h
kube-system kube-scheduler-my-cluster-control-plane-48n9f 1/1 Running 0 7d15h
kube-system kube-vip-my-cluster-control-plane-48n9f 1/1 Running 0 7d15h
kube-system metrics-server-66cb4fb659-xlprc 1/1 Running 0 7d15h
kube-system vsphere-cloud-controller-manager-vmfwl 1/1 Running 1 7d15h
kube-system vsphere-csi-controller-bd8b6cc8c-8ljl8 6/6 Running 0 7d15h
kube-system vsphere-csi-node-6xqf5 3/3 Running 0 7d15h
kube-system vsphere-csi-node-vmbmq 3/3 Running 0 7d15h
pinniped-concierge pinniped-concierge-dcd587f97-lk9n5 1/1 Running 0 7d15h
pinniped-concierge pinniped-concierge-dcd587f97-zrnb7 1/1 Running 0 7d15h
pinniped-concierge pinniped-concierge-kube-cert-agent-8a8e3e38 1/1 Running 0 7d15h
pinniped-supervisor pinniped-post-deploy-job-4ldt7 0/1 Completed 0 7d15h
pinniped-supervisor pinniped-post-deploy-job-m74gz 0/1 Error 0 7d15h
tkg-system kapp-controller-69c4d4bbb4-kwk5l 1/1 Running 0 7d15h

Personnaliser une VM Ubuntu avec Cloud-Init sur vSphere

Cloud-Init semble être l’outil de personnalisation de prédilection pour les OS majeurs visant à être installer sur différents environnement cloud (AWS, Azure, GCP, vSphere, …), il est très puissant, hétérogène mais au début, il est difficile à appréhender.

Les informations de personnalisation sont stockées dans un fichier appelé user-data. Ce fichier est transmis à Cloud-Init grâce à un mécanisme propre à chaque cloud. Dans notre cas, ce sont les VMtools qui vont transmettre le fichier user-data, une fois reçu, Cloud-Init l’exécutera.

J’ai perdu énormément de temps à trouver les étapes minimales pour personnaliser l’OS Ubuntu avec Cloud-Init dans un environnement vSphere. Je recherchais la possibilité de personnaliser l’OS lors des clones à partir de template OVF.

Ci-dessous la procédure que j’utilise pour un Ubuntu 20.04.2 LTS, fraîchement installé et après son premier reboot. J’ai gardé les valeurs par défaut hormis le clavier Français et l’installation de l’option OpenSSH server.

Il faut dire à Cloud-Init de récupérer le fichier de personnalisation user-data via les paramètres OVF de la VM, il y a une étape à faire coté VM et une coté OS.

 

Coté OS :

  • Supprimer le fichier qui met la Datasource à none au lieu d’OVF
    • sudo rm /etc/cloud/cloud.cfg.d/99-installer.cfg
  • Si vous souhaitez que la configuration réseau se fasse, supprimer le fichier qui la désactive
    • sudo rm /etc/cloud/cloud.cfg.d/subiquity-disable-cloudinit-networking.cfg
  • Si vous êtes en DHCP, la VM récupérera toujours la même IP car elle gardera le même machine ID. Pour éviter cela il faut remettre à zéro l’identité de l’OS :
    • sudo truncate -s 0 /etc/machine-id

 

Coté VM :

  • Récupérer le contenu de votre fichier cloud-init user-data et le codé avec base64 :
    • Base64 user-data.yaml
  • A partir du vSphere client, lorsque la VM est arrêtée, Activer les propriétés de l’OVF :
    • Sélectionnez la VM => Configure => vApp Options => vApp Options are disabled … Edit => Cliquer sur “Enable vApp options”
    • Dans l’onglet OVF details => => sélectionner la case VMware Tools
  • A partir du vSphere client, lorsque la VM est arrêtée, ajouter le champ user-data dans les propriétés de l’OVF :
    • => Sélectionnez la VM => Configure => vApp Options => Properties => ADD mettre le Label et Key id  à la valeur user-data.
  • A partir du vSphere client, lorsque la VM est arrêtée, ajouter la valeur au champ user-data dans les propriétés de l’OVF :
    • Sélectionnez la VM => Configure => vApp Options => Properties => SET VALUE, un popup s’ouvre et mettre la clé base64 du contenu du fichier user-data récupérée un peu plus haut

 

 

Maintenant à partir de cette VM, faite directement un clone pour en faire une autre VM ou pour en faire un template. Si vous souhaitez changer le fichier user-data, au moment du déploiement de la VM, changez uniquement la clé base64 par la nouvelle clé.

 

 

Etapes pour la création de VM via kubectl

Pour créer une machine virtuelle avec vSphere with Tanzu via la commande kubectl, il y a des étapes à respecter pour l’administrateur et pour le développeur, elles sont très simples mais ce ne m’a pas empêché de perdre un peu de temps coté personnalisation sur la partie OS.

je vous recommande cet article pour comprendre l’intéret de déployer des VM via Kubernetes : Déployer des VMs dans et via Kubernetes. Le blog de mon collègue : Introducing Virtual Machine Provisioning, via Kubernetes with VM Service | VMware est aussi très bien détaillé.

Dans la dernière partie cet article, je vais apporter quelques précisions sur la partie Content Library et sur la partie YAML. Mais d’abord, revoyons avant les partie à faire coté administrateur et coté développeur

 

Concernant l’administrateur

La première étape consiste à télécharger les images VMs qui sont différentes de celles utilisées pour TKC (Tanzu Kubernetes Cluster aussi appelé Guest Cluster). Les images sont disponibles dans la marketplace VMware, au moment de la rédaction de cet article, il y en a 2 (Ubuntu et Centos), la version Ubuntu actuelle ne permet pas l’utilisation de volume persistent (PVC) car elle est basée sur une version virtual hardware 10 et il faut au minimum une version 12, ce problème va bientôt être corrigé.

Il faut aller sur la marketplace et faire une recherche avec le mot clé « vm service », ça permet de filtrer (un peu) les images compatibles => VMware Marketplace.

Ensuite cliquer sur l’image souhaitée, se connecter avec son compte MyVMware.

Vous avez deux possibilités, la télécharger puis la charger dans une content library locale

ou récupérer l’url de souscription pour créer une content library qui se synchronisera à celle hébergée par VMware.

Une fois l’image chargée ou le lien renseigné, vous devriez avoir une content library de ce type :

Toujours depuis l’interface vSphere, il faut maintenant créer, un namespace, octroyer les droits aux utilisateurs pour qu’ils puissent s’y connecter, affecter la classe de VM, la content library et la classe de stockage, ce qui devrait donner ceci :

 

L’exemple ci-dessus montre une fois le namespace créé, comment affecter une classe de VM, une content library, autoriser les développeurs qui pourront consommer ce namespace, quelle classe de stockage à utiliser et enfin si besoin caper les ressource, CPU, mémoire et stockage.

C’est tout ce qu’il y a à faire coté administrateur d’infrastructure.

 

Concernant le développeur

Il faut un descriptif YAML pour :

  • La configmap qui contient la personnalisation de la VM
  • La création de la VM
  • Le service réseau si vous souhaitez vous y connecter à partir d’un réseau extérieur (optionnel)
  • Le PVC si vous souhaitez utiliser des volumes persistants (optionnel)

Via la commande Kubernetes, le développeur se connecte avec son compte au Namespace fourni, il pourra ainsi lister les classes de services qu’il peut utiliser ainsi que les images qu’il pourra déployer.

kubectl get virtualmachineclass

NAME                  CPU   MEMORY   AGE
best-effort-2xlarge   8     64Gi     22d
best-effort-4xlarge   16    128Gi    22d
best-effort-8xlarge   32    128Gi    22d
best-effort-large     4     16Gi     22d
best-effort-medium    2     8Gi      31d
best-effort-small     2     4Gi      31d
best-effort-xlarge    4     32Gi     22d
best-effort-xsmall    2     2Gi      22d
..
guaranteed-xsmall     2     2Gi      22d

 

kubectl get virtualmachineimage
NAME                                                         VERSION                           OSTYPE                FORMAT   AGE
centos-stream-8-vmservice-v1alpha1-1619529007339                                               centos8_64Guest       ovf      4h8m
ob-15957779-photon-3-k8s-v1.16.8—vmware.1-tkg.3.60d2ffd    v1.16.8+vmware.1-tkg.3.60d2ffd    vmwarePhoton64Guest   ovf      2d19h
ob-16466772-photon-3-k8s-v1.17.7—vmware.1-tkg.1.154236c    v1.17.7+vmware.1-tkg.1.154236c    vmwarePhoton64Guest   ovf      2d19h
ob-16545581-photon-3-k8s-v1.16.12—vmware.1-tkg.1.da7afe7   v1.16.12+vmware.1-tkg.1.da7afe7   vmwarePhoton64Guest   ovf      2d19h
……
ubuntu-20-1621373774638                                                                        ubuntu64Guest         ovf      4h8m

Il peut ainsi créer ses fichiers descriptifs YAML afin de définir ses besoins en ressources pour sa ou ses machines virtuelles et s’ils le souhaitent, il peut la ou les personnaliser afin d’y installer ses outils.

Le fichier descriptif configmap, comprend la personnalisation de la VM. Les 3 champs importants à renseigner pour la personnalisation sont :

  1. Le hostname qui contient le hostname de l’OS
  2. La public-keys, qui contient la clé publique d’un poste à partir duquel on se connectera à l’os en ssh.
  3. La partie user-data est, si vous le souhaitez, l’endroit où on met le contenu du fichier de configuration Cloud Init, il faudra le chiffrer avec la commande base64.

 

cat loeil-du-se-vm-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
    name: loeil-du-se-vm-configmap # Le nom de la ConfigMap, doit être le même que celui référencé dans le YAML de la VirtualMachine
    namespace: loeil-du-se
data:
  # Champs OVF utilisés lors du déploiment de la VM
  hostname: loeil-du-se
  public-keys: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDC4Cclh3rN/l70lBNlwQyK6ZtugxqT/7HeerHZKPSO0hcl5ZWLvz2+7QG5FqvYbkPP6EomvyDhE2MPnQ0kWaIrumVxYXAbVdpBBKKdTI3xJpewWB2syxgVOXP2ZOrw4cRLFv18rnESGHfsohedyaSB1qvubPWAqBFa+PSS4xh3zKalUknwc7Bs14fci8tEwEg8cpvNsqvrPZliJ6qTYFGqKuG6Ct+y449JNW6k6itTepgSYvUdJfjBTxk5tDzBdWz28km5N7lxgUB0rIWgSDl1XLCBrmm+H6bkHtD59MxAuxwLjih4tS4PzspcVjwWiJhd0HH7u2wbsPLCrrAX7am4EP40zphu9IR+fVxk+2jp7eD2uXPS6p9sDPEWHl6wGclI7pnfuoyvcn+CIwCtMweLuUw5MPj2eIIXcBhqUffeVAXVHrx8+e7+yHvqfyhqm2J9Ay3yt3zvAcXW0VqDxfvnfmv8sc9VNUW+8fUeyoo4b4uZRLLSf2DHM8= root@fbenrejdal-z01 # Clé publique SSH du poste permettant de se connecter sans mot de passe à l’OS de la VM
  user-data: | # optionel, le contenu chiffré en base64 du fichier Cloud Init. La clé peut être sur une seule ligne ou sur plusieurs, elle doit démarrer au niveau du “r” sous user-data
     I2Nsb3VkLWNvbmZpZwojIFdBVENIT1VUIHRoZSBmaXJzdCBsaW5lIG11c3Qgc3RhcnQgd2l0aCAj
     Y2xvdWQtY29uZmlnCmdyb3VwczoKICAtIGRldm9wcwp1c2VyczoKICAtIGRlZmF1bHQgIyBDcmVh
     dGUgdGhlIGRlZmF1bHQgdXNlciBmb3IgdGhlIE9TCiAgLSBuYW1lOiBmYmUKICAgIHNzaC1hdXRo
     b3JpemVkLWtleXM6ICMgdGhlIHB1YmxpYyBrZXkgb2YgbXkgbGFwdG9wLCBpdCBjb3VsZCBhbHNv
     IGJlIGZpbGxlZCBpbiB0aGUgT1ZGIHByb3BlcnR5CiAgICAgIC0gc3NoLXJzYSBBQUFBQjNOemFD
     MXljMkVBQUFBREFRQUJBQUFCZ1FEQzRDY2xoM3JOL2w3MGxCTmx3UXlLNlp0dWd4cVRHLzdIZWVy
     SFpLUFNPMGhjbDVaV0x2ejIrN1FHNUZxdllia1BQNkVvbXZ5RGhFMk1QblEwa1dhSXJ1bVZ4WVhB
     YlZkcEJCS0tkVEkzeEpwZXdXL0Iyc3l4Z1ZPWFAyWk9ydzRjUkxGdjE4cm5FU0dIZisvc29oZWR5
     YVNCMXF2dWJQV0FxQkZhK1BTUzR4aDZELzN6S2FsVWtud2M3QnMxNGZjaTh0RXdFZzhjcHZOc3F2
     clBabGlKNnFUWUZHcUt1RzZDdCt5NDQ5Sk5XNms2aXRUZXBnU1l2VWRKZmpCVHhrNXREekJkV3oy
     OGttNU43bHhnVUIwcklXZ1NEbDFYTENCcm1tK0g2YmtIdEQ1OU14QXV4d0xqaWg0dFM0UHpzcGNW
     dGFydCBtb25nb2QK

 

La base64 est obtenu de la manière suivante :
base64  loeil-du-se-vm-cloud-init.yaml

Son contenu en clair :
cat  loeil-du-se-vm-cloud-init.yaml
#cloud-config
# ATTENTION la première ligne doit commencer par #cloud-config
groups:
  – devops
users:
  – default # Créé l’utisateur par défaut
  – name: fbe
  ssh-authorized-keys: # Clé SSH de mon laptop me permettant de me connecter via SSH sans mot de passe. Clé déjà renseignée dans la configmap
    – ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDC4Cclh3rN/l70lBNlwQyK6ZtugxqTG7HeerHZKPSO0hcl5ZWLvz2+7QG5FqvYbkPP6EomvyDhE2MPnQ0kWaIrumVxYXAbVdpBBKKdTI3xJpewWB2syxgVOXP2ZOrw4cRLFv18rnESGHf+sohedyaSB1qvubPWAqBFa+PSS4xh6D3zKalUknwc7Bs14fci8tEwEg8cpvNsqvrPZliJ6qTYFGqKuG6Ct+y449JNW6k6itTepgSYvUdJfjBTxk5tDzBdWz28km5N7lxgUB0rIWgSDl1XLCBrmm+H6bkHtD59MxAuxwLjih4tS4PzspcVjwWiJhd0HH7u2wbsPLCrrAX7am4EP40zphu9IR+fVxk+2jp7eD2uXPS6p9sDPEWHl6wGclI7pnfuoyvcn+CIwCtMweLuUw5MPj2eIIXcBhqUffeVAXVHrx8+e7+yHvqfyhqm2J9Ay3yt3zvAcXW0VqDxfvnfmv8sc9VNUW+8fUeyoo4b4uZRLLSf2DHM8= root@fbenrejdal-z01
      groups: sudo, devops
    shell: /bin/bash
    passwd: VMware1!
    sudo: [‘ALL=(ALL) NOPASSWD:ALL’] # l’utilisateur fbe n’aura pas à rentrer de mot de passe avec la commande sudo
  ssh_pwauth: true
  chpasswd:
  list: |
    fbe:VMware1! # changer le mot de passe de l’utilisateur fbe
    expire: false  # Pour que le mot de passe n’expire pas
runcmd: # Exemple de runcmd pour installer MongoDB. Cloud Init est aussi capable d’utiliser directement APT pour faire des installations
  – echo “deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/4.4 multiverse” | tee /etc/apt/sources.list.d/mongodb-org-4.4.list
  – wget -qO – https://www.mongodb.org/static/pgp/server-4.4.asc | apt-key add –
  – echo “deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/4.4 multiverse” | tee /etc/apt/sources.list.d/mongodb-org-4.4.list
  – apt-get update
  – apt-get install -y mongodb-org
  – echo “mongodb-org hold” | dpkg –set-selections
  – echo “mongodb-org-server hold” | dpkg –set-selections
  – echo “mongodb-org-shell hold” | dpkg –set-selections
  – echo “mongodb-org-mongos hold” | dpkg –set-selections
  – echo “mongodb-org-tools hold” | dpkg –set-selections
  – sed -i ‘s/127.0.0.1/0.0.0.0/’ /etc/mongod.conf
  – ufw allow from any to any port 27017 proto tcp
  – sleep 2
  – systemctl start mongod

Très très important, le fichier doit absolument commencer par #cloud-config et pas autre chose. Ça reste un fichier Cloud Init classique.

Si vous ne maitrisez pas trop Cloud Init, j’y ai mis des commentaires pour que ce soit un peu plus lisible.

 

Le fichier descriptif de la VM

cat loeil-du-se-vm-deployment.yaml
apiVersion: vmoperator.vmware.com/v1alpha1
kind: VirtualMachine
metadata:
  name: loeil-du-se-vm
  namespace: loeil-du-se
labels:
  vm: loeil-du-se-vm
spec:
  imageName: ubuntu-20-1621373774638 #L’image doit être présente dans la content library et visible via la commande kubectl get virtualmachineimage
  className: best-effort-xsmall
  powerState: poweredOn
  storageClass: silver-storage-policy
  networkInterfaces:
  – networkType: nsx-t # soit nsx-t ou vsphere-distributed en fonction de votre installation
# networkName:
si -networkType est vsphere-distributed il faut mettre le nom du port group des workload
  vmMetadata:
    configMapName: loeil-du-se-vm-configmap # Nom de la configmap où la personnalisation de la VM est stockée
    transport: OvfEnv
#
#  Au moment de l’écriture de cet article l’image ubuntu (ubuntu-20-1621373774638) ne peut pas utiliser les volumes car elle est basée sur la version 10 du virtual hardware est il faut au minimum qu’elle soit en 12
#  L’image centos image (centos-stream-8-vmservice-v1alpha1-1619529007339) peut utiliser des volumes
#  volumes: # au moment de l’écriture de cet article, le paramètre mount n’est pas utilisable, le volume est vu mais doit être monté à la main ou via Cloud Init
#    – name: loeil-du-se-volume
#      persistentVolumeClaim:
#      claimName: loeil-du-se-pvc
#      readOnly: false

 

Optionnel, le fichier descriptif du service réseau

Dans mon exemple, je créé un service de type LoadBalancer pour me connecter en ssh à partir d’un réseau externe à celui des PODs.

Attention, le kind n’est pas Service comme habituellement mais VirtualMachineService

cat loeil-du-se-vm-service.yaml
apiVersion: vmoperator.vmware.com/v1alpha1
kind: VirtualMachineService
metadata:
  name: loeil-du-se-vm
spec:
  selector:
    vm: loeil-du-se-vm
  type: LoadBalancer
  ports:
    – name: ssh
      port: 22
      protocol: TCP
      targetPort: 22

 

Une fois les fichiers YAML créés, il ne reste plus qu’à les faire prendre en compte par Kubernetes.

Kubectl create -f loeil-du-se-vm-configmap.yaml

Kubectl create -f loeil-du-se-vm-deployment.yaml

Kubectl create -f loeil-du-se-vm-service.yaml

 

Pour verifier la creation de la VM :

Kubectl get vm

 

Pour en savoir un peu plus :

Kubectl describe vm loeil-du-se-vm

 

Ca reste une VM classique, donc elle va bénéficier de HA et vMotion (via DRS ou mode maintenance du host). Par contre, elle est « Developer Managed », c’est-à-dire qu’elle n’est pas administrable via le vCenter, vous ne verrez pas par exemple le contenu de la console.

Une astuce tout de même, vérifiez sur quel ESXi la VM s’exécute, ensuite connectez-vous directement sur l’ESXi via un navigateur et là vous aurez accès à la console.

Pour se connecter en ssh, si vous avez comme moi un accès via un loadbalancer vous pouvez vous y connecter directement, sinon vous devrez passer par un POD de rebond (genre busybox, alpine ou autre) et faire un ssh avec l’adresse IP sur le réseau de POD. Vous pouvez la retrouver ainsi :

kubectl get vm loeil-du-se-vm -o jsonpath='{.status.vmIp}’; echo
10.244.0.130

 

Le ssh doit se faire via le user renseigné dans le Cloud Init, j’avais mis fbe, ca donne ça :

kubectl get svc loeil-du-se-vm
NAME             TYPE           CLUSTER-IP    EXTERNAL-IP    PORT(S)        AGE
loeil-du-se-vm   LoadBalancer   10.96.1.108   172.20.18.71   22:32148/TCP   2d22h

ssh fbe@172.20.18.71

To run a command as administrator (user “root”), use “sudo <command>”.
See “man sudo_root” for details.
fbe@loeil-du-se:~$

 

Si le ssh ne fonctionne pas, c’est que le user n’a pas était pris en compte par Cloud Init, essayez avec root pour obtenir le user par défaut, en générale ubuntu pour Ubuntu et cloud-user pour CentOS :

ssh roo@172.20.18.71
Please login as the user “ubuntu” rather than the user “root”.

 

Si vous avez l’erreur ci-dessous, c’est que le poste à partir duquel vous vous connectez n’a pas la clé ssh publique renseignée ou il y a une erreur dans celle-ci, il faut donc vérifier la clé figurant dans le fichier de configmap :

fbe@172.20.18.71: Permission denied (publickey,password).

Pour debugger Cloud Init, il faut se connecter à l’os de la vm via ssh ou via la console est regardez la log /var/log/cloud-init-output.log

Voilà, n’hésitez pas à me pinger si vous avez besoin d’informations complémentaires.

Déployer Kubeapps pour un usage multi-clusters

 

Dans cet article nous allons voir comment déployer Kubeapps en environnement multi-cluster. Habituellement il se déployait cluster par cluster, ici, l’objectif est d’avoir une seule instance Kubeapps capable de déployer et de gérer les applications sur plusieurs clusters. Pour cela, il faut que chaque cluster soit capable de s’authentifier à une source IdP (Identity Provider).

Dans mon exemple je vais utiliser des clusters TKG 1.2.1 avec l’extension incluse Dex. Dex va permettre l’authentification avec un provider OpenID Connect (OIDC).  Pour info, dans notre exemple l’extension Gangway qui normalement va de pair avec Dex n’est pas utile. Elle sert à générer un Kubeconfig une fois que l’utilisateur s’est authentifié via la page web du cluster. Kubeapps n’a pas besoin de cette extension car il utilise un proxy Oauth2. Sur mon environnement, je vais utiliser des clusters existant qui sont déjà configurés avec l’extension Gangway et 1 que je vais créer sans installer Gangway (2 clusters auraient pu suffire mais c’est tellement simple à déployer avec TKG qu’on ne va pas se priver).

Étape primordiale, c’est d’ avoir l’extension Dex d’installée sur le cluster de management et le configurer pour qu’il puisse faire des requêtes sur une source IdP : https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.2/vmware-tanzu-kubernetes-grid-12/GUID-extensions-dex.html. Une fois Dex installé, il faut créer des clusters de workload compatibles OIDC et déployer Kubeapps sur un cluster de préférence distinct (ou commencer par installer Kubeapps et le mettre à jour pour qu’il prenne en compte les nouveaux clusters).

Exporter les variables sur l’environnement du cluster DEX :

export AUTH_MGMT_CLUSTER=”auth-mgmt-cluster-admin@auth-mgmt-cluster” # nom de mon cluster de management
export OIDC_ISSUER_URL=https://172.20.7.10:30167 #IP et Port de mon cluster de management où est installé DEX
export OIDC_USERNAME_CLAIM=email
export OIDC_GROUPS_CLAIM=groups
export OIDC_DEX_CA=$(kubectl get secret dex-cert-tls -n tanzu-system-auth -o ‘go-template={{ index .data “ca.crt” }}’ –context $AUTH_MGMT_CLUSTER| base64 -d | gzip | base64) # certificat du cluster de management

Créer ensuite les clusters de workloads :

tkg create cluster usine-32 –enable-cluster-options oidc –plan dev –vsphere-controlplane-endpoint 172.20.7.17

Logs of the command execution can also be found at: /tmp/tkg-20210106T094128013610360.log
Validating configuration…
Creating workload cluster ‘usine-32’…
Waiting for cluster to be initialized…
Waiting for cluster nodes to be available…
Waiting for addons installation…
Workload cluster ‘usine-32’ created

 

Récupérer le context du cluster pour qu’il soit intégré dans le kubeconfig et ainsi récupérer l’url de l’API server: et le certificat certificateAuthorityData:

tkg get credentials usine-32
Credentials of workload cluster ‘usine-32’ have been saved
You can now access the cluster by running ‘kubectl config use-context usine-32-admin@usine-32’

 

Se connecter au cluster afin d’autoriser les utilisateurs à s’y connecter et de déployer des applications :

kubectl config use-context usine-32-admin@usine-32

cat << EOF | kubectl apply –
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tkg-users
subjects:
  – kind: Group          # Donner le rôle au groupe, mettre User si vous souhaitez cibler un user en particulier
    name: tkg-users # Mettre le nom du groupe, tous les utilisateurs du groupe seront pris en compte
    apiGroup: “”
roleRef:
  kind: ClusterRole #this must be Role or ClusterRole
  name: cluster-admin # ClusterRole à avoir
  apiGroup: rbac.authorization.k8s.io
EOF

 

Une fois le cluster créé, les droits d’accès positionnés, l’url et le certificat récupérés (si besoin, reproduire les mêmes étapes pour d’autres clusters de workload), il reste deux fichiers à modifier, l’un concerne le fichier de valeurs de l’installation de Kubeapps et l’autre le fichier de configuration DEX.

Modification du fichier de valeurs pour l’installation de Kubeapps (Exemple provenant de mon collègue Michael Nelson : https://liveandletlearn.net/post/kubeapps-on-tkg-management-cluster/) :

# Dans mon exemple Kubeapps est accessible au travers d’un LoadBalancer
frontend:
  service:
    port: 80
    type: LoadBalancer
# Setup the oauth2-proxy running on the frontend to handle the OIDC authentication
authProxy:
  enabled: true
  provider: oidc
  clientID: auth-tools
  ## les deux Secrets ci-dessous sont à générer par vous-même (32 octets max)
  clientSecret: wPmp8+IrTxbGZbVF/yqPPeP4XZzw5mLt
  cookieSecret: fiUrXyEBQx7uWlcw55CxQkbYwZ4a/cC7
  additionalFlags:
    # C’est l’adresse IP et le port de DEX qui est installé sur le cluster de management
    – –oidc-issuer-url=https://172.20.7.10:30167
    # les clusters derrières le mot audience sont les clusters sur lesquels les déploiements seront autorisés, ils doivent aussi figurer en bas de ce fichier et dans le fichier de configuration Dex
    – –scope=openid email groups audience:server:client_id:workload-01 audience:server:client_id:workload-02 audience:server:client_id:usine-01 audience:server:client_id:usine-32
    # Comme j’ai des certificats autosignés, il ne faut pas les vérifier auprès d’une autorité
    – –ssl-insecure-skip-verify=true
    # Since Kubeapps is running without TLS, can’t use secure cookies
    – –cookie-secure=false
    # If you need to access the actual token in the frontend for testing, uncomment the following.
    # – –set-authorization-header=true
# Liste des clusters sur lesquels les déploiements seront autorisés, les mêmes renseignés un peu plus haut
# L’apiServiceURL et le certificateAuthorityData sont ceux récupérés dans le fichier kubeconfig un peu plus haut
# dans mon exemple j’ai 4 clusters de workload
clusters:
  – name: workload-01
  apiServiceURL: https://172.20.7.14:6443
  certificateAuthorityData: USUZJQ0FURS0tQkFRc0ZBREFWTVJNd0……..E9KOFhFQUI1aVBqVDQxWXZzeEE9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
  – name: workload-02
  apiServiceURL: https://172.20.7.15:6443
  certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FBREFWTVJNd0…….wS1V1UUgvcCtjMWkvYW89Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
  – name: usine-01
  apiServiceURL: https://172.20.7.16:6443
  certificateAuthorityData: LS0TkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0….Es2RWpSNys2NkNlT2dpeHcxVUk9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
  – name: usine-32
  apiServiceURL: https://172.20.7.17:6443
  certificateAuthorityData: BTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0…cldORUNGb3FJelZkdXdKRGNFMTA9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K

 

Maintenant, on peut installer Kubeapps dans un namespace avec comme paramètre ce fichier de valeurs (ici, je l’ai appelé kubeapps-dex.yaml) :

kubectl create namespace kubeapps-system
helm install kubeapps bitnami/kubeapps –namespace kubeapps-system –values kubeapps-dex.yaml

Si vous êtes amené à modifier le fichier de configuration comme par exemple pour ajouter un autre cluster, vous pouvez utiliser cette commande :

helm upgrade kubeapps bitnami/kubeapps –namespace kubeapps-system –values kubeapps-dex.yaml

 

Maintenant, il faut dire à Dex qu’il y a de nouveaux clusters créés

cat ~/tkg/tkg-extensions-v1.2.0+vmware.1//extensions/authentication/dex/vsphere/ldap/dex-data-values.yaml

# Partie à modifier extraite du fichier de configuration utilisait par Dex : ~/tkg/tkg-extensions-v1.2.0+vmware.1//extensions/authentication/dex/vsphere/ldap/dex-data-values.yaml
  #@overlay/replace
  staticClients:
  – id: usine-01 # nom de mon cluster de workload, attention à garder le même nom que dans le fichier de valeurs utilisé par Kubeapps
    redirectURIs:
    – https://172.20.7.16:30166/callback # Adress IP de l’API du cluster de workload et le port normalement utilisé par Gangway
    name: usine-01
    secret: a1094138692761b8bd653e7af36c3d57 # Secret normalement utilisait par Gangway à mettre même si Gangway n’est pas installé, dans ce cas mettez ce que vous voulez
    trustedPeers:
    – auth-tools # nom du cluster Kubeapps
  – id: usine-32
    redirectURIs:
    – https://172.20.7.17:30166/callback
    name: usine-32
    secret: a1094138692721b8bd653e7af36c3d57
    trustedPeers:
    – auth-tools
  – id: workload-01
    redirectURIs:
    – https://172.20.7.14:30166/callback
    name: workload-01
    secret: e36a415d615ccbf37b4c4b8316be9740
    trustedPeers:
    – auth-tools
  – id: workload-02
    redirectURIs:
    – https://172.20.7.15:30166/callback
    name: workload-02
    secret: 85507bc84d6d26899aa9bf1c87600f81
    trustedPeers:
    – auth-tools
  – id: auth-tools
    redirectURIs:
    – http://172.20.7.130/oauth2/callback # Adresse IP de ma VIP qui pointe vers Kubeapps
    name: auth-tools # nom du cluster où j’ai installé Kubeapps, j’ai choisi de l’installer sur un cluster à part
    secret: wPmp8+IrTxbGZbVF/yqPPeP4XZzw5mLt #clé renseignée dans le fichier Kubeapps « clientSecret »

Une fois modifier, il faut dire à Dex de prendre en compte la nouvelle configuration, à faire à partir du cluster de management où Dex est installé :

kubectl create secret generic dex-data-values –from-file ~/tkg/tkg-extensions-v1.2.0+vmware.1/extensions/authentication/dex/vsphere/ldap/dex-data-values.yaml -n tanzu-system-auth -o yaml –dry-run | kubectl replace -f-

Voilà, maintenant Kubeapps est prêt à être utilisé sur les 4 clusters configurés :

A partir d’un navigateur entrez l’adresse où le nom de la VIP kubeapps obtenue et cliquez sur “LOGIN VIA OIDC PROVIDER:”

 

Vous êtes ensuite redirigé vers la page d’authentification DEX, vous remarquerez que l’IP et le port sont ceux renseignés dans le fichier de configuration DEX, entrez votre compte et votre mot de passe :

Vous arrivez ensuite sur la page du cluster et namespace par défaut, l’écran est vide car il n’y a pas eu de déployement via HELM ou via un Operator sur le namespace et cluster défault :

Vous pouvez changer de cluster et de namespace en cliquant sur “Current Context” en haut à droite :

 

 

 

Comment supprimer des containers volumes “orphelins” dans vSphere

Lorsque vous créez des volumes Kubernetes hébergés sur vSphere, cela génère des fichiers VMDKs, ils sont visibles au travers de l’interface graphique

C’est très utile, il est même possible de voir à quel cluster les volumes appartiennent.

Dans certaines situations, vous pouvez vous retrouver avec des volumes dits orphelins, notamment si un cluster Kubernetes est supprimé “brutalement”. Malheureusement il n’est pas possible de supprimer ces volumes/vmdks depuis l’interface graphique (à date de la rédaction de cet article, vSphere 7). Pour ce faire, il existe d’autres possibilités comme par exemple utiliser l’utilitaire govc développé par VMware. Cependant la version habituelle (référence à la version govc version 0.23.0) ne prend pas en charge les options volume.ls et volume.rm, il faut pour cela utiliser une version à compiler soi-même. ci-dessous les étapes à respecter pour y parvenir :

Installer go (sur Ubuntu server dans mon cas), il est important d’avoir une version récente : https://golang.org/doc/install

Lancer la commande go suivante  : go get -u github.com/vmware/govmomi/govc (https://github.com/vmware/govmomi/tree/master/govc). Ca va télécharger les sources dans le répertoire ~/go/src, compiler et stocker le binaire govc dans ~/go/bin.

il faut positionner ensuite un certain nombre de variable à govc afin qu’il puisse se connecter à l’infrastructure, exemple :

export GOVC_URL=<fqdn du vcenter>
export GOVC_USERNAME=<compte avec des droits en consultation>
export GOVC_PASSWORD=<mot de passe du compte>
export GOVC_INSECURE=true (si vous utilisez des certificats non signés)

Grâce à ce govc spécifique, vous pouvez utiliser la commande ~/go/bin/govc volume.ls pour lister tous les volumes et la commande ~/go/bin/govc volume.rm <volume>. Attention à bien choisir les volumes orphelins sinon vous risquez de perdre des données.

Un développeur à fait un script intéressant pour supprimer les volumes orphelins : https://gist.github.com/bburky/fd729f129347b9141255fbc2185c52ea#file-remove-orphaned-cns-volumes-sh-L1 (attention ce script suppose que govc soit dans votre variable $PATH, si ce n’est pas le cas mettez cette variable à jour ou modifier le script pour qu’il pointe sur le bon govc).

Ce script à un petit bémol auquel il faut prêter attention, il suppose qu’il y ait un seul cluster car il utilise la commande kubectl, celle-ci se connecte en utilisant le contexte actif. Si vous avez plusieurs clusters kubernetes hébergés sur votre infrastructure, vous risquez de supprimer des volumes vus comme orphelin alors qu’ils peuvent potentiellement appartenir à d’autres clusters Kubernetes, j’ai soumis au développeur du script cette modification :

> "$temp_dir/kubernetes-temp.txt"
for context in $(kubectl config view -o jsonpath='{.contexts[*].name}')
do
        echo checking context : $context
        kubectl get pv -o jsonpath='{range .items[*]}{.spec.csi.volumeHandle}{"\t"}{.metadata.name}{"\n"}{end}' --context $context  >> "$temp_dir/kubernetes-temp.txt"
done
sort $temp_dir/kubernetes-temp.txt > $temp_dir/kubernetes.txt

Ce n’est pas encore parfait, il peut inclure des volumes provenant de cluster Kubernetes non vSphere mais il n’y aura pas d’incidence sur la suppression des volumes.

 

Ajouter un self-signed certificat dans Kubernetes avec Containerd

Dans cet article (Déployer Harbor avec type loadBalancer) j’ai expliqué comment déployer Habor et utiliser le certificat self-signed pour que Docker puisse l’utiliser. Si vous utilisez Kubernetes avec docker, vous pouvez aussi suivre cette procédure sur chaque worker node. Sinon vous risquez d’avoir l’erreur suivante :

Unknown desc = failed to pull and unpack image “harbor.cpod-tkg.az-lab.shwrfr.com/memecached/hello-world:latest”: failed to resolve reference “harbor.cpod-tkg.az-lab.shwrfr.com/memecached/hello-world:latest”: failed to do request: Head https://harbor.cpod-tkg.az-lab.shwrfr.com/v2/memecached/hello-world/manifests/latest: x509: certificate signed by unknown authority
Warning Failed 12s (x2 over 24s) kubelet, tkg-utility-md-0-798c695db5-pjgsk Error: ErrImagePull

Si vous utilisez Kubernetes avec Containerd, la procédure est différente. Mon collègue Rob Hardt (https://gist.github.com/rhardt-pivotal/) a développé un script pour ça : https://gist.githubusercontent.com/rhardt-pivotal/4aa09ced6302194561936717262bb203/raw/623c707748925c969c525ade4bb432f95b61cff0/node-ca-updater-daemonset.yaml

Il faut néanmoins modifier les 3 champs en rouge :

apiVersion: v1
data:
  ca.pem: |+
    —–BEGIN CERTIFICATE—–
    Mettre votre certificat
    —–END CERTIFICATE—–

kind: ConfigMap
metadata:
 name: trusted-ca-cm
 namespace: default

   —-

apiVersion: v1
data:
    build-ca.sh: “#!/usr/bin/env bash \nset -euxo pipefail\ntdnf update \ntdnf install -y ca-certificates\ntdnf install -y openssl-c_rehash\necho \”$TRUSTED_CERT\” > /etc/ssl/certs/my-trusted-cert.pem\n/usr/bin/rehash_ca_certificates.sh\ncurl -vv https://<Votre URL HARBOR>\n”
kind: ConfigMap
metadata:
    name: rehash-script
    namespace: default
—   
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: trusted-ca-updater
  namespace: default
  labels:
    k8s-app: trusted-ca-updater
spec:
  selector:
    matchLabels:
      name: trusted-ca-updater
  template:
    metadata:
      labels:
        name: trusted-ca-updater
    spec:
      tolerations:
      # this toleration is to have the daemonset runnable on master nodes
      # remove it if your masters can’t run pods
      – key: node-role.kubernetes.io/master
        effect: NoSchedule
      initContainers:
      – name: script-runner
        image: photon:3.0
        command: [“/bin/sh”, “-c”, “/root/build-ca.sh” ]
        volumeMounts:
        – name: update-trusted-certs-script
          mountPath: /root/
        – name: certs-dir
          mountPath: /etc/ssl/certs
        – name: agg-certs-dir
          mountPath: /etc/pki/tls/certs/
        env:
        – name: TRUSTED_CERT
          valueFrom:
            configMapKeyRef:
              name: trusted-ca-cm
              key: ca.pem   
        resources:
            limits:
              ephemeral-storage: 30G # mettre une plus petite taille
      containers:
      – name: sleepy
        image: photon:3.0
        command: [“/bin/sh”]
        args: [“-c”, “while true; do sleep 3600;done”]
      volumes:
      – name: update-trusted-certs-script
        configMap:
            name: rehash-script
            defaultMode: 0766
      – name: certs-dir
        hostPath:
          path: /etc/ssl/certs
          type: Directory
      – name: agg-certs-dir
        hostPath:
          path: /etc/pki/tls/certs/
          type: Directory

 

Il faut ensuite se connecter sur les workernodes pour relancer containerd. Ci-dessous un exemple pour TKG (Une solution Kubernetes as a Service pour tous les Clouds)

# ssh capv@<ip-YourWokerNode>

capv@YourWokerNode$ sudo systemctl restart containerd