はじめに
Istioの全体像がわかるよう、数回に分けて入門してみます。今回はコンセプトやざっくりとしたアーキテクチャの話、次回からはサンプルのbookinfoアプリケーションを元に各機能を深掘りしていく予定です。
Istio入門シリーズ
- [その1 -Istioとは?-][istio1]
- [その2 -Istio構築とサンプルアプリのデプロイ-][istio2]
- [その3 -Blue/Greenデプロイメントによるカナリアリリース-][istio3]
- [その4 -基礎から振り返る-][istio4]
[istio4]: https://qiita.com/Ladicle/items/4ba57078128d6affadd5
[istio1]: https://qiita.com/Ladicle/items/979d59ef0303425752c8
[istio2]: https://qiita.com/Ladicle/items/e949b0f68ac18b7a95d8
[istio3]: https://qiita.com/Ladicle/items/5a68ff85e15e86781453
Istioとは?
Istio1とはマイクロサービスをセキュアにマネージメントするためのOSSで、Kubernetes同様CNCFの一員です。
マイクロサービス化が進むにつれてA/Bテストやカナリーリリースに20%のアクセスのだけ割り当てたいなどの要望により、サービスメッシュ2はより大きく、より複雑になりました。Istioは、このような「複雑なサービスメッシュの管理が追いつかない」という課題を解決するため開発されています。主な機能としては、サービス間の認証やモニタリング、L7での柔軟なロードバランシングが提供されています。現在はKubernetesにのみ対応していますが、将来的には他のプラットフォームにも対応するようです。(現在の0.2系でも鍵管理などの一部機能はベアメタルに対応しています)
また、Istioのコンポーネントは、サービスのサイドカーとしてPodにデプロイされるためサービスコードを修正する必要がありません。これによって、アプリケーション開発者に負担をかけることなく、運用者がシステムを柔軟にマネージメントできるという利点があります。
システム構成
Istioのサービスメッシュは上記の図のようにデータプレーンとコントロールプレーンの2つに分けることができます。
データプレーンはプロキシサーバによるマイクロサービス間の通信の管理、コントロールプレーンではポリシーやプロキシ設定の管理を行なっています。
Istioを構成するコンポーネント
- Envoy: サービスメッシュのイン/アウトバウントの全てのトラフィックを管理するプロキシサーバで、KubernetesではPodのサイドカーとしてデプロイします。ちなみに、Envoy3は素のままではなく、Istio用に拡張されたものを使用しています。
- Mixer: Envoyを通して各サービスのデータを収集し、その情報を元にアクセスコントロールを行うコンポーネントです。プラグインモデルを取っており、柔軟なカスタマイズが可能になっています。
- Pilot: サービスディスカバリやトラフィック管理などを担当しています。Kubernetesの場合、サービスディスカバリはWatch APIによるEnvoyのステータス変更を検知することで実現しています。
- Istio-Auth: KubernetesのService Accountを利用したユーザ認証や、サービス間のTLS相互認証を行います。この認証を利用することで、ポリシーベースでサービスメッシュを管理することができます。また、将来的にはFGAC4に対応するようです。
参考リンク集
- Istio: オフィシャルウェブサイト
- Github - Istio org: GithubのIstioページ
- Istio - A modern service mesh: Gluecon 2017の講演資料(PDF)
おわりに
今回はIstioのコンセプトとアーキテクチャの概要をご紹介しました。最後に登場したIstio-AuthはSPIFFEを利用しているのですが、こちらの詳細については@hiyosiさんが解説されます。それでは、ひき続きZ Labアドベントカレンダーをお楽しみください。