Une solution Kubernetes as a Service pour tous les Clouds

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 :

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

Déployer Kubeapps

Kubeapps est un projet Bitnami. Bitnami a été racheté par VMware en 2019 et fait partie maintenant de la gamme Tanzu et se nomme Tanzu Application Catalog. Kubeapps est un catalogue de déploiement et de management d’applications et de services. Il arrive déjà connecté à la marketplace bitnami et il est possible de synchroniser une registry type docker. https://bitnami.com/kubernetes/kubeapps

La documentation d’installation est assez bien faite, je n’ai trouvé de complexité, juste un peu de vigilance au niveau des rôles si vous êtes en production. Un utilisateur peut avoir un accès en lecture seul et/ou en lecture/écriture (nécessaire pour déployer des applications), le scope des droits peut être le cluster et/ou le namespace. L’utilisateur à la possibilité de créer des namespaces pour y déployer des applications. https://github.com/kubeapps/kubeapps

Installation via Helm (version 3 dans mon exemple)

$ helm repo add bitnami https://charts.bitnami.com/bitnami

$ kubectl create namespace kubeapps

$ helm install kubeapps –namespace kubeapps bitnami/kubeapps –set useHelm3=true –-set fontend.service.type=LoadBalancer

 

Créer un compte et le rôle pourvoir accéder à Kubeapps et pour installer des applications, créer des namespace directement depuis l’interface. Récupérez le token pour se logger à l’interface

$ kubectl create -n default serviceaccount loeilduse

$ kubectl create clusterrolebinding loeilduse –clusterrole=cluster-admin –serviceaccount=default:loeilduse

$ kubectl get -n default secret $(kubectl get -n default serviceaccount loeilduse -o jsonpath='{.secrets[].name}’) -o go-template='{{.data.token | base64decode}}’ && echo

Récupérer le token, il sera demandé lors de la connexion à Kubeapps via le navigateur (ci-dessous un exemple)

eyJhbGciOiJSUzI1NiIsImtpZCI6IkV5bEdwMDU2dkVqTld5dFJtR03RHNVSmhmd09rc1licnJFSm81Nm1EZ3MifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImxvZWlsZHVzZS10b2tlbi1yOGJiZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZShY2NvdW50Lm5hbWUiOiJsb2VpbGR1c2UiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI5NTMwZjZmNy1jMzEzLTQ5MzctODY2ZS1mMDUwNzY0YmI0MDEiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDpb2VpbGR1c2UifQ.kTZhrfFXrOS-S2a3x6oiyO6mqi7d62lrsmy-pTLpFX-XsjAK8NZQ95WaKqJ1gHkQfJa4ah-gvSQOVeI0y8-TueS24iAbrMfFwuocbHOJa6d9x9dfBSNGfxgW2DZaA22TokAVm_VT_DmFbV7uqsOSdFNRC6GnogoUmaO0P2-X1A8HHXuur04zRU5pH-8kNUrmIclIlpUPIaDlkRV1v94nZfn1S0RswG4wzTY1IeqQn4Nn5vh9XKfavp7l42vSWH7F0AHnkpTpY94GN8TNVoninPBkl5ktcF6PZJ7qbYlEK4wz5Y_cEgJFArGYn3kaihzZaZsAH7a6scVsk7KcTuYRQ

Récupérer l’IP fournit par le service Load Balancer

$ Kubectl get svc -n kubeapps

 

 

Ouvrir la page web avec l’IP fourni par le load balancer et renseigner le token récupéré :

 

Si vous avez le message ci-dessous, revoyez la partie création user/droit décrite juste avant

 

Vous devriez avoir ces types d’écrans

 

Lorsque vous déployez des applications depuis le catalogue Kubeapps, n’oubliez pas de modifier le fichier yaml si vous voulez y accéder depuis l’extérieur de votre cluster Kubernetes. Ci-dessous, un exemple de déploiement de Dokuwiki pour qu’il soit accessible via un load balancer (voir tout en bas) :

 

Déployer Harbor avec type loadBalancer

Pour rédiger mes articles de vulgarisation, je suis amené à tester certains produits. C’est très chronophage surtout quand ça ne fonctionne pas du premier coup. Je fais pas mal de recherche sur Internet pour voir si des posts donnent des astuces mais des fois, il faut tenter d’autres pistes. C’est pour cela que j’ai créé une rubrique Astuces Techniques, j’y posterai un résumé des résultats de mes recherches qui pourrait aider d’autres personnes.

Je consacre ce premier article au déploiement de la registry Harbor développée initialement par VMware puis donné à la CNCF. J’ai beaucoup galéré pour la déployer afin qu’elle soit accessible derrière un loadbalancer, j’avais le message suivant lorsque que docker tentait de s’y connecter :

#docker login harbor.cpod-tkg.az-lab.shwrfr.com
Authenticating with existing credentials…
Login did not succeed, error: Error response from daemon: Get https://harbor.cpod-tkg.az-lab.shwrfr.com/v2/: Get https://core.harbor.domain/service/token?account=admin&client_id=docker&offline_token=true&service=harbor-registry: dial tcp: lookup core.harbor.domain: no such host

J’utilise un environnement vSphere 7 pour héberger un cluster Kubernetes V1.17.3 déployé via TKG V1. Le loadbalancer est un Metallb V0.82, Habor V1.10.1 et HELM 3

Télécharger Harbor via Helm 3 :

#helm repo add harbor https://helm.goharbor.io

#helm fetch harbor/harbor –untar

Créer une storage class nécessaire aux volumes persistent, cette storage class utilise une storage policy que j’ai déjà créé dans vSpehre :

kind: StorageClass

apiVersion: storage.k8s.io/v1

metadata:

  name: silver-storage-class

  annotations:

    storageclass.kubernetes.io/is-default-class: “true”

provisioner: csi.vsphere.vmware.com

parameters:

  storagepolicyname: “silver-storage-class”

Installer Harbor avec les bons paramètres notamment externalURL :

# helm install -n harbor-system registry harbor/harbor –set expose.type=loadBalancer,expose.tls.commonName=harbor.cpod-tkg.az-lab.shwrfr.com,externalURL=https://harbor.cpod-tkg.az-lab.shwrfr.com

Si vous n’utilisez pas de certificats signés, il faut que docker soit autorisé à utiliser une registry “Insecure” :

#cat /etc/docker/daemon.json

{

        “insecure-registries” : [“172.20.4.71”, ’’harbor.cpod-tkg.az-lab.shwrfr.com’’]

}

# systemctl restart docker

Télécharger le certificat depuis l’UI d’Harbor => projets => <votre nom de projet> => Reprositories => REGISTRY CERTIFICATE et le copier dans le répertoire docker prévu à cet effet :

#mkdir -p /etc/docker/certs.d/172.20.4.71 et/ou mkdir -p /etc/docker/certs.d/’harbor.cpod-tkg.az-lab.shwrfr.com’

Normalement vous devriez pouvoir vous connecter à Harbor via Docker :

#docker login harbor.cpod-tkg.az-lab.shwrfr.com
Authenticating with existing credentials…
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded