Déploiement avec Kubernetes

Nous avons dans la partie précédente comment déployer l’application du livre d’or sur une même machine en utilisant docker. Nous avons téléchargé les images et lancé manuellement les conteneurs. L’application était alors fonctionnelle. Cependant, les conteneurs ne sont pas monitorés. Si l’un d’eux venait à tomber, il ne serait donc pas remplacé automatiquement et l’application serait défaillante. Aussi, admettons que notre application rencontre un franc succès. Et que le nombre de clients augmente considérablement, à tel point que les conteneurs ne supportent plus la charge. L’application deviendrait alors indisponible.

Avec Kubernetes, les pods hébergeant les conteneurs, sont monitorés. Si l’un d’eux tombe, il est remplacé. Aussi, on peut demander à Kubernetes de redimensionner le cluster si besoin. Nous allons, durant cet exercice, déployer la même application du livre d’or, mais en utilisant cette fois Kubernetes. Pour rappel, cet exercice s’inspire du tutoriel disponible sur le site de kubernetes.

Prise en main :

Le cluster sur lequel sera installée l’application a été déployé avec l’outil minikube. L’interface de ligne de commande est kubectl. Kubectl est configuré pour gérer le cluster Kubernetes qui se trouve au sein de la VM créée par Minikube (lorsque plusieurs clusters sont disponibles, la commande use-context permet de sélectionner le cluster que l’on veut manipuler avec kubectl) :

La configuration du cluster se fait donc depuis la machine physique hôte avec kubectl. Il est aussi possible de se connecter en ssh sur la VM qui héberge le cluster en tapant minikube ssh :

Une fois dans la VM, on retrouve avec docker ps les composants indispensables à un cluster Kubernetes (etcd, kube-controller-manager, kube-scheduler etc…) :

On peut vérifier l’état du cluster avec les commandes kubectl get componentstatus et cluster-info :

Déploiement du redis-master:

Notre cluster Kubernetes étant fonctionnel, nous pouvons déployer notre application.

Nous allons commencer par la création de la base de données master. Pour cela, nous allons créer un pod qui contient un conteneur hébergeant la base de données. Nous allons aussi créer un service portant le nom redis-master. Ce service pointera sur le pod qui héberge la base de données master. Le service portera toujours la même adresse IP qui sera consultable par les autres pods à travers le service dns.

Dans le langage Kubernetes, on dit que la création de pods se fait via un ReplicaSet. Et un ReplicaSet est déployé à travers un Deployment. Un Deployment est définit par un fichier yaml.

Pour la base de données master, le Deployment est le suivant :

A la lecture du fichier, on retrouve plusieurs informations :

replicas : le nombre de pods que l’on veut pour ce deployment. Le master s’assurera que le nombre de pods fonctionnels pour ce deployment soit égal au nombre spécifié et ce à tout moment. Ce nombre peut être changé par la suite,
labels : tags utilisés pour l’identification,
image : l’image à partir de laquelle le conteneur sera construit. On retrouve l’adresse que nous avons utilisée pour le premier exercice avec docker.
ressources : les ressources réservées pour le conteneurs

Pour lancer le deployment, on utilise la commande kubectl apply :

Note : Le fichier yaml est directement disponible sous https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml

Nous avons donc maintenant un pod hebergeant une base de données redis. On peut le voir avec kubectl get-pods :

Nous pouvons déployer désormais le service redis-master. Un service se définit également par un fichier yaml :

Le fichier indique que tous les pods porteurs des labels app : redis, role : master, tier : backend seront associés au service redis-master (name : redis-master). Le service sera accessible sur le port 6379 (port : 6379), et renverra le flux aux pods sur le port 6379 également (targetPort : 6379). Ladresse ‘IP est connue après création.

Nous créons le service avec la commande kubectl apply :

Avec kubectl get service, on retrouve bien notre service tout juste créé :

Déploiement redis-slave :

Pour la base de données slave, la mise en place est similaire. A la différence que nous allons créer 2 réplicas au lieu d’un seul comme nous avons fait pour la base de données master. Ce qui veut dire que l’on aura deux pods, chacun avec un container hébergeant une base de données redis slave. Ces pods seront accessible via l’IP de service. Service qui partagera la charge entre les deux pods.

La définition du deployment pour les pods redis-slave (fichier disponible sous https://k8s.io/examples/application/guestbook/redis-slave-deployment.yaml) :

On remarque une différence avec le deployment du redis-master, c’est la présence du paramètre env. Ici, on indique que les pods créés à travers ce deployment devront utiliser le service dns pour résoudre les correspondance IP — Host qui leurs sont inconnues.

La définition du service (fichier disponible sous https://k8s.io/examples/application/guestbook/redis-slave-service.yaml) :

Déploiement frontend :

Pour le frontend, nous déployons 3 réplicas (fichier disponible sous https://k8s.io/examples/application/guestbook/frontend-deployment.yaml) :

Le service doit être accessible depuis l’extérieur du cluster, donc depuis l’extérieur de la VM hébergeant le cluster. On l’indique sur le fichier de configuration avec le paramètre type : NodePort (fichier disponible sous https://k8s.io/examples/application/guestbook/frontend-service.yaml)

Note : le port à utiliser pour le service n’est pas spécifié. Il sera donc choisi aléatoirement par le master du cluster.

Tous les pods et tous les services sont désormais déployés :

Pour connaitre l’IP externe du service frontend, on utilise la commande minikube service frontend — url :

Il ne nous reste qu’à vérifier que le livre d’or est bien accessible, en tapant l’url retournée par la commande minikube service frontend — url :

Notre application est donc bien fonctionnelle et accessible depuis l’extérieur du cluster. Nous avons deux instances de base de données redis-slave, une instance de base de données redis-master et trois instances de frontend :

Test de recovery :

Nous avons vu plus haut que Kubernetes garantit le monitoring des pods (et donc des conteneurs) ainsi que le maintien du nombre de pods pour un service donné. Nous pouvons tester cela en arrêtant manuellement un pod. Par exemple, un des trois conteneurs frontend :

Rescaling :

Avec Kubernetes, il est possible de redimensionner un deployment et ce à chaud avec la commande kubectl scale deployment. Par exemple, si on veut cinq pods pour le deployment frontend au lieu de trois initialement, on tapera la commande kubectl scale deployment frontend –replicas=5 :