LabHub
学习 学习路径 课程

Istio 심화 — 왜 그렇게 흐르는가 · DestinationRule 트래픽 정책이 클러스터가 되기까지 · 测验

DestinationRule 번역 확인

在 LabHub 中继续学习

6道题. 完成作答后会显示正确答案和解析。

  1. DestinationRule 의 `connectionPool.http.http1MaxPendingRequests` 가 Envoy 클러스터에서 가는 자리는?

    1. outlier_detection.max_ejection_percent
    2. lb_policy 의 LEAST_REQUEST 선택 개수
    3. circuit_breakers.thresholds 의 max_pending_requests
    4. http_protocol_options 의 max_concurrent_streams
  2. consecutive5xxErrors: 2 인 클러스터에 늘 503 을 내는 엔드포인트가 하나 섞여 있다. 사용자가 보게 되는 것은?

    1. 처음부터 그 엔드포인트로 가지 않으므로 503 을 한 번도 보지 않는다
    2. 503 이 요청의 3분의 1 비율로 계속 난다
    3. Envoy 가 모든 엔드포인트를 빼서 전부 503 이 된다
    4. 그 엔드포인트로 간 요청 두 번은 503 을 받고, 그 뒤로는 빠져서 503 이 멈춘다
  3. 부모 trafficPolicy 에 http1MaxPendingRequests: 2 가 있고, 서브셋 v2 의 trafficPolicy 에는 connectionPool.tcp.maxConnections: 1 만 있다. v2 클러스터의 대기열 한도는?

    1. Istio 의 기본값(4294967295) — 서브셋의 connectionPool 이 덩어리째 덮어써 부모의 http 설정이 따라오지 않는다
    2. 2 — 서브셋이 적지 않은 필드는 부모 정책에서 필드 하나씩 그대로 물려받는다
    3. 1 — 서브셋의 maxConnections 가 대기열 한도에도 같은 값으로 적용된다
    4. 1024 — 서브셋이 정하지 않았으므로 Envoy 자체의 기본값이 쓰인다
  4. max_connections: 1, max_pending_requests: 1 인 클러스터의 느린 업스트림(3초)에 요청 다섯 개를 동시에 보냈다. 결과는?

    1. 다섯 개 모두 차례로 처리되어 200 이다 — 대기열이 알아서 늘어난다
    2. 두 개는 200, 세 개는 업스트림에 가지도 않고 503(x-envoy-overloaded)이다
    3. 하나만 200 이고 네 개는 504 타임아웃이다
    4. 다섯 개 모두 503 이다 — 한도가 1이라 동시 요청은 전부 거절된다
  5. 부하 시험에서 maxConnections: 10 으로 걸었는데 서비스가 동시 연결 100개를 받았다. 가장 그럴듯한 이유는?

    1. Istio 가 maxConnections 를 파드 수만큼 곱해 서비스 전체 한도로 바꾼다
    2. HTTP/2 를 쓰면 연결 한도가 무시된다
    3. LEAST_REQUEST 정책이 한도를 넘어도 새 연결을 허용한다
    4. 한도는 호출하는 각 사이드카의 클러스터마다 따로 세므로, 호출 파드가 열 개면 합이 열 배가 된다
  6. DestinationRule 을 고친 뒤 사이드카에 실제로 반영된 한도를 확인하는 가장 확실한 방법은?

    1. kubectl get destinationrule -o yaml 로 적용된 YAML 을 다시 본다
    2. istioctl validate 로 파일을 다시 검사한다
    3. 호출하는 파드의 Envoy 설정 덤프(proxy-config cluster, config_dump)에서 그 클러스터의 circuit_breakers 를 본다
    4. 서비스의 엔드포인트 수를 세어 한도를 역산한다