Resolver problemas de proxies de sidecar en Cloud Service Mesh

En esta sección se explican los problemas habituales de los proxies sidecar de Cloud Service Mesh y cómo resolverlos. Si necesitas más ayuda, consulta el artículo Obtener asistencia.

El contenedor istio-proxy se ha cerrado debido a un evento de falta de memoria

En esta sección, damos por hecho que el contenedor istio-proxy no se ha cerrado con un evento SystemOOM y que el nodo de Kubernetes no está en estado MemoryPressure. El contenedor sidecar istio-proxytiene límites de recursos de forma predeterminada. Si el contenedor istio-proxy se cierra con Reason: OOMKilled, es necesario entender por qué Envoy consume la memoria.

Si se produce una interrupción en la producción, una solución 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 tienes este problema con cargas de trabajo específicas, puedes cambiar el límite solo en esas cargas de trabajo añadiendo las siguientes anotaciones.

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

Asegúrese de que no haya límites inferiores a los valores predeterminados.

La solución a largo plazo es reducir el uso de memoria de tus contenedores istio-proxy sidecar. De forma predeterminada, todos los proxies sidecar se programan con la configuración necesaria para acceder a cualquier otra instancia de carga de trabajo de la malla. Istio proporciona la definición de recurso personalizadoSidecar para limitar el número de endpoints programados en proxies sidecar y, por lo tanto, reducir el consumo de memoria del contenedor istio-proxy.