Risoluzione dei problemi dei proxy collaterali in Cloud Service Mesh

Questa sezione illustra i problemi comuni dei proxy sidecar di Cloud Service Mesh e come risolverli. Se hai bisogno di ulteriore assistenza, consulta la sezione Ricevere assistenza.

Il contenitore istio-proxy viene interrotto a causa di un evento OOM

In questa sezione si presume che il contenitore istio-proxy non venga interrotto da un evento SystemOOM e che il nodo Kubernetes non sia in stato MemoryPressure. Il contenitore sidecar istio-proxy ha per impostazione predefinita limiti di risorse. Se il container istio-proxy viene terminato con Reason: OOMKilled, è necessario per capire perché Envoy sta consumando la memoria.

Se stai riscontrando un'interruzione della produzione, una soluzione rapida è aumentare i limiti per tutti i contenitori utilizzando IstioOperator:

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    global:
      proxy:
        resources:
          requests:
               memory: 128Mi
          limits:
               memory: 1Gi

Se stai riscontrando questo problema con carichi di lavoro specifici, puoi modificare il limite solo su quei carichi di lavoro, aggiungendo annotations.

  • sidecar.istio.io/proxyMemory
  • sidecar.istio.io/proxyMemoryLimit

Assicurati che i limiti non siano inferiori ai valori predefiniti.

La soluzione a lungo termine è ridurre l'utilizzo di memoria dei contenitori sidecar istio-proxy. Per impostazione predefinita, tutti i proxy sidecar sono programmati con la configurazione necessaria per raggiungere qualsiasi altra istanza di carico di lavoro nel mesh. Istio fornisce la definizione della risorsa personalizzata Sidecar per limitare il numero di endpoint programmati per i proxy sidecar e quindi ridurre il consumo di memoria del contenitore istio-proxy.