Enable health check redirection for mesh applications - Alibaba Cloud Service Mesh

Un sidecar intercepte les requêtes reçues par une application de maillage. Par conséquent, les vérifications d'état HTTP et TCP d'une application dans laquelle un sidecar a été injecté sur Alibaba Cloud Service Mesh (ASM) peuvent se comporter de manière inattendue, par exemple en échouant systématiquement. Activez la redirection des vérifications d'état afin qu'elles fonctionnent comme prévu.

Contexte

Le tableau suivant décrit le comportement inattendu des vérifications d'état HTTP et TCP pour les applications du maillage. Pour rétablir le bon fonctionnement des vérifications d'état, ajoutez une annotation afin d'activer leur redirection.

Type

Description

Vérifications d'état HTTP

Dans un cluster Kubernetes, le kubelet envoie les requêtes de vérification d'état de tous les pods. Une fois le mode TLS mutuel (mTLS) activé, les applications du maillage doivent communiquer via TLS. Le kubelet ne faisant pas partie du maillage, il ne dispose pas du certificat émis par ASM pour les applications. Par conséquent, les requêtes de vérification d'état HTTP sont rejetées et les vérifications échouent systématiquement.

Vérifications d'état TCP

Pour intercepter les requêtes, le sidecar écoute sur tous les ports du pod d'une application du maillage. Lors d'une vérification d'état TCP, le kubelet détermine l'état de santé de l'application en vérifiant si une application écoute sur le port configuré pour le pod de l'application.

De ce fait, la vérification d'état réussit toujours tant qu'un sidecar est injecté dans l'application et que le sidecar est en cours d'exécution, indépendamment de l'état réel de l'application. Par exemple, si vous configurez un port incorrect pour l'application, la vérification d'état du pod est censée échouer systématiquement et maintenir le pod dans un état non prêt, mais la vérification réussit malgré tout.

Remarque

Si vous n'activez pas le mode mTLS dans ASM, vous pouvez utiliser les vérifications d'état HTTP sur les pods d'application sans configurer la redirection des vérifications d'état.

Par défaut, le graphe de topologie du maillage affiche les appels de requêtes de vérification d'état des services d'application. Dans de nombreux scénarios, ces appels peuvent fausser les statistiques de trafic. Activez la redirection des vérifications d'état pour les applications du maillage afin d'exclure ces appels internes de vérification d'état des statistiques.

Fonctionnement de la redirection des vérifications d'état

Une annotation dans le modèle de pod d'une charge de travail contrôle la redirection des vérifications d'état. Ajoutez sidecar.istio.io/rewriteAppHTTPProbers: "true" sous template.metadata.annotations, puis appliquez la charge de travail. ASM réécrit les vérifications d'état configurées pour le conteneur d'application en tant que vérifications d'état HTTP sur le port 15020.

Pour les applications du maillage, le port 15020 est un port spécial utilisé pour l'observabilité du maillage. Le trafic envoyé vers ce port n'est pas intercepté par le sidecar et n'a donc pas besoin de respecter les exigences du mode TLS. Une fois la redirection des vérifications d'état activée, le service pilot-agent qui s'exécute dans le conteneur sidecar écoute sur le port 15020 et reçoit les vérifications d'état du kubelet. Sur la base de la configuration de vérification d'état contenue dans la variable d'environnement ISTIO_KUBE_APP_PROBERS, le service pilot-agent transfère les requêtes de vérification d'état au conteneur d'application. Ainsi, les vérifications d'état HTTP s'exécutent comme prévu.

Pour les vérifications d'état TCP, la redirection des vérifications d'état dans ASM effectue le même traitement et les réécrit en tant que vérifications d'état HTTP sur le port 15020. Sur la base de la configuration de vérification d'état TCP contenue dans la variable d'environnement ISTIO_KUBE_APP_PROBERS, le service pilot-agent sonde le port de vérification d'état TCP configuré pour le conteneur d'application. Si la vérification d'état TCP réelle échoue, le service pilot-agent renvoie le code d'état 500 pour indiquer l'échec de la vérification.

Prérequis

L'application est ajoutée à ASM et un sidecar est injecté dans les pods de l'application.
kubectl est connecté au cluster qui exécute l'application. Pour obtenir des instructions, consultez la rubrique Obtenir le fichier kubeconfig d'un cluster et utiliser kubectl pour se connecter au cluster.

Activer la redirection des vérifications d'état HTTP

L'exemple suivant utilise une application Nginx pour activer la redirection des vérifications d'état HTTP. Une fois le mode mTLS activé, la vérification d'état HTTP configurée pour l'application Nginx échoue systématiquement. La redirection des vérifications d'état est ensuite activée pour l'application Nginx. Si les événements du pod ne contiennent aucun événement d'échec de vérification d'état et que le pod est dans l'état prêt, la redirection des vérifications d'état HTTP est activée pour l'application.

Étape 1 : Activer le mode mTLS STRICT pour un namespace

Configurez le mode mTLS sur la page PeerAuthentication de l'instance ASM cible dans la console ASM. Le mode mTLS que vous configurez à cette étape s'applique au namespace que vous sélectionnez.

Connectez-vous à la console ASM.
Dans le volet de navigation de gauche, choisissez Service Mesh > Mesh Management.
Sur la page Mesh Management, recherchez l'instance ASM que vous souhaitez configurer. Cliquez sur le nom de l'instance ASM ou cliquez sur Manage dans la colonne Actions.
Sur la page des détails de l'instance ASM, choisissez Mesh Security Center > PeerAuthentication dans le volet de navigation de gauche.
En haut de la page PeerAuthentication, sélectionnez un namespace, puis cliquez sur Configure Global mTLS Mode.
Dans le panneau Configure Global mTLS Mode, définissez mTLS Mode (Namespace-wide) sur STRICT - Strictly Enforce mTLS, puis cliquez sur Create.

Étape 2 : Déployer l'application Nginx

Déployez l'application Nginx.

Créez un fichier nommé http-liveness.yaml avec le contenu suivant.

http-liveness.yaml : configuration initiale

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /index.html
            port: 80
            httpHeaders:
            - name: X-Custom-Header
              value: hello
          initialDelaySeconds: 5
          periodSeconds: 3

Sous le paramètre readinessProbe, le champ httpGet définit une vérification d'état HTTP pour l'application.

Exécutez la commande suivante pour déployer l'application Nginx.
```
kubectl apply -f http-liveness.yaml
```

Consultez l'état de la vérification d'état de l'application.
1. Exécutez la commande suivante pour afficher le nom du pod de l'application Nginx.
```
kubectl get pod | grep nginx
```
2. Exécutez la commande suivante pour afficher les événements du pod.
```
kubectl describe pod <pod_name>
```
  Sortie attendue :
```
Warning  Unhealthy  45s               kubelet            Readiness probe failed: Get "http://172.23.64.22:80/index.html": read tcp 172.23.64.1:54130->172.23.64.22:80: read: connection reset by peer
```
  La sortie indique que la vérification d'état HTTP du pod a échoué, ce qui maintient le pod dans un état non prêt.

Étape 3 : Activer la redirection des vérifications d'état pour l'application Nginx

Exécutez la commande suivante pour modifier le fichier http-liveness.yaml.

vim http-liveness.yaml

Ajoutez le contenu suivant sous le paramètre template :

annotations:
  sidecar.istio.io/rewriteAppHTTPProbers: "true"

Le code suivant montre le fichier http-liveness.yaml après l'ajout de l'annotation :

http-liveness.yaml : après l'ajout de l'annotation

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        sidecar.istio.io/rewriteAppHTTPProbers: "true"
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /index.html
            port: 80
            httpHeaders:
            - name: X-Custom-Header
              value: hello
          initialDelaySeconds: 5
          periodSeconds: 3

Exécutez la commande suivante pour déployer l'application Nginx.
```
kubectl apply -f http-liveness.yaml
```

Étape 4 : Vérifier le résultat de la vérification d'état

Consultez l'état de la vérification d'état du pod.
1. Exécutez la commande suivante pour afficher le nom du pod de l'application Nginx.
```
kubectl get pod | grep nginx
```
2. Exécutez la commande suivante pour afficher les événements du pod.
```
kubectl describe pod <pod_name>
```
  La sortie ne contient aucun événement d'échec de vérification d'état et le pod est dans l'état prêt. La vérification d'état HTTP fonctionne comme prévu.

Exécutez la commande suivante pour afficher le fichier YAML du pod après la redirection des vérifications d'état.

kubectl get pod <pod_name> -o yaml

Sortie attendue

apiVersion: v1
kind: Pod
metadata:
  ...
  name: nginx-deployment-676f85f66b-cbzsx
  namespace: default
  ...
spec:
  containers:
    - args:
        - proxy
        - sidecar
        - '--domain'
        - $(POD_NAMESPACE).svc.cluster.local
        - '--proxyLogLevel=warning'
        - '--proxyComponentLogLevel=misc:error'
        - '--log_output_level=default:info'
        - '--concurrency'
        - '2'
      env:
        ...
        - name: ISTIO_KUBE_APP_PROBERS
          value: >-
            {"/app-health/nginx/readyz":{"httpGet":{"path":"/index.html","port":80,"scheme":"HTTP","httpHeaders":[{"name":"X-Custom-Header","value":"hello"}]},"timeoutSeconds":1}}
      ...
    - image: nginx
      imagePullPolicy: IfNotPresent
      name: nginx
      ports:
        - containerPort: 80
          protocol: TCP
      readinessProbe:
        failureThreshold: 3
        httpGet:
          httpHeaders:
            - name: X-Custom-Header
              value: hello
          path: /app-health/nginx/readyz
          port: 15020
          scheme: HTTP
        initialDelaySeconds: 5
        periodSeconds: 3
        successThreshold: 1
        timeoutSeconds: 1

Une fois la redirection des vérifications d'état activée, le port de vérification d'état passe de 80 à 15020, et le chemin de vérification d'état passe de /index.html à /app-health/nginx/readyz. La variable d'environnement ISTIO_KUBE_APP_PROBERS est également ajoutée au conteneur sidecar dans le pod. La valeur de la variable correspond à la sérialisation JSON de la configuration de vérification d'état avant sa réécriture.

Activer la redirection des vérifications d'état TCP

L'exemple suivant utilise une application Nginx pour activer la redirection des vérifications d'état TCP. La procédure est identique à celle de la redirection des vérifications d'état HTTP. Seules la configuration de la sonde et les résultats attendus diffèrent. Un port incorrect est configuré pour l'application Nginx, mais la vérification d'état TCP réussit toujours sur le pod de l'application, ce qui ne correspond pas aux attentes. Après avoir activé la redirection des vérifications d'état pour l'application Nginx, la vérification d'état TCP échoue sur le pod de l'application, ce qui correspond aux attentes et indique que la redirection des vérifications d'état TCP est activée pour l'application.

Étape 1 : Déployer l'application Nginx

Déployez l'application Nginx.
1. Créez un fichier nommé tcp-liveness.yaml avec le contenu suivant.
  
  Le contenu suivant configure le port 2940 comme port de vérification d'état, ce qui est incorrect. L'application Nginx n'écoute pas sur le port 2940. Par conséquent, la vérification d'état est censée échouer systématiquement après le déploiement de l'application et maintenir le pod dans un état non prêt.
  tcp-liveness.yaml : configuration initiale
  apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: selector: matchLabels: app: nginx replicas: 1 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent ports: - containerPort: 80 readinessProbe: tcpSocket: port: 2940 initialDelaySeconds: 5 periodSeconds: 3
  Sous le paramètre readinessProbe, le champ tcpSocket définit une vérification d'état TCP pour l'application.
2. Exécutez la commande suivante pour déployer l'application Nginx.
```
kubectl apply -f tcp-liveness.yaml
```
Consultez l'état de la vérification d'état de l'application.
1. Exécutez la commande suivante pour afficher le nom du pod de l'application Nginx.
```
kubectl get pod | grep nginx
```
2. Exécutez la commande suivante pour afficher les événements du pod.
```
kubectl describe pod <pod_name>
```
  La sortie ne contient aucun événement d'échec de vérification d'état et le pod est dans l'état prêt, ce qui ne correspond pas aux attentes.

Étape 2 : Activer la redirection des vérifications d'état pour l'application Nginx

Exécutez la commande suivante pour modifier le fichier tcp-liveness.yaml.

vim tcp-liveness.yaml

Dans le fichier tcp-liveness.yaml, ajoutez le contenu suivant sous le paramètre template :

annotations:
  sidecar.istio.io/rewriteAppHTTPProbers: "true"

Le code suivant montre le fichier tcp-liveness.yaml après l'ajout de l'annotation :

tcp-liveness.yaml : après l'ajout de l'annotation

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        sidecar.istio.io/rewriteAppHTTPProbers: "true"
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        readinessProbe:
          tcpSocket:
            port: 2940
          initialDelaySeconds: 5
          periodSeconds: 3

Exécutez la commande suivante pour déployer l'application Nginx.
```
kubectl apply -f tcp-liveness.yaml
```

Étape 3 : Vérifier le résultat de la vérification d'état

Consultez l'état de la vérification d'état de l'application.
1. Exécutez la commande suivante pour afficher le nom du pod de l'application Nginx.
```
kubectl get pod | grep nginx
```
2. Exécutez la commande suivante pour afficher les événements du pod.
```
kubectl describe pod <pod_name>
```
  Sortie attendue :
```
Warning  Unhealthy  45s               kubelet            Readiness probe failed: HTTP probe failed with statuscode: 500
```
  La sortie indique que la vérification d'état a échoué, ce qui correspond aux attentes.

Exécutez la commande suivante pour afficher le contenu YAML du pod de l'application après la redirection des vérifications d'état.

kubectl get pod <pod_name> -o yaml

Sortie attendue

apiVersion: v1
kind: Pod
metadata:
  ...
  name: nginx-deployment-746458cdc9-m9t9q
  namespace: default
  ...
spec:
  containers:
    - args:
        - proxy
        - sidecar
        - '--domain'
        - $(POD_NAMESPACE).svc.cluster.local
        - '--proxyLogLevel=warning'
        - '--proxyComponentLogLevel=misc:error'
        - '--log_output_level=default:info'
        - '--concurrency'
        - '2'
      env:
        ...
        - name: ISTIO_KUBE_APP_PROBERS
          value: >-
            {"/app-health/nginx/readyz":{"tcpSocket":{"port":2940},"timeoutSeconds":1}}
      ...
    - image: nginx
      imagePullPolicy: IfNotPresent
      name: nginx
      ports:
        - containerPort: 80
          protocol: TCP
      readinessProbe:
        failureThreshold: 3
        httpGet:
          path: /app-health/nginx/readyz
          port: 15020
          scheme: HTTP
        initialDelaySeconds: 5
        periodSeconds: 3
        successThreshold: 1
        timeoutSeconds: 1
      ...

Une fois la redirection des vérifications d'état activée, la vérification d'état TCP d'origine est réécrite en tant que vérification d'état HTTP. Le port de vérification d'état passe de 2940 à 15020, et le chemin de la vérification d'état HTTP est défini sur /app-health/nginx/readyz. La variable d'environnement ISTIO_KUBE_APP_PROBERS est également ajoutée au conteneur sidecar dans le pod. La valeur de la variable correspond à la sérialisation JSON de la configuration de vérification d'état TCP avant sa réécriture.