[6주차] Control Plane 성능 조정 : 성능 조정

---

⚙️ Istio Control Plane 성능 튜닝하기

• Istio의 Control Plane은 서비스 메시의 성능을 좌우하는 핵심 구성 요소입니다. 하지만 클러스터 환경의 변화 빈도, 할당된 리소스, 관리하는 워크로드 수, 설정 크기 등 여러 요인에 의해 성능 병목현상이 발생할 수 있습니다.

---

🔍 Control Plane 성능 병목현상의 원인

• Control Plane의 성능은 다음 네 가지 주요 요인에 의해 영향을 받습니다:

• Rate of Changes: 클러스터에서 이벤트(예: Pod 생성/삭제)의 발생 빈도가 높을수록 처리 부하가 증가합니다.
• Allocated Resources: istiod에 할당된 CPU와 메모리가 부족하면 작업이 지연됩니다.
• Number of Workloads: 관리해야 할 워크로드(서비스 프록시) 수가 많을수록 더 많은 리소스와 네트워크 대역폭이 필요합니다.
• Configuration Size: Envoy 설정 파일의 크기가 크면 푸시 속도가 느려집니다.

• 이러한 요인 중 하나라도 병목현상을 일으키면 성능이 저하될 수 있습니다. 

Control Plane 성능은
변화 빈도, 리소스, 워크로드 수, 설정 크기에 의해 영향을 받습니다.

---

🛠️ 성능 튜닝 방법

• Istio는 Control Plane 성능을 최적화하기 위한 다양한 방법을 제공합니다.

📊 그림으로 이해하기: 성능 튜닝 옵션

1️⃣ 불필요한 이벤트 무시하기

• 클러스터에서 발생하는 모든 이벤트가 서비스 메시와 관련 있는 것은 아닙니다. istiod가 불필요한 이벤트를 무시하도록 설정하면 처리해야 할 이벤트의 양을 줄일 수 있습니다. 예를 들어, 특정 네임스페이스나 리소스 유형에 대한 이벤트를 필터링할 수 있습니다.

# 예: 특정 네임스페이스만 모니터링하도록 설정
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      discoverySelectors:
        - matchLabels:
            istio-discovery: enabled

불필요한 이벤트를 필터링해
istiod의 부하를 줄일 수 있습니다.

2️⃣ 이벤트 Batching 기간 늘리기

• Debouncing을 통해 이벤트를 일정 시간 동안 묶어 처리하면 푸시 횟수를 줄일 수 있습니다. Batching 기간을 늘리면 단기간에 발생하는 여러 이벤트를 하나로 통합해 처리하므로 Data Plane 업데이트 부담이 줄어듭니다.

# 예: Debouncing 기간 설정
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      debounce:
        max: 500ms

더 긴 Batching 기간으로 이벤트 푸시 횟수를 줄여
성능을 향상시킬 수 있습니다.

3️⃣ 리소스 증설

• 리소스 부족이 병목현상의 원인이라면 istiod에 더 많은 리소스를 할당하는 것이 해결책입니다. 이를 위해 두 가지 접근법이 있습니다:

a) Scale-Out: istiod 인스턴스 수 늘리기

istiod 배포를 수평 확장(Scale-Out)하면 워크로드를 여러 istiod 인스턴스에 분산시켜 각 인스턴스의 부하를 줄입니다.

# 예: istiod 복제본 수 증가
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istiod
  namespace: istio-system
spec:
  replicas: 3

b) Scale-Up: istiod 리소스 증가

istiod에 더 많은 CPU와 메모리를 할당해 수직 확장(Scale-Up)하면 Envoy 설정 생성 속도가 빨라지고, 더 많은 푸시 요청을 동시에 처리할 수 있습니다.

# 예: istiod 리소스 할당량 증가
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istiod
  namespace: istio-system
spec:
  template:
    spec:
      containers:
      - name: istiod
        resources:
          requests:
            cpu: "1"
            memory: "1Gi"
          limits:
            cpu: "2"
            memory: "2Gi"

Scale-Out과 Scale-Up을 통해
istiod의 리소스를 증설해 성능을 개선할 수 있습니다.

4️⃣ Sidecar 설정으로 업데이트 최적화

• Sidecar 리소스를 정의하면 각 워크로드에 필요한 최소한의 Envoy 설정만 푸시하도록 Control Plane을 설정할 수 있습니다. 이는 두 가지 이점이 있습니다:
  • 설정 크기 감소: 워크로드에 필요한 설정만 전송해 네트워크 부하를 줄입니다.
  • 업데이트 대상 감소: 특정 이벤트에 대해 업데이트가 필요한 프록시 수를 줄입니다.

# 예: Sidecar 리소스 정의
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: my-sidecar
  namespace: my-namespace
spec:
  workloadSelector:
    labels:
      app: my-app
  egress:
  - hosts:
    - "my-namespace/my-service"

 Sidecar 설정으로 설정 크기와 업데이트 대상을 줄여
성능을 최적화할 수 있습니다.

---

🚀 성능 테스트로 효과 확인하기

• 성능 튜닝의 효과를 확인하려면 클러스터에 테스트용 서비스를 배포하고 성능 테스트를 실행해야 합니다. 예를 들어, 여러 서비스를 추가하고 이벤트를 발생시켜 istiod의 처리 속도와 리소스 사용량을 측정할 수 있습니다. Grafana 대시보드를 통해 pilot_proxy_convergence_time, container_cpu_usage_seconds_total 같은 메트릭을 모니터링하며 튜닝 전후의 성능 차이를 비교하세요.

성능 테스트와 메트릭 모니터링으로
튜닝 효과를 검증할 수 있습니다.

---

📌 핵심 요약

• Control Plane 성능은 변화 빈도, 리소스, 워크로드 수, 설정 크기에 의해 영향을 받습니다.
• 성능 튜닝 방법:
  • 불필요한 이벤트를 무시해 부하를- Filter Events: 불필요한 이벤트를 필터링해 istiod 부하 감소.
  • Batching: 이벤트 배칭 기간을 늘려 푸시 횟수 감소.
  • Scale-Out/Scale-Up: istiod 인스턴스 수 또는 리소스 증설.
  • Sidecar: 필요한 설정만 푸시해 설정 크기와 업데이트 대상 감소.
• Grafana 대시보드로 성능 테스트 결과를 모니터링해 튜닝 효과를 확인하세요.

---

🛠️ Istio 성능 테스트를 위한 워크스페이스 설정

• Istio의 Control Plane 성능을 테스트하려면 실제 환경과 유사한 워크로드를 설정해 istiod의 부하를 시뮬레이션해야 합니다. 

---

🔍 워크스페이스 초기화

• 성능 테스트를 시작하기 전에, 클러스터에 Istio가 이미 설치되어 있지만 다른 애플리케이션 컴포넌트(Deployment, Service 등)는 없는 상태로 가정합니다. 이전 챕터에서 남아 있는 리소스가 있다면 먼저 정리해야 합니다.
• 다음 명령어를 사용해 istioinaction 네임스페이스를 설정하고 기존 리소스를 삭제합니다:

$ kubectl delete virtualservice,deployment,service,destinationrule,gateway --all

• 이 명령어는 VirtualService, Deployment, Service, DestinationRule, Gateway 등 네임스페이스 내 모든 관련 리소스를 제거해 깨끗한 테스트 환경을 만듭니다.

테스트 전 istioinaction 네임스페이스의 기존 리소스를 삭제해 깨끗한 환경을 준비합니다.

---

🚀 워크로드 추가하기

• istiod가 관리할 워크로드를 추가해 부하를 시뮬레이션합니다.
  여기서는 catalog 워크로드와 10개의 더미 워크로드를 배포합니다. 이를 통해 istiod가 처리해야 할 워크로드 수를 늘립니다.
• 다음 명령어를 실행해 워크로드를 배포합니다:

# catalog 워크로드 배포
kubectl -n istioinaction apply -f services/catalog/kubernetes/catalog.yaml

# catalog VirtualService 설정
kubectl -n istioinaction apply -f ch11/catalog-virtualservice.yaml

# catalog Gateway 설정
kubectl -n istioinaction apply -f ch11/catalog-gateway.yaml

# 10개의 더미 워크로드 배포
$ kubectl -n istioinaction apply -f ch11/sleep-dummy-workloads.yaml
serviceaccount/sleep created
service/sleep created
deployment.apps/sleep created

• 하지만 이 정도로는 istiod에 충분한 부하를 주지 못할 수 있습니다.

catalog 워크로드와 10개의 더미 워크로드를 추가해
istiod의 관리 부하를 증가시킵니다.

---

📈 Envoy 설정 크기 늘리기

• istiod에 더 큰 부담을 주기 위해 Envoy 설정 크기를 인위적으로 늘립니다.
  600개의 더미 서비스를 추가해 istiod가 생성하고 푸시해야 하는 설정의 양을 크게 증가시킵니다.
• 다음 명령어를 실행해 더미 서비스를 배포합니다:

# 600개의 더미 서비스 추가
$ kubectl -n istioinaction apply -f ch11/resources-600.yaml
gateway.networking.istio.io/service510b-0-gateway created
service/service510b-0 created
virtualservice.networking.istio.io/service510b-0 created
....

• 이제 istiod는 13개의 워크로드뿐만 아니라 총 600개의 서비스를 인식하게 됩니다. 이는 Envoy 설정 생성에 필요한 처리량을 늘리고, 각 워크로드에 푸시되는 설정 크기를 크게 만듭니다. 결과적으로 istiod의 CPU 사용량과 네트워크 부하가 증가하며, 성능 병목현상을 유도할 수 있는 환경이 조성됩니다.

600개의 더미 서비스를 추가해
Envoy 설정 크기와 처리 부하를 증가시킵니다.

---

📌 핵심 요약

• 워크스페이스 초기화: istioinaction 네임스페이스의 기존 리소스를 삭제해 테스트 환경을 준비합니다.
• 워크로드 추가: catalog 워크로드와 10개의 더미 워크로드를 배포해 istiod가 관리할 워크로드 수를 늘립니다.
• 설정 크기 증가: 600개의 더미 서비스를 추가해 Envoy 설정 크기를 늘리고 istiod의 부하를 시뮬레이션합니다.
• 이 설정은 istiod의 성능 병목현상을 테스트하기 위한 환경을 조성합니다.

---

📈 Istio Control Plane 성능 측정 및 최적화

• Istio의 Control Plane 성능을 최적화하기 위해서는 먼저 현재 성능을 측정하고, 이를 기준으로 개선 효과를 확인해야 합니다.
• Sidecar 리소스를 활용해 Envoy 설정 크기와 푸시 횟수를 줄이는 방법을 설명합니다. 성능 테스트를 통해 최적화 전후의 차이를 비교하며, Sidecar 설정의 중요성을 알아보겠습니다.

---

🔍 성능 테스트로 기준 성능 측정하기

• 성능 최적화의 첫 단계는 현재 Control Plane의 성능을 측정하는 것입니다. 이를 위해 서비스를 반복적으로 생성해 부하를 유도하고, 푸시 횟수와 P99 Latency(99번째 백분위수 지연 시간)를 측정합니다.

📘 P99 Latency란?

• P99 Latency는 가장 빠른 99%의 업데이트가 완료되는 최대 지연 시간을 의미합니다. 예를 들어, P99 Latency가 80ms라면, 99%의 요청이 80ms 이내에 처리되었다는 뜻입니다. 나머지 1%는 더 오래 걸릴 수 있지만, P99는 시스템 성능의 전반적인 건강 상태를 평가하는 데 유용합니다.
• 다음 명령어로 성능 테스트를 실행합니다. 테스트는 10번 반복하며, 각 반복 사이에 2.5초 지연을 두어 이벤트가 배칭(Batching)되지 않도록 합니다:
• bin/performance-test.sh : 파일 수정! $GATEWAY:30000/items

$ ./bin/performance-test.sh --reps 10 --delay 2.5 --prom-url prometheus.istio-system.svc.cluster.local:9090
Pre Pushes: 1534
gateway.networking.istio.io/service-63b6-0 created
service/service-63b6-0 created
virtualservice.networking.istio.io/service-63b6-0 created
...
==============

Push count: 510 # 변경 사항을 적용하기 위한 푸시 함수
Latency in the last minute: 0.10 seconds # 마지막 1분 동안의 지연 시간

• 이 테스트는 기준 성능을 측정하기 위한 결과로, 이후 최적화 효과를 비교하는 데 사용됩니다.

---

• 딜레이 없이 실행

$ ./bin/performance-test.sh --reps 10 --prom-url prometheus.istio-system.svc.cluster.local:9090
Pre Pushes: 2047
gateway.networking.istio.io/service-e927-2 created
service/service-e927-2 created
gateway.networking.istio.io/service-cd31-3 created
gateway.networking.istio.io/service-23c9-4 created
virtualservice.networking.istio.io/service-e927-2 created
...
==============

Push count: 51
Latency in the last minute: 0.10 seconds

• 서비스 간의 간격을 없애면, 푸시 횟수와 지연 시간 모두 떨어지는 것을 볼 수 있다.
  이는 이벤트가 배치 처리돼서 더 적은 작업량으로 처리되기 때문이다.

성능 테스트로 푸시 횟수와 P99 Latency를 측정해
Control Plane의 기준 성능을 파악합니다.

---

🛠️ Sidecar로 설정 크기와 푸시 횟수 줄이기

• 마이크로서비스 환경에서 서비스는 보통 소수의 다른 서비스와만 상호작용합니다. 하지만 Istio는 기본적으로 모든 서비스 프록시가 메시 내 모든 워크로드에 대해 알도록 설정합니다. 이는 Envoy 설정 크기를 불필요하게 늘리고, 성능에 부담을 줍니다.

📏 현재 설정 크기 확인하기

• catalog 워크로드의 설정 크기를 확인해보겠습니다:

# catalog Pod 이름 가져오기
$ CATALOG_POD=$(kubectl -n istioinaction get pod -l app=catalog -o jsonpath={.items..metadata.name} | cut -d ' ' -f 1)

# Envoy 설정 덤프
$ kubectl -n istioinaction exec -ti $CATALOG_POD -c catalog -- curl -s localhost:15000/config_dump > /tmp/config_dump

# 설정 파일 크기 확인
$ du -sh /tmp/config_dump
2.0M    /tmp/config_dump

• 2MB의 설정 크기는 중간 규모 클러스터(200개 워크로드)에서는 총 400MB로 늘어나며, CPU, 메모리, 네트워크 대역폭에 큰 부담을 줍니다.

기본 설정은 모든 워크로드를 포함해 Envoy 설정 크기를 불필요하게 키웁니다.

---

🚀 Sidecar 리소스 이해하기

• Sidecar 리소스는 워크로드별로 필요한 최소한의 설정만 푸시하도록 Control Plane을 조정합니다. 이를 통해 설정 크기와 푸시 횟수를 줄여 성능을 최적화할 수 있습니다.
• 다음은 Sidecar 리소스의 예시입니다:

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: default
  namespace: istioinaction
spec:
  workloadSelector:
    labels:
      app: foo
  egress:
  - hosts:
    - "./bar.istioinaction.svc.cluster.local"
    - "istio-system/*"

주요 필드 설명

• workloadSelector: 이 설정이 적용될 워크로드를 지정합니다(예: app: foo 레이블).
• ingress: 수신 트래픽 처리 방식. 생략 시 Pod 정의를 기반으로 자동 설정.
• egress: 송신 트래픽 대상 서비스 지정. 생략 시 더 일반적인 Sidecar 설정을 상속하거나 모든 서비스로의 접근을 허용.
• outboundTrafficPolicy: 송신 트래픽 처리 모드.
  • REGISTRY_ONLY: 설정된 서비스로만 트래픽 허용.
  • ALLOW_ANY: 모든 대상으로 트래픽 허용.
• Sidecar를 적용하면 Control Plane은 egress 필드를 참조해 워크로드가 필요로 하는 서비스만 포함한 설정을 생성합니다. 이는 CPU, 메모리, 네트워크 대역폭 사용량을 줄입니다.

Sidecar 리소스는 워크로드별 최소 설정을 푸시해 성능을 최적화합니다.

---

🌐 메시 전체 Sidecar 설정으로 기본값 개선

• 모든 서비스 프록시에 최소한의 설정을 적용하려면 Mesh-Wide Sidecar 설정을 정의합니다.
  이 설정은 istio-system 네임스페이스의 서비스(예: Control Plane, Prometheus)로의 트래픽만 허용하도록 기본값을 지정합니다. 이를 통해 불필요한 설정을 제거하고, 서비스 소유자가 명시적으로 egress 트래픽을 정의하도록 유도합니다.
• 테스트를 위해 샘플 nginx 배포

$ cat << EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP
EOF
deployment.apps/nginx created
service/nginx created

• catalog 에서 nginx 서비스 접속 확인

$ docker exec -it myk8s-control-plane istioctl proxy-config endpoint deploy/catalog.istioinaction | grep nginx
10.10.0.23:80                                           HEALTHY     OK                outbound|80||nginx.default.svc.cluster.local

$ kubectl exec -it deploy/catalog -n istioinaction -- curl nginx.default | grep title
<title>Welcome to nginx!</title>

•  
• 다음은 Mesh-Wide Sidecar 설정 예시입니다:

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: default
  namespace: istio-system
spec:
  egress:
  - hosts:
    - "istio-system/*"
    - "prometheus/*"
  outboundTrafficPolicy:
    mode: REGISTRY_ONLY

• 이 설정을 클러스터에 적용합니다:

$ kubectl -n istio-system apply -f ch11/sidecar-mesh-wide.yaml
sidecar.networking.istio.io/default created

설정 크기 확인

• Mesh-Wide Sidecar 적용 후 catalog 워크로드의 설정 크기를 다시 확인합니다:

$ CATALOG_POD=$(kubectl -n istioinaction get pod -l app=catalog -o jsonpath={.items..metadata.name} | cut -d ' ' -f 1)
$ kubectl -n istioinaction exec -ti $CATALOG_POD -c catalog -- curl -s localhost:15000/config_dump > /tmp/config_dump
$ du -sh /tmp/config_dump
512K    /tmp/config_dump

• 설정 크기가 2MB에서 512K로 대폭 줄었습니다! 또한, Control Plane은 이제 필요한 워크로드에만 업데이트를 푸시하므로 푸시 횟수도 감소합니다.

Mesh-Wide Sidecar는 최소 설정을 적용해
설정 크기와 푸시 횟수를 줄입니다.

---

📊 최적화 후 성능 테스트

• Mesh-Wide Sidecar 적용 후 성능 테스트를 다시 실행해 개선 효과를 확인합니다:

$ ./bin/performance-test.sh --reps 10 --delay 2.5 --prom-url prometheus.istio-system.svc.cluster.local:9090
Pre Pushes: 2327
gateway.networking.istio.io/service-21db-0 created
service/service-21db-0 created
virtualservice.networking.istio.io/service-21db-0 created
...
==============

Push count: 74
Latency in the last minute: 0.10 seconds

 

• 푸시 횟수는 74로, P99 Latency는 0.10s(100ms)로 Sidecar 설정으로 성능이 크게 개선되었습니다. 이는 메시 운영 비용을 줄이고, 서비스 소유자가 명시적인 egress 설정을 정의하도록 유도하는 좋은 습관을 강화합니다.

Mesh-Wide Sidecar로 푸시 횟수와 Latency를 줄여
성능을 크게 향상시켰습니다.

---

⚠️ 기존 클러스터에서의 주의사항

• 기존 클러스터에서 Mesh-Wide Sidecar를 적용하기 전에, 서비스 소유자와 협의해 워크로드별 egress 트래픽을 명시적으로 정의해야 합니다. 이를 생략하면 서비스 중단이 발생할 수 있습니다. 항상 Pre-Production 환경에서 테스트 후 적용하세요.

📘 Sidecar 설정 범위

• Sidecar 설정은 적용 범위에 따라 세 가지로 나뉩니다:
  • Mesh-Wide: istio-system 네임스페이스에 적용, 모든 워크로드에 기본값 설정. 일반적으로 default로 명명.
  • Namespace-Wide: 특정 네임스페이스에 적용, workloadSelector 없이 정의. default로 명명.
  • Workload-Specific: workloadSelector로 특정 워크로드 대상, 가장 우선순위 높음.

동일 범위 내 다중 Sidecar 정의는 지원되지 않으며, 동작이 문서화되지 않았습니다.

Mesh-Wide Sidecar 적용 전 egress 정의와 테스트가 필수입니다.

---

📌 핵심 요약

• 성능 테스트: 서비스 생성으로 부하를 유도해 푸시 횟수(700)와 P99 Latency를 측정.
• 문제점: 기본 설정은 모든 워크로드를 포함해 Envoy 설정 크기(2MB)를 증가시킴.
• Sidecar 리소스: 워크로드별 최소 설정을 푸시해 CPU, 메모리, 네트워크 부하 감소.
• Mesh-Wide Sidecar: istio-system 서비스로의 트래픽만 허용, 설정 크기와 푸시 횟수대폭 감소.
• 주의사항: 기존 클러스터에서는 egress 정의 후 Pre-Production 테스트 필수.
• Sidecar 범위: Mesh-Wide, Namespace-Wide, Workload-Specific으로 나뉘며, 우선순위가 다름.

---

🚫 Istio Control Plane 부하 줄이기:
Discovery Selectors 활용

• Istio의 Control Plane은 기본적으로 모든 네임스페이스의 Pod, Service 등 리소스 생성 이벤트를 감시합니다. 대규모 클러스터에서는 이로 인해 istiod에 과도한 부하가 발생할 수 있습니다. 이를 해결하기 위해 Istio 1.10부터 추가된 Discovery Selectors 기능을 사용하면 감시 대상 네임스페이스를 선택적으로 지정해 부하를 줄일 수 있습니다.

---

🔍 Discovery Selectors란?

• 기본적으로 Control Plane은 클러스터의 모든 네임스페이스에서 발생하는 이벤트를 감시하고, 이를 바탕으로 Envoy 설정을 생성해 Data Plane에 배포합니다. 하지만 대규모 클러스터에서는 불필요한 이벤트까지 처리하면서 성능이 저하될 수 있습니다. 예를 들어, 메시와 관련 없는 워크로드(예: Spark Job처럼 빈번히 생성/삭제되는 워크로드)의 이벤트는 istiod에 불필요한 부담을 줍니다.
• Discovery Selectors는 Control Plane이 감시할 네임스페이스를 특정 레이블로 제한하는 기능입니다. 이를 통해 메시와 관련 있는 네임스페이스만 처리하고, 나머지는 무시해 성능을 최적화할 수 있습니다.

Discovery Selectors는
감시 대상 네임스페이스를 제한해 Control Plane의 부하를 줄입니다.

---

🛠️ Discovery Selectors 설정하기

• Discovery Selectors를 활성화하려면 IstioOperator 리소스를 사용해 Istio 설치 시 네임스페이스 선택 조건을 지정합니다. 아래는 특정 레이블(istio-discovery: enabled)이 있는 네임스페이스만 감시하도록 설정하는 예시입니다:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
spec:
  meshConfig:
    discoverySelectors:
    - matchLabels:
        istio-discovery: enabled

• 이 설정은 istio-discovery: enabled 레이블이 있는 네임스페이스만 Control Plane이 감시하도록 제한합니다. 레이블이 없는 네임스페이스는 무시됩니다.

IstioOperator의 discoverySelectors로
감시 대상 네임스페이스를 레이블로 지정합니다.

---

🚀 특정 네임스페이스 제외하기

• 모든 네임스페이스를 감시하되, 특정 네임스페이스만 제외하고 싶을 때는 matchExpressions를 사용해 제외 조건을 정의할 수 있습니다. 아래는 istio-exclude: true 레이블이 있는 네임스페이스를 제외하는 예시입니다:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
spec:
  meshConfig:
    discoverySelectors:
    - matchExpressions:
      - key: istio-exclude
        operator: NotIn
        values:
        - "true"

• 이 설정을 적용하려면 다음 명령어를 실행합니다:

$ docker exec -it myk8s-control-plane istioctl install -y -f /istiobook/ch11/istio-discovery-selector.yaml
✔ Istio core installed
✔ Istiod installed
✔ Egress gateways installed
✔ Ingress gateways installed
✔ Installation complete                                                                                                        Making this installation the default for injection and validation.

Thank you for installing Istio 1.17.  Please take a few minutes to tell us about your install/upgrade experience!  https://forms.gle/hMHGiwZHPU7UQRWe9

• 이렇게 하면 기존 동작(모든 네임스페이스 감시)을 유지하면서 istio-exclude: true 레이블이 있는 네임스페이스만 제외됩니다.

matchExpressions로
특정 네임스페이스를 제외해 감시 범위를 세밀히 조정할 수 있습니다.

---

🧪 설정 테스트하기

• Discovery Selectors 설정 후, 제외된 네임스페이스의 워크로드가 Control Plane에 영향을 주지 않는지 확인해보겠습니다.
  새 네임스페이스를 생성하고 제외 레이블을 추가합니다:

$ kubectl create ns new-ns
namespace/new-ns created

$ kubectl label namespace new-ns istio-injection=enabled
namespace/new-ns labeled

$ kubectl label ns new-ns istio-exclude=true
namespace/new-ns labeled

• 이 네임스페이스에 새 워크로드를 배포하더라도 istioinaction 네임스페이스의 워크로드는 해당 엔드포인트를 인식하지 않습니다. 이는 Control Plane이 해당 네임스페이스의 이벤트를 무시하기 때문입니다. 직접 워크로드를 배포해 결과를 확인해보세요.
• 테스트를 위해 샘플 nginx 배포

cat << EOF | kubectl apply -n new-ns -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP
EOF


$ docker exec -it myk8s-control-plane istioctl proxy-config endpoint deploy/istio-ingressgateway.istio-system | grep nginx
10.10.0.23:80                                           HEALTHY     OK                outbound|80||nginx.default.svc.cluster.local
10.10.0.24:80                                           HEALTHY     OK                outbound|80||nginx.new-ns.svc.cluster.local

• 확인

$ docker exec -it myk8s-control-plane istioctl proxy-config endpoint deploy/istio-ingressgateway.istio-system | grep nginx
10.10.0.23:80                                           HEALTHY     OK                outbound|80||nginx.default.svc.cluster.local

핵심 내용: 제외된 네임스페이스의 워크로드는 Control Plane에 영향을 주지 않습니다.

---

🔄 다음 단계: 이벤트 배칭

• Discovery Selectors로 감시 범위를 줄였음에도 Control Plane이 포화 상태라면, 다음으로 이벤트 배칭(Event Batching) 을 고려해야 합니다. 이벤트를 개별적으로 처리하는 대신 일정 시간 동안 모아 한꺼번에 처리하면 푸시 횟수를 줄이고 성능을 개선할 수 있습니다.

Discovery Selectors로도 포화가 해결되지 않으면 이벤트 배칭을 활용하세요.

---

📌 핵심 요약

• Discovery Selectors는 Control Plane이 감시할 네임스페이스를 레이블로 제한해 부하를 줄이는 Istio 1.10의 기능입니다.
• matchLabels로 특정 레이블(예: istio-discovery: enabled)이 있는 네임스페이스만 감시하도록 설정 가능.
• matchExpressions로 특정 레이블(예: istio-exclude: true)을 제외해 세밀한 제어 가능.
• 제외된 네임스페이스의 워크로드는 Control Plane에 영향을 주지 않으며, 직접 테스트로 확인 가능.
• 포화 상태가 지속되면 이벤트 배칭으로 추가 최적화를 고려해야 합니다.

---

⚙️ Istio Control Plane 최적화:
이벤트 배칭과 리소스 할당

• Istio의 Control Plane은 클러스터 환경에서 발생하는 다양한 이벤트를 처리해 Data Plane의 설정을 최신 상태로 유지합니다. 하지만 이벤트가 너무 자주 발생하거나 처리량이 많아지면 성능 병목현상이 발생할 수 있습니다.
• 이벤트 배칭(Event Batching) 과 푸시 스로틀링(Push Throttling), 그리고 리소스 증설을 통해 Control Plane 성능을 최적화하는 방법을 설명합니다.

---

🔍 이벤트 배칭과 푸시 스로틀링 이해하기

• 클러스터에서 서비스 생성, 스케일링, 상태 변화 같은 이벤트는 Control Plane이 감지해 Envoy 설정을 업데이트합니다. 하지만 모든 이벤트를 즉시 처리하면 istiod에 과도한 부하가 걸립니다. 이를 줄이기 위해 이벤트 배칭과 푸시 스로틀링을 사용합니다.

📊 이벤트 배칭이란?

• 이벤트 배칭은 일정 시간 동안 발생한 이벤트를 모아 한꺼번에 처리하는 방식입니다. 이를 Debouncing이라고도 하며, 배칭된 이벤트는 하나의 Envoy 설정으로 통합되어 Data Plane에 푸시됩니다. 이 과정은 푸시 횟수를 줄여 성능을 개선합니다.

📊 그림으로 이해하기: 이벤트 배칭

• Debouncing 기간을 늘리면 더 많은 이벤트가 하나의 푸시로 통합되지만, 너무 길게 설정하면 설정이 오래되어 Data Plane이 최신 상태를 반영하지 못할 수 있습니다. 반대로, 기간을 줄이면 업데이트 속도는 빨라지지만 푸시 요청이 많아져 Push Queue에서 스로틀링이 발생할 수 있습니다.

이벤트 배칭은 이벤트를 모아 한꺼번에 처리해 푸시 횟수를 줄입니다.

---

🛠️ 배칭과 스로틀링 환경 변수 설정

• Istio는 istiod의 동작을 조정하는 여러 환경 변수를 제공합니다. 이를 통해 Debouncing 기간과 Push Throttling을 세밀히 조정할 수 있습니다.

주요 환경 변수

• PILOT_DEBOUNCE_AFTER: 이벤트가 푸시 큐에 추가되기 전 대기 시간. 기본값은 100ms로, 이 기간 동안 추가 이벤트가 발생하면 함께 병합됩니다.
• PILOT_DEBOUNCE_MAX: 최대 Debouncing 시간. 기본값은 10초로, 이 시간을 초과하면 병합된 이벤트가 푸시 큐에 추가됩니다.
• PILOT_ENABLE_EDS_DEBOUNCE: 엔드포인트 업데이트에 Debouncing을 적용할지 여부. 기본값은 true로, false로 설정하면 엔드포인트 업데이트가 즉시 큐에 추가됩니다.
• PILOT_PUSH_THROTTLE: 동시에 처리되는 푸시 요청 수. 기본값은 100이며, CPU가 충분하면 더 높게 설정해 업데이트 속도를 높일 수 있습니다.

설정 가이드라인

• Control Plane 포화 시:
  • 이벤트 배칭 증가: PILOT_DEBOUNCE_AFTER를 늘려 푸시 횟수 감소.
  • 동시 푸시 감소: PILOT_PUSH_THROTTLE을 줄여 아웃바운드 트래픽 부하 감소.
• 빠른 업데이트 필요 시:
  • 이벤트 배칭 감소: PILOT_DEBOUNCE_AFTER를 줄여 빠른 업데이트.
  • 동시 푸시 증가: PILOT_PUSH_THROTTLE을 늘려 처리 속도 향상(포화되지 않은 경우에만).

환경 변수를 조정해 Debouncing과 Throttling을 최적화할 수 있습니다.

---

🚀 배칭 기간 늘리기 실습

• 이벤트 배칭의 효과를 확인하기 위해 PILOT_DEBOUNCE_AFTER를 2.5초로 설정해보겠습니다. 이는 프로덕션 환경에서는 권장되지 않는 과도한 값으로, 실습 목적으로만 사용됩니다.
• 다음 명령어로 Istio를 설치하며 환경 변수를 설정합니다:

$ docker exec -it myk8s-control-plane bash
root@myk8s-control-plane:/# istioctl install --set profile=demo --set values.pilot.env.PILOT_DEBOUNCE_AFTER="2500ms" --set values.global.proxy.privileged=true --set meshConfig.accessLogEncoding=JSON -y
✔ Istio core installed
✔ Istiod installed
✔ Egress gateways installed
✔ Ingress gateways installed
✔ Installation complete                                                                                                        Making this installation the default for injection and validation.

Thank you for installing Istio 1.17.  Please take a few minutes to tell us about your install/upgrade experience!  https://forms.gle/hMHGiwZHPU7UQRWe9
root@myk8s-control-plane:/# exit

• 이제 성능 테스트를 실행해 푸시 횟수와 Latency를 확인합니다:

$ ./bin/performance-test.sh --reps 10 --delay 2.5 --prom-url prometheus.istio-system.svc.cluster.local:9090
Pre Pushes: 106
gateway.networking.istio.io/service-e250-0 created
service/service-e250-0 created
virtualservice.networking.istio.io/service-e250-0 created
...
==============

Push count: 21
Latency in the last minute: 0.10 seconds

 

• 푸시 횟수가 21로 대폭 줄었습니다! 이는 더 많은 이벤트가 하나의 푸시로 병합되어 Envoy 설정 생성과 푸시 작업이 줄어들었기 때문입니다. 결과적으로 CPU 사용량과 네트워크 대역폭 소비가 감소했습니다.

⚠️ Latency 메트릭 주의점

• 테스트 결과 Latency는 0.10 seconds 로 나타났지만, 이는 Push Queue에 요청이 추가된 이후의 시간만 측정한 것입니다
  Debouncing 기간(2.5초)은 포함되지 않으므로 실제 업데이트 지연은 더 길어질 수 있습니다.
  과도한 Debouncing은 Data Plane 설정이 오래되는 문제를 유발하므로, 프로덕션에서는 작은 단위로 조정하세요.

엔드포인트 업데이트 지연을 방지하려면
PILOT_ENABLE_EDS_DEBOUNCE를 false로 설정해 Debouncing을 건너뛰세요.

긴 Debouncing 기간은 푸시 횟수를 줄이지만, 과도하면 설정이 오래될 수 있습니다.

---

📊 리소스 증설로 성능 개선

• Sidecar 설정, Discovery Selectors, 이벤트 배칭을 적용했음에도 성능이 충분하지 않다면, Control Plane에 리소스를 추가해야 합니다. 리소스 증설은 Scale-Out(인스턴스 수 증가)과 Scale-Up(인스턴스 리소스 증가) 두 가지 방식으로 진행됩니다.

Scale-Out vs. Scale-Up

• Scale-Out: 아웃바운드 트래픽이 병목현상 원인일 때 적합. istiod 인스턴스를 늘려 워크로드 관리 부하를 분산.
• Scale-Up: 인바운드 트래픽(예: Service, VirtualService 처리)이 병목현상 원인일 때 적합. 각 istiod 인스턴스의 CPU/메모리를 늘려 처리 능력 강화.

$ docker exec -it myk8s-control-plane bash
root@myk8s-control-plane:/# istioctl install --set profile=demo \
--set values.pilot.resources.requests.cpu=1000m \
--set values.pilot.resources.requests.memory=4Gi \
--set values.pilot.replicaCount=3 -y
✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Egress gateways installed
✔ Installation complete                                                                                                        Making this installation the default for injection and validation.

Thank you for installing Istio 1.17.  Please take a few minutes to tell us about your install/upgrade experience!  https://forms.gle/hMHGiwZHPU7UQRWe9
root@myk8s-control-plane:/# exit
exit

• CPU 요청: 파드의 CPU 요청을 1000 millicores (1 CPU 코어)로 설정합니다.
• 메모리 요청: 파드의 메모리 요청을 1GiB로 설정합니다.
• 복제본 수: 파드의 레플리카 수를 2로 설정합니다.

Scale-Out은 워크로드 수를 분산하고,
Scale-Up은 처리 능력을 강화합니다.

---

⚠️ Autoscaling 주의점

• istiod에 Autoscaling을 적용하면 부하에 따라 인스턴스 수가 자동 조정되지만, 현재는 효과가 제한적입니다. istiod는 워크로드와 30분간의 ADS(Aggregated Discovery Service) 연결을 유지하므로, 새 인스턴스가 즉시 부하를 분담하지 못합니다. 이로 인해 Autoscaling은 Flapping(인스턴스 수의 반복적인 증가/감소)을 유발할 수 있습니다.

Autoscaling은 장기적인 부하 증가(일, 주, 월 단위)에 적합하며, 단기 부하에는 수동 조정이 더 안정적입니다.

istiod Autoscaling은 ADS 연결로 인해 단기 부하에 적합하지 않습니다.

---

📌 핵심 요약

• 이벤트 배칭: Debouncing으로 이벤트를 모아 푸시 횟수를 줄여 성능 개선(PILOT_DEBOUNCE_AFTER, PILOT_DEBOUNCE_MAX).
• 푸시 스로틀링: 동시 푸시 수를 조정해 부하 관리(PILOT_PUSH_THROTTLE).
• 실습 결과: PILOT_DEBOUNCE_AFTER를 2.5초로 설정해 푸시 횟수를 27로 줄임(프로덕션에서는 작은 조정 권장).
• Latency 주의: Debouncing 기간은 Latency 메트릭에 포함되지 않아 실제 지연은 더 길어질 수 있음.
• 리소스 증설: Scale-Out(아웃바운드 병목)과 Scale-Up(인바운드 병목)으로 성능 개선.
• Autoscaling 제한: ADS 연결로 인해 단기 부하에 부적합, 장기 부하에 적합.
• 최적화 우선순위: Sidecar 설정, Discovery Selectors, 배칭 조정 후 리소스 증설 고려.

---