Skip to content

Commit 55892e5

Browse files
icheikhrouhouicheikhrouhou
committed
translate liveness fr
1 parent a29da47 commit 55892e5

File tree

4 files changed

+367
-0
lines changed

4 files changed

+367
-0
lines changed

‎content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md

Lines changed: 303 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,303 @@
1+
---
2+
title: Configurer les Liveness, Readiness et Startup Probes
3+
content_template: templates/task
4+
weight: 110
5+
---
6+
7+
{{% capture overview %}}
8+
9+
Cette page montre comment configurer les liveness, readiness and startup probes pour les conteneurs.
10+
11+
[Kubelet](/docs/admin/kubelet/) utilise les liveness probes pour détecter quand redémarrer un conteneur. Par exemple, Liveness probes pourraient attraper un deadlock, dans le cas où une application est en cours d'exécution, mais incapable de progresser. Le redémarrage d'un conteneur dans un tel état rend l'application plus disponible malgré les bugs.
12+
13+
Kubelet utilise readiness probes pour savoir quand un conteneur est prêt à accepter le trafic. Un Pod est considéré comme prêt lorsque tous ses conteneurs sont prêts.
14+
Ce signal sert notamment à contrôler les pods qui sont utilisés comme backends pour les Services. Lorsqu'un Pod n'est pas prêt, il est retiré des équilibreurs de charge des Services.
15+
16+
Kubelet utilise startup probes pour savoir quand une application d'un conteneur a démarré.
17+
Si une telle probe est configurée, elle désactive les contrôles de liveness and readiness jusqu'à cela réussit, en s'assurant que ces probes n'interfèrent pas avec le démarrage de l'application.
18+
Cela peut être utilisé dans le cas des liveness checks sur les conteneurs à démarrage lent, en les évitant de se faire tuer par le Kubelet avant qu'ils ne soient opérationnels.
19+
20+
{{% /capture %}}
21+
22+
{{% capture prerequisites %}}
23+
24+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
25+
26+
{{% /capture %}}
27+
28+
{{% capture steps %}}
29+
30+
## Définir une commande de liveness
31+
32+
De nombreuses applications fonctionnant pour de longues périodes finissent par passer à des états de rupture et ne peuvent pas se rétablir, sauf en étant redémarrées. Kubernetes fournit
33+
des liveness probes pour détecter et remédier à ces situations.
34+
35+
Dans cet exercice, vous allez créer un Pod qui exécute un conteneur basé sur l'image `k8s.gcr.io/busybox`. Voici le fichier de configuration pour le Pod :
36+
37+
{{< codenew file="pods/probe/exec-liveness.yaml" >}}
38+
39+
Dans le fichier de configuration, vous constatez que le Pod a un seul conteneur.
40+
Le champ `periodSeconds` spécifie que le Kubelet doit effectuer un check de liveness toutes les 5 secondes. Le champ `initialDelaySeconds` indique au Kubelet qu'il devrait attendre 5 secondes avant d'effectuer la première probe. Pour effectuer une probe, le Kubelet exécute la commande `cat /tmp/healthy` dans le conteneur. Si la commande réussit, elle renvoie 0, et le Kubelet considère que le conteneur est vivant et en bonne santé. Si la commande renvoie une valeur non nulle, le Kubelet tue le conteneur et le redémarre.
41+
42+
Au démarrage, le conteneur exécute cette commande :
43+
44+
```shell
45+
/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"
46+
```
47+
48+
Pour les 30 premières secondes de la vie du conteneur, il y a un fichier `/tmp/healthy`.
49+
Donc pendant les 30 premières secondes, la commande `cat /tmp/healthy` renvoie un code de succès. Après 30 secondes, `cat /tmp/healthy` renvoie un code d'échec.
50+
51+
Créez le Pod :
52+
53+
```shell
54+
kubectl apply -f https://k8s.io/examples/pods/probe/exec-liveness.yaml
55+
```
56+
57+
Dans les 30 secondes, visualisez les événements du Pod :
58+
59+
```shell
60+
kubectl describe pod liveness-exec
61+
```
62+
63+
La sortie indique qu'aucune liveness probe n'a encore échoué :
64+
65+
```shell
66+
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
67+
--------- -------- ----- ---- ------------- -------- ------ -------
68+
24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
69+
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"
70+
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"
71+
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
72+
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
73+
```
74+
75+
Après 35 secondes, visualisez à nouveau les événements du Pod :
76+
77+
```shell
78+
kubectl describe pod liveness-exec
79+
```
80+
81+
Au bas de la sortie, il y a des messages indiquant que les liveness probes ont échoué, et que les conteneurs ont été tués et recréés.
82+
83+
```shell
84+
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
85+
--------- -------- ----- ---- ------------- -------- ------ -------
86+
37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
87+
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"
88+
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"
89+
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
90+
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
91+
2s 2s 1 {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
92+
```
93+
94+
Attendez encore 30 secondes et vérifiez que le conteneur a été redémarré :
95+
96+
```shell
97+
kubectl get pod liveness-exec
98+
```
99+
100+
La sortie montre que `RESTARTS` a été incrémenté :
101+
102+
```shell
103+
NAME READY STATUS RESTARTS AGE
104+
liveness-exec 1/1 Running 1 1m
105+
```
106+
107+
## Définir une requête HTTP de liveness
108+
109+
Un autre type de liveness probe utilise une requête GET HTTP. Voici la configuration
110+
d'un Pod qui fait fonctionner un conteneur basé sur l'image `k8s.gcr.io/liveness`.
111+
112+
{{< codenew file="pods/probe/http-liveness.yaml" >}}
113+
114+
Dans le fichier de configuration, vous pouvez voir que le Pod a un seul conteneur.
115+
Le champ `periodSeconds` spécifie que le Kubelet doit effectuer une liveness probe toutes les 3 secondes. Le champ `initialDelaySeconds` indique au Kubelet qu'il
116+
devrait attendre 3 secondes avant d'effectuer la première probe. Pour effectuer une probe, le Kubelet envoie une requête HTTP GET au serveur qui s'exécute dans le conteneur et écoute sur le port 8080. Si le handler du chemin `/healthz` du serveur renvoie un code de succès, le Kubelet considère que le conteneur est vivant et
117+
en bonne santé. Si le handler renvoie un code d'erreur, le Kubelet tue le conteneur et le redémarre.
118+
119+
Tout code supérieur ou égal à 200 et inférieur à 400 indique un succès. Tout autre code indique un échec.
120+
121+
Vous pouvez voir le code source du serveur dans
122+
[server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go).
123+
124+
Pendant les 10 premières secondes où le conteneur est en vie, le handler `/healthz` renvoie un statut de 200. Après cela, le handler renvoie un statut de 500.
125+
126+
```go
127+
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
128+
duration := time.Now().Sub(started)
129+
if duration.Seconds() > 10 {
130+
w.WriteHeader(500)
131+
w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds())))
132+
} else {
133+
w.WriteHeader(200)
134+
w.Write([]byte("ok"))
135+
}
136+
})
137+
```
138+
139+
Le Kubelet commence à effectuer des contrôles de santé 3 secondes après le démarrage du conteneur.
140+
Ainsi, les premiers contrôles de santé seront réussis. Mais après 10 secondes, les contrôles de santé échoueront, et le Kubelet tuera et redémarrera le conteneur.
141+
142+
Pour essayer le HTTP liveness check, créez un Pod :
143+
144+
```shell
145+
kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml
146+
```
147+
148+
Après 10 secondes, visualisez les événements du Pod pour vérifier que les liveness probes ont échoué et le conteneur a été redémarré :
149+
150+
```shell
151+
kubectl describe pod liveness-http
152+
```
153+
154+
Dans les versions antérieures à la v1.13 (y compris la v1.13), au cas où la variable d'environnement `http_proxy` (ou `HTTP_PROXY`) est définie sur le noeud où tourne un Pod, le HTTP liveness probe utilise ce proxy.
155+
Dans les versions postérieures à la v1.13, les paramètres de la variable d'environnement du HTTP proxy local n'affectent pas le HTTP liveness probe.
156+
157+
## Définir une TCP liveness probe
158+
159+
Un troisième type de liveness probe utilise un TCP Socket. Avec cette configuration, le Kubelet tentera d'ouvrir un socket vers votre conteneur sur le port spécifié.
160+
S'il arrive à établir une connexion, le conteneur est considéré comme étant en bonne santé, s'il n'y arrive pas, c'est un échec.
161+
162+
{{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}}
163+
164+
Comme vous le voyez, la configuration pour un check TCP est assez similaire à un check HTTP.
165+
Cet exemple utilise à la fois des readiness et liveness probes. Kubelet transmettra la première readiness probe 5 secondes après le démarrage du conteneur. Il tentera de se connecter au conteneur `goproxy` sur le port 8080. Si la probe réussit, le conteneur sera marqué comme prêt. Kubelet continuera à effectuer ce check tous les 10 secondes.
166+
167+
En plus de la readiness probe, cette configuration comprend une liveness probe.
168+
Kubelet effectuera la première liveness probe 15 secondes après que le conteneur démarre. Tout comme la readiness probe, celle-ci tentera de se connecter au conteneur de `goproxy` sur le port 8080. Si la liveness probe échoue, le conteneur sera redémarré.
169+
170+
Pour essayer la TCP liveness check, créez un Pod :
171+
172+
```shell
173+
kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml
174+
```
175+
176+
Après 15 secondes, visualisez les événements de Pod pour vérifier les liveness probes :
177+
178+
```shell
179+
kubectl describe pod goproxy
180+
```
181+
182+
## Utilisation d'un port nommé
183+
184+
Vous pouvez utiliser un [ContainerPort](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerport-v1-core) nommé pour les HTTP or TCP liveness probes :
185+
186+
```yaml
187+
ports:
188+
- name: liveness-port
189+
containerPort: 8080
190+
hostPort: 8080
191+
192+
livenessProbe:
193+
httpGet:
194+
path: /healthz
195+
port: liveness-port
196+
```
197+
198+
## Protéger les conteneurs à démarrage lent avec des startup probes {#define-startup-probes}
199+
200+
Parfois, vous devez faire face à des applications legacy qui peuvent nécessiter un temps de démarrage supplémentaire lors de leur première initialisation.
201+
Dans de telles situations, il peut être compliqué de régler les paramètres de la liveness probe sans compromettant la réponse rapide aux blocages qui ont motivé une telle probe.
202+
L'astuce est de configurer une startup probe avec la même commande, HTTP ou TCP check avec un `failureThreshold * periodSeconds` assez long pour couvrir le pire des scénarios des temps de démarrage.
203+
204+
Ainsi, l'exemple précédent deviendrait :
205+
206+
```yaml
207+
ports:
208+
- name: liveness-port
209+
containerPort: 8080
210+
hostPort: 8080
211+
212+
livenessProbe:
213+
httpGet:
214+
path: /healthz
215+
port: liveness-port
216+
failureThreshold: 1
217+
periodSeconds: 10
218+
219+
startupProbe:
220+
httpGet:
221+
path: /healthz
222+
port: liveness-port
223+
failureThreshold: 30
224+
periodSeconds: 10
225+
```
226+
227+
Grâce à la startup probe, l'application aura un maximum de 5 minutes (30 * 10 = 300s) pour terminer son démarrage.
228+
Une fois que la startup probe a réussi, la liveness probe prend le relais pour fournir une réponse rapide aux blocages de conteneurs.
229+
Si la startup probe ne réussit jamais, le conteneur est tué après 300s puis soumis à la `restartPolicy` (politique de redémarrage) du Pod.
230+
231+
## Définir les readiness probes
232+
233+
Parfois, les applications sont temporairement incapables de servir le trafic.
234+
Par exemple, une application peut avoir besoin de charger des larges données ou des fichiers de configuration pendant le démarrage, ou elle peut dépendre de services externes après le démarrage.
235+
Dans ces cas, vous ne voulez pas tuer l'application, mais tu ne veux pas non plus lui envoyer de requêtes. Kubernetes fournit des readiness probes pour détecter et atténuer ces situations. Un pod avec des conteneurs qui signale qu'elle n'est pas prête ne reçoit pas de trafic par les services de Kubernetes.
236+
237+
{{< note >}}
238+
Readiness probes fonctionnent sur le conteneur pendant tout son cycle de vie.
239+
{{< /note >}}
240+
241+
Readiness probes sont configurées de la même façon que les liveness probes. La seule différence est que vous utilisez le champ `readinessProbe` au lieu du champ `livenessProbe`.
242+
243+
```yaml
244+
readinessProbe:
245+
exec:
246+
command:
247+
- cat
248+
- /tmp/healthy
249+
initialDelaySeconds: 5
250+
periodSeconds: 5
251+
```
252+
253+
La configuration des readiness probes HTTP et TCP reste également identique à celle des liveness probes.
254+
255+
Les readiness et liveness probes peuvent être utilisées en parallèle pour le même conteneur.
256+
L'utilisation des deux peut garantir que le trafic n'atteigne pas un conteneur qui n'est pas prêt et que les conteneurs soient redémarrés en cas de défaillance.
257+
258+
## Configurer les Probes
259+
260+
{{< comment >}}
261+
Éventuellement, une partie de cette section pourrait être déplacée vers un sujet conceptuel.
262+
{{< /comment >}}
263+
264+
[Probes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) ont un certain nombre de champs qui vous pouvez utiliser pour contrôler plus précisément le comportement de la vivacité et de la disponibilité des probes :
265+
266+
* `initialDelaySeconds`: Nombre de secondes après le démarrage du conteneur avant que les liveness et readiness probes ne soient lancées. La valeur par défaut est de 0 seconde. La valeur minimale est 0.
267+
* `periodSeconds`: La fréquence (en secondes) à laquelle la probe doit être effectuée. La valeur par défaut est de 10 secondes. La valeur minimale est de 1.
268+
* `timeoutSeconds`: Nombre de secondes après lequel la probe time out. Valeur par défaut à 1 seconde. La valeur minimale est de 1.
269+
* `successThreshold`: Le minimum de succès consécutifs pour que la probe soit considérée comme réussie après avoir échoué. La valeur par défaut est 1. Doit être 1 pour la liveness probe. La valeur minimale est de 1.
270+
* `failureThreshold`: Quand un Pod démarre et que la probe échoue, Kubernetes va tenter pour un temps de `failureThreshold` avant d'abandonner. Abandonner en cas de liveness probe signifie redémarrer le conteneur. En cas de readiness probe, le Pod sera marqué Unready.
271+
La valeur par défaut est 3, la valeur minimum est 1.
272+
273+
[HTTP probes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)
274+
ont des champs supplémentaires qui peuvent être définis sur `httpGet` :
275+
276+
* `host`: Nom de l'hôte auquel se connecter, par défaut l'IP du pod. Vous voulez peut être mettre "Host" en httpHeaders à la place.
277+
* `scheme`: Schéma à utiliser pour se connecter à l'hôte (HTTP ou HTTPS). La valeur par défaut est HTTP.
278+
* `path`: Chemin d'accès sur le serveur HTTP.
279+
* `httpHeaders`: En-têtes personnalisés à définir dans la requête. HTTP permet des en-têtes répétés.
280+
* `port`: Nom ou numéro du port à accéder sur le conteneur. Le numéro doit être dans un intervalle de 1 à 65535.
281+
282+
Pour une probe HTTP, Kubelet envoie une requête HTTP au chemin et au port spécifiés pour effectuer la vérification. Kubelet envoie la probe à l'adresse IP du Pod, à moins que l'adresse ne soit surchargée par le champ optionnel `host` dans `httpGet`. Si Le champ `scheme` est mis à `HTTPS`, Kubelet envoie une requête HTTPS en ignorant la vérification du certificat. Dans la plupart des scénarios, vous ne voulez pas définir le champ `host`.
283+
Voici un scénario où vous le mettriez en place. Supposons que le conteneur écoute sur 127.0.0.1 et que le champ `hostNetwork` du Pod a la valeur true. Alors `host`, sous `httpGet`, devrait être défini
284+
à 127.0.0.1. Si votre Pod repose sur des hôtes virtuels, ce qui est probablement plus courant, vous ne devriez pas utiliser `host`, mais plutôt mettre l'en-tête `Host` dans `httpHeaders`.
285+
286+
Kubelet fait la connexion de la probe au noeud, pas dans le Pod, ce qui signifie que vous ne pouvez pas utiliser un nom de service dans le paramètre `host` puisque Kubelet est incapable pour le résoudre.
287+
288+
{{% /capture %}}
289+
290+
{{% capture whatsnext %}}
291+
292+
* Pour en savoir plus sur
293+
[Probes des Conteneurs](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
294+
295+
### Référence
296+
297+
* [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
298+
* [Conteneur](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
299+
* [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
300+
301+
{{% /capture %}}
302+
303+

‎content/fr/examples/pods/probe/exec-liveness.yaml

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
apiVersion: v1
2+
kind: Pod
3+
metadata:
4+
labels:
5+
test: liveness
6+
name: liveness-exec
7+
spec:
8+
containers:
9+
- name: liveness
10+
image: k8s.gcr.io/busybox
11+
args:
12+
- /bin/sh
13+
- -c
14+
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
15+
livenessProbe:
16+
exec:
17+
command:
18+
- cat
19+
- /tmp/healthy
20+
initialDelaySeconds: 5
21+
periodSeconds: 5

‎content/fr/examples/pods/probe/http-liveness.yaml

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
apiVersion: v1
2+
kind: Pod
3+
metadata:
4+
labels:
5+
test: liveness
6+
name: liveness-http
7+
spec:
8+
containers:
9+
- name: liveness
10+
image: k8s.gcr.io/liveness
11+
args:
12+
- /server
13+
livenessProbe:
14+
httpGet:
15+
path: /healthz
16+
port: 8080
17+
httpHeaders:
18+
- name: Custom-Header
19+
value: Awesome
20+
initialDelaySeconds: 3
21+
periodSeconds: 3

‎content/fr/examples/pods/probe/tcp-liveness-readiness.yaml

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
apiVersion: v1
2+
kind: Pod
3+
metadata:
4+
name: goproxy
5+
labels:
6+
app: goproxy
7+
spec:
8+
containers:
9+
- name: goproxy
10+
image: k8s.gcr.io/goproxy:0.1
11+
ports:
12+
- containerPort: 8080
13+
readinessProbe:
14+
tcpSocket:
15+
port: 8080
16+
initialDelaySeconds: 5
17+
periodSeconds: 10
18+
livenessProbe:
19+
tcpSocket:
20+
port: 8080
21+
initialDelaySeconds: 15
22+
periodSeconds: 20

0 commit comments

Comments
 (0)