Istio 심화 — 왜 그렇게 흐르는가 · DestinationRule 트래픽 정책이 클러스터가 되기까지 · 测验
DestinationRule 번역 확인
6道题. 完成作答后会显示正确答案和解析。
DestinationRule 의 `connectionPool.http.http1MaxPendingRequests` 가 Envoy 클러스터에서 가는 자리는?
- outlier_detection.max_ejection_percent
- lb_policy 의 LEAST_REQUEST 선택 개수
- circuit_breakers.thresholds 의 max_pending_requests
- http_protocol_options 의 max_concurrent_streams
consecutive5xxErrors: 2 인 클러스터에 늘 503 을 내는 엔드포인트가 하나 섞여 있다. 사용자가 보게 되는 것은?
- 처음부터 그 엔드포인트로 가지 않으므로 503 을 한 번도 보지 않는다
- 503 이 요청의 3분의 1 비율로 계속 난다
- Envoy 가 모든 엔드포인트를 빼서 전부 503 이 된다
- 그 엔드포인트로 간 요청 두 번은 503 을 받고, 그 뒤로는 빠져서 503 이 멈춘다
부모 trafficPolicy 에 http1MaxPendingRequests: 2 가 있고, 서브셋 v2 의 trafficPolicy 에는 connectionPool.tcp.maxConnections: 1 만 있다. v2 클러스터의 대기열 한도는?
- Istio 의 기본값(4294967295) — 서브셋의 connectionPool 이 덩어리째 덮어써 부모의 http 설정이 따라오지 않는다
- 2 — 서브셋이 적지 않은 필드는 부모 정책에서 필드 하나씩 그대로 물려받는다
- 1 — 서브셋의 maxConnections 가 대기열 한도에도 같은 값으로 적용된다
- 1024 — 서브셋이 정하지 않았으므로 Envoy 자체의 기본값이 쓰인다
max_connections: 1, max_pending_requests: 1 인 클러스터의 느린 업스트림(3초)에 요청 다섯 개를 동시에 보냈다. 결과는?
- 다섯 개 모두 차례로 처리되어 200 이다 — 대기열이 알아서 늘어난다
- 두 개는 200, 세 개는 업스트림에 가지도 않고 503(x-envoy-overloaded)이다
- 하나만 200 이고 네 개는 504 타임아웃이다
- 다섯 개 모두 503 이다 — 한도가 1이라 동시 요청은 전부 거절된다
부하 시험에서 maxConnections: 10 으로 걸었는데 서비스가 동시 연결 100개를 받았다. 가장 그럴듯한 이유는?
- Istio 가 maxConnections 를 파드 수만큼 곱해 서비스 전체 한도로 바꾼다
- HTTP/2 를 쓰면 연결 한도가 무시된다
- LEAST_REQUEST 정책이 한도를 넘어도 새 연결을 허용한다
- 한도는 호출하는 각 사이드카의 클러스터마다 따로 세므로, 호출 파드가 열 개면 합이 열 배가 된다
DestinationRule 을 고친 뒤 사이드카에 실제로 반영된 한도를 확인하는 가장 확실한 방법은?
- kubectl get destinationrule -o yaml 로 적용된 YAML 을 다시 본다
- istioctl validate 로 파일을 다시 검사한다
- 호출하는 파드의 Envoy 설정 덤프(proxy-config cluster, config_dump)에서 그 클러스터의 circuit_breakers 를 본다
- 서비스의 엔드포인트 수를 세어 한도를 역산한다