> For the complete documentation index, see [llms.txt](https://atomoh.gitbook.io/kubernetes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atomoh.gitbook.io/kubernetes/quiz/service-mesh/linkerd/traffic-management.md).
# 트래픽 관리 퀴즈
이 퀴즈는 Linkerd 트래픽 관리에 대한 이해를 테스트합니다.
## 퀴즈 문제
### 1. ServiceProfile에서 라우트별로 설정할 수 없는 것은?
A. 타임아웃 B. 재시도 가능 여부 C. 로드밸런서 알고리즘 D. 경로 조건
정답 및 설명
**정답: C. 로드밸런서 알고리즘**
**설명:** ServiceProfile은 라우트별로 타임아웃, 재시도 가능 여부(isRetryable), 경로 조건(method, pathRegex)을 설정할 수 있습니다. 로드밸런서 알고리즘은 Linkerd 전역 설정이며 EWMA가 사용됩니다.
### 2. Linkerd가 사용하는 로드 밸런싱 알고리즘은?
A. Round Robin B. Least Connections C. EWMA (Exponentially Weighted Moving Average) D. Random
정답 및 설명
**정답: C. EWMA (Exponentially Weighted Moving Average)**
**설명:** Linkerd는 EWMA 알고리즘을 사용하여 응답 지연 시간이 빠른 엔드포인트를 선호합니다. 실시간으로 엔드포인트 상태에 적응하고 느린 엔드포인트로의 트래픽을 자동으로 감소시킵니다.
### 3. TrafficSplit이 따르는 표준 사양은?
A. CNCF B. SMI (Service Mesh Interface) C. OpenAPI D. gRPC
정답 및 설명
**정답: B. SMI (Service Mesh Interface)**
**설명:** TrafficSplit은 SMI(Service Mesh Interface) 표준을 따르는 CRD입니다. SMI는 서비스 메시의 공통 인터페이스를 정의하여 다양한 메시 구현 간 호환성을 제공합니다.
### 4. 재시도 예산(retryBudget)의 retryRatio가 0.2일 때 의미하는 것은?
A. 모든 요청의 20%만 재시도 B. 실패한 요청의 20%만 재시도 C. 원래 요청 대비 최대 20% 추가 재시도 허용 D. 20초마다 재시도 예산 리셋
정답 및 설명
**정답: C. 원래 요청 대비 최대 20% 추가 재시도 허용**
**설명:** retryRatio 0.2는 원래 요청 수 대비 최대 20%의 추가 재시도를 허용합니다. 예: 100개 요청 중 최대 20개의 추가 재시도 가능. 이는 재시도로 인한 과부하를 방지합니다.
### 5. ServiceProfile을 자동 생성하는 방법이 아닌 것은?
A. OpenAPI/Swagger 스펙에서 생성 B. 실제 트래픽 탭에서 생성 C. Protobuf 정의에서 생성 D. Kubernetes Service에서 자동 생성
정답 및 설명
**정답: D. Kubernetes Service에서 자동 생성**
**설명:** ServiceProfile은 `linkerd profile --open-api`, `linkerd viz profile --tap`, `linkerd profile --proto` 명령으로 생성할 수 있습니다. Kubernetes Service에서 자동 생성되지 않으며 명시적으로 정의해야 합니다.
### 6. 카나리 배포 시 TrafficSplit의 backends 가중치 합계는?
A. 반드시 100이어야 함 B. 반드시 1이어야 함 C. 어떤 값이든 상관없음 (비율로 계산) D. 반드시 1000이어야 함
정답 및 설명
**정답: C. 어떤 값이든 상관없음 (비율로 계산)**
**설명:** TrafficSplit의 가중치는 상대적 비율로 계산됩니다. weight: 90과 weight: 10은 weight: 9와 weight: 1과 동일합니다. 합계가 100일 필요는 없습니다.
### 7. HTTPRoute(Gateway API)에서 지원하지 않는 라우팅 조건은?
A. 헤더 기반 라우팅 B. 경로 기반 라우팅 C. 쿠키 기반 라우팅 D. 소스 IP 기반 라우팅
정답 및 설명
**정답: D. 소스 IP 기반 라우팅**
**설명:** HTTPRoute는 헤더, 경로, 메서드, 쿠키(헤더를 통해) 기반 라우팅을 지원합니다. 소스 IP 기반 라우팅은 L7 라우팅 범위를 벗어나며 NetworkPolicy나 다른 메커니즘으로 처리됩니다.
### 8. Flagger와 Linkerd 통합 시 사용되는 메트릭 서버는?
A. Metrics Server B. Prometheus C. InfluxDB D. Datadog
정답 및 설명
**정답: B. Prometheus**
**설명:** Flagger는 Linkerd Viz의 Prometheus에서 메트릭(성공률, 지연 시간 등)을 가져와 카나리 분석을 수행합니다. Flagger 설치 시 `--set metricsServer=http://prometheus.linkerd-viz:9090`으로 연결합니다.
### 9. ServiceProfile의 isRetryable이 false인 라우트에서 발생하는 것은?
A. 모든 요청이 실패함 B. 재시도가 발생하지 않음 C. 타임아웃이 무시됨 D. 라우트가 비활성화됨
정답 및 설명
**정답: B. 재시도가 발생하지 않음**
**설명:** isRetryable: false는 해당 라우트의 요청이 실패해도 재시도하지 않음을 의미합니다. POST 요청처럼 멱등성이 없는 작업에 적합합니다. 요청 자체는 정상적으로 처리됩니다.
### 10. 서킷 브레이커(Circuit Breaker) 패턴이 Linkerd에서 구현되는 방식은?
A. Circuit Breaker CRD B. Failure Accrual C. Rate Limiter D. Timeout Policy
정답 및 설명
**정답: B. Failure Accrual**
**설명:** Linkerd는 failure accrual을 통해 서킷 브레이커 패턴을 구현합니다. 연속 실패 시 해당 엔드포인트를 일시적으로 제외하고, 지수 백오프로 재시도하며, 성공 시 정상 상태로 복귀합니다.
### 11. 트래픽 분할 없이 미러 서비스로 트래픽을 보내는 방법은?
A. TrafficMirror CRD 사용 B. 직접 미러 서비스 DNS 호출 C. 자동으로 모든 트래픽이 미러링됨 D. Linkerd는 트래픽 미러링을 지원하지 않음
정답 및 설명
**정답: B. 직접 미러 서비스 DNS 호출**
**설명:** Linkerd 자체는 Istio의 트래픽 미러링 같은 기능이 없습니다. 다중 클러스터의 미러 서비스(예: web-west)는 직접 DNS로 호출하거나 TrafficSplit으로 가중치를 설정해야 합니다.
### 12. ServiceProfile 타임아웃이 설정되지 않은 라우트의 동작은?
A. 기본 5초 타임아웃 적용 B. 타임아웃 없음 (무제한) C. 요청이 즉시 실패 D. 전역 타임아웃 적용
정답 및 설명
**정답: B. 타임아웃 없음 (무제한)**
**설명:** ServiceProfile에서 timeout이 지정되지 않은 라우트는 타임아웃 없이 무제한으로 대기합니다. 스트리밍이나 장시간 작업에 적합하지만, 일반적으로 타임아웃을 명시적으로 설정하는 것이 권장됩니다.