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 :

 

 

 

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

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) :