Cloud Service Mesh의 사이드카 프록시 문제 해결

이 섹션에서는 일반적인 Cloud Service Mesh 사이드카 프록시 문제와 해결 방법을 설명합니다. 추가 지원이 필요하면 지원 받기를 참조하세요.

OOM 이벤트로 인해 istio-proxy 컨테이너가 종료됩니다.

이 섹션에서는 istio-proxy 컨테이너가 SystemOOM 이벤트로 인해 종료되지 않고 Kubernetes 노드가 MemoryPressure 조건이 아니라고 가정합니다. istio-proxy 사이드카 컨테이너에는 기본적으로 리소스 한도가 있습니다. istio-proxy 컨테이너가 Reason: OOMKilled로 종료되는 경우 Envoy가 메모리를 소비하는 이유를 이해해야 합니다.

프로덕션 중단이 발생하는 경우 빠른 해결 방법은 IstioOperator를 사용하여 모든 컨테이너의 한도를 올리는 것입니다.

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

특정 워크로드에서 이 문제가 발생하면 다음 annotations을 추가하여 해당 워크로드에 대한 제한을 변경할 수 있습니다.

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

기본값보다 작은 한도가 없는지 확인하세요.

장기적인 해결책은 istio-proxy 사이드카 컨테이너의 메모리 사용 공간을 줄이는 것입니다. 기본적으로 모든 사이드카 프록시는 메시의 다른 워크로드 인스턴스에 연결하는 데 필요한 구성으로 프로그래밍됩니다. Istio는 사이드카 프록시로 프로그래밍된 엔드포인트 수를 제한하여 istio-proxy 컨테이너의 메모리 소비를 줄이기 위한 커스텀 리소스 정의 Sidecar를 제공합니다.