Orchestrez vos conteneurs avec Kubernetes

Identifiez l’utilité du service dans Kubernetes

Vous savez maintenant comment déployer le site web LiveCorp grâce au kind Deployment. Celui-ci déploie autant de pods qu’il est précisé dans le réplicas. Mais chaque pod reçoit sa propre adresse IP. Cela est embêtant quand on doit contacter tous les pods du site web.

Pour pallier cela et faire abstraction du concept de pod, Kubernetes a introduit la notion de service. Un service est un concept fondamental qui vous permet de regrouper et d'accéder à un ensemble de pods. L’application peut donc scaler le nombre de pod par rapport à la charge, le service saura toujours comment accéder aux pods de l’application.

Les pods sont éphémères. Leur adresse IP peut changer si un pod est recréé. Un service fournit alors une adresse IP stable et un nom DNS qui restent constants, même si les pods changent.

Le service joue alors le rôle de load balancer interne au cluster pour accéder à l’application déployée. Il fournit aussi un nom DNS prédictible sous la forme<nom_du_service>.<namespace>.svc.cluster.local. Cela est pratique par exemple pour spécifier le nom DNS de la base de données connecté à l’application, sans passer par l’adresse IP des pods.

Les autres applications de votre cluster peuvent facilement trouver et communiquer avec votre service en utilisant son nom DNS. C’est ce qu’on appelle la découverte de service.

Le service répartit aussi automatiquement le trafic entrant entre les pods qui lui sont associés, améliorant ainsi la disponibilité et les performances de votre application.

Enfin, les services de type LoadBalancer peuvent être utilisés pour exposer votre application à l'extérieur du cluster Kubernetes, par exemple sur Internet.

Excellente question ! Vous vous rappelez lors de l’écriture du déploiement, vous aviez mis des labels sur ce déploiement. Et bien, chaque service a un sélecteur de labels qui définit quels pods doivent être inclus dans le service. Par exemple, un sélecteur pourrait rechercher tous les pods avec le labelapp: mon-application. Dans le cas du site web LiveCorp, le service ira chercher tous les pods avec le labelapp: site-ecommerce. 

Chaque service se voit attribuer une adresse IP virtuelle stable (appelée ClusterIP) qui est accessible à l'intérieur du cluster et qui restera toujours la même quel que soit le redéploiement de pods.

Il existe principalement quatre types de service :

• ClusterIP (par défaut) : Kubernetes assigne une adresse IP virtuelle au service, accessible uniquement à l'intérieur du cluster. Cela est idéal pour les applications internes au cluster qui n'ont pas besoin d'être exposées à l'extérieur, par exemple une base de données backend accessible uniquement par vos applications web.

• NodePort : Le service est exposé sur un port statique de chaque nœud du cluster. Le trafic entrant sur ce port est acheminé vers le service. C’est très utile pour exposer temporairement un service pour des tests ou des outils de développement comme par exemple une application web en cours de développement à des testeurs externes.

• LoadBalancer : Cela va créer un load balancer externe qui distribue le trafic entrant vers les pods du service. C’est la  méthode standard pour exposer des applications au monde extérieur.

• ExternalName : Kubernetes va mapper le service à un nom DNS externe. Ce type de service est utilisé pour accéder à des services externes qui ne font pas partie du cluster Kubernetes ou pour migrer progressivement le trafic d'un service existant vers un nouveau service dans Kubernetes.

Si je résume :

Explorez les différentes sections d'un service

Maintenant que vous savez à quoi sert un service, il est temps d’écrire votre fichier YAML pour exposer l’application web de LiveCorp au travers d’un service.

Voici l’exemple de fichier service pour exposer le site web :

apiVersion: v1
kind: Service
metadata:
name: site-ecommerce-service
labels:
app: site-ecommerce
spec:
selector:
app: site-ecommerce
ports:
- protocol: TCP
port: 80  # Port exposé par le service
targetPort: 8080  # Port sur lequel le pod écoute
type: ClusterIP  # Type de service (ClusterIP, NodePort, LoadBalancer)

Regardons ensemble le contenu de ce fichier :

• apiVersion: La version de l'API Kubernetes utilisée pour définir le service. C’est la même version que lors du déploiement ;

• kind: Le type d'objet Kubernetes que vous créez (dans ce cas, un Service) ;

• name: Le nom unique du service dans votre cluster ;

• labels: C’est un label que vous allez mettre sur votre service afin  d’organiser et sélectionner des objets Kubernetes.

Le début du fichier service reste le même que celui du déploiement. La section d’aprèsspec  change par rapport au kind que vous allez créer. Dans le cas du service, voici ce qu’il faut mettre dans la sectionspec  :

• selector: Ce sont les labels utilisés pour identifier les pods qui appartiennent au service. Dans le cas du site web,app: site-ecommerce

La sectionports  est la section qui va spécifier une liste de port à accéder coté pods :

• protocol: Le protocole utilisé, soit TCP, soit UDP ;

• port: Le port sur lequel le service est exposé. Cela peut-être n’importe quel port ou vous voulez que votre service soit accessible ;

• targetPort: Le port sur lequel les pods ciblés écoutent. Il faut que le targetPort matche le port spéficié lors du déploiement ;

• type: Le type de service que l’on veut déployer (ClusterIP, NodePort, LoadBalancer, ExternalName).

Ce fichier est relativement simple comparé au déploiement où vous deviez détailler beaucoup d’informations avant d’avoir vos premiers pods déployés.

Écrivez votre premier fichier Service

Maintenant que vous connaissez les différentes sections du fichier service, il est temps de déployer votre premier service sur le cluster Kubernetes pour exposer votre application.

Voici le fichier qu’il va falloir créer et déployer sur le cluster Kubernetes :

apiVersion: v1
kind: Service
metadata:
name: site-ecommerce-service
labels:
app: site-ecommerce
spec:
selector:
app: site-ecommerce
ports:
- protocol: TCP
port: 80
targetPort: 8080
type: ClusterIP

Ce fichier service va alors créer un service accessible sous le nom DNS site-ecommerce-service.default.svc.cluster.local et qui répartira la charge sur les 5 pods déjà déployé.

D’abord, vérifiez bien que minikube est en cours d’exécution :

minikube status
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

Vous devriez voir un statut "Running" pour le cluster et la machine virtuelle. Ensuite, vérifiez quekubectl est configuré pour Minikube :

kubectl config current-context
minikube

Le résultat devrait indiquer "minikube".

Enfin déployez le service :

kubectl apply -f site-ecommerce-service.yaml

Le fichier devrait alors s’appliquer sur le cluster et créer le service. Pour vérifier que le service a bien été créé :

kubectl get services
NAME     TYPE    CLUSTER-IP   EXTERNAL-IP   PORT(S)      AGE
kubernetes   ClusterIP   10.96.0.1    <none>    443/TCP      26d
web      NodePort 10.101.222.162   <none>    8080:31634/TCP   8d

Vous devriez voir votre service listé avec son nom, son type et son ClusterIP.

Pour vérifier que le service fonctionne bien et redirige bien vers les pods déjà créé, vous pouvez démarrer un nouveau pod et accéder à l’url du service :

kubectl exec deploy/site-ecommerce-deployment -- curl http://site-ecommerce-service.default.svc.cluster.local

Cette commande va alors récupérer la page d’accueil du site ecommerce de LiveCorp que vous avez précédemment déployé.

Dans ce screencast, vous avez appris à :

• créer un service pour accéder aux pods de l’application ;

• vérifier que le service a bien été créé ;

• vérifier que le service fonctionnait bien.

À vous de jouer

Contexte

Alice : J’ai vu que tu avais déployé l’application dans le cluster Kubernetes. Malheureusement, aucun des membres de l’équipe ne peut accéder à l’application ! Es-tu sûr que tu as bien exposé l’application via un service ?

Consignes

1. Créez un fichier Service pour exposer l’application dans le cluster ;

2. Vérifiez que le service a bien été créé ;

3. Accédez à l’application via un curl et son nom DNS.

En résumé

• Le kind Service sert à exposer un Deployment au sein du cluster.

• Le nom du service est prédictible et toujours de la forme <nom_du_service>.<nom_du_namespace>.svc.cluster.local.

• Kubernetes se base sur la résolution DNS pour identifier les services exposés.

Dans le prochain chapitre, vous allez apprendre à persister les données d’un pod !