メッシュへのワークロードの追加

ほとんどの場合、クラスタ管理者はIstioメッシュインフラストラクチャをデプロイします。アンビエントデータプレーンモードがサポートされた状態でIstioが正常にデプロイされると、それを使用するように構成された名前空間内のすべてのユーザーによってデプロイされたアプリケーションに対して透過的に利用可能になります。

メッシュ内のアプリケーションのアンビエントモードの有効化

アンビエントモードでアプリケーションまたは名前空間をメッシュに追加するには、対応するリソースにラベルistio.io/dataplane-mode=ambientを追加します。このラベルは、名前空間または個々のポッドに適用できます。

アンビエントモードは、アプリケーションポッドに関する限り、完全に透過的にシームレスに有効（または無効）にできます。サイドカーデータプレーンモードとは異なり、アプリケーションをメッシュに追加するために再起動する必要はなく、ポッドに追加のコンテナがデプロイされているとは表示されません。

レイヤー4とレイヤー7の機能

セキュアなL4オーバーレイは、認証および承認ポリシーをサポートしています。アンビエントモードでのL4ポリシーサポートについて学びましょう。トラフィックルーティングなどのIstioのL7機能を使用するには、ウェイポイントプロキシをデプロイして、ワークロードを使用するように登録する必要があります。

アンビエントモードとKubernetes NetworkPolicy

アンビエントとKubernetes NetworkPolicyを参照してください。

異なるデータプレーンモードのポッド間の通信

アンビエントデータプレーンモードを使用するアプリケーションポッドと、非アンビエントエンドポイント（Kubernetesアプリケーションポッド、Istioゲートウェイ、またはKubernetes Gateway APIインスタンスを含む）間の相互運用性には複数のオプションがあります。この相互運用性により、同じIstioメッシュ内でアンビエントワークロードと非アンビエントワークロードをシームレスに統合するための複数のオプションが提供され、メッシュのデプロイと運用ニーズに最適なアンビエント機能の段階的な導入が可能になります。

メッシュ外のポッド

サイドカーモードまたはアンビエントモードのいずれでも、メッシュの一部ではない名前空間がある場合があります。この場合、非メッシュポッドは、送信元ノードのztunnelを経由せずに、宛先ポッドに直接トラフィックを開始しますが、宛先ポッドのztunnelは、トラフィックを許可するか拒否するかを制御するためにL4ポリシーを適用します。

たとえば、アンビエントモードが有効になっている名前空間で、mTLSモードがSTRICTに設定されたPeerAuthenticationポリシーを設定すると、メッシュ外部からのトラフィックが拒否されます。

サイドカーモードを使用したメッシュ内のポッド

Istioは、同じメッシュ内のサイドカーを持つポッドとアンビエントモードを使用するポッドの間で、東西の相互運用性をサポートします。サイドカープロキシは、宛先がHBONE宛先として検出されたため、HBONEプロトコルを使用することを認識しています。

mTLSモードがSTRICTに設定されたPeerAuthenticationポリシーは、Istioサイドカープロキシを持つポッドからのトラフィックを許可します。

イングレスおよびエグレスゲートウェイとアンビエントモードポッド

イングレスゲートウェイは非アンビエント名前空間で実行でき、アンビエントモード、サイドカーモード、または非メッシュポッドによって提供されるサービスを公開できます。アンビエントモードのポッドとIstioエグレスゲートウェイの間でも相互運用性がサポートされています。

アンビエントモードとサイドカーモードのポッド選択ロジック

Istioの2つのデータプレーンモードであるサイドカーとアンビエントは、同じクラスタ内に共存できます。同じポッドまたは名前空間が両方のモードを使用するように構成されていないことを確認することが重要です。ただし、これが起こった場合、現在、サイドカーモードがそのようなポッドまたは名前空間に対して優先されます。

同じ名前空間内の2つのポッドは、名前空間ラベルとは別に個々のポッドにラベルを付けることで、異なるモードを使用するように設定できる可能性があることに注意してください。ただし、これは推奨されません。最も一般的なユースケースでは、単一の名前空間内のすべてのポッドに対して単一のモードを使用する必要があります。

ポッドがアンビエントモードを使用するように設定されているかどうかを判断するための正確なロジックは次のとおりです。

1. cni.values.excludeNamespacesで構成されたistio-cniプラグイン構成除外リストを使用して、除外リスト内の名前空間をスキップします。

2. ポッドに対してambientモードが使用されるのは、次のいずれかの場合です。

   • 名前空間またはポッドにラベルistio.io/dataplane-mode=ambientがある場合
   • ポッドにオプトアウトラベルistio.io/dataplane-mode=noneがない場合
   • ポッドにアノテーションsidecar.istio.io/statusがない場合

構成の競合を回避する最も簡単なオプションは、ユーザーが各名前空間に対して、サイドカーインジェクションのラベル（istio-injection=enabled）またはアンビエントモードのラベル（istio.io/dataplane-mode=ambient）のいずれかを持っていることを確認することです。両方を同時に使用しないでください。

ラベルリファレンス

次のラベルは、リソースがアンビエントモードでメッシュに含まれるかどうか、ウェイポイントプロキシがリソースのL7ポリシーを適用するために使用されるかどうか、およびトラフィックをウェイポイントに送信する方法を制御します。

istio.io/use-waypointラベルの値を有効にするには、ウェイポイントがトラフィックを処理するリソースタイプに対して構成されていることを確認する必要があります。デフォルトでは、ウェイポイントはサービスへのトラフィックを受け入れます。たとえば、istio.io/use-waypointラベルを介して特定のウェイポイントを使用するようにポッドにラベルを付ける場合、ウェイポイントにはworkloadまたはallの値を持つラベルistio.io./waypoint-forを付ける必要があります。