Comment supprimer des containers volumes “orphelins” dans vSphere

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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/

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

(attention il y a deux tirets normalement, je ne sais pas pourquoi wordpress en affiche qu’un. Si vous faites un copié/colé, enlever le tiret et en mettre deux à la place)

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

 

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_cEgJFArGYn3kaihzZ aZsAH7a6scVsk7KcTuYRQ

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

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