Resuelve problemas de proxies de sidecar en Cloud Service Mesh

En esta sección, se explican los problemas comunes de los proxies de sidecar de Cloud Service Mesh y cómo y 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 de recurso personalizada Sidecar para limitar el número de endpoints programados para proxies de sidecar y, por lo tanto, el consumo de memoria del contenedor istio-proxy.