クイズ: トラフィック管理

VirtualService 의 spec.http 배열에서 조건 없는 라우트를 맨 위에 두면?

• 그 라우트가 모든 요청을 잡아채 아래 조건부 규칙이 실행되지 않는다
• 도달할 수 없는 규칙이 생긴다는 검증 오류가 나면서 적용이 거부된다
• 조건이 더 구체적인 규칙이 먼저 평가되도록 순서가 자동으로 재정렬된다
• 조건 없는 라우트는 기본값으로 취급되어 언제나 가장 마지막에 평가된다

DestinationRule 의 subset 이 실제로 파드를 고르는 기준은?

• subset 의 name 에 적은 이름 문자열
• Deployment 이름 끝에 붙은 버전 접미사
• Service 포트 이름에 적은 프로토콜 접두어
• subset 의 labels 에 적은 라벨

timeout: 2s, retries.attempts: 3, perTryTimeout: 1s 로 설정했을 때의 문제는?

• retryOn 이 없으면 재시도가 아예 동작하지 않는다
• perTryTimeout 이 timeout 보다 작아 설정이 거부된다
• 전체 데드라인이 시도 시간의 합보다 짧아 재시도가 끝까지 수행되지 못한다
• attempts 는 최대 2까지만 허용된다

A → B → C 체인에서 각 단계가 재시도 2회를 갖고 있습니다. C 가 받게 되는 최대 요청 수는?

• 재시도는 곱해지지 않는다고 보고 3회
• 각 단계의 세 번 시도가 곱해진 최대 9회
• 바깥 단계만 센 최대 3회
• 두 단계의 재시도를 더한 최대 6회

outlierDetection 에 maxEjectionPercent 를 반드시 두어야 하는 이유는?

• 상한이 없으면 격리 시간이 지수적으로 늘어 끝내 복귀하지 못하기 때문
• 격리된 인스턴스는 메트릭 보고가 끊겨 관측에 공백이 생기기 때문
• 일시적 장애로 모든 인스턴스가 격리되면 전면 장애가 되기 때문
• 이 필드를 비우면 outlierDetection 전체가 검증에서 거부되기 때문

액세스 로그의 응답 플래그가 UH 였습니다. 가장 먼저 확인할 것은?

• 받는 쪽만 STRICT 이고 보내는 쪽이 평문을 쓰는 mTLS 불일치가 있는지
• DestinationRule subset 의 라벨과 실제 파드 라벨이 일치하는지
• VirtualService 의 조건이 모두 빗나가 catch-all 라우트가 없는지
• 연결 풀의 최대 커넥션 수가 작아 동시 요청이 대기 없이 잘려 나가는지

Service 의 포트 이름을 http 로 시작하게 짓는 이유는?

• 같은 Service 안에서 포트 번호가 겹치는 것을 API 서버가 이름으로 막아 주기 때문
• kubectl get svc 출력에서 포트가 이름순으로 정렬되어 읽기 편해지기 때문
• 메시가 포트 이름으로 프로토콜을 판단해 L7 라우팅 적용 여부를 정하기 때문
• 프로메테우스가 그 이름을 보고 스크레이프할 포트를 자동으로 고르기 때문