Istio入門

社内勉強会で使用した資料になります。Istio入門に少しでもお役に立てれば幸いです。

Transcript

1. 入門 2022/06 李 俊起
2. 本日のゴール Who • Istio導入を検討している(すでに導入している)システムの担当者 • Istioという単語を聞いたことはあるけど何をするものかよく分からない方 What • Istioの機能(何を解決してくれるか)を理解した上で、 担当システムへのIstio導入について適切に判断できるようになる • Istioについて何となく分かった気になれる！（李含む）
3. 本日の構成 • 座学 • Service Meshとは • Service Meshが登場した(必要となった)背景 • Istioの機能 • Istioの構成 • デモ • Traffic Management • Observerbility • まとめ
4. Service Meshとは • 各アプリ(Service)の隣にProxyを配置し、アプリ(Service)同士の すべての通信を、プロキシーを経由するよう(Mesh)にした状態
5. Service Meshが登場した背景 • マイクロサービスアーキテクチャの台頭 A 機能 B 機能 D 機能 モノリス C 機能 マイクロサービス A 機能 B 機能 D 機能 C 機能 API API API API
6. マイクロサービスに潜む課題 マイクロサービス A 機能 B 機能 D 機能 C 機能 API API API API • ネットワークは不安定という前提 →リトライ、タイムアウト • 過剰なAPI Callから自身を守る必要がある →流量制限 • カスケード障害の恐れ →サーキットブレーカー • 障害/遅延発生時、原因箇所の特定が困難 →俯瞰的な監視 • サービス同士でネットワーク通信が発生 →通信の暗号化 Istioですべて解決!
7. Istioの機能 ✓ タイムアウト ✓ リトライ ✓ フォールトインジェクション ✓ カナリアリリース ✓ B/Gデプロイメント ✓ 流量制限 ✓ サーキットブレーカー ✓ Kiali ✓ テレメトリーデータの生成 (OSSツールとの高い親和性) ✓ mTLS
8. Istioの構成 • Control Plane ➢ サービスメッシュ全体を司る司令塔（istiod） ✓ トラフィックの設定をProxyに反映 ✓ 証明書管理/配布 ✓ Proxyからテレメトリーデータを収集 • Data Plane ➢ Sidecar Proxy（Envoy） ✓ 実際トラフィックを制御 ✓ テレメトリーデータを生成
9. v1.5からIstioの構成がシンプルに 1.5からistiodという １つのPodになった
10. Demo
11. デモ用アプリの構成 Client Calculate DB Image ・以下をまとめてHTMLをレンダリング - Imageからのペット写真 - DBからのペット情報 - Calculateからの計算結果 ・計算結果を返すAPI ・DB/Image API Gateway ・ペットの情報を返すAPI ・ペットの写真を返すAPI
12. Istioインストール/アプリデプロイ • istioctlインストール ➢ curl -sL https://istio.io/downloadIstioctl | sh - • istioインストール ➢ istioctl install --set profile=default -y • istioインストール確認 ➢ kubectl get po,svc –n istio-system
13. Sidecar Proxy(Envoy)がない！？ • Sidecar Proxyを挿入したいnamespace(ns)に以下のラベルを付与 ➢ kubectl label ns <対象namespace> istio-injection=enabled • アプリを削除後、再デプロイ • PodのREADY列の値が「1/1」→「2/2」に変わったことを確認 • IstioのSidecar Injectorが「istio-injection=enabled」ラベルが 付いているnsにPodが払い出される時、PodにEnvoyコンテナを挿入
14. インストール(デプロイ)直後の状態 ELB EKS Cluster Ingress Gateway Client Calculate DB Image Client Calculate DB Image Ingress Gatewayと ClientのServiceを 関連付ける必要がある Ingress Gatewayの受付設定が必要 エッジProxy メッシュProxy
15. IngressGatewayとServiceの紐づけ VirtualService Ingress Gateway Client Gateway Ingress Gatewayが受け付ける Port番号とProtocolを指定 このルールを適用する Ingress Gatewayを指定 webサイトのドメインを指定 Gatewayのhostsに合せる 紐づけるIngress Gatewayを指定 ※Gatewayの[metadata.name]に合せる 設定反映 トラフィックを流すServiceとポート番号を指定 Client ELB 8 0 8 0
16. ①Traffic Management
17. タイムアウト、リトライを試すための設定 Client Calculate Clientから計算を求められた時に 20秒間Sleepするようにアプリを修正 Calculate向け通信に タイムアウト時間を設定して、 タイムアウトさせる １ ２ Calculate向け通信にタイムアウト時間を 設定して、タイムアウトが発生した際、 リトライする ３ タイムアウト リトライ
18. タイムアウト、リトライ • タイムアウト • リトライ Calculate向けの通信に 2秒のタイムアウトを設定 「retryOn」に指定した事象が発生した時に 「attempts」の数の分リトライする。 「perTryTimeout」は最初のリクエスト &リト ライ時のタイムアウト時間
19. フォールトインジェクション Client Calculate Calculate向け通信で503エラー発生 「httpStatus」のエラーを 「percentage.value」の確率で発生させる
20. カナリアリリース、 B/Gデプロイメント Client Calculate dog-with-multi Calculate cat-with-plus 90% 10% Calculate向け通信において 「version: cat-plus」ラベルのPodは 「cat-with-plus」というsubsetとして定義 Calculate向け通信において 「version: dog-multi」ラベルのPodは 「dog-with-multi」というsubsetとして定義 Calculate向け通信の90%を 「cat-with-plus」subsetにルーティング Calculate向け通信の10%を 「dog-with-multi」subsetにルーティング
21. Darkリリース (Dark Launching) • Darkリリースとは ユーザに影響を与えず(もしくは一部のユーザのみに)新機能をリリースして リスクなしに(もしくは少ないリスクで)新機能を試すリリース方式 HTTPヘッダーに「version: dog」が ある場合はdog-with-multiに、それ以外場合は cat-with-plusにルーティングする Client Calculate cat-with-plus Calculate dog-with-multi version: dog ヘッダー有 version: dog ヘッダー無
22. 流量制限（Rate Limit） • 2種類のRate Limitが存在 1. Global Rate Limit ➢ クラスター全体に適用する流量制限 2. Local Rate Limit ➢ 特定のインスタンス(アプリ)に適用する流量制限
23. Global Rate Limit • rate limit serviceという別コンポーネントのデプロイが必要 • リクエストのたびにrate limit serviceに加算され、 クォータを超えたら“429 Too Many Requests”を返す Ingress Gateway ratelimit 429 クォータ超過時 ※今回は1分以内に5回以上 リクエストが発生したら 429を返すように設定 rate limit service
24. Local Rate Limit • rate limit serviceなど別コンポーネント不要 • tokenのbucketがあり、リクエストのたびにtokenが消費され、 tokenを使い切ったら“429 Too Many Requests”を返す • tokenは一定時間後補充される
25. サーキットブレーカー 10s以内にErrorが 3回以上発生したら 30s間対象Podを切り離す Client Calculate dog-with-multi Calculate cat-with-plus 5秒間Sleep Calculate向け通信に1秒の タイムアウト時間を設定して、 cat-with-plus向け通信を タイムアウトさせる。 タイムアウトが3回以上 発生したらcat-with-plusへの ルーティングを取りやめる
26. ②Observability
27. Kiali • Istio専用の観測ツール • Service Map等、クラスター全体の状態が確認できる • サービス(アプリ)ごとのメトリクス/ログも確認可能 • Istioの設定確認/変更もできる
28. メトリクス • Prometheus形式でメトリクスを生成（Envoy） • Istio自身に関するメトリクス • トラフィック関連メトリクス • GrafanaでIstio専用ダッシュボードが用意されている ※ダッシュボードをImportするだけ
29. 分散トレーシング • Envoyがトレースデータを生成 • Jaeger等、バックエンド側を用意するだけでOK • が、Istioの分散トレーシングには１つ注意点が・・・。
30. トレースがつながってない理由 • Envoyは自動でContextを生成/伝搬 • アプリはトレースの存在について知らない（伝搬しない） • ヘッダーにあるContextを伝搬するようアプリ側の実装が必要 Client Calculate Ingress Gateway ・x-b3-traceid ・x-b3-spanid ・x-b3-traceid ・x-b3-spanid ・x-b3-traceid ・x-b3-spanid ・x-b3-traceid ・x-b3-spanid Context生成 ・x-b3-traceid ・x-b3-spanid 新Context生成 ・x-b3-traceid ・x-b3-spanid ・x-b3-traceid ・x-b3-spanid 新Context生成
31. ③Security
32. ｍTLS • クラスター内のIn/Outすべての通信を暗号化 • デフォルトで適用 Client Calculate DB Image Ingress Gateway EKS Cluster
33. まとめ
34. Service Meshは本当に必要なのか • Istio利用にはそれなりの稼働が必要。(定期的なバージョンアップなど) • システムにService Meshのどの機能が必要で、代替手段はないか確認 • 必要な機能によってはマネージドサービス(App Mesh)の利用を検討 ※YouTube https://www.youtube.com/watch?v=ZwfdLAClzsc ※資料 https://speakerdeck.com/toricls/service-meshes-do-we-really-need-them-what- problems-do-they-solve
35. ✓ タイムアウト ✓ リトライ → 共通ライブラリ ✓ カナリアリリース ✓ フォールトインジェクション → 利用シーンが少ない ✓ B/Gデプロイメント → Argo Rollouts等 ✓ 流量制限 → OWL、OWX ✓ サーキットブレーカー → 閾値設定の難しさ ✓ Kiali ✓ テレメトリーデータ → Opentelemetry、X-Ray Datadog、Prometheus等 ✓ mTLS → 閉域網内で完結 する場合がほとんど Service Meshは本当に必要なのか
36. Istio VS AWS App Mesh 機能 / ツール Istio AWS App Mesh Proxy Envoy Envoy Operations Cost High (自前構築/運用) Low (マネージドサービス) (追加料金なし) Retry / Timeout 〇 〇 Weighted routing 〇 〇 Rate Limit 〇 X (※1) Curcuit Breaker 〇 〇 mTLS 〇 〇 Observability 〇 〇 (※2) ※1 一応ロードマップにはRate Limitの機能追加が載っている ※2 分散トレーシング利用のためには有効化する必要がある
37. 資材公開しています • 本日使用した資材はすべてgitに上げています！ ぜひ付録のハンズオン手順をもとに実際手を動かして試してみて下さい！ • 実行環境 • EKS v1.21
38. ※付録 ハンズオン手順
39. Istioインストール • istioctlインストール ➢ curl -sL https://istio.io/downloadIstioctl | sh - • istioインストール ➢ istioctl install --set profile=default -y • istioインストール確認 ➢ kubectl get po,svc –n istio-system • default namespaceに以下のラベルを付与 ➢ kubectl label ns default istio-injection=enabled
40. デモ用アプリ/Gatewayデプロイ • デモ用アプリのデプロイ ➢ git clone https://github.com/nutslove/python.git ➢ cd python/FastAPI ➢ kubectl apply -f 00_Application/ • Gatewayデプロイ ➢ kubectl apply –f 01_IngressGateway/ • ブラウザから下記コマンドで出力されるLoadBalancerの EXTERNAL-IPにアクセスし、デモ用アプリが表示されることを確認 ➢ kubectl get svc –n istio-system ※ELBのSGから80ポートを、ワーカーノードのSGから30000～32767を許可しておくこと
41. タイムアウト • Timeout用アプリのデプロイし、新しいcalculate-v1のPodが動いていることを確認 ➢ kubectl apply -f 02_Timeout/calculate_v1_sleep.yml • ブラウザから画面下部の数字１と数字２に適当に数字を入れて 「足し算」を押下し、しばらく(20秒間)結果が返ってこないことを確認 • IstioのＴｉｍｅｏｕｔの設定を適用する ➢ kubectl apply -f 02_Timeout/Istio_Timeout.yml • 再度ブラウザから数字１と数字２に適当に数字を入れて 「足し算」を押下し、2秒後「Timeout Error」が返ってくることを確認 • IstioのＴｉｍｅｏｕｔの設定を削除する ➢ kubectl delete -f 02_Timeout/Istio_Timeout.yml
42. リトライ • IstioのRetryの設定を適用する ➢ kubectl apply -f 03_Retry/ • ブラウザから数字１と数字２に適当に数字を入れて 「足し算」を押下し、8秒後「Timeout Error」が返ってくることを確認 • IstioのRetryの設定を削除する ➢ kubectl delete -f 03_Retry/ ➢ kubectl apply -f 00_Application/
43. フォールトインジェクション • IstioのFault Injectionの設定を適用する ➢ kubectl apply -f 04_Fault_Injection/ • ブラウザからアクセスし、「503 Service Unavailable」が表示されることを確認 • IstioのFault Injectionの設定を削除する ➢ kubectl delete -f 04_Fault_Injection/
44. カナリアリリース • v2のcalculateをデプロイ ➢ kubectl apply -f 05_CanaryRelease_BG_Deployment/calculate_v2/ • ブラウザから何回かアクセスし、犬/猫が交互に表示されることを確認 • IstioのWeighted routingの設定を適用する ➢ kubectl apply -f 05_CanaryRelease_BG_Deployment/ • ブラウザから何回かアクセスし主に猫が、たまに犬が表示されることを確認
45. B/Gデプロイメント • viでdogのweightを100、catのweightを0にして再適用する ➢ vi 05_CanaryRelease_BG_Deployment/Istio_Canary_Release.yml ➢ kubectl apply –f 05_CanaryRelease_BG_Deployment/ • ブラウザからアクセスし、犬だけが表示されることを確認 • IstioのCanary Releaseの設定を削除する ➢ kubectl delete -f 05_CanaryRelease_BG_Deployment/
46. Darkリリース • ブラウザ(Chrome/Edge)の拡張機能「Mod Header」をインストールする • IstioのDark Releaseの設定を適用する ➢ kubectl apply -f 06_Dark_Release/ • ブラウザからアクセスし、猫だけが表示されることを確認 • Mod HeaderのRequest headersから「version: dog」を設定した後、 ブラウザからアクセスし、犬だけが表示されることを確認 • IstioのDark Releaseの設定を削除する ➢ kubectl delete -f 05_CanaryRelease_BG_Deployment/calculate_v2/ ➢ kubectl delete -f 06_Dark_Release/
47. 流量制限(Global Rate Limit) • IstioのGlobal Rate Limitの設定を適用する ➢ kubectl apply -f 07_RateLimits/Istio_Global_RateLimiting.yml • ブラウザから6回目のアクセスで429エラーが表示されることを確認 • IstioのGlobal Rate Limitの設定を削除する ➢ kubectl delete -f 07_RateLimits/Istio_Global_RateLimiting.yml
48. 流量制限(Local Rate Limit) • IstioのLocal Rate Limitの設定を適用する ➢ kubectl apply -f 07_RateLimits/Istio_Local_RateLimiting.yml • ブラウザから数字１と数字２に適当に数字を6回入れて、 6回目で「Too Many Requests」が返ってくることを確認 ※初回は6回目以上クリックが必要だったり、 60s経過前に制限が解除されたりすることがある • IstioのLocal Rate Limitの設定を削除する ➢ kubectl delete -f 07_RateLimits/Istio_Local_RateLimiting.yml
49. サーキットブレーカー • IstioのCircuit Breakerの設定をデプロイ ➢ kubectl apply -f 08_CircuitBreakers/ • 以下curlで一定数の“Timeout Error”が発生した後、 “犬と掛け算の部屋”だけが表示されることを確認 ➢ while true; do curl -s http://<LoadBalancerのEXTERNAL-IP>/ ¥ | grep '<h1>' && sleep 0.5 ;done • IstioのCircuit Breakerの設定を削除する ➢ kubectl delete -f 08_CircuitBreakers/ ➢ kubectl apply -f 00_Application/
50. Observability • 各種Observabilityツールをデプロイ ➢ kubectl apply -f 09_Observability/ • トレースのサンプリングの数値を修正 ➢ kubectl -n istio-system edit deploy istiod ➢ 「PILOT_TRACE_SAMPLING」の値を100に修正してから「:wq」で保存 • Kiali → ブラウザより「<ワーカーノードのPublic IP>:32000」にアクセス • Grafana →ブラウザより「<ワーカーノードのPublic IP>:32001」にアクセス • Jaeger → ブラウザより「<ワーカーノードのPublic IP>:32002」にアクセス
51. ヘッダーの伝搬 • ヘッダー伝搬対応バージョンをデプロイ ➢ kubectl apply -f 10_Header_Propagation/ • JaegerにてトレースがIngress GatewayからDB/Imageまで つながっていることを確認