Temps de démarrage du pod
Cette section explique les problèmes courants liés à Cloud Service Mesh et au temps de démarrage des pods, et indique comment les résoudre. Si vous avez besoin d'une aide supplémentaire, consultez la page Obtenir de l'aide.
Démarrage du pod et synchronisation de la configuration d'Envoy
Un problème courant observé lors du démarrage du pod dans certains environnements Cloud Service Mesh et Istio concerne la synchronisation entre la préparation de l'application et la configuration du proxy Envoy. Le problème vient du démarrage simultané du conteneur d'application et du sidecar Envoy. L'application peut signaler la disponibilité avant que le proxy Envoy n'ait terminé son initialisation et reçu sa configuration du plan de contrôle. Cela crée une condition de course où les requêtes entrantes sont dirigées vers un proxy Envoy non configuré qui n'est pas prêt à recevoir du trafic. Cela peut entraîner l'abandon, le mauvais routage ou le mauvais traitement des requêtes lors de la phase initiale de démarrage de l'application, car il n'y a pas de sidecar pour transférer le trafic.
Stratégies d'atténuation
Les sections suivantes décrivent des méthodes permettant de limiter ce problème.
Configuration du maillage global: holdApplicationUntilProxyStarts
La première option consiste à définir holdApplicationUntilProxyStarts: true dans la configuration du réseau maillé Istio. Notez qu'il est désactivé par défaut. L'indicateur ajoute des crochets pour retarder le démarrage de l'application jusqu'à ce que le proxy du pod soit prêt à accepter le trafic.
L'ajout de la configuration élimine cette course, mais peut entraîner un retard dans les délais de préparation des applications pour les nouveaux pods si elle n'était pas activée auparavant.
Vérifications de préparation
Une autre solution consiste à implémenter des sondes de préparation qui intègrent à la fois les vérifications de l'état de l'application et d'Envoy. Les vérifications d'aptitude informent Kubernetes lorsqu'un pod est prêt à accepter du trafic. De manière critique, la logique de sonde de préparation doit vérifier non seulement la préparation de l'application, mais aussi l'état du proxy Envoy. Pour ce faire, interrogez le port administrateur d'Envoy sur son état de fonctionnement. En combinant les deux vérifications, Kubernetes empêche le trafic d'être dirigé vers le pod tant que l'application et Envoy ne sont pas entièrement initialisés et configurés.
Cette approche est plus flexible et permet une logique de démarrage et de préparation plus complexe, mais elle est plus complexe.
Créez le fichier healthcheck.sh à partir du code suivant:
#!/bin/sh
APP_HEALTH=$(curl -s -o /dev/null -w "%{http_code}" \
http://localhost:8080/health)
ENVOY_HEALTH=$(curl -s -o /dev/null -w "%{http_code}" \
http://localhost:9901/ready)
if [[ "$APP_HEALTH" -eq 200 && "$ENVOY_HEALTH" -eq 200 ]]; then
exit 0
else
exit 1
fi
Remplacez les adresses IP/ports par celles de votre conteneur d'application et d'Envoy.
Le fichier YAML suivant définit une vérification d'aptitude qui utilise le script que vous avez créé précédemment:
apiVersion: v1
kind: Pod
metadata:
name: my-app-with-envoy
spec:
containers:
- name: application
<…>
readinessProbe:
initialDelaySeconds: 15
periodSeconds: 10
failureThreshold: 3
exec:
command:
- /healthcheck.sh # using the script
- name: envoy
<…>