Cloud Service Mesh에서 Istio 확장 문제 해결

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

배율

Istiod는 수명이 긴 gRPC 스트림을 사용하여 구성을 각 사이드카에 전송합니다. 다음과 같이 확장에 영향을 미치는 여러 가지 특성이 있습니다.

  • 생성할 구성의 크기:
    • 총 서비스/포드 및 Istio 리소스 수
    • 규모가 큰 경우 Sidecar 설정을 조정하여 구성 크기를 줄입니다.
  • 환경의 변경 속도:
    • 새 서비스가 생성되거나 Istio 구성이 변경되면 전체 업데이트가 프록시로 전송됩니다.
    • 증분 업데이트만 전송되므로 새 엔드포인트를 추가해도 성능 대비 비용은 저렴합니다.
  • 구성이 생성되는 프록시 수:
    • 사이드카를 사용하는 게이트웨이 및 포드 수의 영향을 받습니다.

확장 고려사항

Istiod는 수직(대규모 요청)과 수평(여러 개의 복제본)으로 원활하게 확장됩니다. CPU 한도가 지나치게 제한적이지 않은지 확인합니다. Istiod가 CPU 한도에 도달하면 제한이 발생할 수 있으며, 이는 구성 배포에 부정적인 영향을 미칩니다. 성능 문제가 발생하는 경우 각 버전에 성능 최적화 기능이 있으므로 최신 버전의 Cloud Service Mesh로 업그레이드하는 것이 좋습니다.

불균형 부하

클러스터 크기가 크게 변경되면 수명이 긴 연결로 인해 일시적으로 불균형 부하가 발생할 수 있습니다. 이렇게 되면 최대 연결 수명이 30분까지 단축되어 Envoy에 gRPC config stream closed: 13과 같은 오류 메시지가 반환될 수 있으며, 이로 인해 부하가 원활하게 다시 분산됩니다.

Istiod의 복제본을 여러 개(기본값: 2개) 만들거나 극단적인 클러스터 수직 확장이 예상되는 경우 사전 확장을 수행하여 이 문제를 완화합니다.