Cloud Native Developers JP Istio入門 @hhiroshell 1

Cloud Native Developers JP お品書き • Istioの概要 • Istioのユースケースの具体例 • Istioの使い方 2

Cloud Native Developers JP Istioの概要 3

Cloud Native Developers JP なぜサービスメッシュが必要なのか • 分散システム[^1]には、分散されたワークロード間のネットワーク において、様々な課題がある – トラフィックのロードバランシング – セキュリティ（暗号化、サービス間の認証） – ポリシーの適用 – モニタリングとレポート – … • サービスメッシュは、これらの課題に対する実装を提供するミドル ウェア • アプリケーションから見て透過的に、ネットワークレベルの課題を 適用する 4 [^1] 例えばマイクロサービス・アーキテクチャを採用するシステム

Cloud Native Developers JP Istioとは • サービス・メッシュの実装のひとつ • Google, IBM, Lyftによって開発され、2017年にオープンソース化さ れた • Istioが利用するEnvoy proxyはCloud Native Computing Foundation(CNCF)がホストするプロジェクト 5

Cloud Native Developers JP Istioのアーキテクチャ概要 • サイドカーコンテナとしてPodに Envoyを注入 • Envoyがネットワークトラフィック を仲介して、ネットワーク周りの 様々な制御を行う • アプリケーションの変更無しで導 入可能 6 policy check /telemetry Pod Envoy アプリ Pod Envoy アプリ Control Plane Istio- Auth Mixer Pilot

Cloud Native Developers JP Istioのアーキテクチャ概要 • Envoy – トラフィックを仲介をおこなう実態 • Mixer – Envoyに適用するポリシーを提供 – 各種メトリックの収集 • Pilot – Envoyにサービスディスカバリの機能や各 種ルーティングルールを提供 • Istio-Auth – サービス同士認証、ユーザー-サービス間 の認証サービスのための各種情報（TLS証 明書など）を提供 7 policy check /telemetry Pod Envoy アプリ Pod Envoy アプリ Control Plane Istio- Auth Mixer Pilot

Cloud Native Developers JP ユースケースの具体例 8

Cloud Native Developers JP サービス境界の問題の例 – 障害の連鎖 1. サービスAが依存するサービスBで 障害発生 9 システムの広範囲が機能しなくなるケースも 2. サービスAでサービスBの応答待ち のリクエストが累積 3. 応答待ちリクエストがAのリソース を専有し、Aも停止 4. Bへのアクセス集中が続き、 Bが復旧困難に。Bに依存する他 サービスもAと同様に次々停止 A B A B A B A B C D

Cloud Native Developers JP 対策 - サーキットブレーカー • サービス呼び出しに対する応答が一定の条件を満たした場合に、障害発生 と判断し、以降の呼び出しを遮断する機構 • 呼び出し元のサービスに早期にエラーが返されるので、呼び出し元でのリ ソースの専有を回避。適切なエラーにフォールバックできる • リクエストが遮断されている間に障害を起こしたサービスが回復 10 障害が起きたサービスを負荷から開放して素早く復旧 サービス サービス サーキット ブレーカー サービス サービス サーキット ブレーカー error ! (1) 一定数のエラーを観測したら error ! (2) リクエストを遮断 復旧！

Cloud Native Developers JP 11 これらすべてに自力で対処するのは大変 サービス境界の問題と対処法 – たくさんある内の一部 対処したい障害 対処法の名前 対処法の実装 サービス間通信の一時的な障害 に対処する リトライ 他サービスの呼び出しに失敗した際、呼び出し 元から見て透過的に再試行を行う。 障害が起きているサービスに対 してリクエストを送り続け、無 駄にリソース消費する サーキットブレーカー 障害が起きているサービスへのリクエストに対 し早期にエラーレスポンスを返し、リソースの 無駄な消費を防止する 障害がサービス機能全体に影響 することを防止する バルクヘッド アプリケーションの構成要素をプールに分離し、 一つが失敗しても他が引き続き機能できるよう にする。 複数サービスをまたがるデータ 更新において、結果整合性を保 証する 補正トランザクション 各サービスのデータ更新において、更新前の状 態に復元するための手がかりとなる情報を残し ておく。 更新失敗時のロールバックにおいて、その情報 を使って順次状態を元に戻す。

Cloud Native Developers JP 対処したい障害 対処法の名前 対処法の実装 サービス間通信の一時的な障害 に対処する リトライ 他サービスの呼び出しに失敗した際、呼び出し 元から見て透過的に再試行を行う。 障害が起きているサービスに対 してリクエストを送り続け、無 駄にリソース消費する サーキットブレーカー 障害が起きているサービスへのリクエストに対 し早期にエラーレスポンスを返し、リソースの 無駄な消費を防止する 障害がサービス機能全体に影響 することを防止する バルクヘッド アプリケーションの構成要素をプールに分離し、 一つが失敗しても他が引き続き機能できるよう にする。 複数サービスをまたがるデータ 更新において、結果整合性を保 証する 補正トランザクション 各サービスのデータ更新において、更新前の状 態に復元するための手がかりとなる情報を残し ておく。 更新失敗時のロールバックにおいて、その情報 を使って順次状態を元に戻す。 12 サービス境界の問題の多くにIstioで対処できる サービスメッシュ”Istio”で対処できる問題

Cloud Native Developers JP IstioとCI/CDツールによるカナリーデプロイメント • Istioにより、リクエストの配分 率をきめ細かに設定可能 • CI/CDツールからカナリー デプロイメントで必要なタスク を自動実行 – リクエスト配分率の適用 (istioctl) – カナリーバージョンのデプロイ (kubectl) 13 カナリーデプロイメントによって安定／安全なリリースを実現 V1 V1 アプリ Kubernetesクラスター カナリーをデプロイ V2 Canary リクエスト配分率を設定 CI/CD ツール 1% 99%

Cloud Native Developers JP Istioの基本的な使い方 14

Cloud Native Developers JP Kubernetesへのインストール • Istioの利用に必要なもの一揃いがアーカイブとして提供されている （https://github.com/istio/istio/releases） – インストールで重要なものは以下 • Istioのコマンドラインツール「istioctl」 • Kubernetesに必要なコンポーネントをデプロイするためのmanifestファイル「istio.yaml」 – 基本的なものはistio.yamlだけで入る • インストール – istioctlにPathを通す – kubectl create -f install/kubernetes/istio.yaml 15

Cloud Native Developers JP 入門時の注意 • Istioは結構リソースを食う – 公式のサンプルアプリ bookinfo はシングルノードクラスターでも4G Memory以上必要 • KubernetesのRole Based Access Control (RBAC)が必須 – Istioのコンポーネントはクラスター内で様々な制御を行っている – これに必要な権限をアサインするためにRBACを使っている • アンインストール時は必ずマニュアルを見るべし – https://istio.io/docs/setup/kubernetes/quick-start.html#uninstalling – ネームスペース”istio-system”に必要なものがきれいに収まっているように見 えるが、これを消しただけでは不十分 16

Cloud Native Developers JP Istioを動かすまで • ここまでで、Control Planeが入っ た状態 • EnvoyをPodに注入する必要がある 17 policy check /telemetry Pod Envoy アプリ Pod Envoy アプリ Control Plane Istio- Auth Mixer Pilot

Cloud Native Developers JP Envoyの注入 • Manual sidecar injection – istioctlを使って、KubernetesのmanifestファイルにEnvoyの記述を追加する – 最もシンプルな例 $ istioctl kube-inject -f ./manifests/app.yaml -o ./manifests/app-istio.yaml $ kubectl create -f ./manifests/app-istio.yaml • Automatic sidecar injection – Kubernetes 1.9+ で利用可能 – ValidatingAdmissionWebhookの機能を利用して、Kubernetesに対するオペ レーションをフックしてEnvoyの注入を行っている 18

Cloud Native Developers JP Istioによるトラフィックの制御 • 適用したいトラフィックルー ルをmanifestに記述 • manifestを入力としてistioctl を実行 istioctl create -f ./rollout.yaml • 右の例では、reviewsサービスに対 してルーティングルールを適用 • ルーティング先のラベルを使ってト ラフィックを流す割合を指定 19 apiVersion: config.istio.io/v1alpha2 kind: RouteRule metadata: name: reviews-v2-rollout spec: destination: name: reviews route: - labels: version: v2 weight: 25 - labels: version: v1 weight: 75

Cloud Native Developers JP 公式チュートリアルが充実しています（英語ですが） • ラフィックの管理 – https://istio.io/docs/tasks/traffic-management/ • ポリシーの適用 – https://istio.io/docs/tasks/policy-enforcement/ • メトリック、ログ、トレース情報の収集 – https://istio.io/docs/tasks/telemetry/ • セキュリティ – https://istio.io/docs/tasks/security/ 20

Cloud Native Developers JP Fin. 21