Guide et instructions

1. Objectifs

  • Déployer une application multi-container
  • Exposer l’application via un service

2. Introduction

Créez un dossier « lab04 » et basculez dans ce dossier

mkdir lab04
cd lab04

3. Déploiement d’une application

Cet « exercice » est un exemple d’actions montrant une façon de déployer une application multi container et son exposition via l’objet service. La première partie sera faite en mode impératif (« kubectl » uniquement) ensuite on va utiliser les manifeste « yaml » en mode déclaratif. L’application utilisée est tirée du J. Petazzoni (société Docker). L’application est un générateur de « coins », une pseudo-monnaie virtuelle imaginaire. L’application est découpée en 5 micro-services:

  • Un service rng générant des nombres aléatoires
  • Un service hasher calculant des hash
  • Une base donnée redis
  • Un « worker » générant un “coin” toutes les secondes en s’appuyant sur rng et hasher. Le dockercoin est stocké dans la base redis
  • Une IHM webui affichant le nombre de coins générés par seconde en quasi-temps réel dockercoins

3.1 CLI kubectl

On va commencer par déployer le composant « redis » avec la commande suivante:

kubectl create deployment redis --image=redis

Ensuite on va déployer les autres services:

kubectl create deployment hasher --image=dockercoins/hasher:v0.1
kubectl create deployment rng --image=dockercoins/rng:v0.1
kubectl create deployment webui --image=dockercoins/webui:v0.1
kubectl create deployment worker --image=dockercoins/worker:v0.1

Challenge

Supprimez les déploiements des composants hasher, rng, webui, worker. Scripter le déploiement de ces composants dans un fichier « deploy_app_coins.sh » avec une boucle et variabilisez les composant ainsi que le registre (Registry) des images et leurs tags.

Vérifiez les objets «deployment»

kubectl get  deploy -o wide

Après avoir déployer les services regardant les logs des services rng et worker

kubectl logs deploy/rng
kubectl logs deploy/worker

Qu’est-ce que vous constatez ? Regardez le schéma de l’application, on doit exposer des ports des composants redis, rng et hasher.

kubectl expose deployment redis --port 6379
kubectl expose deployment rng --port 80
kubectl expose deployment hasher --port 80

Vérifiez à nouveau les logs du service worker.

kubectl logs deploy/worker --follow

Maintenant, on veut accéder à l’interface web de cette application. Pour cela il est nécessaire de passer par un service. Le service remplira plusieurs rôles :

  • Création d’une entrée DNS stable dans Kubernetes.
  • Mise à jour de l’entrée DNS du service en cas de changement de pod.
  • Répartition de la charge dans le cas où le déploiement procéderait à la création de plusieurs pods. On va utiliser le service de type « NodePort ». La création du service se fait avec la commande suivante:
kubectl expose deploy/webui --type=NodePort --port=80

Affichez le port associé à ce service

kubectl get svc

Le service est maintenant créé. Cela va créer une nouvelle adresse DNS au sein du cluster Kubernetes. Malheureusement, depuis l’extérieur du cluster, avec un service « NodePort » il n’est pas possible d’interroger le serveur DNS de Kubernetes. On peut passer par l’ip du node http://node-ip-address:3xxxx, mais comme notre cluster est basé sur minikube et le driver est « docker » on va passer par du « port-forward »

kubectl port-forward  --address 0.0.0.0  services/webui 8081:80

Ouvrez l’interface via http://[LAB_ENVIRONMENT_IP]:8081

Supprimez toutes les ressources de cette application

kubectl delete svc --all
kubectl delete deploy --all

3.2 Déploiement avec un manifeste YAML

Dans exercice il faut refaire le déploiement de l’application « appcoins » on utilisant un seul manifeste app-coins.yaml. Exposez le composant « webui » avec un service de type « LoadBalancer » sur le port 8081. Pour mettre plusieurs objets dans le manifeste utilisez le séparateur « — »

kind: ...
apiVersion: ...
metadata: ...
  name: ...
 ...
 ---
kind: ...
apiVersion: ...
metadata: ...
  name: ...
 ...

Ou sous forme d’une liste comme suit :

apiVersion: v1
kind: List
items:
 - kind: ...
   apiVersion: ...
   ...
 - kind: ...
   apiVersion: ...
   ...

Appliquez le manifeste avec la commande suivante:

kubectl apply -f app-coins.yaml --prune --all

« –prune » : supprimera les ressources qui n’existent pas dans le manifeste YAML

Listez les services

kubectl get services

Comme on est sous minukube, le service « webui » va affichez l’ip externe “en attente” (pending ). Pour remédier à ça, utilisez un autre terminal et lancez la création d’un tunnel.

minikube -p kubelabs tunnel

Dans un autre terminal lancez

kubectl port-forward --address 0.0.0.0 services/webui 8081:8081

Ouvrez l’interface via http://[LAB_ENVIRONMENT_IP]:8081 Scalez le « deployment » worker

kubectl scale deployment worker --replicas=3

Que constatez-vous sur l’IHM ?

3.3 DaemonSet

On veut scaler le composant « rng », on va utiliser l’objet « daemonSet », car c’est un service qui produit des données et il faut s’assurer qu’il est toujours disponible.

Un DaemonSet est un objet Kubernetes qui garantit que la copie d’un pod défini dans la configuration est toujours disponible sur chaque nœud Worker d’un cluster. Quand un nouveau nœud est ajouté à un cluster, le DaemonSet alloue automatiquement le pod sur ce nœud. Pour créer cet objet, on va passer un manifeste. Pour créer ce manifeste on va suivre les étapes suivantes:

kubectl get deploy/rng -o yaml > rng.yaml

Éditez le fichier rng.yaml replacer la valeur du champs « kind : Deployment» par « kind :DaemonSet » et supprimer les sections et champs suivants :

  • replicas
  • strategy
  • progressDeadlineSeconds
  • annotations
  • creationTimestamp
  • status: {}

Appliquez ce manifeste

kubectl apply -f rng.yml

Listez les « DaemonSet »

kubectl get ds

Listez les pods pour confirmer que dans chaque node worker (avec minikuke aussi dans contrôle plane node) on a un pod « rng »

kubectl get pods -o wide

Confirmez aussi que la cadence de génération des coins à augmenter dans l’IHM web.

Supprimez et nettoyez les ressources créées

kubectl delete -f rng.yaml
kubectl delete ds rng