Résoudre les problèmes liés aux proxys side-car dans Cloud Service Mesh

Cette section explique les problèmes couramment rencontrés avec les proxys side-car Cloud Service Mesh, ainsi que la manière de les résoudre. Si vous avez besoin d'une aide supplémentaire, consultez la page Assistance.

Le conteneur istio-proxy est supprimé en raison d'un événement OOM

Dans cette section, nous partons du principe que le conteneur istio-proxy n'est pas supprimé par un événement SystemOOM et que le nœud Kubernetes n'est pas dans la condition MemoryPressure. Le conteneur side-car istio-proxy est soumis par défaut à des limites de ressources. Si le conteneur istio-proxy est supprimé à cause de Reason: OOMKilled, il est nécessaire de comprendre pourquoi Envoy utilise la mémoire.

En cas d'interruption de production, une solution rapide consiste à augmenter les limites de tous les conteneurs à l'aide de IstioOperator :

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

Si vous rencontrez ce problème avec des charges de travail spécifiques, vous pouvez modifier la limite uniquement sur ces charges de travail en ajoutant les annotations suivantes.

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

Veillez à ne pas définir de limites inférieures aux valeurs par défaut.

La solution à long terme consiste à réduire les exigences en mémoire de vos conteneurs side-car istio-proxy. Par défaut, tous les proxys side-car sont programmés avec la configuration nécessaire pour atteindre toute autre instance de charge de travail dans le maillage. Istio fournit la définition de ressource personnalisée Sidecar pour limiter le nombre de points de terminaison programmés sur les proxys side-car, et ainsi réduire la consommation de mémoire du conteneur istio-proxy.