Como resolver problemas de proxies sidecar no Anthos Service Mesh
Nesta seção, explicamos os problemas comuns dos arquivos secundários do Anthos 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
.