Tous les articles par dans Farid BENREJDAL

Déployer Kubeapps pour un usage multi-clusters

 

Dans cet article nous allons voir comment déployer Kubeapps en environnement multi-cluster. Habituellement il se déployait cluster par cluster, ici, l’objectif est d’avoir une seule instance Kubeapps capable de déployer et de gérer les applications sur plusieurs clusters. Pour cela, il faut que chaque cluster soit capable de s’authentifier à une source IdP (Identity Provider).

Dans mon exemple je vais utiliser des clusters TKG 1.2.1 avec l’extension incluse Dex. Dex va permettre l’authentification avec un provider OpenID Connect (OIDC).  Pour info, dans notre exemple l’extension Gangway qui normalement va de pair avec Dex n’est pas utile. Elle sert à générer un Kubeconfig une fois que l’utilisateur s’est authentifié via la page web du cluster. Kubeapps n’a pas besoin de cette extension car il utilise un proxy Oauth2. Sur mon environnement, je vais utiliser des clusters existant qui sont déjà configurés avec l’extension Gangway et 1 que je vais créer sans installer Gangway (2 clusters auraient pu suffire mais c’est tellement simple à déployer avec TKG qu’on ne va pas se priver).

Étape primordiale, c’est d’ avoir l’extension Dex d’installée sur le cluster de management et le configurer pour qu’il puisse faire des requêtes sur une source IdP : https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.2/vmware-tanzu-kubernetes-grid-12/GUID-extensions-dex.html. Une fois Dex installé, il faut créer des clusters de workload compatibles OIDC et déployer Kubeapps sur un cluster de préférence distinct (ou commencer par installer Kubeapps et le mettre à jour pour qu’il prenne en compte les nouveaux clusters).

Exporter les variables sur l’environnement du cluster DEX :

export AUTH_MGMT_CLUSTER=”auth-mgmt-cluster-admin@auth-mgmt-cluster” # nom de mon cluster de management
export OIDC_ISSUER_URL=https://172.20.7.10:30167 #IP et Port de mon cluster de management où est installé DEX
export OIDC_USERNAME_CLAIM=email
export OIDC_GROUPS_CLAIM=groups
export OIDC_DEX_CA=$(kubectl get secret dex-cert-tls -n tanzu-system-auth -o ‘go-template={{ index .data “ca.crt” }}’ –context $AUTH_MGMT_CLUSTER| base64 -d | gzip | base64) # certificat du cluster de management

Créer ensuite les clusters de workloads :

tkg create cluster usine-32 –enable-cluster-options oidc –plan dev –vsphere-controlplane-endpoint 172.20.7.17

Logs of the command execution can also be found at: /tmp/tkg-20210106T094128013610360.log
Validating configuration…
Creating workload cluster ‘usine-32’…
Waiting for cluster to be initialized…
Waiting for cluster nodes to be available…
Waiting for addons installation…
Workload cluster ‘usine-32’ created

 

Récupérer le context du cluster pour qu’il soit intégré dans le kubeconfig et ainsi récupérer l’url de l’API server: et le certificat certificateAuthorityData:

tkg get credentials usine-32
Credentials of workload cluster ‘usine-32’ have been saved
You can now access the cluster by running ‘kubectl config use-context usine-32-admin@usine-32’

 

Se connecter au cluster afin d’autoriser les utilisateurs à s’y connecter et de déployer des applications :

kubectl config use-context usine-32-admin@usine-32

cat << EOF | kubectl apply –
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tkg-users
subjects:
  – kind: Group          # Donner le rôle au groupe, mettre User si vous souhaitez cibler un user en particulier
    name: tkg-users # Mettre le nom du groupe, tous les utilisateurs du groupe seront pris en compte
    apiGroup: “”
roleRef:
  kind: ClusterRole #this must be Role or ClusterRole
  name: cluster-admin # ClusterRole à avoir
  apiGroup: rbac.authorization.k8s.io
EOF

 

Une fois le cluster créé, les droits d’accès positionnés, l’url et le certificat récupérés (si besoin, reproduire les mêmes étapes pour d’autres clusters de workload), il reste deux fichiers à modifier, l’un concerne le fichier de valeurs de l’installation de Kubeapps et l’autre le fichier de configuration DEX.

Modification du fichier de valeurs pour l’installation de Kubeapps (Exemple provenant de mon collègue Michael Nelson : https://liveandletlearn.net/post/kubeapps-on-tkg-management-cluster/) :

# Dans mon exemple Kubeapps est accessible au travers d’un LoadBalancer
frontend:
  service:
    port: 80
    type: LoadBalancer
# Setup the oauth2-proxy running on the frontend to handle the OIDC authentication
authProxy:
  enabled: true
  provider: oidc
  clientID: auth-tools
  ## les deux Secrets ci-dessous sont à générer par vous-même (32 octets max)
  clientSecret: wPmp8+IrTxbGZbVF/yqPPeP4XZzw5mLt
  cookieSecret: fiUrXyEBQx7uWlcw55CxQkbYwZ4a/cC7
  additionalFlags:
    # C’est l’adresse IP et le port de DEX qui est installé sur le cluster de management
    – –oidc-issuer-url=https://172.20.7.10:30167
    # les clusters derrières le mot audience sont les clusters sur lesquels les déploiements seront autorisés, ils doivent aussi figurer en bas de ce fichier et dans le fichier de configuration Dex
    – –scope=openid email groups audience:server:client_id:workload-01 audience:server:client_id:workload-02 audience:server:client_id:usine-01 audience:server:client_id:usine-32
    # Comme j’ai des certificats autosignés, il ne faut pas les vérifier auprès d’une autorité
    – –ssl-insecure-skip-verify=true
    # Since Kubeapps is running without TLS, can’t use secure cookies
    – –cookie-secure=false
    # If you need to access the actual token in the frontend for testing, uncomment the following.
    # – –set-authorization-header=true
# Liste des clusters sur lesquels les déploiements seront autorisés, les mêmes renseignés un peu plus haut
# L’apiServiceURL et le certificateAuthorityData sont ceux récupérés dans le fichier kubeconfig un peu plus haut
# dans mon exemple j’ai 4 clusters de workload
clusters:
  – name: workload-01
  apiServiceURL: https://172.20.7.14:6443
  certificateAuthorityData: USUZJQ0FURS0tQkFRc0ZBREFWTVJNd0……..E9KOFhFQUI1aVBqVDQxWXZzeEE9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
  – name: workload-02
  apiServiceURL: https://172.20.7.15:6443
  certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FBREFWTVJNd0…….wS1V1UUgvcCtjMWkvYW89Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
  – name: usine-01
  apiServiceURL: https://172.20.7.16:6443
  certificateAuthorityData: LS0TkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0….Es2RWpSNys2NkNlT2dpeHcxVUk9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
  – name: usine-32
  apiServiceURL: https://172.20.7.17:6443
  certificateAuthorityData: BTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0…cldORUNGb3FJelZkdXdKRGNFMTA9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K

 

Maintenant, on peut installer Kubeapps dans un namespace avec comme paramètre ce fichier de valeurs (ici, je l’ai appelé kubeapps-dex.yaml) :

kubectl create namespace kubeapps-system
helm install kubeapps bitnami/kubeapps –namespace kubeapps-system –values kubeapps-dex.yaml

Si vous êtes amené à modifier le fichier de configuration comme par exemple pour ajouter un autre cluster, vous pouvez utiliser cette commande :

helm upgrade kubeapps bitnami/kubeapps –namespace kubeapps-system –values kubeapps-dex.yaml

 

Maintenant, il faut dire à Dex qu’il y a de nouveaux clusters créés

cat ~/tkg/tkg-extensions-v1.2.0+vmware.1//extensions/authentication/dex/vsphere/ldap/dex-data-values.yaml

# Partie à modifier extraite du fichier de configuration utilisait par Dex : ~/tkg/tkg-extensions-v1.2.0+vmware.1//extensions/authentication/dex/vsphere/ldap/dex-data-values.yaml
  #@overlay/replace
  staticClients:
  – id: usine-01 # nom de mon cluster de workload, attention à garder le même nom que dans le fichier de valeurs utilisé par Kubeapps
    redirectURIs:
    – https://172.20.7.16:30166/callback # Adress IP de l’API du cluster de workload et le port normalement utilisé par Gangway
    name: usine-01
    secret: a1094138692761b8bd653e7af36c3d57 # Secret normalement utilisait par Gangway à mettre même si Gangway n’est pas installé, dans ce cas mettez ce que vous voulez
    trustedPeers:
    – auth-tools # nom du cluster Kubeapps
  – id: usine-32
    redirectURIs:
    – https://172.20.7.17:30166/callback
    name: usine-32
    secret: a1094138692721b8bd653e7af36c3d57
    trustedPeers:
    – auth-tools
  – id: workload-01
    redirectURIs:
    – https://172.20.7.14:30166/callback
    name: workload-01
    secret: e36a415d615ccbf37b4c4b8316be9740
    trustedPeers:
    – auth-tools
  – id: workload-02
    redirectURIs:
    – https://172.20.7.15:30166/callback
    name: workload-02
    secret: 85507bc84d6d26899aa9bf1c87600f81
    trustedPeers:
    – auth-tools
  – id: auth-tools
    redirectURIs:
    – http://172.20.7.130/oauth2/callback # Adresse IP de ma VIP qui pointe vers Kubeapps
    name: auth-tools # nom du cluster où j’ai installé Kubeapps, j’ai choisi de l’installer sur un cluster à part
    secret: wPmp8+IrTxbGZbVF/yqPPeP4XZzw5mLt #clé renseignée dans le fichier Kubeapps « clientSecret »

Une fois modifier, il faut dire à Dex de prendre en compte la nouvelle configuration, à faire à partir du cluster de management où Dex est installé :

kubectl create secret generic dex-data-values –from-file ~/tkg/tkg-extensions-v1.2.0+vmware.1/extensions/authentication/dex/vsphere/ldap/dex-data-values.yaml -n tanzu-system-auth -o yaml –dry-run | kubectl replace -f-

Voilà, maintenant Kubeapps est prêt à être utilisé sur les 4 clusters configurés :

A partir d’un navigateur entrez l’adresse où le nom de la VIP kubeapps obtenue et cliquez sur “LOGIN VIA OIDC PROVIDER:”

 

Vous êtes ensuite redirigé vers la page d’authentification DEX, vous remarquerez que l’IP et le port sont ceux renseignés dans le fichier de configuration DEX, entrez votre compte et votre mot de passe :

Vous arrivez ensuite sur la page du cluster et namespace par défaut, l’écran est vide car il n’y a pas eu de déployement via HELM ou via un Operator sur le namespace et cluster défault :

Vous pouvez changer de cluster et de namespace en cliquant sur “Current Context” en haut à droite :

 

 

 

Passer du code source à une image container en une seule commande

Le passage d’un code source à une image container prête à être consommée est une étape indispensable et l’effort que cela nécessite est souvent sous-estimé. Pour synthétiser, ce passage consiste à créer un fichier de configuration pour renseigner sur quel image de système d’exploitation doit fonctionner le container, comment télécharger le compilateur, comment compiler l’application et comment exécuter l’application. Ensuite, il faut lancer la commande de construction du container puis le charger dans une registry pour un téléchargement et une exécution ultérieurs. Sur un petit environnement avec quelques containers, quelques fichiers de configuration et quelques commandes à exécuter, c’est faisable. Cependant, ça devient vite plus compliqué à mesure où le nombre de container croît. Ça sera d’autant plus compliqué avec l’inévitable gestion du cycle de vie des applications, celle-ci est induite par la mise à jour du code applicatif et par les mises à jour de sécurité des composants liés au système d’exploitation. C’est une tâche fastidieuse et chronophage.

L’agilité étant l’objectif premier de l’utilisation des containers, l’automatisation du processus de création d’image container est vite devenue indispensable. Dans la majorité des cas, l’utilisation d’un pipe-line est privilégiée pour enchaîner les commandes de création et de mise à jour. La mise en place et le maintien en condition opérationnel de ce pipeline n’est pas non plus à négliger.

J’ai récemment testé VMware Tanzu Build Service (TBS), je me suis vite rendu compte qu’il simplifie drastiquement ce processus et j’ai été séduit par sa facilité d’utilisation. En effet en une seule commande, le code source est transformé en image container puis stockée dans une registry et ce sans que le développeur n’ait à générer de fichier de configuration.

Les containers sont créés au format OCI (Open Container Initiative, lancée en 2015 par Docker) assurant leur fonctionnement sur l’ensemble des runtime container du marché à condition qu’ils respectent cette initiative.

D’un point de vu macro, l’image container générée est découpée en 3 parties indépendantes : la Stack, le buildpack et l’Application qui permettent une modification granulaire.

La stack (appelée aussi Cloudstack) concerne la partie liée au système d’exploitation, le Buildpack concerne la partie qui permet de construire et d’exécuter l’application (java, nodejs, php, …), la partie Application concerne le code source de l’application. Cela permet de mettre à jour granulairement chaque partie de manière indépendante. Ainsi, si par exemple une faille de sécurité est détectée sur la partie stack, TBS permettra de mettre à jour que cette partie en appliquant un patch de sécurité.

Voyons le fonctionnement principal :

En entrée TBS a besoin d’un code source (les langages pris en charge sont fonctions des buildpack installés (Java, go, php, …)), ce code source peut être, dans un répertoire local, sur un repository git ou encore sur un blob store http au format zip, tgz ou tar.

En sortie, TBS va stocker le container image dans une registry de type Harbor, GCRIO ou autre.

Comme exemple, la commande ci-dessous avec en entrée un repository git et en sortie un lien vers une registry privée Harbor :

kp image create spring-music –tag harbor.cpod-velocity.az-fkd.cloud-garage.net/tanzu/spring-music:1 –git https://github.com/fbenrejdal/spring-music.git –git-revision master

TBS détecte automatiquement les buildpacks dont l’application a besoin pour construire et exécuter l’image.

L’option –git-revision master indique à TBS de surveiller les modifications de la version master et d’enclencher automatiquement une mise à jour de l’image container si une nouvelle version a été “commitée”. dans ce cas, seule la partie Application de l’image container est modifiée.

 

La solution TBS vient déjà avec un certain nombre de buildpack mais il est possible de construire ses propres buildpacks. La commande ci-dessous permet de visualiser les buildpacks déjà installés.

$ kp clusterstore status default
Status: Ready

BUILDPACKAGE ID VERSION HOMEPAGE
paketo-buildpacks/procfile 2.0.2 https://github.com/paketo-buildpacks/procfile
tanzu-buildpacks/dotnet-core 0.0.5
tanzu-buildpacks/go 1.0.6
tanzu-buildpacks/httpd 0.0.38
tanzu-buildpacks/java 3.8.0 https://github.com/pivotal-cf/tanzu-java
tanzu-buildpacks/java-native-image 3.6.0 https://github.com/pivotal-cf/tanzu-java-native-image
tanzu-buildpacks/nginx 0.0.46
tanzu-buildpacks/nodejs 1.2.1
tanzu-buildpacks/php 0.0.3

 

Pour résumer, Tanzu Build Service permet de réduire drastiquement le temps et les opérations de création ainsi que les mises à jour des images containers, le développeur n’a plus à se soucier à gérer des fichiers de configuration, il se focalise juste sur son code. TBS détecte tout seul en fonction du code source les dépendances dont il a besoin et est capable aussi de détecter les mises à jour qui ont été “commitées” pour générer une nouvelle image container. TBS découpe l’image container en couche : Stack, Buildpack et Application afin de pouvoir mettre à jour unitairement chaque partie.

Pour voir comment créer une image et la mettre à jour, j’ai créé deux courtes vidéos :

TBS creation d’une image container à partir de github

TBS détection automatique d’une mise à jour

Mes collègues spécialistes Alexandre et Guillaume ont animé un webinar en Français plus détaillé sur ce sujet :

Cloud Native Buildpack : La formule pour transformer vos applications en conteneurs avec Kubernetes

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.