編集

次の方法で共有


Azure Kubernetes Service でデュアル スタック ネットワーク トラフィックを有効にする

Azure Kubernetes Service (AKS)
Azure Load Balancer
Azure Virtual Network
Azure Container Registry

このベースライン インフラストラクチャの例では、IPv4 と IPv6 の両方のアドレスを使用して、デュアル スタック ネットワーク上の複数のリージョンに Azure Kubernetes Service (AKS) クラスターをデプロイします。

アーキテクチャ

図は、IPv4 および IPv6 トラフィックを使用したデュアルスタック構成を示しています。

このアーキテクチャの Visio ファイルをダウンロードします。

データフロー

この例では、イングレス コントローラーの NAT64 プロキシを使用して、外部トラフィックを IPv4 または IPv6 に変換します。 これは、最小限の変更で既存のインフラストラクチャに対して追加や削除を行うことができます。 変更する必要があるのは 1 つのイングレスのみです。

クライアントは、サービスへの接続を確立すると、最も近い DNS サーバーからサービス IP アドレスを取得します。 AAAA レコードから IPv6 値を、ドメイン名の A レコードから IPv4 値を取得します。 インターネットのクライアントの場合、最も近い DNS サーバーに、グローバル DNS サーバーを指定できます。 カスタム DNS 解決ルールを使用する Azure 仮想ネットワーク内のクライアントの場合、最も近いサーバーに Azure プライベート DNS サーバーを指定できます。

このアーキテクチャ例には、次の 2 つのオプションがあります。

  • IPv4 を実行する AKS サービス
  • IPv6 を実行する AKS サービス

IPv4 を実行する AKS サービス

  • IPv4 トラフィック (黒線): Azure Load Balancer は、次のように IPv4 トラフィックを仮想ネットワーク内の対応するサービスに転送します。

    1. パブリック インターネットまたは外部ネットワークからのトラフィックが、Azure Load Balancer 上の IPv4 に到達します。

    2. ロード バランサーが、IPv4 トラフィック専用の AKS イングレスにトラフィックを転送します。

    3. AKS イングレスが、Kubernetes サービスにトラフィックを転送するためのリバース プロキシとして機能します。

    4. 各 Kubernetes サービスが、そのアプリケーションにトラフィックを分散します。

    5. アプリケーションは、Azure インフラストラクチャ内の Azure ストレージ サービスとの間でデータを安全に格納および取得できます。

    6. Azure Container Registry により、アプリケーション イメージをすばやく安全に配信できます。

  • IPv6 トラフィック (オレンジ色の回線): Load Balancer は、次のように IPv6 トラフィックを転送します。

    1a. IPv6 が、Load Balancer 上の IPv6 オプションに到達します。

    1b. ロード バランサーが IPv6 イングレスにトラフィックを転送し、そこで NAT64 プロキシがそのアドレスを変換します。 この変換には Nginx のようなサーバーを使用できます。

    1c. IPv6 イングレスが、トラフィックを IPv4 アドレスに転送します。 これは、IPv6 ソース アドレスを含みますが、より多くのメタデータがある IPv4 トラフィックになっています。

    2-6. 2 から 6 までのデータフローは、IPv4 データフローと同じです。

IPv6 を実行する AKS サービス

別の方法として、AKS メイン トラフィックを IPv6 上で実行でき、IPv4 イングレスが NAT46 プロキシとして機能します。

Components

例は、次のコンポーネントで構成されています。

  • デュアル スタック Azure Kubernetes Service (AKS) は、Azure クラウドでホストされているマネージド Kubernetes クラスターです。 Azure は Kubernetes API サービスを管理します。 ユーザーは、エージェント ノードを管理するだけです。 デュアル スタック AKS は、デュアル スタック Azure Virtual Network で実行する必要があります。

  • デュアル スタック Azure Virtual Network は、Azure インフラストラクチャ上に高度にセキュリティで保護された仮想ネットワーク環境を提供します。 既定では、Azure Virtual Network で IPv4 のみをサポートします。 デプロイ プロセス中に IPv6 を有効にします。

  • Azure ネットワーク セキュリティ グループは、Azure 仮想ネットワーク内の Azure リソース間のトラフィックをフィルター処理します。

  • Azure DNS ゾーンは、クライアントに対してドメイン名解決サービスを提供します。 IPv4 と IPv6 のクライアントはどちらも、違いに気付くことなく同じドメイン名に接続できます。

  • Azure Load BalancerAzure ネットワーク インターフェイスは、Kubernetes のイングレスがデプロイされた後、AKS によって自動的に作成されます。

  • Azure Container Registry には、AKS クラスターで実行できるプライベート コンテナー イメージが格納されます。

  • Azure Key Vault では、AKS サービスのセキュリティ キーを格納および管理します。

代替

もう 1 つの方法は、各機能サービスを分離することです。 IPv6 イングレスをリッスンする AKS サービスを 1 つと、IPv4 イングレスをリッスンする AKS サービスを 1 つ使用します。 この方法は、IPv6 トラフィックの NAT64 ホップを回避するのに役立ち、その逆も同様です。

この方法は、より優れたパフォーマンスを提供する自然な Kubernetes アプローチに似ています。 ただし、多数のサービスを含むマイクロサービス アーキテクチャでこのアプローチを使用する場合、各サービスが重複するため、適切なコード メンテナンスはサポートされません。 メインの方法では、永続的な接続を使用してパフォーマンス ヒットを分散させることができます。

AKS がサービス 層でのデュアル スタックデプロイを完全にサポートできるとき、メインの方法では IPv6 イングレスのみを再マップできますが、代替の方法ではより多くのメンテナンスが必要です。

シナリオの詳細

IPv4 アドレスの枯渇により、IPv6 が 1995 年に導入され、2017 年にインターネットの標準になりました。 米国内のトラフィックの 50% 以上が IPv6 経由であると推定されています。 IPv4 と IPv6 のプロトコルには互換性がありません。 インフラストラクチャは、IPv4 ネットワークと IPv6 ネットワークのいずれかで実行されます。 このワークロード例では、Azure Kubernetes Service でデュアル スタック ネットワークを実行するためのいくつかの構成について説明します。 詳細については、デュアルスタック kubenet ネットワークに関するページを参照してください。

現在の制限により、トラフィックは処理前に、同じ IP バージョンにプロキシ処理する必要があります。 イングレスを externalTrafficPolicy: Local として構成します。 制限に対応したら、モード RequireDualStack または PreferDualStack を使用する AKS サービスを作成できます。 Kubernetes サービスはそれぞれ、デュアル スタック トラフィックを処理できます。

Azure Application Gateway がデュアルスタック ネットワークをサポートすると、HTTP クライアントで標準ロード バランサーの代わりにそれを使用できます。 この構成は、ゲートウェイの Azure Web Application Firewall を利用して、デプロイを簡略化します。

この記事では、ネットワーク インフラストラクチャのデュアル スタック IP アドレスを有効にすることに焦点をあてています。 AKS インフラストラクチャの開始点である AKS ベースライン アーキテクチャについて理解を深めておく必要があります。 AKS ベースラインでは、Microsoft Entra ワークロード ID、イングレスとエグレスの制限、リソース制限、その他のセキュリティで保護された AKS インフラストラクチャ構成などの機能が記述されています。

考えられるユース ケース

IPv6 を使用すると、ノード間の直接アドレス指定が可能になり、接続性が向上し、接続を管理しやすくなり、ルーティングのオーバーヘッドが軽減されます。 これらの機能は、次の業界でモノのインターネットを有効にするのに便利です。

  • 自動車
  • エネルギー
  • 医療
  • 製造
  • 遠距離通信

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

[信頼性]

システムの "信頼性" とは、システムの可用性を確保しながら障害から復旧する機能です。

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。

可用性ゾーン全体にわたって AKS をデプロイすることを検討してください。 このアプローチは、計画メンテナンス イベントや計画外の停止からアプリケーションを保護するのに役立ちます。

Azure には、サポートされているリージョンごとに 3 つの可用性ゾーンが用意されています。 少なくともその 2 つで AKS を実行してください。 各アプリケーションにゾーン全体で少なくとも 2 つのポッドがある場合、この解決策では、一方のゾーンがオフラインの場合でも、他方のゾーンが中断することなくエンド ユーザーにサービスを提供することを保証します。

回復性を向上させたい場合は、複数リージョンの AKS を検討してください。各リージョンではデュアル スタック ネットワークもサポートされます。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

Azure には、ビルドから AKS を実行するアプリケーション ワークロードまでのエンドツーエンドのセキュリティ パイプラインが用意されています。

Azure FirewallAzure ネットワーク セキュリティ グループAzure Web Application Firewall を使用して、ネットワーク レイヤー全体にわたるネットワーク セキュリティを強化することもできます。

コスト最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、 コスト最適化の柱の概要 に関する記事をご覧ください。

コストの見積もりには、Azure 料金計算ツールをご利用ください。

デュアル スタック ネットワークを備えたこの AKS アーキテクチャは、既存のインフラストラクチャへの IPv6 トラフィックを処理するコストを吸収するのに役立ちます。 現在の構成を変更することなく、同じ AKS に IPv6 イングレスをデプロイできます。 IPv6 トラフィック ハンドラーに対する追加支払いはありません。 この方法は、ワークロードが複数の可用性ゾーンまたは複数のリージョンで実行されるときに大きな効果があります。

オペレーショナル エクセレンス

オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスの重要な要素の概要」を参照してください。

オペレーショナル エクセレンスの重要な要素のガイダンスに従うこの解決策は、既存のシステムへのプラグインとしても機能します。 この解決策を追加すると、既存のシステムに影響を与えることなく IPv6 トラフィックをサポートしたり、無効にしたりできます。 AKS の既存のメカニズムを使用して、追加のインフラストラクチャ コンポーネントを管理することなくこの解決策を監視することもできます。

パフォーマンス効率

パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。

この解決策には、次の 2 つのパフォーマンス上の利点があります。

  • IPv6 トラフィックと IPv4 トラフィックが、同じコンピューティング リソースを共有します。 リソースの再利用により、IPv6 リソースと IPv4 リソースを別個に処理せずに、コンピューティング リソースをスケーリングできます。
  • IPv6 と IPv4 のイングレスは独立してスケーリングできるため、パフォーマンスが最大化されます。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

Andy Nguyen | シニア ソフトウェア エンジニア

その他の共同作成者:

Senthil Chandran | プリンシパル ソフトウェア エンジニアリング マネージャー

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ