Istioとはなにか

以前、サービスメッシュがなぜ必要なのかをこちらの記事で紹介した。

architecting.hateblo.jp

今回はサービスメッシュの実装の一つであるIstioについて取り上げる。

サービスメッシュは執筆時点ではまだ新しい技術であり変化が激しい。実装間の差も大きく、Istioの方式が標準というわけでない。あくまでサービスメッシュの一例としてIstioを紹介する。

概要

YouTubeを見る限り「イスティーオー」と発音するようだ。

Lyft、IBM、Googleが開発した技術である。

データプレーンを担うEnvoyとコントロールプレーンを担うIstiodで構成される。厳密にはデータプレーンはEnvoy以外の製品でも問題ない。しかしEnvoy自体の評価が高いため、Envoyと組み合わせることが一般的である。

---

機能

以下の機能を提供する。

1. Traffic management

• トラフィックフローやAPI呼び出し制御
• サーキットブレーカー、タイムアウトの設定
• A / Bテスト、カナリーリリース

2. Security

• 通信トラフィックの暗号化、
• 認証・認可といった機能

3. Observability

• テレメトリの収集 分散トレース
• アクセスログ

---

Envoy

• 各サービスの隣に配置されるコンテナ形式のプロキシ。
• このような形を「サイドーカー」と呼ぶこともある。
• サービス間の通信を受け取り以下のような機能を提供する。
  • サービスディスカバリ
  • 負荷分散
  • TLS終端
  • HTTP/2 と gRPC のプロキシ
  • サーキットブレーカー
  • ヘルスチェック
  • トラフィックの分割（A/Bテスト）
  • Fault Injection
  • メトリクスの取得

---

Istiod

Istiodは以下の４つのコンポーネントで構成されている。

1. Pilot

• Envoyの制御を行う

2. Galley

• Istioを管理するためのAPIを提供する

3. Citadel

• Certificate Authorityとして鍵管理、証明書の発行を行う。

4. Mixer

• Envoyから送らてくるTelemetryデータやPolicy Check要求を処理する。

---

設定

• Istioの設定はk8sのYAML設定ファイルに記述し、kubectl apply -fで適用する。
• k8sの一部として利用でき、学習コストも設定管理コストも抑えられる。
• 以下の３つの要素（kind）を設定する
  • Gateway（IngressのLB）
  • Virtual Services（リクエストの最初の送り先）
  • Destination Rules（細かいポリシー）

---

サービスのコードへの影響

• IstioはサービスにはTransparentであり、システムでIstioが有効でも無効でもコードに影響はない
• 特殊なコーディングは不要でサービスは一般的なWebAPIのサービスとして設計、開発すればよい
• ただしEnvoyが提供する機能はコーディングしなくて済む