Pod-Startzeit
In diesem Abschnitt werden häufig auftretende Cloud Service Mesh-Probleme mit der Pod-Startzeit und deren Behebung erläutert. Weitere Informationen finden Sie unter Support.
Pod-Start und Envoy-Konfigurationssynchronisierung
Ein häufiges Problem beim Starten von Pods in einigen Cloud Service Mesh- und Istio-Umgebungen betrifft die Synchronisierung zwischen Anwendungsbereitschaft und Envoy-Proxy-Konfiguration. Das Problem entsteht durch den gleichzeitigen Start des Anwendungscontainers und des Envoy-Sidecars. Die Anwendung kann die Bereitschaft signalisieren, bevor der Envoy-Proxy seine Initialisierung abgeschlossen und seine Konfiguration von der Kontrollebene erhalten hat. Dies führt zu einer Race-Condition, bei der eingehende Anfragen an einen nicht konfigurierten Envoy-Proxy weitergeleitet werden, der noch nicht für den Empfang von Traffic bereit ist. Dies kann dazu führen, dass Anfragen in der Anfangsphase des Anwendungsstarts gelöscht, falsch weitergeleitet oder falsch verarbeitet werden, da es keinen Sidecar gibt, der den Traffic weiterleitet.
Strategien zur Risikominderung
In den folgenden Abschnitten werden Methoden beschrieben, mit denen sich dieses Problem minimieren lässt.
Globale Mesh-Konfiguration: holdApplicationUntilProxyStarts
Die erste Option besteht darin, holdApplicationUntilProxyStarts: true in der Istio-Mesh-Konfiguration festzulegen. Standardmäßig ist sie deaktiviert. Mit dem Flag werden Hooks hinzugefügt, um den Anwendungsstart zu verzögern, bis der Proxy des Pods bereit ist, Traffic zu akzeptieren.
Durch das Hinzufügen der Konfiguration wird dieses Problem behoben. Wenn die Konfiguration jedoch zuvor nicht aktiviert war, kann es zu Verzögerungen bei der Anwendungsbereitschaft neuer Pods kommen.
Bereitschaftsprüfungen
Eine weitere Lösung besteht darin, Bereitschaftsprüfungen zu implementieren, die sowohl die Anwendungs- als auch die Envoy-Systemdiagnosen umfassen. Bereitschaftsprüfungen informieren Kubernetes darüber, wann ein Pod bereit ist, Traffic anzunehmen. Die Logik der Bereitschaftsprüfung sollte nicht nur die Bereitschaft der Anwendung, sondern auch den Status des Envoy-Proxy prüfen. Dazu können Sie den Administratorport von Envoy nach dem Status fragen. Durch die Kombination beider Prüfungen verhindert Kubernetes, dass Traffic an den Pod weitergeleitet wird, bis sowohl die Anwendung als auch Envoy vollständig initialisiert und konfiguriert sind.
Dieser Ansatz ist flexibler und ermöglicht eine kompliziertere Start- und Bereitschaftslogik. Er ist jedoch auch komplexer.
Erstellen Sie die Datei healthcheck.sh aus dem folgenden Code:
#!/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
Ersetzen Sie die IP-Adressen/Ports durch die Ihres Anwendungscontainers und Envoys.
In der folgenden YAML-Datei wird eine Bereitschaftsprüfung definiert, für die das zuvor erstellte Script verwendet wird:
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
<…>