Tempo di avvio del pod
Questa sezione illustra i problemi comuni di Cloud Service Mesh relativi al tempo di avvio del pod e come risolverli. Se hai bisogno di ulteriore assistenza, consulta Ricevere assistenza.
Avvio del pod e sincronizzazione della configurazione di Envoy
Un problema comune osservato durante l'avvio del pod in alcuni ambienti Cloud Service Mesh e Istio riguarda la sincronizzazione tra l'idoneità dell'applicazione e la configurazione del proxy Envoy. Il problema si verifica a causa dell'avvio simultaneo del container dell'applicazione e del sidecar Envoy. L'applicazione potrebbe segnalare la disponibilità prima che il proxy Envoy abbia completato l'inizializzazione e abbia ricevuto la configurazione dal piano di controllo. Ciò crea una condizione di gara in cui le richieste in arrivo vengono indirizzate a un proxy Envoy non configurato che non è pronto a ricevere traffico. Ciò può comportare la perdita delle richieste, la loro deviazione o un loro trattamento errato durante la fase iniziale di avvio dell'applicazione, poiché non è presente alcun sidecar per inoltrare il traffico.
Strategie di mitigazione
Le sezioni seguenti descrivono i metodi che possono mitigare questo problema.
Configurazione della mesh globale: holdApplicationUntilProxyStarts
La prima opzione è impostare holdApplicationUntilProxyStarts: true nella configurazione del mesh Istio. Tieni presente che è disattivata per impostazione predefinita. Il flag aggiunge hook per ritardare
l'avvio dell'applicazione finché il proxy del pod non è pronto ad accettare il traffico.
L'aggiunta della configurazione elimina questa situazione, ma potrebbe comportare un ritardo nei tempi di idoneità dell'applicazione per i nuovi pod se non è stata attivata in precedenza.
Probe di idoneità
Un'altra soluzione è implementare probe di idoneità che includono i controlli di integrità sia dell'applicazione sia di Envoy. I probe di idoneità informano Kubernetes quando un pod è pronto ad accettare traffico. È fondamentale che la logica del probe di idoneità verifichi non solo l'idoneità dell'applicazione, ma anche lo stato del proxy Envoy. Questo può essere ottenuto eseguendo una query sul report dell'amministratore di Envoy per verificarne lo stato di salute. Combinando entrambi i controlli, Kubernetes impedisce che il traffico venga indirizzato al pod finché sia l'applicazione sia Envoy non sono completamente inizializzati e configurati.
Questo approccio è più flessibile e consente una logica di avvio e di idoneità più complessa, ma ha il costo di una maggiore complessità.
Crea il file healthcheck.sh dal seguente codice:
#!/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
Sostituisci l'IP/le porte con il contenitore dell'applicazione e con quelli di Envoy.
Il seguente file YAML definisce un probe di idoneità che utilizza lo script creato in precedenza:
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
<…>