Anthos Service Mesh와 Traffic Director가 이제 Cloud Service Mesh로 통합되었습니다. 자세한 내용은 Cloud Service Mesh 개요를 참조하세요.

Cloud Service Mesh의 리소스 한도 문제 해결

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

Cloud Service Mesh 리소스 한도 문제의 원인은 다음 중 하나일 수 있습니다.

리소스 문제의 증상은 다음과 같을 수 있습니다.

Cloud Service Mesh가 Envoy proxy NOT ready 오류가 표시되는 컨트롤 플레인에서 구성을 반복적으로 수신하지 않습니다. 시작할 때 이 오류가 몇 번 표시되는 것은 정상이지만 그 외의 경우에는 문제가 됩니다.
일부 pod 또는 노드에 네트워킹 문제가 발생하여 연결이 되지 않습니다.
istioctl proxy-status가 출력에 STALE 상태를 표시합니다.
노드의 로그에 있는 OOMKilled 메시지
컨테이너의 메모리 사용량: kubectl top pod POD_NAME --containers
노드 내부 pod의 메모리 사용량: kubectl top node my-node
Envoy의 메모리 부족: kubectl get pods가 출력에 OOMKilled 상태를 표시합니다.

사이드카는 구성을 수신하는 데 오랜 시간이 걸림

istiod에 할당된 리소스가 부족하거나 과도하게 큰 클러스터 크기로 인해 구성 전파 시간이 느려질 수 있습니다.

다음과 같은 몇 가지 방법을 통해 이 문제를 해결할 수 있습니다.

클러스터 내 Cloud Service Mesh의 경우 모니터링 도구(Prometheus, Stackdriver 등)에 istiod의 리소스 사용률이 높은 경우 해당 리소스의 할당을 늘립니다(예: istiod 배포의 CPU 또는 메모리 한도 늘리기). 이는 일시적인 솔루션이며, 리소스 소비를 줄이기 위한 방법을 조사하는 것이 좋습니다.
대규모 클러스터나 배포에서 이 문제가 발생하면 사이드카 리소스를 구성하여 각 프록시로 푸시되는 구성 상태의 양을 줄입니다.
클러스터 내 Cloud Service Mesh의 경우 문제가 지속되면 istiod를 수평 확장해 보세요.
다른 모든 문제 해결 단계를 수행해도 문제가 해결되지 않으면 배포 및 관측된 문제를 자세히 설명하는 버그를 보고합니다. 가능한 경우 클러스터 크기, pod 수, 서비스 수에 대한 자세한 설명과 함께 CPU/메모리 프로필을 버그 보고서에 포함하려면 다음 단계를 따르세요.