次の方法で共有

Azure Red Hat OpenShift のネットワーク トポロジと接続性に関する考慮事項

  • [アーティクル]

Azure Red Hat OpenShift ランディング ゾーン アクセラレータを使用する際のネットワーク トポロジと接続性に関する設計上の考慮事項と推奨事項について説明します。

設計上の考慮事項

  • Azure Red Hat OpenShift には、プライマリ サブネットとセカンダリ サブネットが必要です。

    • プライマリ サブネットを使用して、クラスターのマスター ノードをデプロイします。
    • セカンダリ サブネットを使用して、クラスターのワーカー ノードをデプロイします。
    • セカンダリ サブネットとプライマリ サブネットの両方が最小 /27 ルートである必要があります。
    • クラスターをデプロイした後に、セカンダリ サブネットまたはプライマリ サブネットを変更することはできません。
    • プライマリ サブネットとセカンダリ サブネットには、ネットワーク セキュリティ グループを関連付けることはできません。 Azure Red Hat OpenShift クラスターでは、ネットワーク セキュリティ グループが自動的に作成および管理されます。
    • セカンダリ サブネットとプライマリ サブネットは、オンプレミス ネットワークや Azure 内の他のネットワークと重複することはできません。

  • クラスターのスケーリングをサポートするために、IP アドレスと仮想ネットワーク サブネットのサイズを慎重に計画します。 ノードを追加することが必要な場合があります。

  • パブリックまたは内部のロード バランサーを使用して、Azure Red Hat OpenShift のサービスとルートを公開できます。 セカンダリ ノードと同じサブネットに内部ロード バランサーを設定します。 制限付きエグレス クラスターでは、非対称ルーティングが原因でパブリック ロード バランサーを使用できません。

  • Azure Red Hat OpenShift では CoreDNS を使用して、クラスターで実行されているポッドに名前解決が提供されます。

    • CoreDNS により、クラスター内部ドメインが直接解決されます。
    • Azure Red Hat OpenShift では、仮想ネットワーク内のカスタム DNS サーバーもサポートされています。
    • その他のドメインは、Azure Virtual Network で構成した DNS サーバーに転送されます。 DNS サーバーは、既定の Azure DNS リゾルバーか、仮想ネットワーク レベルで設定する任意のカスタム DNS サーバーです。
    • Azure Red Hat OpenShift CoreDNS で DNS 転送をカスタマイズできます。
    • 仮想ネットワークにカスタム DNS サーバーが構成されていない場合、Azure Red Hat OpenShift では既定の Azure DNS リゾルバーが使用されます。

    DNS の詳細については、「Azure プライベート エンドポイントの DNS 構成」を参照してください。

  • 送信 (エグレス) ネットワーク トラフィックは、Azure Firewall またはネットワーク仮想アプライアンス クラスター経由で送信できます。

  • 既定では、Azure Red Hat OpenShift クラスター内のすべてのポッドは制限なしにトラフィックを送受信できます。 プロジェクト内のすべてのポッドには、他のポッドとネットワーク エンドポイントからアクセスできます。 プロジェクト内の 1 つ以上のポッドを分離するには、プロジェクト内に NetworkPolicy オブジェクトを作成して、許可されている受信接続を示すことができます。 Red Hat OpenShift ソフトウェア定義ネットワーク (SDN) では、既定のネットワーク分離モードでのネットワーク ポリシーの使用がサポートされています。

  • サービス メッシュには、トラフィック管理、回復性、ポリシー、セキュリティ、強力な ID、可観測性などの機能が備えられています。 Red Hat OpenShift Service Mesh の詳細については、Service Mesh と Istio の相違点に関するページをご覧ください。

  • Azure Traffic Manager や Azure Front Door などのグローバル負荷分散メカニズムでは、異なる Azure リージョンにある可能性がある複数のクラスター間でトラフィックをルーティングすることによって、回復性を高めています。

プライベート クラスター

Azure Red Hat OpenShift API クラスターの IP アドレスは、パブリックまたはプライベートにすることができます。 プライベート クラスターでは、プライベート IP アドレス経由で Azure Red Hat OpenShift API が公開されますが、パブリック IP アドレス経由では公開されません。 Azure Red Hat OpenShift API には、その IP アドレスを使用してアクセスしないでください。 代わりに、完全修飾ドメイン名 (FQDN) を使用して Azure Red Hat OpenShift API にアクセスします。 Azure DNS は、Azure Red Hat OpenShift API FQDN をその IP アドレスに解決します。

Azure ランディング ゾーンの実証済みプラクティスに従って、Azure ワークロードの DNS 解決は、接続サブスクリプションにデプロイされている一元化された DNS サーバーによって提供されます。 Azure DNS サーバーは、ハブ仮想ネットワークか、Azure Virtual WAN に接続されている共有サービス仮想ネットワーク内のいずれかにあります。 DNS サーバーにより、Azure DNS を使用して Azure 固有の名前とパブリック名 (IP アドレス 168.63.129.16) が条件付きで解決されます。 サーバーは、企業の DNS サーバーを使用してプライベート名を解決します。 この接続モデルは一般的であり、プライベート エンドポイントを使用する場合は、他の Azure リソースへのプライベート アクセスを許可することが重要です。

プライベート クラスターのネットワークを示す図。

アプリケーション ユーザーからクラスターへのトラフィック

受信 (イングレス) コントローラーを使用して、Azure Red Hat OpenShift クラスターで実行されているアプリケーションを公開します。

  • イングレス コントローラーでは、複雑さがわずかに増加するだけで、アプリケーションレベルのルーティングが提供されます。
  • Azure Red Hat OpenShift では、クラスター内で公開されているアプリケーションへのアクセスを簡略化する汎用 DNS エントリが作成されます。 DNS エントリは、例えば *.apps.<cluster-ID>.<region>.aroapp.io のように表記されます。 プライベート クラスターでは、アプリケーションのトラフィックをルーティングすると便利です。
  • Azure Red Hat OpenShift には、組み込みのイングレス コントローラーとルートが用意されています。
  • Azure Front Door で Azure Red Hat OpenShift イングレスを使用できます。
  • 構成をエグレス フィルター処理設計に合わせて、非対称ルーティングを回避します。 UDR によって非対称ルーティングが発生する場合があります。
  • シナリオで TLS 終端が必要な場合は、TLS 証明書を管理する方法を検討します。

重要

Azure Firewall を使用してエグレス トラフィックを制限し、すべてのエグレス トラフィックを強制する UDR を作成するときは、イングレス トラフィックを正しく許可するために、Azure Firewall で適切な 宛先ネットワーク アドレス変換 (DNAT) 規則を作成する必要があります。 UDR で Azure Firewall を使用すると、非対称ルーティングによってイングレス設定が機能しなくなります Azure Red Hat OpenShift サブネットにファイアウォールのプライベート IP アドレスに送信される既定のルートがあるのに、パブリック ロード バランサー (種類が Load Balancer であるイングレスまたは Kubernetes サービス) を使用している場合、この問題が発生します。 この場合、ロード バランサーの受信トラフィックはパブリック IP アドレス経由で受信されますが、復路のパスはファイアウォールのプライベート IP アドレスを通過します。 ファイアウォールはステートフルであり、確立済みのセッションを検出しないため、返されるパケットは破棄されます。 Azure Firewall をイングレスまたはサービスのロード バランサーと統合する方法については、「Azure Firewall と Azure Standard Load Balancer を統合する」を参照してください。

次の手順では、Azure Red Hat OpenShift プライベート クラスターとイングレス コントローラーで Azure Front Door を使用する場合のフローについて説明します。

  1. パブリック インターネットからのクライアントでは、Azure Front Door を指すアプリケーションの DNS 名が解決されます。
  2. Azure Front Door では、Azure Private Link サービスを使用して、Azure 内部ネットワーク ロード バランサーのプライベート IP アドレスにアクセスし、Azure Red Hat OpenShift イングレス コントローラー内のアプリケーションにアクセスします。

この手順では、Azure Red Hat OpenShift プライベート クラスターにアクセスする Web 以外のアプリケーションのフローについて説明します。

  1. パブリック インターネットからのクライアントは、Azure Firewall またはネットワーク仮想アプライアンスのパブリック IP アドレスを指すアプリケーションの DNS 名を解決します。
  2. Azure Firewall またはネットワーク仮想アプライアンスは、Azure 内部ネットワーク ロード バランサーのプライベート IP アドレスを使用して Azure Red Hat OpenShift イングレス コントローラー内のアプリケーションにアクセスすることで、トラフィック (DNAT) を Azure Red Hat OpenShift プライベート クラスターに転送します。

Azure Red Hat OpenShift ポッドからバックエンド サービスへのトラフィック

Azure Red Hat OpenShift クラスター内で実行されているポッドは、Azure Storage、Azure Key Vault、Azure SQL Database、Azure Cosmos DB などのバックエンド サービスにアクセスすることが必要になる場合があります。 仮想ネットワーク サービス エンドポイントと Azure Private Link を使用して、これらの Azure マネージド サービスへの接続をセキュリティで保護できます。

バックエンド トラフィックに Azure プライベート エンドポイントを使用している場合は、Azure サービスの DNS 解決に Azure プライベート DNS ゾーンを使用できます。 環境全体の DNS リゾルバーはハブ仮想ネットワーク (または、Virtual WAN 接続モデルを使用している場合は共有サービス仮想ネットワーク) 内にあるため、これらのプライベート ゾーンは接続サブスクリプションに作成します。 プライベート サービスの FQDN を解決するために必要な A レコードを作成するには、接続サブスクリプション内のプライベート DNS ゾーンをアプリケーション サブスクリプション内のプライベート エンドポイントに関連付けることができます。 この操作では、それらのサブスクリプションで特定のアクセス許可が必要です。

A レコードを手動で作成することはできますが、プライベート DNS ゾーンをプライベート エンドポイントに関連付けると、セットアップで誤った構成になる可能性が低くなります。

プライベート エンドポイント経由で公開される Azure Red Hat OpenShift ポッドから Azure サービスとしての Azure プラットフォーム (PaaS) サービスへのバックエンド接続は、次の手順に従います。

  1. Azure Red Hat OpenShift ポッドでは、Azure Red Hat OpenShift 仮想ネットワークでカスタム DNS サーバーとして定義されている接続サブスクリプション内の中央 DNS サーバーを使用して、Azure PaaS の FQDN が解決されます。
  2. 解決された IP アドレスは、プライベート エンドポイントのプライベート IP アドレスであり、Azure Red Hat OpenShift ポッドから直接アクセスされます。

Azure Red Hat OpenShift クラスターが Azure Firewall によるエグレス フィルター処理用に構成されている場合でも、Azure Red Hat OpenShift ポッドとプライベート エンドポイント間のトラフィックは、既定ではハブ仮想ネットワーク (または Virtual WAN を使用する場合はセキュリティで保護された仮想ハブ) 内の Azure Firewall インスタンスを通過しません。 プライベート エンドポイントによって、Azure Red Hat OpenShift がデプロイされているアプリケーション仮想ネットワークのサブネットに /32 ルートが作成されます。

設計の推奨事項

  • セキュリティ ポリシーにより、Azure Red Hat OpenShift API のプライベート IP アドレスを使用する必要がある場合は、プライベート Azure Red Hat OpenShift クラスターをデプロイします。
  • Azure Red Hat OpenShift クラスターで使用する仮想ネットワークを保護するには、一元化されたサブスクリプションで Azure Firewall または Web アプリケーション ファイアウォールを使用する場合を除き、Azure DDoS Protection を使用します。
  • Azure Virtual WAN またはハブ アンド スポーク アーキテクチャ、Azure DNS ゾーン、独自の DNS インフラストラクチャによる全体的なネットワーク設定にリンクされた DNS 構成を使用します。
  • Azure Private Link を使用してネットワーク接続をセキュリティで保護し、Private Link をサポートする他のマネージド Azure サービス (Azure Storage、Azure Container Registry、Azure SQL Database、Azure Key Vault など) にプライベート IP ベースの接続を使用します。
  • イングレス コントローラーを使用して、高度な HTTP ルーティングとセキュリティを提供し、アプリケーションに単一のエンドポイントを提供します。
  • イングレスを使用するように構成した Web アプリケーションは、すべて TLS 暗号化を使用する必要があります。暗号化されていない HTTP を使用したアクセスは許可しないようにしてください。
  • Azure Front Door と Web アプリケーション ファイアウォールを使用して、Azure Red Hat OpenShift アプリケーションをインターネットに安全に発行します。
  • Azure Red Hat OpenShift クラスターで生成されるすべての送信インターネット トラフィックの検査がセキュリティ ポリシーによって求められる場合は、Azure Firewall、またはマネージド ハブ仮想ネットワークにデプロイされているサードパーティのネットワーク仮想アプライアンスを使用して、エグレス ネットワーク トラフィックをセキュリティ保護します。 詳細については、Azure Red Hat OpenShift クラスターへのエグレス トラフィックの制御に関するページを参照してください。
  • Web 以外のアプリケーションには、Azure Load Balancer の Basic レベルではなく、Standard レベルを使用します。

次の手順