NSX Intelligence sur Tanzu

Introduction

Bienvenue pour ce premier article, qui a pour objectif de détailler, pas à pas, le déploiement de NSX Intelligence en version 3.2+.

Cette mise à jour change radicalement le déploiement et l’activation de certaines fonctionnalités NSX T dont NSX Intelligence.

Dorénavant NSX Intelligence est une solution conteneurisée à déployer sur la nouvelle brique technologie NSX Application Plateform (i.e NAPP).

NAPP se déploie sur un cluster K8s pré existant. L’administrateur VMware n’a plus d’autre choix que de monter en compétence sur Kubernetes… NSX ne déploiera pas le cluster pour vous.

Si K8s est déjà déployé (distribution Tanzu ou autre) le déploiement de NAPP sera (presque) une formalité. Mais quid d’un environnement sans licence Tanzu et sans environnement K8s?

La bonne nouvelle est l’arrivée il y a quelques mois de Tanzu Community Edition (i.e TCE). TCE a l’avantage pour un profil VMware de permettre de garder certains repères tout en profitant des apports de Tanzu (mises à jour, « simplicité » de déploiement…).

Mon but est de détailler toutes les étapes nécessaires pour un déploiement NSX Intelligence from scratch mais il y aura forcément des adaptations à effectuer de votre côté.

Architecture Lab / prés requis

Architecture LAB

L’environnement utilisé pour cet article est un cluster physique vSAN 2 nœuds 7U3.

Si vous avez déployé l’appliance NSX Intelligence auparavant vous connaissez ses importants prés requis en CPU et RAM.

La version conteneurisée a les mêmes prés requis mais va demander le triple de ressources afin d’avoir un cluster NSX Intelligence résilient. A ces pres requis s’ajoute la consommation des VMs Tanzu.

Pour le stockage lors de mon premier déploiement l’ensemble Tanzu/NAPP consommait env 400Go.

Pour cet article je ferai un déploiement avec un unique control et worker node, ce qui correspond au form factor « Evaluation » de NAPP. Bien sur ce déploiement n’apporte pas de résilience et empêche les mises à jour des services déployés.

Malgré le form factor minimum la consommation en ressource est élevée (surtout en environnement lab) et vous constaterez une augmentation non négligeable des opérations I/O sur votre stockage.

Un segment overlay NSX T est configuré pour les VMs déployés par Tanzu. Sur ce segment le service DHCP a été activé avec un range dédié. La configuration NSX est « standard » avec un routage externe STATIC.

Un service DHCP est obligatoire pour le déploiement de TCE et des clusters.

Tip : Garder les premières IPs du réseau pour le service DHCP de NSX T si vous comptez l’utiliser.

Comme dit précédemment je conseil de dédier un segment à Tanzu. Une partie des IPs réservées pour le DHCP et le reste pour les IPs fixes que nous devrons enregistrer sur le serveur DNS.

Si vous avez des règles de pare feu il faudra identifier les flux à ouvrir selon votre environnement. Également si vous faites du DPI il faudra exclure les VMs Tanzu de l’inspection. Les VMs Tanzu sur ce réseau seront

Segment Tanzu dédié

Range DHCP pour les clusters Tanzu Community Edition

Outillage

En plus de notre cluster vSphere nous allons configurer une VM Linux dites « Boostrap » ainsi qu’une VM Template qui sera utilisé par Tanzu pour ses déploiements.

La VM Boostrap contiendra tous les outils Tanzu nécessaire à son déploiement et son administration.

J’ai choisi la distribution Ubuntu 22.04 principalement pour sa communauté qui propose un large choix de guide plus de ressources qui peuvent aider pour non spécialiste linux.

Il est également possible d’utiliser un environnement Windows pour gérer Tanzu mais je conseil une VM Linux dédiée car c’est ce qu’on retrouve le plus sur le terrain et permet de centraliser les opérations.

Je conseil de faire le premier déploiement en graphique. Le déploiement en CLI est possible.

A la fin du Wizard GUI il est possible d'exporter le fichier yaml de configuration du cluster ainsi que son emplacement "local".

Une fois le cluster de management déployé, le reste des opérations à la VM Boostrap en SSH.

Déploiement Template Tanzu

Les ova des template Tanzu se téléchargent depuis le site de VMware : Lien téléchargement Appliance Tanzu v0.12 

Une fois dans menu de téléchargement il faut choisir la distribution (Photon ou Ubuntu) et la version de K8s installé de sa VM template.

Pour ma part j’ai choisi la distribution Ubuntu en 1.22.x. La distribution ne change en rien les étapes de déploiement. La distribution Photon est plus légère, Ubuntu est plus connu.

Sans allumer les VMs déployées, les convertir directement en template.

Résumé des étapes de déploiement

Faites comme à votre habitude

Laissez le nom par défaut !!

Le template Ubuntu consomme env 22Go

Configuration VM Bootstrap

Choisissez la distribution qui vous convient le mieux. J’ai choisis la dernière LTS Ubuntu pour sa large communauté.

Pour télécharger Ubuntu : https://ubuntu.com/download/desktop

Une fois déployé, mettez à jours la VM, donnez-lui une IP fixe / réservation DHCP avec un enregistrement DNS.

Configuration IP fixe sur la VM Ubuntu

Désactiver le DNS « Automatic » avant d’appliquer la configuration:

La passerelle correspond à l'Uplink de l'Edge dans mon lab.u

L’installation minimale est adaptée. Je coche les maj pendant l’installation ainsi que l’installation des drivers Tiers. Ce n’est pas un prérequis mais on évite un potentiel problème avec VMware.

apt update 
apt-upgrade  
apt install open-vm-tools-desktop open-vm-tools 
reboot

Installation de OpenSSH pour l'accès... SSH.

#Mise à jour de la bdd apt 
apt update  

#Installation du binaire 
apt install openssh-server 

#Démarrage du service et lancement auto au démarrage 
systemctl start ssh 
systemctl enable ssh
systemctl status ssh 

A partir de là vous pouvez vous connecter en SSH depuis votre environnement de travail et ne revenir sur le KVM VMware que pour le Wizard de déploiement.

Configuration du client NTP

# Edition de la configuration du service 
nano /etc/systemd/timesyncd.conf

# On redémarre le service
systemctl restart systemd-timesyncd

# Vérification de la configuration
timedatectl timesync-status  

Il est très important de configurer le service NTP pour TCE

Installation du package Tanzu Community Edition

Lien vers la documentation Tanzu pour référence.

Afin de simplifier son déploiement, VMware recommande d’utiliser Homebrew pour l’installation de TCE.

Note : Changez le nom du répertoire home par celui de votre utilisateur $USER

# Installation de Brew 
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"Post #Conf Brew 
echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"' >> /home/$USER/.profile# eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)" 

# Brew recommande d’installer les dépendances communes et GCC (requis pour TCE) 
sudo apt-get install build-essential 

brew install gcc 

#Installation de TCE 
brew install vmware-tanzu/tanzu/tanzu-community-edition  

A la fin de l’installation de TCE, Brew vous avertira qu’il faut exécuter un script afin de finaliser l’installation (obligatoire sinon vous aurez des commandes manquantes)

La commande à exécuter se trouve ici :

Création d’une clé SSH pour TCE

ssh-keygen -t rsa -b 4096 -C email@example.com 

Le Wizard de déploiement TCE demande une clé SSH (de la VM Booststrap) qui sera utilisée pour se connecter sur les VMs Tanzu.

Notez le chemin de la clé SSH

Entrez un mot de passe

# On démarre l’agent SSH 
eval $(ssh-agent) 

# On ajoute la clé 
ssh-add /home/$USER/.ssh/id_rsa.pub 

# Pour vérifier l’ajout de votre clé 
ssh-add -l 

On ajoute la clé à la liste du service SSH

Enfin on copie la clé public SSH id_rsa.pub dans un fichier texte facilement accessible. On l’utilisera lors de déploiement de TCE.

Le début du fun ... le tout, mais vraiment, le tout début …

Notre Ubuntu est installé avec sa configuration de base. On va pouvoir déployer Tanzu !

Pas si vite !

Le Wizard de déploiement à ses propres prés requis… à commencer par nécessiter Kubectl.

Installation de Kubectl

# Téléchargement du binaire kubectl  
curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl 

# Installation de Kubectl 
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl 

# Vérification de l'installation 
kubectl version 

Sans Kubectl le déploiement de TCE échouera mais son installation est rapide.

Kubectl est correctement installé, on peut passer à celle de Docker.

Installation de docker

# Installation des prérequis 
sudo apt-get update 
sudo apt-get install ca-certificates curl gnupg lsb-release 

# Ajout du repository Docker 
sudo mkdir -p /etc/apt/keyrings  
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o etc/apt/keyrings/docker.gpg 
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null 

# Installation de Docker 
sudo apt-get updatesudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin 

# Vérification de docker 
sudo docker run hello-world  

Afin de pouvoir gérer Docker avec notre compte non-root on suit la procédure ci dessous.

# Création d’un groupe Docker 
sudo groupadd docker 

# Ajout de notre compte à ce groupe 
sudo usermod -aG docker $USER 

# Redémarrage pour prise en compte 
sudo reboot

# Test du bon fonctionnement en non root 
docker run hello-world 

# Lancement de Docker au démarrage 
sudo systemctl enable docker.service 
sudo systemctl enable containerd.service 

Docker est prêt !

Le Wizard TCE de déploiement est prêt à être lancé !

Depuis la remote console VMware de la VM Booststrap on exécute la commande suivante :

tanzu management-cluster create --ui

Si la commande s’exécute correctement le service web se lance et indique le port à utiliser.

Pour cet article c’est le déploiement de TCE sur un cluster vSphere qui nous intéresse.

On indique les éléments de connexion au vCenter et on importe la clé publique SSH créée plus tôt.

Pour NSX Intelligence il faut sélectionner à minima une instance de type « Medium ».

L’ip du Control Plane Endpoit correspond à la VIP du cluster gérée par Kube-vip.

On laisse l’onglet VMware NSX ALB vide puisque nous utilisons Kube-vip

NAPP ne nécessite pas de configuration spécifique.

On indique le cluster ou sera déployé TCE.

On sélectionne le port group pour le réseau Tanzu.

On ne modifie pas les deux range IPs préremplis. Sauf si vous savez ce que vous faites.

Importants : Les VMs déployées par Tanzu nécessite un accès un internet pour récupérer les binaires. Si besoin vous pouvez configurer un proxy

Le service identity Management n’étant pas nécessaire on le désactive. Les droits de NSX Intelligence sont définis depuis l’interface NSX.

Vous vous souvenez du template que vous avez créé au début ? C’est le moment de l’indiquer dans le wizard pour permettre à TCE de se déployer.

On vérifie que la configuration avant déploiement.

Le Wizard permet de copier la ligne de commande à utiliser dans un terminal. L’information la plus importante est le chemin d’accès au fichier YAML de configuration du cluster de management.

Notez bien le chemin du fichier YAML. On en aura besoin pour la suite.

Je vous conseille d’exporter la configuration dans votre dossier utilisateur avant de lancer le déploiement. Il sera facilement accessible pour la suite.

Le Wizard possède d’un terminal intégré pour suivre le déploiement.

Le Wizard clone et configure les appliances

Après une quinzaine de minutes le déploiement se termine.

Coté vCenter.

Consommation après le déploiement (VM Bootstrap incluse)

Déploiement du Workload Cluster

Retour au terminal SSH pour la suite.

Configuration du fichier YAML

Pour déployer notre cluster k8s on copie le fichier YAML du Management Cluster pour le modifier et ne changer que les champs nécessaires.

Dans mon cas j’ai fait une copie sur le bureau

Ouvrez le yaml copié et changez les lignes suivantes avec les paramètres appropriés

• Un nom pour le cluster Workload
• Pour un déploiement lab changez « prod » par « dev ». Ce qui déploiera 1 CP et 1 Worker

CLUSTER_NAME: tcenapp
CLUSTER_PLAN: dev

• L’IP VIP du cluster Workload

VSPHERE_CONTROL_PLANE_ENDPOINT: 192.168.2.105

On doit modifier le profil matériel des appliances en accord avec les prés requis NAPP et NSX Intelligence

• Pour le Control Plane on change la ram et la taille du disque

VSPHERE_CONTROL_PLANE_DISK_GIB: "64"
VSPHERE_CONTROL_PLANE_ENDPOINT: 192.168.2.105
VSPHERE_CONTROL_PLANE_MEM_MIB: "4096"
VSPHERE_CONTROL_PLANE_NUM_CPUS: "2"

• On modifie les champs pour le nœud Worker

VSPHERE_WORKER_DISK_GIB: "1024"
VSPHERE_WORKER_MEM_MIB: "65536"
VSPHERE_WORKER_NUM_CPUS: "16"

On peut afficher les builds disponibles.

tanzu kubernetes-release

On note le nom de la version qui nous intéresse : v1.21.11—vmware.1-tkg.1-tf-v0.11.4

tanzu cluster create WORKLOAD-CLUSTER-NAME –file CONFIG-FILE –tkr v1.21.11—vmware.1-tkg.1-tf-v0.11.4

On est prêt à créer notre cluster Workload.

A l’instar du déploiement du cluster de management, TCE s’occupe de déployer et configurer les appliances.

Tcenapp est déployé !

Vue du vCenter

La nouvelle consommation de l’ensemble

Afin de pouvoir l’administrer il faut enregistrer le cluster dans la configuration de kubectl

tanzu cluster kubeconfig get <WORKLOAD-CLUSTER-NAME> --admin

On peut maintenant utiliser kubectl pour gérer notre Workload Cluster avec la commande

# Exécuter la commande afin de se connecter à notre nouveau cluster
kubectl config use-context CLUSTERNAME-admin@CLUSTERNAME

Création du fichier de configuration de NAPP avec un token non expirable

Pour cette étape je renvoi à la documentation VMware, la procédure consiste en de multiple copier- coller. Rien de complexe.

Il faut réaliser les étapes de 2 à 7.

Note : Modifier les champs « napp » avec le nom de votre cluster Workload. Dans mon cas c’est « tcenapp ». Je remplace par exemple les entrées « napp-admin » par « tcenapp-admin »

Note 2 : Indiquez le chemin où sera créé le YAML à la variable suivante :

TO_BE_CREATED_KUBECONFIG_FILE=”/home/Vince/Desktop/napp.yaml”

Configuration de MetalLB (Service DHCP pour NAPP)

NAPP nécessite un Service Name pour son fonctionnement. TCE propose plusieurs options.

Plus concrètement, la VIP et les ips utilisées par NAPP seront portées par le Service Name

# MetalLb  (12.1) se deploit en deux ligne de commandes
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.12.1/manifests/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.12.1/manifests/metallb.yaml 

Dans notre scénario nous n’avons pas accès aux fonctionnalité payantes de Tanzu. VMware supporte MetalLB dans un scénario « gratuit ».

Pour la suite on doit s’assurer d’être dans le bon contexte Kubectl (i.e Workload Cluster).

# Affichage du contexte actuel 
kubectl config current-context 

# Dans mon cas le résultat doit être 
tcenapp-admin@tcenapp 

MetalLb propose un template de configuration disponible ici. Copiez les lignes dans un nouveau fichier avec Nano et adaptez la plage ip.

Une fois adapté à mon environnement j’ai le document suivant :

Dans votre serveur DNS associez la première IP de votre range  à un nom pour NAPP. Dans mon cas j'ai choisi « napp.vincelab.local ».

# On applique la configuration 
kubectl apply -f metallb-config.yaml 

On peut retourner à notre console web NSX pour la suite.

On peut lancer le déploiement de NAPP

# Helm 
https://projects.registry.vmware.com/chartrepo/nsx_application_platform 

# Docker 
projects.registry.vmware.com/nsx_application_platform/clustering 

On commence par indiquer les repository Helm et Docker pour télécharger NAPP

Si les url sont validées le wizard indique la build qui sera déployée.

Cette onglet peut prendre un certain temps à se charger.

Pendant le chargement on peut en profiter pour récupérer sur mon bureau le fichier YAML crée à partir de la documentation VMware.

Charger le fichier YAML de NAPP.

Une fois le fichier chargé on sélectionne le Form Factor « Evaluation »

Indiquez le FQDN du service NAPP (1 ère IP du range MetalLb) - A enregistrer dans votre DNS cf étape précédente.

On exécute les pré checks. Le Warning est un rappel d’avoir les appliances NSX et TCE synchronisées sur l’heure.

On peut déployer NAPP.

Le déploiement prend quelques dizaines de minutes.

Activer la fonctionnalité Intelligence depuis l'onglet NAPP.

Quelques pré checks

Une fois les prés requis validés nous pouvons « activer » Intelligence.

Et au bout de 15 min…

Ce n’était pas bien compliqué !

Consommation active des ressources.