Chapitre 12. Contrôler l'état de santé des applications à l'aide de bilans de santé
Dans les systèmes logiciels, les composants peuvent devenir malsains en raison de problèmes transitoires tels qu'une perte de connectivité temporaire, des erreurs de configuration ou des problèmes avec des dépendances externes. Les applications OpenShift Container Platform disposent d'un certain nombre d'options pour détecter et gérer les conteneurs malsains.
12.1. Comprendre les bilans de santé
Un contrôle de santé effectue périodiquement des diagnostics sur un conteneur en cours d'exécution à l'aide de n'importe quelle combinaison des contrôles de disponibilité, d'état de marche et de démarrage.
Vous pouvez inclure une ou plusieurs sondes dans la spécification du module qui contient le conteneur que vous souhaitez contrôler.
Si vous souhaitez ajouter ou modifier des contrôles de santé dans un pod existant, vous devez éditer l'objet pod DeploymentConfig ou utiliser la perspective Developer dans la console web. Vous ne pouvez pas utiliser l'interface de commande pour ajouter ou modifier les contrôles de santé d'un module existant.
- Sondage sur l'état de préparation
Un readiness probe détermine si un conteneur est prêt à accepter des demandes de service. Si la sonde de préparation échoue pour un conteneur, le kubelet supprime le pod de la liste des points de terminaison de service disponibles.
Après un échec, la sonde continue d'examiner le module. Si le pod devient disponible, le kubelet l'ajoute à la liste des points d'extrémité de service disponibles.
- Bilan de santé du caractère vivant
Un liveness probe détermine si un conteneur est toujours en cours d'exécution. Si la sonde d'intégrité échoue en raison d'une condition telle qu'un blocage, le kubelet tue le conteneur. Le pod répond alors en fonction de sa politique de redémarrage.
Par exemple, une sonde de vivacité sur un pod avec un
restartPolicydeAlwaysouOnFailuretue et redémarre le conteneur.- Sonde de démarrage
Une adresse startup probe indique si l'application au sein d'un conteneur est démarrée. Toutes les autres sondes sont désactivées jusqu'à ce que le démarrage réussisse. Si la sonde de démarrage ne réussit pas dans un délai spécifié, le kubelet tue le conteneur, et le conteneur est soumis au pod
restartPolicy.Certaines applications peuvent nécessiter un temps de démarrage supplémentaire lors de leur première initialisation. Vous pouvez utiliser une sonde de démarrage avec une sonde de disponibilité ou de préparation pour retarder cette sonde suffisamment longtemps pour gérer un temps de démarrage prolongé à l'aide des paramètres
failureThresholdetperiodSeconds.For example, you can add a startup probe, with a
failureThresholdof 30 failures and aperiodSecondsof 10 seconds (30 * 10s = 300s) for a maximum of 5 minutes, to a liveness probe. After the startup probe succeeds the first time, the liveness probe takes over.
Vous pouvez configurer des sondes de disponibilité, d'état de préparation et de démarrage avec l'un des types de tests suivants :
HTTP
GET: Lors de l'utilisation d'un test HTTPGET, le test détermine l'état de santé du conteneur à l'aide d'un crochet web. Le test est réussi si le code de réponse HTTP est compris entre200et399.Vous pouvez utiliser un test HTTP
GETavec des applications qui renvoient des codes d'état HTTP lorsqu'elles sont complètement initialisées.-
Commande de conteneur : Lors d'un test de commande de conteneur, la sonde exécute une commande à l'intérieur du conteneur. La sonde est réussie si le test se termine avec un état
0. - Socket TCP : Lors de l'utilisation d'un test de socket TCP, la sonde tente d'ouvrir un socket vers le conteneur. Le conteneur n'est considéré comme sain que si la sonde peut établir une connexion. Vous pouvez utiliser un test de socket TCP avec des applications qui ne commencent à écouter qu'une fois l'initialisation terminée.
Vous pouvez configurer plusieurs champs pour contrôler le comportement d'une sonde :
-
initialDelaySeconds: Le temps, en secondes, après le démarrage du conteneur avant que la sonde puisse être programmée. La valeur par défaut est 0. -
periodSeconds: Délai, en secondes, entre l'exécution des sondes. La valeur par défaut est10. Cette valeur doit être supérieure àtimeoutSeconds. -
timeoutSeconds: Le nombre de secondes d'inactivité après lesquelles la sonde s'arrête et le conteneur est considéré comme ayant échoué. La valeur par défaut est1. Cette valeur doit être inférieure àperiodSeconds. -
successThreshold: Nombre de fois où la sonde doit signaler un succès après un échec pour que l'état du conteneur soit rétabli. La valeur doit être1pour une sonde d'intégrité. La valeur par défaut est1. failureThreshold: Le nombre de fois que la sonde est autorisée à échouer. La valeur par défaut est 3. Après les tentatives spécifiées :- pour une enquête sur l'état de conservation, le conteneur est redémarré
-
pour une sonde de disponibilité, le pod est marqué
Unready -
pour une sonde de démarrage, le conteneur est tué et est soumis à l'autorité de contrôle du pod
restartPolicy
Exemples de sondes
Voici des exemples de sondes différentes telles qu'elles apparaîtraient dans une spécification d'objet.
Échantillon de sonde de préparation avec un conteneur commande sonde de préparation dans un pod spec
apiVersion: v1
kind: Pod
metadata:
labels:
test: health-check
name: my-application
...
spec:
containers:
- name: goproxy-app 1
args:
image: registry.k8s.io/goproxy:0.1 2
readinessProbe: 3
exec: 4
command: 5
- cat
- /tmp/healthy
...
Exemple de sonde de démarrage de commande de conteneur et de sonde de vivacité avec des tests de commande de conteneur dans une spécification de pod
apiVersion: v1
kind: Pod
metadata:
labels:
test: health-check
name: my-application
...
spec:
containers:
- name: goproxy-app 1
args:
image: registry.k8s.io/goproxy:0.1 2
livenessProbe: 3
httpGet: 4
scheme: HTTPS 5
path: /healthz
port: 8080 6
httpHeaders:
- name: X-Custom-Header
value: Awesome
startupProbe: 7
httpGet: 8
path: /healthz
port: 8080 9
failureThreshold: 30 10
periodSeconds: 10 11
...
- 1
- Le nom du conteneur.
- 2
- Spécifiez l'image du conteneur à déployer.
- 3
- Une enquête sur l'état d'avancement des travaux.
- 4
- Un test HTTP
GET. - 5
- Le schéma internet :
HTTPouHTTPS. La valeur par défaut estHTTP. - 6
- Le port sur lequel le conteneur écoute.
- 7
- Une sonde de démarrage.
- 8
- Un test HTTP
GET. - 9
- Le port sur lequel le conteneur écoute.
- 10
- Le nombre de fois où la sonde doit être réessayée après un échec.
- 11
- Le nombre de secondes nécessaires pour exécuter la sonde.
Exemple de sonde de vivacité avec un test de commande de conteneur qui utilise un délai d'attente dans une spécification de pod
apiVersion: v1
kind: Pod
metadata:
labels:
test: health-check
name: my-application
...
spec:
containers:
- name: goproxy-app 1
args:
image: registry.k8s.io/goproxy:0.1 2
livenessProbe: 3
exec: 4
command: 5
- /bin/bash
- '-c'
- timeout 60 /opt/eap/bin/livenessProbe.sh
periodSeconds: 10 6
successThreshold: 1 7
failureThreshold: 3 8
...
- 1
- Le nom du conteneur.
- 2
- Spécifiez l'image du conteneur à déployer.
- 3
- La sonde d'intégrité.
- 4
- Le type de sonde, ici une sonde de commande de conteneur.
- 5
- La ligne de commande à exécuter dans le conteneur.
- 6
- Fréquence en secondes de l'exécution de la sonde.
- 7
- Le nombre de succès consécutifs nécessaires pour montrer un succès après un échec.
- 8
- Le nombre de fois où la sonde doit être réessayée après un échec.
Exemple de sonde d'état de préparation et de sonde d'état de disponibilité avec un test de socket TCP dans un déploiement
kind: Deployment
apiVersion: apps/v1
...
spec:
...
template:
spec:
containers:
- resources: {}
readinessProbe: 1
tcpSocket:
port: 8080
timeoutSeconds: 1
periodSeconds: 10
successThreshold: 1
failureThreshold: 3
terminationMessagePath: /dev/termination-log
name: ruby-ex
livenessProbe: 2
tcpSocket:
port: 8080
initialDelaySeconds: 15
timeoutSeconds: 1
periodSeconds: 10
successThreshold: 1
failureThreshold: 3
...
