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 

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 :