サービスメッシュ(ASM)を使用すると、複数のコンテナサービス Kubernetes(ACK)クラスターを 1 つの ASM インスタンスに統合し、疎分散サービスの集中管理および O&M プラットフォームを提供できます。ASM クロス クラスター メッシュ プロキシは、マルチクラスター ネットワークにより柔軟な相互接続ソリューションを提供します。このトピックでは、ASM クロス クラスター メッシュ プロキシを使用して、複数のクラスターのクロスネットワーク通信を構成する方法について説明します。
背景情報
ASM はマルチクラスターモードをサポートしています。これは、同じ ASM インスタンスに複数の ACK クラスターを追加できることを意味します。ASM のマルチクラスターモードでは、異なるネットワークに存在する複数の ACK クラスターを同じ ASM インスタンスに追加できます。設備の制限、CIDR ブロックの競合、料金などの理由により、これらのクラスターに対してレイヤー 3 でクロスネットワーク通信を確立できない場合は、ASM クロス クラスター メッシュ プロキシを使用してクラスターを接続できます。ASM クロス クラスター メッシュ プロキシを使用すると、パブリック ネットワークとプライベート ネットワークを使用して、これらのクラスターを柔軟に接続できます。このようにして、サービスコードを変更することなく CIDR ブロックの競合を解決し、複数のクラスターの集中トラフィックガバナンス、セキュリティ保護、エンドツーエンドの監視を実装できます。このトピックでは、同じ ASM インスタンスに追加された複数のクラスターのクロスネットワーク通信を構成するために、ASM クロス クラスター メッシュ プロキシを使用する方法について説明します。この例では、sleep アプリケーションを使用して、クラスター間で HTTPBin アプリケーションにアクセスします。
メリット
V1.22 以降の ASM インスタンスによって提供される ASM クロス クラスター メッシュ プロキシは、レイヤー 7 のロード バランシングを完全に実装します。クロス クラスター通信シナリオにおける East-West ASM ゲートウェイのルーティング機能は、クロス クラスター以外の通信シナリオにおけるルーティング機能と同じです。
前提条件
バージョン 1.22 以降の ASM インスタンスが作成されていること。詳細については、「ASM インスタンスの作成」をご参照ください。
複数のクラスターが ASM インスタンスに追加されていること。詳細については、「ASM インスタンスへのクラスターの追加」をご参照ください。(この例では、2 つのクラスターが追加されています。)
ASM インスタンスで自動サイドカー プロキシ インジェクションが有効になっていること。詳細については、「グローバル名前空間の管理」トピックの「自動サイドカー プロキシ インジェクションの有効化」セクションをご参照ください。
サービス間のクロス クラスター アクセスは、次の 2 つの条件のいずれかが満たされている場合にのみ使用できます。
ASM インスタンスでドメイン ネーム システム(DNS)プロキシ機能が有効になっていること。詳細については、「ASM インスタンスでの DNS プロキシ機能の使用」をご参照ください。この方法をお勧めします。
サーバーを提供するクラスターと同じ宛先サービスが、クライアントを提供するクラスターに手動で作成されていること。
手順 1:ASM インスタンスの コントロール プレーン に Elastic IP アドレス(EIP)を関連付ける
データ プレーン上のクラスターが ASM インスタンスが存在する仮想プライベートクラウド(VPC)と通信できず、データ プレーンと ASM インスタンスの コントロール プレーン をインターネット経由で接続する場合、ASM インスタンスの コントロール プレーン の Istio Pilot エンドポイントの SLB インスタンスに EIP を関連付けて、Istio Pilot エンドポイントをインターネットに公開できます。
ASM コンソール にログインします。左側のナビゲーションペインで、 を選択します。
[メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションペインで、 を選択します。
[基本情報] ページの右側で、[istio Pilot エンドポイント] を選択し、[EIP のバインド] をクリックします。
この場合、ASM インスタンスがリリースされると、EIP もリリースされます。
手順 2:クラスターのネットワーク設定を構成し、クロス クラスター メッシュ プロキシを有効にする
各クラスターに論理ネットワークを指定できます。同じ論理ネットワーク上のサービスは、相互に直接アクセスできます。異なる論理ネットワーク上のサービスは、クロス クラスター メッシュ プロキシを使用して相互にアクセスする必要があります。
ASM コンソール にログインします。左側のナビゲーションペインで、 を選択します。
[メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションペインで、 を選択します。
[マルチクラスター ネットワーク構成] をクリックし、次の方法を使用して構成を完了します。
ACK 1 の [ホーミング論理ネットワーク名] を network1 に設定します。
ACK 2 の [ホーミング論理ネットワーク名] を network2 に設定し、ACK 2 で [クロス クラスター メッシュ プロキシ経由のアクセスを有効にする] をオンにします。

上記の構成を適用すると、ASM は ACK 2 にデフォルトのクロス クラスター メッシュ プロキシを作成します。このメッシュ プロキシは EIP に関連付けられています。ACK 1 のサービスは、このクロス クラスター メッシュ プロキシを自動的に使用して ACK 2 のサービスにアクセスし、この通信パスでは相互トランスポート層セキュリティ(mTLS)暗号化がデフォルトで有効になります。
対応するクラスターの kubeconfig ファイルで、クロス クラスター メッシュ プロキシの定義を表示できます。クロス クラスター メッシュ プロキシは、asm-cross-network-${ACK ID} の形式で名前が付けられます。ビジネス要件に基づいて、リソースやレプリカ数など、クロス クラスター メッシュ プロキシの構成を調整できます。
クロス クラスター メッシュ プロキシは TCP プロキシであり、レイヤー 7 のロード バランシングを実行できません。場合によっては、ロードの不均衡が発生する可能性があります。
手順 3:クロス クラスター アクセスを確認する
上記のネットワーク構成は、対応するアプリケーション ポッドが起動されたときに有効になります。ネットワーク構成を変更する前にアプリケーション ポッドがすでに起動されている場合は、アプリケーション ポッドを再起動する必要があります。
ACK 1 に sleep アプリケーションを作成します。YAML コンテンツの例:
ACK 2 に HTTPBin アプリケーションを作成します。YAML コンテンツの例:
sleep アプリケーションを実行しているポッドから HTTPBin アプリケーションにアクセスします。(ACK 1 の kubeconfig ファイルの情報に基づいてポッドに接続します。)
sleep アプリケーションを実行しているポッドの名前を取得します。
kubectl get pod | grep sleepcurl コマンドを実行して、sleep アプリケーションから HTTPBin アプリケーションにアクセスします。
kubectl exec ${sleep アプリケーションを実行しているポッドの名前} -- curl httpbin:8000/status/418次の出力は、アクセスが成功したことを示しています。
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 135 100 135 0 0 16075 0 --:--:-- --:--:-- --:--:-- 16875 -=[ teapot ]=- _...._ .' _ _ `. | ."` ^ `". _, \_;`"---"`|// | ;/ \_ _/ `"""`
sleep アプリケーションがクロス クラスター メッシュ プロキシを使用して HTTPBin アプリケーションにアクセスしていることを確認します。
sleep アプリケーションを実行しているポッドのログを確認します。(ACK 1 の kubeconfig ファイルの情報に基づいてポッドに接続します。)
kubectl logs ${sleep アプリケーションを実行しているポッドの名前} -c istio-proxy | tail -1次のコマンド出力が返されます。
{"authority_for":"httpbin:8000","bytes_received":"0","bytes_sent":"135","downstream_local_address":"xxx.xxx.xxx.xx:8000","downstream_remote_address":"xx.x.xxx.xxx:xxxxx","duration":"7","istio_policy_status":"-","method":"GET","path":"/status/418","protocol":"HTTP/1.1","request_id":"08dc43e9-60c8-4f2f-910a-b727172ce311","requested_server_name":"-","response_code":"418","response_flags":"-","route_name":"default","start_time":"2024-05-23T10:06:27.289Z","trace_id":"-","upstream_cluster":"outbound|8000||httpbin.default.svc.cluster.local","upstream_host":"xxx.xx.xxx.xxx:15443","upstream_local_address":"xx.x.xxx.xxx:60248","upstream_response_time":"7","upstream_service_time":"7","upstream_transport_failure_reason":"-","user_agent":"curl/8.1.2","x_forwarded_for":"-"}upstream_hostフィールドは、sleep アプリケーションを実行しているポッドによって直接アクセスされる宛先サービスを識別します。出力は、ポート15443でアクセスが実行されていることを示しています。ポート15443は、クロス クラスター メッシュ プロキシの専用ポートです。クロス クラスター メッシュ プロキシのログを確認します。(ACK 2 の kubeconfig ファイルの情報に基づいてポッドに接続します。)
まず、クロス クラスター メッシュ プロキシを実行しているポッドを取得します。
kubectl -n istio-system get pod | grep asm-cross-network istio-asm-cross-network-c0859be51XXX 1/1 Running 0 20h istio-asm-cross-network-c0859be51XXX 1/1 Running 0 20h出力は、デフォルトで 2 つのポッドがクロス クラスター メッシュ プロキシを実行していることを示しています。これらの 2 つのポッドのログを個別に確認できます。ログは似ています。
kubectl logs istio-asm-cross-network-c0859be51XXX -n istio-system | tail -1 {"authority_for":"-","bytes_received":"xxxx","bytes_sent":"xxxx","downstream_local_address":"xx.xx.x.xx:15443","downstream_remote_address":"xx.xx.xx.xx:xxxxx","duration":"1568569","istio_policy_status":"-","method":"-","path":"-","protocol":"-","request_id":"-","requested_server_name":"outbound_.8000_._.httpbin.default.svc.cluster.local","response_code":"0","response_flags":"-","route_name":"-","start_time":"2024-05-23T08:41:16.618Z","trace_id":"-","upstream_cluster":"outbound_.8000_._.httpbin.default.svc.cluster.local","upstream_host":"xx.xx.xx.xxx:80","upstream_local_address":"xx.x.xx.xx:xxxxx","upstream_response_time":"-","upstream_service_time":"-","upstream_transport_failure_reason":"-","user_agent":"-","x_forwarded_for":"-"}