01. October 2023

Enoncé TP 8

TP8 : Deployment rolling upgrade & Probes

🇫🇷 Version Française

Deployment rolling upgrade

Upgrader le deployment de backend avec une nouvelle version de l’image 1.1 -> 1.2.

Que se passe t’il ?

Health probes

Rappel :

Dans le cas où un pod ne démarre pas, aucune requete n’arrive jusqu’au pod donc le service n’est pas interrompue.

En revanche, par exemple dans le cas où le pod démarre, mais n’arrive pas à exposer son API, les requetes qui arrivant maintenant sur le pod tombent en erreur.

Pour empécher ça, il faut ajouter des health probes pour autoriser/couper le routing sur le pod si celui ne marche pas.

Implémenter des Heallth probes (readiness / liveness) sur le backend.

l’image 1.3 du backend expose la route /health qui répond :

200 si connexion à la base ok et API ok

500 si connexion à la base ko

400 si API ko

La readiness se déclenchera après 3 secondes afins de laisser le backend exposé son API.

La liveness se déclenchera après 10 secondes pour laisser la readiness le temps de se mettre en place.

Le pod redémarrera si la liveness échoue deux fois consécutives et ces appels seront espacés de 5 secondes.

Notes: Ici on a choisi d’utiliser une readiness probe pour gérer les requêtes qui rentre dans le pod. L’avantage de la probe readiness c’est que si même au bout de 2h le pod se met à ne plus rendre son service, les requêtes ne seront pas redirigés vers ce pod.

Il existe un autre type de probe les startup probe, qui agit comme une readiness pour le démarrage d’un pod puis s’arrète et n’est plus joué. Vous pouvez implémenté une startup probe si vous le voulez.

🇬🇧 English version

Deployment rolling upgrade

Upgrade the backend deployment with a new version of the image 1.1 -> 1.2.

What is happening?

Health probes

Reminder:

When a pod does not start, no request reaches the pod so the service is not interrupted.

On the other hand, for example in the case where the pod starts, but cannot expose its API, the requests which now arrive on the pod fall in error.

To prevent this, you must add health probes to authorize/disable routing on the pod if it does not work.

Implement health probes (readiness / liveness) on the backend.

image 1.3 of the backend exposes the /health route which responds:

200 if connection to the base is ok and if the API is ok

500 if connected to the base is ko

400 if API is ko

Readiness will be triggered after 3 seconds to leave the backend exposed its API.

Liveness will be triggered after 10 seconds to give readiness time to set up.

The pod will restart if liveness fails twice in a row and these calls will be 5 seconds apart.

Notes: Here we chose to use a readiness probe to manage the requests that enter the pod. The advantage of the readiness probe is that if even after 2 hours the pod starts to no longer provide its service, the requests will not be redirected to this pod.

There is another type of probe, the startup probe, which acts as a readiness for starting a pod then stops and is no longer played. You can implement a startup probe if you want in addition of the readiness (as a best practice we must implement the 3 types of probes).