Istioとは？

Istioは、マイクロサービス向けの統合フレームワークであり、アプリケーションコードに変更を加えることなく、可観測性、セキュリティ、トラフィック管理のための統一されたレイヤーを提供します。

サービスメッシュプラットフォームとして、Istioはネットワーク上でのサービス間通信パターンをカバーする基盤レイヤーとして機能します。Istioはプラットフォームに依存しませんが、Kubernetesとの連携を最適に設計されています。

本記事では、まずIstioの概要と主要な機能についてご説明いたします。次に、Istioの主要コンポーネントとその役割について詳述します。実環境で得られた知見に基づき、Istioデプロイメントのセキュリティ確保に関するベストプラクティスを順を追ってご紹介いたします。最後に、アドオンや統合機能を活用したIstioの拡張方法について考察いたします。

それでは、始めましょう。

Istioのしくみ

簡単に申し上げますと、Istioはオペレーターが複数のサービスやアプリケーションにまたがる機能を追加することを可能にするソフトウェアです。これらの機能には、可観測性、セキュリティ、アクセス制御、トラフィック管理、コンプライアンス、サービスディスカバリーなどが含まれます。

クラウド環境で数百のアプリケーションサービスが稼働していると想像してください。変更のたびにコードを修正することなく、これらのサービス同士が相互に認識し合い、認証やセキュリティ制御、リトライ機構、トレーシングを追加するにはどうすればよいでしょうか？その答えがIstioのようなサービスメッシュソフトウェアです。これはアプリケーション配信に関連する横断的な側面をすべて抽象化します。

Istioが特に重要なのは、Kubernetes（K8s）に対する第一級のサポートを備えている点です。サービスメッシュはホスティングプラットフォームに依存しませんが、K8sエコシステムと統合できる場合（多くの企業がインフラをそこに投資しているため）、その価値はさらに高まります。新しい技術の導入においては、その仕組みとビジネス目標への適合性を理解することが極めて重要です。Istioの主要機能について詳しく学ぶことで、本番環境で問題が発生することなく設定を行うことが可能となります。

Istioの主な機能

Istioは、個々のアプリケーションと並行して動作するサービス間メッシュを提供します。Istioを初めてインストールおよび設定する際には、使用するクラスターの数、クラスターの規模、各サービスメッシュが運用するネットワークの数など、様々な選択肢を検討する必要があります。このシステムが提供する主な機能を理解することで、ご要件を具体的な結果に結びつけることが可能となります。

Istioが提供する主な機能は以下の通りです：

以下の手順および設定は、Kubernetes 1.25環境においてKindを使用し、istioctlツール経由でデプロイされたIstio 1.16.1でテスト済みです。

可観測性

可観測性とは、システムの出力情報を分析することで、その内部状態に関する情報を提供するものです。アプリケーションと並行して動作する各サイドカーサービスから内部ログ、トレース、テレメトリイベントを収集し、それらのデータを関連付けてダッシュボード上に可視化します。

Istioは、アプリケーションと並行して動作するプロセスであるEnvoyサイドカープロキシを使用してテレメトリイベントを送信します。サイドカーとは、アプリケーションのコードを変更することなく、アプリケーションの傍らに配置され、サービス間通信に関連する機能を提供するプロセスです。

Istioはアプリケーションのイベントやメトリクスを収集し、Jaegerなどの事前設定済みのトレーシングツールへ転送します。トレーシング設定の状態は、IstioのWebコンソールであるKialiアドオンをインストールすることで確認できます。Kialiはメッシュ内で稼働するサービス（Istioコンポーネントを含む）のリアルタイムな可観測性を提供し、推奨されるアドオンです

$ istioctl dashboard kiali
http://localhost:20001/kialiCode language: Shell Session (shell)

トレーシング情報を確認する前に、推奨されるモジュール（Jaeger、Grafana、Prometheusなど）の可観測性設定に時間を割く必要がございます。

例えば、スタンドアロンマニフェストを適用することで、GrafanaとPrometheusを迅速にインストールできます。その後、istioctlツールを使用してダッシュボードにアクセスしてください

$ istioctl dashboard grafanaCode language: Shell Session (shell)

Istioは、サービスメッシュへの流入および流出トラフィックのあらゆるタイプについてメトリクスを生成し、それらをPrometheusに転送することが可能です。

IstioOperator

を適用する際、テレメトリ設定仕様をカスタマイズすることで、メトリクスのレベルや種類を設定できます。また、telemetry manifestへのオーバーライドを適用することで同様の設定が可能です。

IstioOperatorについて言えば、現在のマニフェストは istioctl profile dump コマンドでコンソールに出力され、確認することができます。

$ istioctl profile dump demo
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    base:
      enabled: true
    cni:
…Code language: Shell Session (shell)

Istioはログも収集しており、ワークロードを選択し、サービスを選択した後、ログタブに移動することで確認できます。

IstioはEnvoyの分散トレーシング機能を活用しているため、トレーシングバックエンド（Zipkin、Lightstep、OpenCensus Agentなど）の設定が可能です。

セキュリティ

クラウドインフラのセキュリティ確保は企業にとって最優先事項であるため、Istioチームはあらゆる脅威を軽減するための包括的なセキュリティ制御を整備しております。以下の機能がサポートされています：

• 認証と認可：Istioは各ポッド上でサイドカープロキシを実行するため、ポッド間の認証および認可トラフィックを管理できます。セキュリティヘッダーの転送、JWTトークンの処理、リダイレクトルールの適用、セキュリティポリシーの強制を構成可能です。ワークロードへのアクセス制御用に標準的なDENY/ALLOWルールを用いた認可ポリシーを含む、ポッド間の相互TLS設定も、構成マニフェストを記述するだけで実現できます。
• IDおよび証明書管理：Istioには独自のIstio認証局（CA）が付属しており、ルート証明書、署名証明書、鍵を備えているため、ワークロードの署名に使用できます。また、鍵と証明書のローテーション設定もあり、クラスタの基本的なセキュリティ態勢を向上させます。

トラフィック管理

サービスやポッドに出入りするすべてのトラフィックは、Istioによって透過的に処理されます。デフォルトでサーキットブレーカー、タイムアウト、再試行といった信頼性エンジニアリング機能を追加し、DestinationRuleポリシーで設定することも可能です。ただし、Istioの中核となる機能はVirtualServiceと呼ばれる抽象化です。

VirtualServiceは、トラフィックルーティングに影響を与える設定ルールを管理するカスタムリソース定義です。内部ゲートウェイの定義と捉えてください。着信リクエストのパスを指定し、そのパスを宛先に転送するためのルールを適用できます。カスタムヘッダー、トークン、バックエンドサービスの異なるバージョンなどを転送することが可能です。以下のマニフェストは、2つのプレフィックスパスを新しいパスに書き換えるために使用されます

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: store-route
spec:
  hosts:
  - store.prod.svc.cluster.local
  http:
  - name: "store-routes"
    match:
    - uri:
        prefix: "/catalog"
    - uri:
        prefix: "/listing"
    rewrite:
      uri: "/shop"
    route:
    - destination:
        host: store.prod.svc.cluster.local
        subset: v2Code language: JSON / JSON with Comments (json)

/catalog/ または /listing/ で始まるパスを持つ HTTP リクエストは、すべて /shop に書き換えられ、「version: v2」というラベルが付いたポッドに送信されます。

VirtualServices を使用することで、コードを変更することなくポッド間の通信を簡素化できます。コードベース内では、アプリケーションは他のエンドポイントとの通信に、環境から取得した共通の名前またはパスを使用するだけで済みます。例えば、BookInfo デモアプリケーションでは、評価サービスは環境からピアサービスのホスト名を取得し、それらのホスト名をハードコーディングせずに更新送信に使用しています

servicesDomain = "" if (os.environ.get("SERVICES_DOMAIN") is None) else "." + os.environ.get("SERVICES_DOMAIN")
detailsHostname = "details" if (os.environ.get("DETAILS_HOSTNAME") is None) else os.environ.get("DETAILS_HOSTNAME")
ratingsHostname = "ratings" if (os.environ.get("RATINGS_HOSTNAME") is None) else os.environ.get("RATINGS_HOSTNAME")
reviewsHostname = "reviews" if (os.environ.get("REVIEWS_HOSTNAME") is None) else os.environ.get("REVIEWS_HOSTNAME")Code language: JavaScript (javascript)

Istioクラスターをパブリックインターネットに公開する場合、Istioのトラフィック管理機能の一つであるIstio Ingressゲートウェイの設定をご検討ください。IstioゲートウェイまたはKubernetesゲートウェイのいずれかをご利用いただけます。ゲートウェイは、ロードバランシング、TLS終端、フロントエンドプロキシを処理するパブリック向けフロントエンドエンドポイントとして機能します。

最後に、Istioのあまり知られていない機能の一つにカオステストの実行能力があります。これは本番環境内で偶発的でありながら制御可能な「インシデント」を引き起こすテスト手法であり、トポロジの回復力を検証することが可能です。例えば、特定のサービスに対してHTTP遅延を導入し、負荷下での動作をテストすることが可能です。また、特定のHTTPエラーコードや処理が困難な中止応答を送信することもできます。これらの機能により、Istioは分散環境におけるアプリケーションのスケーリングを実現する堅牢なプラットフォームとなっています。

拡張性

Istioは、WasmまたはWebAssemblyを使用してプログラム的に拡張することが可能です。これはEnvoyFilterと呼ばれる抽象化を利用しており、ミドルウェアフレームワークのように機能します。EnvoyFilterは、トラフィックがシステムを経由してルーティングされる際に、カスタムのビジネスロジックや設定を追加するために使用されます。

これらのプラグイン（通常はC++で記述されます）を開発する際には、特定の規約に従う必要があります。その後、拡張機能をコンパイルします。コンパイルされた.wasmのURIは、EnvoyFilterマニフェスト内で参照することが可能です。

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: example-filter-config
spec:
  configPatches:
  - applyTo: EXTENSION_CONFIG
    match:
      context: SIDECAR_INBOUND
    patch:
      operation: ADD
      value:
        name: example-filter-config
        typed_config:
          '@type': type.googleapis.com/udpa.type.v1.TypedStruct
          type_url: type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm
          value:
            config:
              vm_config:
                code:
                  remote:
                    http_uri:
                      uri: https://storage.googleapis.com/istio-ecosystem/wasm-extensions/example/1.9.0.wasmCode language: JSON / JSON with Comments (json)

デプロイ後、KialiダッシュボードのIstio Configオプション内で、EnvoyFilterのステータスログを確認できます。

Istioの機能についてご理解いただけたところで、その主要な構成要素について詳しく見ていきましょう。

Istio コントロールプレーンコンポーネント

Istioは、一連の境界内で連携して動作する複数のコンポーネントで構成される大規模なプラットフォームです。Istioコントロールプレーンは、制御操作を扱うコンポーネントの層であり、K8sコントロールプレーンと同様に機能し、システムの頭脳となります。

Istiodは、コントロールプレーン上で動作するデーモンサービスであり、Istioコントロールプレーンコンポーネントを単一のバイナリに統合します。これにより、このプレーンの管理と運用が簡素化されます。以下の図は、Istioの主なアーキテクチャを示しています：

Pilot

Pilotは、トラフィック管理を担当するサービスです。実際には以下の2つのモジュールで構成されています：

• pilot-agent: サイドカーまたはゲートウェイコンテナ内で動作し、必要に応じてEnvoyエージェントを起動します。
• pilot-discovery: サービスディスカバリーなど、フリート全体のトラフィック管理機能を備えています。

Citadel（シタデル）

シタデルは、セキュリティ、認証、および認証情報管理を扱うコントロールプレーンサービスです。シタデルは、サービスIDに基づいてポリシーを適用するよう設定でき、証明書の発行とローテーションも担当します。ただし、現在のコード内での存在感は希薄です。Istioチームが徐々にその本来の機能をIstiodに移行しているため、将来のIstioバージョンではシタデルの機能セットは限定的となる見込みです。

Galley

Galleyは、かつてIstioの構成管理および検証コンポーネントでした。しかし、新しいバージョンのIstioではレガシーコンポーネントとなり、その機能の大部分はIstiodへ移行されました。コードベース内では、ごくわずかな参照しか見られなくなっています。

Istio データプレーンコンポーネント

Istioのデータプレーンは、個々のサイドカープロセスが配置されるレイヤーです。

Envoy

Envoyは、クラウドネイティブアプリケーション向けに特別に設計されたオープンソースのサービスプロキシです。Istioは、同じポッド内のアプリケーションの傍らに配置されるサイドカープロセスとしてEnvoyを採用しています。Istioは、pilot-agentおよびpilot-discoveryモジュールを使用して、そのランタイム設定とライフサイクルを管理します。プロキシの状態は、istioctl proxy-statusコマンドで随時確認できます。また、特定のEnvoy設定はistioctl proxy-configで確認可能です。EnvoyFilterを使用すると、Istio Pilotが生成した設定をカスタマイズできます。

Istioのアドオンと統合

優れたソフトウェアの主な強みの一つは、その拡張性です。Istioはデフォルトでモジュール化設計となっており、多様な拡張オプションを提供しています。

サードパーティ開発者やクラウドプロバイダーは、Istioの拡張性を活用する重要な取り組みを進めており、適切なコネクタやアドオンを実装しています。Istioのアドオンと統合には以下のカテゴリがあります：

プロバイダー

主要なクラウドプロバイダーは、Istioベースのデプロイメント向けに専用ソリューションを開発しています。例えば、GCloud AnthosやRedHat Service MeshはIstioを基盤としており、それぞれのエコシステム内で効果的に機能します。企業は自社のプラットフォームで標準のIstioを使用することも可能ですが、日常業務の管理コストを軽減する点で、これらのネイティブ対応ソリューションを採用する強い理由があります。

アドオン

Kubernetesデプロイメント向けにサービスを提供するサードパーティ製ツールは、期待通りに動作させるためにIstioの存在とその設定方法を認識する必要があります。例えば、既存の認可ライブラリは、Istio導入後も既存ルールを書き換えることなく利用可能であるべきです。

代表的なユースケースとして、Envoyベースの認可ライブラリであるCasbinが挙げられます。

Istioはデータプレーン内でEnvoyを利用しているため、CasbinポリシーをIstioで再利用できるようになることが有用です。Istio 1.9以降では、アクセス制御の決定をそのバックエンドに委譲するCUSTOMアクションを採用することで、サードパーティ認証ツールを利用できます。同様のアドオンは、初期の meshConfigオブジェクト上でExtensionProviderを使用することで、トレーシングやモニタリングにも適用可能です。

以前にも触れましたが、IstioはカスタムEnvoyFiltersやWasmプラグインモジュールを用いて拡張可能です。後者は実行時に動的にロードすることもできます。安定したセキュアなプラットフォームを維持し、バグを排除するためには、検証済みのモジュールのみを使用されることを推奨いたします。これによりセキュリティとコンプライアンスの向上が図れます。

本番環境におけるIstioデプロイメントの維持には非常に複雑な作業と労力が必要となります。そのため、継続的に遵守すべきセキュリティ対策とベストプラクティスを理解しておくことが不可欠です。

Istioのセキュリティとベストプラクティス

Istioでは、ワークロードのセキュリティ確保に特化した詳細なドキュメントページを提供しております。ほとんどの推奨事項は有効ですが、以下の点にもご留意いただければ幸いです：

• 確実なアップグレード計画の策定：本番環境向けにIstioを設定する際、まず最初に行うべきことは更新とアップグレードの管理です。Istioが受けるセキュリティ更新を常に把握しておく必要があります。その有効な方法の一つとして、Istioオペレーターの異なるバージョン管理にKustomizeを活用することが挙げられます。まず、運用するIstioの各バージョン（例：1.15.4や1.16.1）ごとにフォルダーを作成し、Istioオペレーターの設定ファイルと新バージョン追加手順を追加します。各バージョンの設定マニフェストを生成した後、クラスタや環境ごとに段階的にアップグレードを適用し、問題がないことを確認できます。これにより、クラスタ間で更新を標準化することが可能になります。
• 信頼できる拡張機能とアドオンのみを使用する：外部プロバイダーやアドオンを利用できることはIstioの魅力的な機能ですが、リスクがないわけではありません。GitHubからカスタムWasmモジュールやEnvoyFilterを追加する場合は、その動作内容や既知のバグの有無を把握するため、必ず監査を実施してください。依存関係の脆弱性は絶対に避けなければなりません。攻撃者が依存関係の混乱やその他のソフトウェアサプライチェーン攻撃を利用してシステムを感染させ、機密データを窃取することは非常に容易です。
• Istioクラスターの過小プロビジョニングは避けてください：Istioは効率的に動作するためにCPUとメモリを必要とする複数のコンポーネントで構成されています。最小ハードウェア要件として、小規模なIstioクラスターには少なくとも4 vCPUユニットと16GB RAMを推奨します。リソースを過少にプロビジョニングすると、負荷増加に伴いクラスターのパフォーマンスが低下し、タイムアウトが発生したりシステムサービスの可用性が失われたりする可能性があります。アプリケーションやサービスをデプロイする際は、クラスターのリソース使用状況を監視し、十分なハードウェア容量を確保してください。

まとめ

Istioは、Kubernetesにデプロイされたマイクロサービスアプリケーションの運用能力を最大限に引き出すための、非常に有用なオープンなエコシステムです。長年にわたり幾度かの変遷と変更を経てきましたが、多くの企業や組織にとって信頼できるツールとなっています。そのモジュール式のアーキテクチャ、優れた拡張性、柔軟性により、中規模から大規模なKubernetesクラスターや、あらゆる種類のマルチクラウド／ハイブリッドクラウドソリューションにおいて、事実上の選択肢となっています。