Accueiil
Products
Red Hat OpenShift Service on AWS
4
Applications de construction
Chapitre 10. Contrôle de la santé des applications en utilisant des contrôles de santé

Chapitre 10. Contrôle de la santé des applications en utilisant des contrôles de santé

Dans les systèmes logiciels, les composants peuvent devenir malsains en raison de problèmes transitoires tels que la perte de connectivité temporaire, les erreurs de configuration ou les problèmes de dépendances externes. Le service OpenShift Red Hat sur les applications AWS dispose d’un certain nombre d’options pour détecter et gérer des conteneurs malsains.

10.1. Comprendre les contrôles de santé

Le bilan de santé effectue périodiquement des diagnostics sur un conteneur en cours d’exécution en utilisant n’importe quelle combinaison de la préparation, de la vivacité et des contrôles de santé au démarrage.

Il est possible d’inclure une ou plusieurs sondes dans la spécification de la gousse qui contient le contenant que vous souhaitez effectuer les contrôles de santé.

Note

Lorsque vous souhaitez ajouter ou modifier des contrôles de santé dans un pod existant, vous devez modifier l’objet Pod DeploymentConfig ou utiliser la perspective Développeur dans la console Web. Il n’est pas possible d’utiliser le CLI pour ajouter ou modifier des contrôles de santé pour un pod existant.

La sonde de préparation

La sonde de préparation détermine si un conteneur est prêt à accepter les demandes de service. En cas de défaillance de la sonde de préparation pour un conteneur, le kubelet retire la gousse de la liste des terminaux de service disponibles.

Après une défaillance, la sonde continue d’examiner la gousse. Lorsque la gousse devient disponible, le kubelet ajoute le pod à la liste des points de terminaison de service disponibles.

Contrôle de l’état de vie

La sonde de vivacité détermine si un conteneur est toujours en cours d’exécution. En cas d’échec de la sonde de vivacité en raison d’une condition telle qu’une impasse, le kubelet tue le conteneur. Le pod répond ensuite en fonction de sa politique de redémarrage.

À titre d’exemple, une sonde de vivacité sur une gousse avec redémarragePolicy of Always or OnFailure tue et redémarre le conteneur.

La sonde de démarrage

La sonde de démarrage indique si l’application dans un conteneur est lancée. Les autres sondes sont désactivées jusqu’à ce que la startup réussisse. Lorsque 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 à la police de redémarrage.

Certaines applications peuvent nécessiter un temps de démarrage supplémentaire lors de leur première initialisation. Il est possible d’utiliser une sonde de démarrage avec une sonde de vivacité ou de préparation pour retarder cette sonde assez longtemps pour gérer le temps de démarrage long en utilisant les paramètres de panneThreshold et periodSeconds.

A titre d’exemple, vous pouvez ajouter une sonde de démarrage, avec un seuil de 30 défaillances et une périodeDeuxièmes de 10 secondes (30 * 10s = 300s) pour un maximum de 5 minutes, à une sonde de vivacité. Après que la sonde de démarrage réussit la première fois, la sonde de vivacité prend le relais.

Configurez des sondes de vivacité, de préparation et de démarrage avec l’un des types de tests suivants:

HTTP GET: Lors de l’utilisation d’un test HTTP GET, le test détermine la santé du conteneur en utilisant un crochet Web. Le test est réussi si le code de réponse HTTP se situe entre 200 et 399.
Il est possible d’utiliser un test HTTP GET avec des applications qui renvoient les codes d’état HTTP lorsqu’ils sont complètement initialisés.
Commande de conteneur : Lors de l’utilisation 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 sort avec un statut 0.
Douille TCP: Lors de l’utilisation d’un test de prise TCP, la sonde tente d’ouvrir une prise sur le conteneur. Le récipient n’est considéré comme sain que si la sonde peut établir une connexion. Il est possible d’utiliser un test de socket TCP avec des applications qui ne commencent pas à écouter jusqu’à ce que l’initialisation soit terminée.

Configurez 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.
le délai, en secondes, entre l’exécution des sondes. La valeur par défaut est 10. Cette valeur doit être supérieure au timeoutSeconds.
chronométrageSeconds: Le nombre de secondes d’inactivité après quoi la sonde est sortie et le conteneur est supposé avoir échoué. La valeur par défaut est 1. Cette valeur doit être inférieure à periodSeconds.
le nombre de fois que la sonde doit signaler le succès après un échec à réinitialiser l’état du conteneur pour réussir. La valeur doit être de 1 pour une sonde de vivacité. La valeur par défaut est 1.
failThreshold: Le nombre de fois où la sonde est autorisée à échouer. La valeur par défaut est 3. Après les tentatives spécifiées:
- dans le cas d’une sonde de vivacité, le conteneur est redémarré
- dans le cas d’une sonde de préparation, le pod est marqué
- dans le cas d’une sonde de démarrage, le conteneur est tué et est soumis au redémarrage du podPolicy

Exemples de sondes

Ce qui suit sont des échantillons de sondes différentes comme ils apparaîtraient dans une spécification d’objet.

Échantillon de sonde de préparation avec une sonde de préparation de commande de conteneur dans un pod spec

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: health-check
  name: my-application
# ...
spec:
  containers:
  - name: goproxy-app 
    args:
    image: registry.k8s.io/goproxy:0.1 
    readinessProbe: 
      exec: 
        command: 
        - cat
        - /tmp/healthy
# ...

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: health-check
  name: my-application
# ...
spec:
  containers:
  - name: goproxy-app


    args:
    image: registry.k8s.io/goproxy:0.1


    readinessProbe:


      exec:


        command:


        - cat
        - /tmp/healthy
# ...

Copy to Clipboard

1: Le nom du conteneur.
2: L’image du conteneur à déployer.
3: C’est une sonde de préparation.
4: Essai de commande de conteneur.
5: Les commandes à exécuter sur le conteneur.

Exemple de sonde de démarrage de commande de conteneur et sonde de vivacité avec des tests de commande de conteneur dans un pod spec

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: health-check
  name: my-application
# ...
spec:
  containers:
  - name: goproxy-app 
    args:
    image: registry.k8s.io/goproxy:0.1 
    livenessProbe: 
      httpGet: 
        scheme: HTTPS 
        path: /healthz
        port: 8080 
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
    startupProbe: 
      httpGet: 
        path: /healthz
        port: 8080 
      failureThreshold: 30 
      periodSeconds: 10 
# ...

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: health-check
  name: my-application
# ...
spec:
  containers:
  - name: goproxy-app


    args:
    image: registry.k8s.io/goproxy:0.1


    livenessProbe:


      httpGet:


        scheme: HTTPS


        path: /healthz
        port: 8080


        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
    startupProbe:


      httpGet:


        path: /healthz
        port: 8080


      failureThreshold: 30


      periodSeconds: 10


# ...

Copy to Clipboard

1: Le nom du conteneur.
2: Indiquez l’image du conteneur à déployer.
3: C’est une sonde de vivacité.
4: Le test HTTP GET.
5: Le schéma Internet : HTTP ou HTTPS. La valeur par défaut est HTTP.
6: Le port sur lequel le conteneur est à l’écoute.
7: La sonde de démarrage.
8: Le test HTTP GET.
9: Le port sur lequel le conteneur est à l’écoute.
10: Le nombre de fois pour essayer la sonde après une défaillance.
11: Le nombre de secondes pour effectuer la sonde.

Échantillon de sonde de vivacité avec un test de commande de conteneur qui utilise un timeout dans un pod spec

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: health-check
  name: my-application
# ...
spec:
  containers:
  - name: goproxy-app 
    args:
    image: registry.k8s.io/goproxy:0.1 
    livenessProbe: 
      exec: 
        command: 
        - /bin/bash
        - '-c'
        - timeout 60 /opt/eap/bin/livenessProbe.sh
      periodSeconds: 10 
      successThreshold: 1 
      failureThreshold: 3 
# ...

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: health-check
  name: my-application
# ...
spec:
  containers:
  - name: goproxy-app


    args:
    image: registry.k8s.io/goproxy:0.1


    livenessProbe:


      exec:


        command:


        - /bin/bash
        - '-c'
        - timeout 60 /opt/eap/bin/livenessProbe.sh
      periodSeconds: 10


      successThreshold: 1


      failureThreshold: 3


# ...

Copy to Clipboard

1: Le nom du conteneur.
2: Indiquez l’image du conteneur à déployer.
3: La sonde de vivacité.
4: Le type de sonde, ici une sonde de commande de conteneur.
5: La ligne de commande à exécuter à l’intérieur du conteneur.
6: Combien de fois en secondes pour effectuer la sonde.
7: Le nombre de succès consécutifs nécessaires pour montrer le succès après un échec.
8: Le nombre de fois pour essayer la sonde après une défaillance.

Échantillon de sonde de préparation et sonde de vivacité avec un test de prise TCP dans un déploiement

kind: Deployment
apiVersion: apps/v1
metadata:
  labels:
    test: health-check
  name: my-application
spec:
# ...
  template:
    spec:
      containers:
        - resources: {}
          readinessProbe: 
            tcpSocket:
              port: 8080
            timeoutSeconds: 1
            periodSeconds: 10
            successThreshold: 1
            failureThreshold: 3
          terminationMessagePath: /dev/termination-log
          name: ruby-ex
          livenessProbe: 
            tcpSocket:
              port: 8080
            initialDelaySeconds: 15
            timeoutSeconds: 1
            periodSeconds: 10
            successThreshold: 1
            failureThreshold: 3
# ...

kind: Deployment
apiVersion: apps/v1
metadata:
  labels:
    test: health-check
  name: my-application
spec:
# ...
  template:
    spec:
      containers:
        - resources: {}
          readinessProbe:


            tcpSocket:
              port: 8080
            timeoutSeconds: 1
            periodSeconds: 10
            successThreshold: 1
            failureThreshold: 3
          terminationMessagePath: /dev/termination-log
          name: ruby-ex
          livenessProbe:


            tcpSocket:
              port: 8080
            initialDelaySeconds: 15
            timeoutSeconds: 1
            periodSeconds: 10
            successThreshold: 1
            failureThreshold: 3
# ...

Copy to Clipboard

1: La sonde de préparation.
2: La sonde de vivacité.

Retour au début

Chapitre 10. Contrôle de la santé des applications en utilisant des contrôles de santé

10.1. Comprendre les contrôles de santé

Exemples de sondes

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Rendre l’open source plus inclusif

À propos de Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links