Istio とサイドカー パターンの基本概念・メリット
Istio が提供する サイドカー パターンは、マイクロサービス間の通信をインフラ層で統一的に管理できる仕組みです。アプリケーションコードを変更せずにトラフィック制御・観測・セキュリティ機能を付与できるため、開発速度と運用安定性の両立が可能になります。本節ではサイドカーの役割と、サービスメッシュ全体で得られる主な利点を簡潔に解説します。
Contents
- 1 サイドカーとは
- 2 サービスメッシュで得られる主な利点
- 3 Kubernetes バージョン要件
- 4 kubectl と istioctl のインストール手順
- 5 istioctl install の実行と推奨プロファイル選択
- 6 Namespace へのラベル付与による自動サイドカー注入
- 7 サンプルアプリのデプロイ手順
- 8 VirtualService と DestinationRule によるトラフィック分割
- 9 実装結果の確認方法
- 10 Telemetry・Kiali・Grafana の有効化とダッシュボード確認
- 11 mTLS 設定とバージョン依存性の注意点
- 12 デバッグに便利な istioctl コマンド例
サイドカーとは
サイドカーは各 Pod に同梱される軽量プロキシ（デフォルトは Envoy）で、アプリコンテナと同じネットワーク名前空間で動作します。これにより すべての inbound/outbound トラフィックが自動的にプロキシ経由 となり、以下のような効果が得られます。
- アプリ側は通信ロジックを書き換える必要がない
- プロキシ側で認証・暗号化・リトライなどを一元管理できる
たとえば product-service Pod が起動すると、同じ Pod 内に istio-proxy コンテナが生成され、HTTP と TCP の両方のパケットが Envoy を通過します。
サービスメッシュで得られる主な利点
Istio は コントロールプレーン（Pilot・Mixer・Citadel など）と データプレーン（サイドカー）の二層構造で機能を提供します。その結果、次のような価値が実現します。
| カテゴリ | 主な利点 |
|---|---|
| トラフィック管理 | カナリアリリースや A/B テストをコード変更なしで実行できる |
| Observability（可観測性） | メトリクス・分散トレース・ログが自動収集され、Grafana/Kiali で可視化可能 |
| セキュリティ | mTLS による相互認証とポリシーベースのアクセス制御を標準装備 |
これらの機能が一つのプラットフォームに統合されているため、運用コスト削減とサービス信頼性向上 が同時に得られます。
前提条件とインストール準備
本セクションでは、Istio を安全かつスムーズに導入するための Kubernetes バージョン要件 と、kubectl・istioctl の取得手順を示します。事前に環境が整っていないと、後続のデプロイでエラーが頻発するため重要です。
Kubernetes バージョン要件
Istio の最新版（執筆時点 1.22 系）は Kubernetes 1.24 以上 を推奨しています。これは API の安定化や、PodSecurityPolicy の廃止に伴う互換性確保が目的です。
|
1 2 3 |
$ kubectl version --short # Server Version: v1.27.3 ← 推奨範囲内の例 |
バージョンが要件を満たさない場合は、クラスター全体のアップグレードまたは別環境でのテスト実施を検討してください。
kubectl と istioctl のインストール手順
公式サイトから直接バイナリを取得し、PATH に配置する方法が最も確実です。パッケージマネージャ経由だとリポジトリの更新タイミングに差異が生じやすく、ドキュメントとの乖離が起きることがあります。
|
1 2 3 4 5 6 7 8 9 |
# ── kubectl (最新安定版) ─────────────────────── curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" chmod +x kubectl && sudo mv kubectl /usr/local/bin/ # ── istioctl (例: 1.22.0) ─────────────────────── ISTIO_VERSION=1.22.0 curl -L https://istio.io/downloadIstio | ISTIO_VERSION=$ISTIO_VERSION sh - sudo cp istio-$ISTIO_VERSION/bin/istioctl /usr/local/bin/ |
インストール後は次のコマンドでバージョンが正しく表示されることを確認します。
|
1 2 3 |
$ kubectl version --client $ istioctl version |
Istio 本体のデプロイと自動サイドカー注入設定
ここでは Istio コントロールプレーンのインストール と、Namespace 単位で有効化できる 自動サイドカー注入 の手順を解説します。正しいインストールは、全サービスが同一メッシュ内で安全に通信できる前提条件です。
istioctl install の実行と推奨プロファイル選択
default プロファイルは Telemetry・Ingress/Egress ゲートウェイ・基本的なセキュリティ機能をバランス良く含んでいるため、初期導入に最適です。カスタマイズが必要な場合は --set values... オプションで個別項目を上書きできます。
|
1 2 3 |
istioctl install --set profile=default -y # 出力例: Istio control plane installed successfully |
インストール完了後、以下のコマンドで istio-system 名前空間に全コンポーネントが起動していることを確認してください。
|
1 2 |
kubectl get pods -n istio-system |
Namespace へのラベル付与による自動サイドカー注入
Istio の Admission Webhook は istio-injection=enabled ラベルが付いた Namespace に対して、Pod 作成時に自動的に istio-proxy コンテナを挿入します。
|
1 2 3 4 5 6 |
kubectl create namespace demo kubectl label namespace demo istio-injection=enabled # 設定確認 kubectl get namespace -L istio-injection |
このラベル付与は一度設定すれば以降のデプロイ全てに適用され、手作業でサイドカーを追加する必要がなくなります。
ハンズオン：Bookinfo アプリで学ぶサイドカー注入とトラフィック制御
公式サンプル Bookinfo を使って、実際にサイドカーが注入されたことの確認方法と、L7 ルーティングを行う VirtualService／DestinationRule の作成手順を体験します。ハンズオンは「インフラ層で機能追加できる」感覚をつかむ最適な練習です。
サンプルアプリのデプロイ手順
以下のコマンドで demo Namespace に Bookinfo の全コンポーネントを一括適用します。Namespace がラベル付与済みなので、Pod 作成時に自動的にサイドカーが注入されます。
|
1 2 |
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.22/samples/bookinfo/platform/kube/bookinfo.yaml -n demo |
デプロイ完了後、kubectl get pods -n demo を実行すると productpage-v1-…, details-v1-… などのアプリ Pod と同時に istio-proxy コンテナが表示されます。
VirtualService と DestinationRule によるトラフィック分割
次に レビューサービス（reviews） のバージョンを 80%:20% に振り分ける設定例を示します。まずは DestinationRule で各バージョンのサブセットを定義し、続いて VirtualService でウェイト付きルーティングを書きます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
# destinationrule-reviews.yaml apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: reviews namespace: demo spec: host: reviews subsets: - name: v2 labels: version: v2 - name: v3 labels: version: v3 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
# virtualservice-reviews.yaml apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: reviews namespace: demo spec: hosts: - reviews http: - route: - destination: host: reviews subset: v2 weight: 80 - destination: host: reviews subset: v3 weight: 20 |
|
1 2 3 |
kubectl apply -f destinationrule-reviews.yaml -n demo kubectl apply -f virtualservice-reviews.yaml -n demo |
この設定により、reviews サービスへのリクエストは 80% が v2、20% が v3 に振り分けられます。
実装結果の確認方法
以下の手順でルーティングが期待通りに機能しているか検証します。外部から Ingress Gateway 経由で productpage を取得し、表示されるレビューのバージョンを確認してください。
|
1 2 3 4 5 6 |
# Ingress の IP アドレス取得（例: 10.0.0.1） INGRESS_IP=$(kubectl -n istio-system get svc istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}') # productpage にアクセスしてレビューのバージョンが混在しているか確認 curl -s http://$INGRESS_IP/productpage | grep "Reviews version" |
また、Pod 内部で Envoy 設定を直接ダンプし、ルーティングテーブルに期待したウェイトが入っていることも確認できます。
|
1 2 3 4 5 6 |
# reviews の Pod 名取得 REV_POD=$(kubectl get pod -l app=reviews -n demo -o jsonpath='{.items[0].metadata.name}') # Envoy ルート設定の表示 istioctl proxy-config routes $REV_POD.demo -n demo |
Observability、セキュリティ、トラブルシューティングのベストプラクティス
本章では Telemetry／Kiali／Grafana の有効化手順、mTLS 設定方法、そして障害発生時に役立つ istioctl 系コマンドをまとめます。これらを日常的に活用すれば、運用監視とインシデント対応が格段に楽になります。
Telemetry・Kiali・Grafana の有効化とダッシュボード確認
Istio 1.22 以降は telemetry=v2 がデフォルトでプロメテウスと OpenTelemetry にエクスポートされ、アドオン（Kiali, Grafana）も同時にインストールできます。
|
1 2 3 4 5 |
istioctl install --set profile=default \ --set values.telemetry.enabled=true \ --set values.kiali.enabled=true \ --set values.grafana.enabled=true -y |
ポートフォワーディングで UI にアクセスし、メトリクスやトレースが正しく可視化されていることを確認してください。
|
1 2 3 4 5 6 |
# Kiali (http://localhost:20001) kubectl -n istio-system port-forward svc/kiali 20001:20001 & # Grafana (http://localhost:3000) kubectl -n istio-system port-forward svc/grafana 3000:3000 & |
mTLS 設定とバージョン依存性の注意点
公式ドキュメント（2024年10月時点）によると、デフォルトで全 Namespace に対して mTLS が有効です。ただしこの挙動は Istio のマイナーバージョンや設定プロファイルに依存する可能性があります。必ず最新の 「PeerAuthentication」 リファレンスを確認したうえで、必要なら明示的にポリシーを定義してください。
|
1 2 3 4 5 6 7 8 9 |
apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: demo spec: mtls: mode: STRICT # 全通信を暗号化・認証する |
適用後は次のコマンドで TLS 設定が反映されているかチェックできます。
|
1 2 |
istioctl authn tls-check <pod-name>.demo -n demo |
デバッグに便利な istioctl コマンド例
| コマンド | 用途 |
|---|---|
istioctl proxy-status |
全 Pod の Envoy 同期状態（SYNCED / NOT_SYNCED）を一覧表示 |
kubectl logs <pod>-istio-proxy -n demo |
サイドカーの実行ログ取得 |
istioctl proxy-config listeners <pod> -n demo |
リスナー設定（ポート・プロトコル）確認 |
istioctl proxy-config clusters <pod> -n demo |
上流サービス情報や TLS 設定を可視化 |
istioctl proxy-config routes <pod> -n demo |
HTTP ルーティングテーブルの内容確認 |
障害が発生したらまず proxy-status が SYNCED かどうかを確認し、続いてログ・設定ダンプで原因を切り分けます。
まとめ
- サイドカー パターンはコード変更不要でトラフィック管理・観測・セキュリティを提供し、マイクロサービス運用のハードルを大幅に下げる。
- 前提条件は Kubernetes 1.24+ と、公式バイナリから取得した
kubectl／istioctlを使用すること。 istioctl install --set profile=defaultによりコントロールプレーンをデプロイし、Namespace ラベルで 自動サイドカー注入 を有効化できる。- Bookinfo ハンズオンでサイドカーの注入確認と、
VirtualService／DestinationRuleによるトラフィック分割手順を体験することで、実践的なスキルが身につく。 - Observability（Telemetry・Kiali・Grafana）や mTLS STRICT の設定はデフォルトで有効になるものの、バージョン依存性があるため公式ドキュメントを定期的にチェックし、
istioctl系コマンドで日常的に状態確認すると障害対応が迅速になる。
上記フローに沿ってテスト環境で実装・検証すれば、本番導入時のリスクを最小限に抑えつつ、サービスメッシュの恩恵を最大限活用できます。