Como resolver problemas de proxies sidecar no Cloud Service Mesh

Nesta seção, explicamos os problemas comuns dos arquivos secundários do Cloud Service Mesh e como resolvê-los. Se você precisar de mais ajuda, consulte Como receber suporte.

O contêiner istio-proxy foi encerrado devido a um evento OOM

Nesta seção, presumimos que o contêiner istio-proxy não foi eliminado por um evento SystemOOM, e o nó do Kubernetes não está na condição MemoryPressure. O contêiner de arquivo secundário istio-proxy tem os limites de recursos por padrão. Se o contêiner istio-proxy for eliminado com Reason: OOMKilled, é necessário entender por que o Envoy está consumindo a memória.

Se você estiver enfrentando uma interrupção na produção, uma solução rápida é aumentar os limites de todos os contêineres usando IstioOperator:

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

Se você estiver enfrentando esse problema com cargas de trabalho específicas, altere o limite apenas nessas cargas adicionando as anotações a seguir.

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

Verifique se você não tem limites menores dos valores padrão.

A solução de longo prazo é reduzir a área de ocupação da memória dos seus contêineres secundários do istio-proxy. Por padrão, todos os proxies de arquivos secundários 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 recurso personalizada Sidecar para limitar o número de endpoints programados para proxies sidecar e, portanto, reduzir o consumo de memória do contêiner istio-proxy.