DestinationRule Translation Check

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 를 본다
• 서비스의 엔드포인트 수를 세어 한도를 역산한다