Cloud Service Mesh의 리소스 한도 문제 해결
이 섹션에서는 일반적인 Cloud Service Mesh 문제와 해결 방법을 설명합니다. 추가 지원이 필요하면 지원 받기를 참조하세요.
Cloud Service Mesh 리소스 한도 문제의 원인은 다음 중 하나일 수 있습니다.
istio-system
네임스페이스 또는 자동 사이드카 주입이 사용 설정된 모든 네임스페이스에서 생성된LimitRange
객체- 너무 낮게 설정된 사용자 정의 한도
- 메모리나 다른 리소스가 부족한 노드
리소스 문제의 증상은 다음과 같을 수 있습니다.
- 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/메모리 프로필을 버그 보고서에 포함하려면 다음 단계를 따르세요.