Istio 서비스 메시 추가 기능 성능 및 크기 조정

아티클
10/19/2024

Istio 기반 서비스 메시 추가 기능은 논리적으로 컨트롤 플레인(istiod)과 데이터 평면으로 분할됩니다. 데이터 평면은 워크로드 Pod 내부의 Envoy 사이드카 프록시로 구성됩니다. Istiod는 이러한 Envoy 프록시를 관리하고 구성합니다. 이 문서에서는 리소스 사용량, 사이드카 용량 및 대기 시간 오버헤드를 포함하여 수정 버전 asm-1-19에 대한 컨트롤 플레인 및 데이터 평면의 성능을 소개합니다. 또한 부하가 많이 발생하는 기간 동안 리소스에 대한 잠재적 부담을 해결하기 위한 제안을 제공합니다. 이 문서에서는 컨트롤 플레인과 게이트웨이의 크기 조정을 사용자 지정하는 방법도 다룹니다.

컨트롤 플레인 성능

Istiod의 CPU 및 메모리 요구 사항은 배포 및 구성 변경 속도 및 연결된 프록시 수와 상관 관계가 있습니다. 테스트된 시나리오는 다음과 같습니다.

Pod 변동: Pod 변동이 istiod에 미치는 영향을 검사합니다. 변수를 줄이기 위해 모든 사이드카에 하나의 서비스만 사용됩니다.
여러 서비스: Istiod가 관리할 수 있는 최대 사이드카(사이드카 용량)에 대한 여러 서비스의 영향을 검사합니다. 여기서 각 서비스에는 전체 최대 용량을 합한 값인 N 사이드카가 있습니다.

테스트 사양

기본 설정을 사용한 istiod 인스턴스 1개
HPA(Horizontal Pod Autoscaling) 사용 안 함
두 개의 네트워크 플러그 인으로 테스트됨: Azure CNI(Container Networking Interface) 오버레이 및 Cilium을 사용한 Azure CNI 오버레이 (대규모 클러스터에 권장되는 네트워크 플러그 인)
노드 SKU: 표준 D16 v3(16 vCPU, 64GB 메모리)
Kubernetes 버전: 1.28.5
Istio 수정 버전: asm-1-19

Pod 변동

ClusterLoader2 프레임워크를 사용하여 사이드카 변동 시 Istiod가 관리할 수 있는 최대 사이드카 수를 결정했습니다. 변동 비율은 테스트 중에 사이드카가 위/아래로 변동되는 백분율로 정의됩니다. 예를 들어 10,000개의 사이드카에 대해 50%의 변동은 5,000개의 사이드카가 변동된 다음 5,000개의 사이드카가 변동되는 것을 의미합니다. 테스트된 변동률은 배포 롤아웃(maxUnavailable) 도중 발생하는 일반적인 변동률에서 결정되었습니다. 변동률은 변동 프로세스를 완료하는 데 걸린 실제 시간 동안 변동된 사이드카의 총 수를 결정하여 계산되었습니다.

사이드카 용량과 Istiod CPU 및 메모리

Azure CNI 오버레이

변동(%)	변동률(사이드카/초)	사이드카 용량	Istiod 메모리(GB)	Istiod CPU
0	--	25000	32.1	15
25	31.2	15000	22.2	15
50	31.2	15000	25.4	15

Cilium을 사용한 Azure CNI 오버레이

변동(%)	변동률(사이드카/초)	사이드카 용량	Istiod 메모리(GB)	Istiod CPU
0	--	30000	41.2	15
25	41.7	25000	36.1	16
50	37.9	25000	42.7	16

여러 서비스

ClusterLoader2 프레임워크를 사용하여 istiod가 1,000개의 서비스로 관리할 수 있는 최대 사이드카 수를 결정했습니다. 결과는 Pod 변동 시나리오의 0% 변동 테스트(하나의 서비스)와 비교할 수 있습니다. 각 서비스에는 전체 최대 사이드카 수에 기여하는 N 사이드카가 있었습니다. 추가 기능에서 상당한 스트레스가 있는지 확인하기 위해 API Server 리소스 사용량을 관찰했습니다.

사이드카 용량

Azure CNI 오버레이	Cilium을 사용한 Azure CNI 오버레이
20000	20000

CPU 및 메모리

리소스	Azure CNI 오버레이	Cilium을 사용한 Azure CNI 오버레이
API 서버 메모리(GB)	38.9	9.7
API 서버 CPU	6.1	4.7
Istiod 메모리(GB)	40.4	42.6
Istiod CPU	15	16

데이터 평면 성능

요청 크기, 프록시 작업자 스레드 수 및 클라이언트 연결 수와 같은 다양한 요인이 사이드카 성능에 영향을 줍니다. 또한 메시를 통해 이동하는 모든 요청은 클라이언트 쪽 프록시와 서버 쪽 프록시를 통과합니다. 따라서 데이터 평면 성능을 파악하기 위해 대기 시간 및 리소스 사용량을 측정합니다.

로드를 만드는 데 Fortio가 사용되었습니다. 테스트는 추가 기능에 사용하기 위해 수정된 Istio 벤치마크 리포지토리를 사용하여 수행되었습니다.

테스트 사양

2개의 네트워크 플러그 인으로 테스트함: Cilium을 사용한 Azure CNI 오버레이 및 Azure CNI 오버레이(대규모 클러스터에 권장되는 네트워크 플러그 인)
노드 SKU: 표준 D16 v5(16 vCPU, 64GB 메모리)
Kubernetes 버전: 1.28.5
프록시 작업자 2명
페이로드 1KB
다양한 클라이언트 연결에서 초당 쿼리 수(QPS) 1,000개
http/1.1 프로토콜 및 상호 TLS(전송 계층 보안)가 사용하도록 설정됨
수집된 데이터 포인트 26개

CPU 및 메모리

모든 네트워크 플러그 인 시나리오에서 16개의 클라이언트 연결 및 1,000QPS에 대한 클라이언트 및 서버 프록시의 메모리 및 CPU 사용량은 약 0.4 vCPU 및 72MB입니다.

대기 시간

사이드카 Envoy 프록시는 클라이언트에 응답한 후 원시 원격 분석 데이터를 수집하므로 요청의 총 처리 시간에 직접적인 영향을 주지 않습니다. 그러나 이 프로세스는 다음 요청 처리 시작을 지연하여 큐 대기 시간과 평균 및 비상 대기 시간에 영향을 줍니다. 트래픽 패턴에 따라 실제 비상 대기 시간이 달라집니다.

다음 결과는 P90 및 P99 대기 시간을 보여 주는 사이드카 프록시를 데이터 경로에 추가하는 경우의 영향을 평가합니다.

사이드카 트래픽 경로: 클라이언트 -> 클라이언트 사이드카 --> 서버 사이드카 --> 서버
기준 트래픽 경로: 클라이언트 --> 서버

Istio 추가 기능 및 AKS 버전에서의 데이터 평면 대기 시간 성능 비교는 여기에서 확인할 수 있습니다.

Azure CNI 오버레이	Cilium을 사용한 Azure CNI 오버레이

확장

Horizontal Pod 자동 크기 조정 사용자 지정

HPA(수평형 Pod 자동 크기 조정)는 istiod 및 수신 게이트웨이 Pod에 대해 사용 설정되었습니다. istiod 및 게이트웨이의 기본 구성은 다음과 같습니다.

최소 복제본: 2
최대 복제본: 5
CPU 사용률: 80%

참고 항목

PodDisruptionBudget과의 충돌을 방지하기 위해 추가 기능은 minReplicas를 초기 기본값인 2 아래로 설정하는 것을 허용하지 않습니다.

다음은 istiod 및 수신 게이트웨이 HPA 리소스입니다.

NAMESPACE           NAME                                         REFERENCE
aks-istio-ingress   aks-istio-ingressgateway-external-asm-1-19   Deployment/aks-istio-ingressgateway-external-asm-1-19

aks-istio-ingress   aks-istio-ingressgateway-internal-asm-1-19   Deployment/aks-istio-ingressgateway-internal-asm-1-19

aks-istio-system    istiod-asm-1-19                              Deployment/istiod-asm-1-19

HPA 구성은 패치 및 직접 편집을 통해 수정할 수 있습니다. 예제:

kubectl patch hpa aks-istio-ingressgateway-external-asm-1-19 -n aks-istio-ingress --type merge --patch '{"spec": {"minReplicas": 3, "maxReplicas": 6}}'

참고 항목

카나리아 업그레이드 중 두 수정 버전에서 HPA 설정이 적용되는 방법에 대한 자세한 내용은 Istio 추가 기능 업그레이드 설명서를 참조하세요.

서비스 항목

Istio의 ServiceEntry 사용자 지정 리소스 정의를 사용하면 Istio의 내부 서비스 레지스트리에 다른 서비스를 추가할 수 있습니다. ServiceEntry를 사용하면 메시에 이미 있는 서비스가 지정된 서비스를 라우팅하거나 액세스할 수 있습니다. 그러나 resolution 필드가 DNS로 설정된 여러 ServiceEntries를 구성하면 DNS(Domain Name System) 서버에 과도한 로드가 발생할 수 있습니다. 다음 제안 사항은 부하 발생을 줄이는 데 도움이 될 수 있습니다.

프록시 DNS 조회를 완전히 방지하려면 resolution: NONE으로 전환합니다. 대부분의 사용 사례에 적합합니다.
확인 대상 도메인을 제어하는 경우 TTL(Time To Live)을 늘립니다.
exportTo를 사용하여 ServiceEntry 범위를 제한합니다.

다음을 통해 공유

Istio 서비스 메시 추가 기능 성능 및 크기 조정

컨트롤 플레인 성능

테스트 사양

Pod 변동

사이드카 용량과 Istiod CPU 및 메모리

여러 서비스

데이터 평면 성능

테스트 사양

CPU 및 메모리

대기 시간

확장

Horizontal Pod 자동 크기 조정 사용자 지정

서비스 항목

추가 리소스