Istio シリーズです。
そういえば Ingress Gateway になかなか辿りつかないな。
OutlierDetection 設定
OutlierDetection は DestinationRule に設定するものでドキュメントもそこにあります。
一旦 VirtualService での転送先を v2 だけにします。
| |
OutlierDetection で Target を Evict するには転送先にいくつかの Pod が必要なので replica 数を増やします。
| |
次に、DestinationRule に OutlierDetection を設定します。
| |
しかし、これはどうやって確認すれば良いのだろうか? envoy の 15000/stats へアクセスしてみるのかな?後でわかります。
httpbin.org は /status/500 とか /status/503 にアクセスすれば任意の status code を返させることができます。/status/503 にアクセスしてみると curl を実行する側の Pod の istio-proxy のログには1つしか出ませんが、転送先は3つの Pod にアクセスがありました。500 や 502, 504 ではどれも転送先でも1つしかログは出ませんでしたし、response_flags は空でした。retry しても 503 の場合は response_flag が URX になっています。response_flag の意味は Envoy のドキュメントにあります。URX の意味は “The request was rejected because the upstream retry limit (HTTP) or maximum connect attempts (TCP) was reached.” “response_flags”: “UF,URX” と、カンマ区切りで複数入っていることもありました。
| |
転送先のログ
| |
Retry について
Retry の回数などは VirtualService の http.retries.attempts などで設定することができます。Outlier の話から外れちゃうけどここで retries をいじってみます。
| |
curl を実行する Pod で http://localhost:15000/config_dump を確認してみると "num_retries": 10 になりました。"retry_on": "connect-failure,refused-stream,unavailable,cancelled,resource-exhausted,retriable-status-codes" ということなので、 x-envoy-retriable-status-codes ヘッダーで指定すれば 503 以外でも retry してくれそうです。
| |
"num_retries": 10 になったことで、合計のアクセス回数が11回になりました。デフォルトは2だったということですね。
次に 502 でも retry されるかどうか x-envoy-retriable-status-codes ヘッダーを試しましたが、、期待の動作にならなりませんでした… 🤔
OutlierDetection を状態を確認しながらテスト
話を OutlierDetection に戻します。istioctl proxy-config コマンドで OUTLIER CHECK の状態が確認できることがわかりました。
$ istioctl proxy-config endpoint ubuntu-deployment-cc86cc647-vsvbh | egrep '^ENDPOINT|v2\|httpbin'
ENDPOINT STATUS OUTLIER CHECK CLUSTER
172.17.0.10:80 HEALTHY OK outbound|80|v2|httpbin-service.default.svc.cluster.local
172.17.0.11:80 HEALTHY OK outbound|80|v2|httpbin-service.default.svc.cluster.local
172.17.0.12:80 HEALTHY OK outbound|80|v2|httpbin-service.default.svc.cluster.local
172.17.0.13:80 HEALTHY OK outbound|80|v2|httpbin-service.default.svc.cluster.local
172.17.0.8:80 HEALTHY OK outbound|80|v2|httpbin-service.default.svc.cluster.local次のようにして状態を確認しながら /status/503 にアクセスをしてみます。
while : ; do
date
istioctl proxy-config endpoint ubuntu-deployment-cc86cc647-vsvbh \
| egrep '^ENDPOINT|v2\|httpbin'
sleep 3
doneSun Mar 8 17:49:37 JST 2020
ENDPOINT STATUS OUTLIER CHECK CLUSTER
172.17.0.10:80 HEALTHY OK outbound|80|v2|httpbin-service.default.svc.cluster.local
172.17.0.11:80 HEALTHY OK outbound|80|v2|httpbin-service.default.svc.cluster.local
172.17.0.12:80 HEALTHY OK outbound|80|v2|httpbin-service.default.svc.cluster.local
172.17.0.13:80 HEALTHY OK outbound|80|v2|httpbin-service.default.svc.cluster.local
172.17.0.8:80 HEALTHY OK outbound|80|v2|httpbin-service.default.svc.cluster.local
Sun Mar 8 17:49:40 JST 2020
ENDPOINT STATUS OUTLIER CHECK CLUSTER
172.17.0.10:80 HEALTHY OK outbound|80|v2|httpbin-service.default.svc.cluster.local
172.17.0.11:80 HEALTHY FAILED outbound|80|v2|httpbin-service.default.svc.cluster.local
172.17.0.12:80 HEALTHY OK outbound|80|v2|httpbin-service.default.svc.cluster.local
172.17.0.13:80 HEALTHY OK outbound|80|v2|httpbin-service.default.svc.cluster.local
172.17.0.8:80 HEALTHY OK outbound|80|v2|httpbin-service.default.svc.cluster.local
Sun Mar 8 17:49:43 JST 2020
ENDPOINT STATUS OUTLIER CHECK CLUSTER
172.17.0.10:80 HEALTHY FAILED outbound|80|v2|httpbin-service.default.svc.cluster.local
172.17.0.11:80 HEALTHY FAILED outbound|80|v2|httpbin-service.default.svc.cluster.local
172.17.0.12:80 HEALTHY FAILED outbound|80|v2|httpbin-service.default.svc.cluster.local
172.17.0.13:80 HEALTHY FAILED outbound|80|v2|httpbin-service.default.svc.cluster.local
172.17.0.8:80 HEALTHY FAILED outbound|80|v2|httpbin-service.default.svc.cluster.local全部 FAILED になった状態でもアクセスできました。一部だけ FAILED の時は OK の Endpoint にだけ送られました。
FAILED となって外されている期間は baseEjectionTime かける eject された回数時間になるようです。
Istio 導入への道シリーズ
- Istio 導入への道 (1) – インストール編
- Istio 導入への道 (2) – サービス間通信編
- Istio 導入への道 (3) – VirtualService 編
- Istio 導入への道 (4) – Fault Injection 編
- Istio 導入への道 (5) – OutlierDetection と Retry 編
- Istio 導入への道 (6) – Ingress Gatway 編
- Istio 導入への道 (7) – 外部へのアクセス / ServiceEntry 編
- Istio 導入への道 (8) – 外部へのアクセスでも Fault Injection 編
- Istio 導入への道 (9) – gRPC でも Fault Injection 編
- Istio 導入への道 (10) – 図解
- Istio 導入への道 (11) – Ingress Gateway で TLS Termination 編


