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

 

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

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

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

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

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

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

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 🤔😉.

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.

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