Resolver problemas de proxies sidecar no Cloud Service Mesh

Esta secção explica os problemas comuns dos proxies sidecar do Cloud Service Mesh e como resolvê-los. Se precisar de assistência adicional, consulte o artigo Receber apoio técnico.

O contentor istio-proxy é terminado devido a um evento de falta de memória

Nesta secção, assumimos que o contentor istio-proxy não é terminado por um evento SystemOOM e que o nó do Kubernetes não está na condição MemoryPressure. O contentor secundário tem limites de recursos por predefinição.istio-proxy Se o contentor istio-proxy for terminado com Reason: OOMKilled, é necessário compreender por que motivo o Envoy está a consumir a memória.

Se estiver a enfrentar uma indisponibilidade de produção, uma solução rápida é aumentar os limites para todos os contentores que usam IstioOperator:

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

Se estiver a ter este problema com cargas de trabalho específicas, pode alterar o limite apenas nessas cargas de trabalho adicionando as seguintes anotações.

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

Certifique-se de que não tem limites inferiores aos valores predefinidos.

A solução a longo prazo é reduzir a utilização de memória dos contentores auxiliares.istio-proxy Por predefinição, todos os proxies sidecar são programados com a configuração necessária para alcançar qualquer outra instância de carga de trabalho na malha. O Istio fornece a definição de recursos personalizadosSidecar para limitar o número de pontos finais programados para proxies sidecar e, por conseguinte, reduzir o consumo de memória do contentor istio-proxy.