En esta sección, se explican los problemas comunes de los proxies de sidecar de Anthos Service Mesh y cómo resolverlos. Si necesitas asistencia adicional, consulta Obtén asistencia.
Se elimina el contenedor istio-proxy
debido a un evento de OOM.
En esta sección, suponemos que un evento SystemOOM
no elimina el contenedor istio-proxy
y que el nodo de Kubernetes no está en condición MemoryPressure
.
El contenedor istio-proxy
del archivo adicional tiene límites de recursos de forma predeterminada.
Si el contenedor de istio-proxy se elimina con Reason: OOMKilled
, es necesario comprender por qué Envoy consume la memoria.
Si te enfrentas a una interrupción de la producción, una solución alternativa rápida es aumentar los límites de todos los contenedores mediante IstioOperator
:
---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
values:
global:
proxy:
resources:
requests:
memory: 128Mi
limits:
memory: 1Gi
Si te encuentras con este problema con cargas de trabajo específicas, puedes agregar las siguientes anotaciones para cambiar el límite solo en esas cargas de trabajo.
sidecar.istio.io/proxyMemory
sidecar.istio.io/proxyMemoryLimit
Asegúrate de no tener límites que sean inferiores a los valores predeterminados.
La solución a largo plazo es reducir el alcance de memoria de los contenedores de sidecar de istio-proxy
. De forma predeterminada, todos los proxies de sidecar se programan con la configuración necesaria para alcanzar cualquier otra instancia de carga de trabajo en la malla.
Istio proporciona la definición personalizada de recursos Sidecar
para limitar la cantidad de extremos programados en proxies de sidecar y, por lo tanto, reducir el consumo de memoria del contenedor istio-proxy
.