はじめに

先日、名古屋の中日ホール＆カンファレンスにて開催された「クラウドネイティブ会議」において、実行委員会の有志の方々が企画・運営されたハンズオンに現地参加してきました。このハンズオンは、Docker・Kubernetes・ArgoCD・Istio など、さまざまな技術を題材に資料が用意されており、各々が興味のある技術について黙々と理解を深めていけるような流れとなっていました。そんな中私は、Istio のサービスメッシュに関する題材に取り組みました。Istio については「あのサービスメッシュのやつね」くらいの知識感だった私が、ハンズオンを通じて学んだ Istio の基本概念と実践内容を本記事にまとめます。

サービスメッシュとは

CNCF（Cloud Native Computing Foundation）用語集では、サービスメッシュについて次のように解説されています。

サービスメッシュは、コードの変更を必要とせずに、クラスタ全体のすべてのサービスに対して、信頼性、オブザーバビリティ、およびセキュリティ機能を均一に追加します。サービスメッシュが登場する前は、その機能をすべての個々のサービスに組み込む必要があり、バグや技術的負債の潜在的な原因となっていました。

マイクロサービス構成のアプリケーションでは、複数のサービスが互いに通信しながら動いています。サービスが増えるにつれ、以下のような課題が生まれます。

• 通信失敗時のリトライ処理
• サービス間通信の暗号化
• どのサービスがどこと通信しているかの把握
• 特定サービスへのトラフィックの段階的な切り替え

これらをアプリケーション側のコードで解決しようとすると、多くのサービスに同様の処理を書く必要があります。サービスメッシュはこの問題をアプリの外側のインフラ層で解決する仕組みです。

Istioとは

Istio は先の項で触れたサービスメッシュを Kubernetes 上で実現する OSS です。Google・IBM・Lyft によって 2017 年に開発が開始され、現在は CNCF の Graduated プロジェクトになっています。

Istio が提供する主な機能は以下のとおりです。

• サービス間通信の TLS 暗号化（mTLS）
• 細かなトラフィックルーティング制御
• メトリクス・ログ・トレースの自動収集
• 認可制御（サービス間の通信の許可・拒否）

Istioのアーキテクチャ

Istio はコントロールプレーンとデータプレーンの 2 層で構成されます。

コントロールプレーン（Istiod）

Istiod は以下の 3 つの役割を担っています。

データプレーン（Envoy）

Envoy は Lyft 社が開発した高性能プロキシです。Istio ではアプリケーションのサイドカーとして各 Pod に自動注入されます。全通信が Envoy を経由することで、アプリを変更せずに通信の制御・観測・暗号化が実現できます。

出典: Istio公式ドキュメント

Envoy はアプリ Pod のサイドカーだけでなく、クラスター外からのトラフィックを受け付けるイングレスゲートウェイとしても配置されます。

どちらも Istiod から設定を受け取って動いています。

トラフィックの流れ

外部からのリクエストは、以下の順でアプリ Pod に届きます。

クライアント
    ↓
istio-ingressgateway Service（NodePort で外部トラフィックを受け付ける）
    ↓
istio-ingressgateway Pod（Envoy がトラフィックを処理）
    ↓  Gateway：どのホスト名・ポートを受け付けるか判断
    ↓  VirtualService：どの Service に流すか決定
    ↓  DestinationRule：どの subset（Pod グループ）に届けるか解決
アプリ Pod

各ステップで登場する Kubernetes リソースと Istio CRD の役割は以下のとおりです。

登場するリソースと役割

Gateway

クラスター外からのトラフィックを受け入れる入口を定義する CRD です。

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: handson
spec:
  selector:
    istio: ingressgateway   # istio-ingressgateway Podを指定
  servers:
  - port:
      number: 80
      protocol: HTTP
    hosts:
    - app.example.com       # このホスト名のトラフィックを受け付ける

VirtualService

Gateway で受け入れたトラフィックをどの Service に流すかを定義する CRD です。

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: simple-routing
spec:
  hosts:
  - app.example.com
  gateways:
  - handson              # handson Gatewayから来たトラフィックが対象
  http:
  - route:
    - destination:
        host: handson    # handson Serviceに流す
        port:
          number: 8080

トラフィック制御

当日はさまざまなトラフィック制御を実際に手を動かしながら体験しました。その中からいくつかをご紹介します。

重み付けルーティング（カナリアリリース）

VirtualService と DestinationRule を組み合わせることで、カナリアリリースをアプリ変更なしで実現できます。

# VirtualService：トラフィックの割合を定義
http:
  - route:
    - destination:
        subset: v1
      weight: 90   # 90%をv1に
    - destination:
        subset: v2
      weight: 10   # 10%をv2に

# DestinationRule：v1・v2のグループを定義
subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Fault Injection

意図的に遅延やエラーを発生させ、異常系のテストができます。

fault:
  delay:
    percentage:
      value: 50
    fixedDelay: 3s   # 50%のリクエストに3秒の遅延を発生させる

通常では再現が難しいタイムアウトやエラーハンドリングの検証を、本番に近い環境で安全に実施できます。

認可制御（AuthorizationPolicy）

サービス間の通信を L4 や L7 で許可・拒否できます。ドキュメントでは以下のような図で解説されていました。

出典: Istio公式ドキュメント - Security

簡単な実装で動作の確認も行いました。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-from-ingressgateway
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account

上記の例は特定のサービスアカウントからの通信のみ許可するという設定です。他にも、ポート単位での接続ブロック（L4）や HTTP メソッド単位での操作制限（L7）など、きめ細かなアクセス制御が可能です。

付け足し: Kialiによる可視化

今回、Istio のハンズオンを通してトラフィックを可視化するために Kiali というツールを使用しました。Kiali は Istio サービスメッシュ専用の可視化ツールで、Prometheus が収集したメトリクスを Kiali が読み取り、サービス間のトラフィックをリアルタイムでグラフ表示してくれます。

参考: Kiali公式ドキュメント

まとめ

今回のハンズオンを通じて、Istio がアプリケーションに変更を加えることなく、トラフィック制御・セキュリティ・可観測性を実現できることを実際に体験できました。

特に印象的だったのは以下の点です。

• サイドカーパターンにより、アプリを一切変更せずに Envoy が透過的に挿入される仕組み
• VirtualService・DestinationRuleによる柔軟なトラフィック制御

今回のようなイベントは、普段触れる機会の少ない技術を実践的に学べる貴重な機会です。今後もコミュニティへの参加を続けながら、得た知見をチームに還元していきたいと思います。