Service Mesh (ASM) インスタンス内の Pod からのアウトバウンドトラフィックは、デフォルトでサイドカープロキシを介してリダイレクトされます。Pod がメッシュ外のサービス (サードパーティ API、データベース、SaaS エンドポイントなど) にアクセスできるようにするには、プロキシが未登録の送信先へのリクエストをどのように処理するかを構成する必要があります。
ASM は 3 つのアプローチをサポートしており、それぞれセットアップの労力、トラフィックの可視性、および制御の間で異なるトレードオフがあります。
| アプローチ | トラフィックの可視性 | トラフィック制御 | セットアップの労力 | 最適な用途 |
|---|---|---|---|---|
アウトバウンドトラフィックポリシー (ALLOW_ANY) | なし | なし | 低 | 初期テストと評価 |
| ServiceEntry (推奨) | 完全 | 完全 (ルーティング、リトライ、タイムアウト、障害注入) | 中 | 本番ワークロード |
| CIDR ベースのインターセプト | バイパスされたトラフィックにはなし | バイパスされたトラフィックにはなし | 低 | プロキシのオーバーヘッドを許容できないパフォーマンス重視のワークロード |
前提条件
開始する前に、以下を確認してください。
サイドカープロキシ注入が有効になっている ASM インスタンス
外部アクセスをテストするために使用できる、サイドカープロキシが注入された Pod
ASM コンソールでの ASM インスタンス設定の変更権限
テスト Pod をセットアップするには、サンプルワークロードをデプロイし、Pod 名をエクスポートします。
export SOURCE_POD=$(kubectl get pod -l <app-label> -o jsonpath='{.items..metadata.name}')<app-label> をテストワークロードのラベルセレクターに置き換えます。以降のすべての curl コマンドは、この Pod 内で実行されます。
curl -I http://www.aliyun.com/アウトバウンドトラフィックポリシーの設定
[アウトバウンドトラフィックポリシー] 設定は、サイドカープロキシがメッシュに登録されていない送信先へのトラフィックをどのように処理するかを制御します。
ALLOW_ANY: プロキシはすべてのアウトバウンドトラフィックを転送します。Pod は任意の外部サービスにアクセスできますが、Istio はトラフィックをモニターまたは制御しません。REGISTRY_ONLY: プロキシは、メッシュのサービスレジストリに登録されていない送信先へのトラフィックをブロックします。
アウトバウンドトラフィックポリシーが ALLOW_ANY に設定されており、ServiceEntry が定義されていない場合、サイドカープロキシは任意の IP アドレスとポートへの TCP トラフィックを許可します。これには明示的なフロー制御がなく、複数のサービスが同じポートでリッスンしている場合に予期しない動作を引き起こす可能性があります。データベースなどの外部サービスにはこのモードを使用しないでください。代わりに ServiceEntry リソースを定義して、トラフィックの送信先を明示的に制御してください。
ポリシーを ALLOW_ANY に設定
ASM コンソールにログインします。
左側のナビゲーションウィンドウで、[Service Mesh] > [メッシュ管理] を選択します。
「[メッシュ管理]」ページで、対象の ASM インスタンスを検索します。インスタンス名をクリックするか、[操作] 列の [管理] をクリックします。
左側のナビゲーションウィンドウで、データプレーンコンポーネント管理 > サイドカープロキシ設定 を選択します。
[グローバル]タブで、[送信トラフィックポリシー]をクリックし、値を[ALLOW_ANY]に設定してから、[設定項目の更新]をクリックします。
外部アクセスの検証
サイドカープロキシが注入された Pod から、HTTP および HTTPS アクセスをテストします。
HTTP リクエスト:
curl -I http://www.aliyun.com/期待される出力:
HTTP/1.1 301 Moved Permanently
server: envoy
date: Mon, 07 Sep 2020 09:28:54 GMT
content-type: text/html
content-length: 239
location: https://www.aliyun.com/
x-envoy-upstream-service-time: 67HTTPS リクエスト:
curl -I https://www.aliyun.com/期待される出力:
HTTP/2 200
server: Tengine
content-type: text/html; charset=utf-8
strict-transport-security: max-age=31536000HTTP 応答の server: envoy ヘッダーは、トラフィックがサイドカープロキシを通過することを確認します。
ServiceEntry の作成
アウトバウンドトラフィックポリシーが REGISTRY_ONLY に設定されている場合、サイドカープロキシはメッシュに登録されていない外部サービスへのリクエストをブロックします。例:
ブロックされた HTTP リクエスト (502 を返します):
curl -I http://www.aliyun.com/HTTP/1.1 502 Bad Gateway
server: envoyブロックされた HTTPS リクエスト (接続拒否):
curl -I https://www.aliyun.com/curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.aliyun.com:443REGISTRY_ONLY モードを維持しながら特定の外部サービスへのアクセスを許可するには、そのサービスをメッシュに登録する ServiceEntry を作成します。登録された ServiceEntry は、外部トラフィックに対して、ルーティングルール、タイムアウト、リトライ、障害注入といった Istio の完全なトラフィック管理を可能にします。
ステップ 1: ServiceEntry の作成
ASM コンソールにログインします。
左側のナビゲーションウィンドウで、Service Mesh > Mesh 管理 を選択します。
[メッシュ管理] ページで、対象の ASM インスタンスを見つけます。インスタンス名をクリックするか、[操作] 列の [管理] をクリックします。
左側のナビゲーションウィンドウで、[クラスターおよびワークロード管理] > [外部サービス (ServiceEntry)] を選択します。
[YAML から作成] をクリックします。
名前空間を選択し、次の YAML を貼り付け、[作成] をクリックします。
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: aliyun-com-ext
spec:
hosts:
- 'www.aliyun.com'
ports:
- number: 80
name: http
protocol: HTTP
- number: 443
name: https
protocol: HTTPS
resolution: DNS
location: MESH_EXTERNALhosts フィールドを対象の外部サービスのホスト名に設定します。この例では、www.aliyun.com をポート 80 (HTTP) と 443 (HTTPS) で登録します。
ステップ 2: 外部アクセスの検証
サイドカープロキシが注入された Pod から、再度アクセスをテストします。
HTTP リクエスト:
curl -I http://www.aliyun.com/期待される出力:
HTTP/1.1 301 Moved Permanently
server: envoy
date: Mon, 07 Sep 2020 09:49:17 GMT
content-type: text/html
content-length: 239
location: https://www.aliyun.com/
x-envoy-upstream-service-time: 66HTTPS リクエスト:
curl -I https://www.aliyun.com/期待される出力:
HTTP/2 200
server: Tengine
content-type: text/html; charset=utf-8
strict-transport-security: max-age=31536000成功応答は、ServiceEntry が機能していることを確認します。
ステップ 3: トラフィック管理ルールの適用 (オプション)
ServiceEntry で外部サービスを登録した後、Istio のトラフィック管理ルールを適用できます。次の例では、www.aliyun.com へのすべてのリクエストに 5 秒の遅延を追加する VirtualService を作成します。これは、低速な外部依存関係に対するワークロードの回復性をテストするのに役立ちます。
左側のナビゲーションウィンドウで、[トラフィック管理センター] > [VirtualService] を選択します。
[YAML から作成] をクリックします。
名前空間を選択し、以下の YAML を貼り付け、[作成]をクリックします。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: aliyun-com-ext
spec:
hosts:
- 'www.aliyun.com'
http:
- fault:
delay:
percent: 100
fixedDelay: 5s
route:
- destination:
host: www.aliyun.com
weight: 100ステップ 4: トラフィックルールの検証
5 秒の遅延が適用されていることを確認します。
time curl -o /dev/null -s -w "%{http_code}\n" http://www.aliyun.com/期待される出力:
301
real 0m 5.07s
user 0m 0.00s
sys 0m 0.00s約 5 秒の real 時間は、VirtualService の障害注入ルールが有効であることを確認します。
CIDR ベースのインターセプトの設定
デフォルトでは、サイドカープロキシはすべての IP アドレスへのトラフィックをインターセプトします。インターセプト範囲を特定の CIDR ブロックに絞り込むことで、他の送信先へのトラフィックがサイドカープロキシを完全にバイパスするようにできます。
共通パターンとして、インターセプト範囲をデータプレーン上の Kubernetes クラスターのサービス CIDR ブロックに設定することが挙げられます。クラスター内サービスへのトラフィックは、可観測性と制御のためにサイドカープロキシを通過しますが、外部サービスへのトラフィックは、低レイテンシーのためにバイパスされます。
他の 2 つのアプローチとは異なり、CIDR ベースのバイパスは、バイパスされたトラフィックに対して Istio の機能 (可観測性、トラフィック管理、セキュリティポリシー) を完全に無効にします。このアプローチは、特定の外部送信先に対してプロキシのオーバーヘッドが許容できない場合にのみ使用してください。
操作手順
「[ASM コンソール]」にログインしてください。
左側のナビゲーションウィンドウで、[Service Mesh] > [Mesh Management] を選択します。
「[メッシュ管理]」ページで、対象の ASM インスタンスを見つけます。インスタンス名をクリックするか、[操作] 列の [管理] をクリックします。
左側のナビゲーションウィンドウで、データプレーンコンポーネント管理 > サイドカープロキシ設定 を選択します。
[グローバル] タブで、[サイドカープロキシをポートまたはIPアドレスで有効化/無効化] をクリックします。
[外部アクセスがサイドカープロキシにリダイレクトされるアドレス] フィールドに、インターセプトする CIDR ブロックを入力し、[設定の更新] をクリックします。
デフォルト値は * で、すべてのトラフィックをインターセプトします。ビジネス要件に基づいて CIDR ブロックを入力できます。一般的に、ASM インスタンスのデータプレーン上の Kubernetes クラスターのサービス CIDR ブロックを入力できます。
別の方法として、[サイドカープロキシにリダイレクトされない外部アクセスのアドレス] フィールドを使用して、サイドカープロキシをバイパスする CIDR ブロックを指定します。他のすべてのトラフィックはインターセプトされます。
セキュリティに関する考慮事項
外部アクセスを構成する際は、以下の点に留意してください。
本番環境では ServiceEntry リソースと
REGISTRY_ONLYを優先します。 このアプローチにより、明示的に登録された外部サービスのみが到達可能になり、意図しないデータ漏洩のリスクが軽減されます。データベースアクセスには
ALLOW_ANYを避けてください。 明示的な ServiceEntry 定義がない場合、データベースへのトラフィックにはフロー制御がなく、複数のサービスが同じポートでリッスンしている場合に予期しない動作を引き起こす可能性があります。
次のステップ
メッシュに登録されているサービスを表示するには、ASM コンソールで [ASM インスタンス] > [インスタンスのステータス] に移動します。
Istio ServiceEntry の構成の詳細については、「Istio ServiceEntry リファレンス」をご参照ください。