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/

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).