VPC クラスターのネットワーキングについて

クラスターを作成するときには、特定のクラスター・コンポーネントがお互いに通信し、クラスター外部のネットワークまたはサービスと通信できるように、ネットワークのセットアップを選択する必要があります。

VPC サブネットを使用したワーカー間の通信

初めて VPC クラスターを作成する前に、ワーカーノードを展開する各ゾーンに VPC サブネットを作成しておく必要があります。 VPC サブネットとは、指定したプライベート IP アドレス範囲 (CIDR ブロック) のことであり、ワーカー・ノードとポッドのグループを、物理的に同じ線に接続したかのように構成できるものです。

クラスターを作成するときに、ゾーンごとに既存の VPC サブネットを指定します。 クラスターに追加する各ワーカー・ノードは、そのゾーンの VPC サブネットのプライベート IP アドレスを使用してデプロイされます。 ワーカー・ノードがプロビジョンされた後は、ワーカー・ノードの IP アドレスは reboot 操作を実行しても変わりませんが、replace 操作および update 操作を実行すると変わります。

サブネットは、クラスター内のワーカー・ノード間の接続チャネルとして機能します。 さらに、同じ VPC であれば、どのプライベート・サブネットであろうとプライベート・サブネットに接続したシステムはワーカーと通信できます。 例えば、1 つの VPC 内のすべてのサブネットは、標準装備の VPC ルーターによるレイヤー 3 のプライベートなルーティングを介して通信できます。 複数のクラスターが相互に通信する必要がある場合は、それらのクラスターを同じ VPC 内に作成することができます。 ただし、クラスターが通信する必要がない場合は、別個の VPC にクラスターを作成することで、より優れたネットワーク・セグメンテーションを実現することができます。 また、VPC サブネットのアクセス制御リスト (ACL) を作成して、プライベート・ネットワーク上のトラフィックを調節することもできます。 ACL は、各 VPC サブネットで許可する送受信を定義するインバウンド・ルールとアウトバウンド・ルールで構成されます。

VPC クラスターを作成し、クラスターの作成中にパブリックおよびプライベート両方のクラウド・サービス・エンドポイントを有効にすると、クラスターの Red Hat OpenShift Web コンソールなどのコンポーネントにアクセスするために、パブリッククラウド・サービス・エンドポイントがデフォルトで使用されます。 コンソール・ポッドが、セキュアなパブリック接続をパブリック・サービス・エンドポイント経由でインターネット上で確立するために、ワーカー・ノードのデプロイ先の VPC サブネットごとに、パブリック・ゲートウェイを有効にする必要があります。

VPC クラスターを作成し、クラスターの作成中にプライベートクラウド・サービス・エンドポイントのみを有効にすると、Red Hat OpenShift Web コンソールや OperatorHub などの Red Hat OpenShift コンポーネントにアクセスするために、プライベートクラウド・サービス・エンドポイントがデフォルトで使用されます。 これらのコンポーネントにアクセスしたり、クラスターで kubectl コマンドを実行したりするには、VPN 接続経由などでプライベート VPC ネットワークに接続されている必要があります。

VPC サブネットのデフォルトの IP アドレス範囲は、10.0.0.0 から 10.255.255.255 までです。 VPC ゾーンごとの IP アドレス範囲のリストについては、VPC のデフォルト・アドレス接頭部 を参照してください。

VPC の作成時にクラシック・アクセスを有効にする場合に、クラシック・アクセス用のデフォルトのアドレス接頭部を使用すると、ユーザーが作成するサブネットの IP 範囲が自動的に決定されます。 しかし、クラシック・アクセス VPC のサブネットのデフォルトの IP 範囲は、Red Hat OpenShift on IBM Cloud のコントロール・プレーンのサブネットと競合しています。 その代わりに、 自動で割り当てられるデフォルトのアドレスプレフィックスを含めない状態でVPCを作成し、その後、その範囲内でクラスター用に独自のアドレスプレフィックスとサブネットを作成 する必要があります。

クラスターを作成するときにはカスタム範囲のサブネットを使用しなければなりませんか? カスタム・アドレス接頭部に関するこのガイダンスを確認してください。 ワーカー・ノードにカスタム範囲のサブネットを使用する場合は、ワーカー・ノード・サブネットがクラスターのポッド・サブネットとオーバーラップしないようにしてください。

クラスターの作成時にクラスターに接続したサブネットや、ゾーンにワーカー・ノードを追加するときにクラスターに接続したサブネットは削除しないでください。 クラスターで使用されている VPC サブネットを削除すると、そのサブネットの IP アドレスを使用しているロード・バランサーで問題が発生するだけでなく、ロード・バランサーの新規作成もできなくなる可能性があります。

クラスターの VPC サブネットを作成する際には、以下の機能と制限に留意してください。 VPC サブネットについて詳しくは、VPC のサブネットの特性を参照してください。

  • 各 VPC サブネットのデフォルトの CIDR サイズは /24 であるため、最大 253 台のワーカー・ノードをサポートできます。 1 つのクラスターでゾーンごとに 250 台を超えるワーカー・ノードをデプロイする場合は、より大きなサイズのサブネットを作成することを検討してください。
  • VPC サブネットを作成した後は、そのサイズを変更したり、その IP 範囲を変更したりすることはできません。
  • サブネットは同じ VPC 内の複数のクラスターで共有できます。
  • VPCサブネットは、単一のゾーンまたはリージョンに紐付けられており、複数のゾーンやリージョンにまたがることはできません。
  • サブネットを作成した後、それを別のゾーン、リージョン、または VPC に移動することはできません。
  • ゾーン内の既存のサブネットに接続されているワーカー・ノードがある場合は、クラスター内のそのゾーンのサブネットを変更することはできません。
  • 172.16.0.0/16、172.18.0.0/16、172.19.0.0/16、172.20.0.0/16 の範囲は禁止されています。

仮想プライベート・エンドポイントまたはクラウド・サービス・エンドポイントを使用したワーカーとマスター間およびユーザーとマスター間の通信

Red Hat OpenShift on IBM Cloud さまざまな種類のサービスエンドポイントを使用して、承認されたクラスタユーザーおよびワーカーノードから Kubernetes マスターへの接続を確立します。 許可されたクラスター・ユーザーは、クラウド・サービス・エンドポイントを介して Kubernetes マスターと通信します。 クラスターのバージョンに応じて、ワーカー・ノードは、クラウド・サービス・エンドポイントまたは VPC の仮想プライベート・エンドポイントを介して Kubernetes マスターと通信します。

クラスターを作成する前に、アカウントでサービス・エンドポイントを使用できるようにする必要があります。 サービス・エンドポイントを有効にするには、ibmcloud account update --service-endpoint-enable true を実行します。

Red Hat OpenShift on IBM Cloud の VPC クラスターでは、プライベート・クラウド・サービス・エンドポイントを無効にすることも、パブリック・クラウド・サービス・エンドポイントのみでクラスターをセットアップすることもできません。

デフォルトでは、VPC クラスターにはパブリック・クラウド・サービス・エンドポイントとプライベート・クラウド・サービス・エンドポイントの両方が作成されます。 プライベート・ネットワークにのみ接続されているワーカー・ノードを持つクラスターを作成するには、クラスターの作成時にプライベート・サービス・エンドポイントのみを有効にする必要があります。 パブリック・サービス・エンドポイントは有効化しません。 たとえば、 CLI で プライベートクラウドサービスエンドポイントのみを含む VPC クラスターを作成するには、 --disable-public-service-endpoint オプションを指定します。 このオプションを含めると、デフォルトでは、プライベートネットワーク上でのみアプリケーションを公開するルーターとIngressコントローラーを備えたクラスターが作成されます。 後からアプリをパブリック・ネットワークに公開する必要が生じた場合は、パブリックのルーターと Ingress コントローラーを手動で作成する必要があります。

VPC クラスターでのワーカーとマスター間の通信

ワーカーノードから Kubernetes マスターへの通信では、デフォルトで VPC仮想プライベートエンドポイント（VPE） が使用されます。 クラスタ用のVPEゲートウェイのホスト名は、リージョンに応じて、 CLUSTERID.vpe.private.REGION.containers.cloud.ibm.com または CLUSTERID.private.REGION.containers.cloud.ibm.com のいずれかの形式になります。 ワーカーからマスターへのすべてのトラフィックは、このプライベートVPEゲートウェイを経由してルーティングされます。

VPEゲートウェイへの接続に失敗し、かつクラスターでアウトバウンドトラフィックの保護が無効になっている場合、ワーカーノードはパブリッククラウドサービスのエンドポイントにフォールバックします。 このフォールバックは、VPEゲートウェイに接続できない場合にのみ発生し、通常の動作中には発生しません。 アウトバウンドトラフィックの保護が有効になっている場合、パブリックエンドポイントへのフォールバックは行われません。

パブリックおよびプライベートクラウドサービスのエンドポイントやVPEを介した通信のセキュリティを確保するため、 Red Hat OpenShift on IBM Cloud では、クラスタの作成時に、 Kubernetes のマスターノードとワーカーノード間のKonnectivity接続が自動的に設定されます。 ワーカーノードは TLS 証明書を介してマスターと安全に通信し、マスターはKonnectivity接続を介してワーカーと通信します。

VPC クラスターでのユーザーとマスター間の通信

許可されたクラスター・ユーザーが Kubernetes マスターと通信できるようにするには、パブリックとプライベートのクラウド・サービス・エンドポイントを有効にするか、またはプライベートのクラウド・サービス・エンドポイントのみを有効にします。

  • パブリックおよびプライベートのクラウド・サービス・エンドポイント: デフォルトでは、許可されたクラスター・ユーザーによって開始されたマスターの呼び出しはすべて、パブリックのクラウド・サービス・エンドポイントを介して転送されます。 許可されたクラスター・ユーザーが VPC ネットワーク内にいる場合、または VPC の VPN 接続を介して接続している場合は、プライベート・クラウド・サービス・エンドポイントを介してプライベートにマスターにアクセスできます。
  • プライベートのクラウド・サービス・エンドポイントのみ: プライベートのクラウド・サービス・エンドポイントを介してマスターにアクセスするには、許可されたクラスター・ユーザーが VPC ネットワークの中にいるか、または VPC の VPN 接続を介して接続している必要があります。

コンテキスト・ベースの制限を使用して、クラスタのサービス・エンドポイントへのネットワーク・アクセスを保護できます。 許可リストに登録されたサブネットから送信された、クラスタマスターへの認証済みリクエストのみが、クラスタのサービスエンドポイントを通じて許可されます。 コンテキスト・ベースの制限を使用することで、許可されていないスキャン行為を防ぐことができる。 詳しくは、コンテキスト・ベースの制限を使用する を参照のこと。

他のサービスまたはネットワークへのワーカー通信

ワーカー・ノードが他の IBM Cloud サービス、オンプレミス・ネットワーク、他の VPC、および IBM Cloud クラシック・インフラストラクチャーと安全に通信できるようにします。

プライベート・ネットワークまたはパブリック・ネットワークを介した他の IBM Cloud サービスとの通信

ワーカー・ノードは、プライベート・クラウド・サービス・エンドポイントをサポートしている他の IBM Cloud サービス (IBM Cloud® Container Registry など) とプライベート・ネットワーク経由で自動的かつ安全に通信できます。 プライベート・クラウド・サービス・エンドポイントがサポートされていない IBM Cloud サービスとは、ワーカー・ノードはサブネットのパブリック・ゲートウェイを介してパブリック・ネットワーク経由で安全に通信できます。

VPC サブネットに アクセス制御リスト (ACL) を使用する場合は、ワーカー・ノードが対象のサービスと通信できるように、インバウンド・ルールまたはアウトバウンド・ルールを作成する必要があります。

オンプレミス・データ・センター内にあるリソースとの通信

クラスターをオンプレミスのデータ・センターに接続するには、IBM Cloud® Virtual Private Cloud VPN または IBM Cloud® Direct Link を使用します。

クラスターをオンプレミス・ネットワークに接続する場合は、次の有用な情報を確認してください。

  • IBM 提供のデフォルトのポッドの範囲 172.30.0.0/16 およびサービスの範囲 172.21.0.0/16 とサブネットが競合する可能性があります。 CLI からクラスターを作成する 際、 --pod-subnet オプションでポッド用のカスタムサブネット CIDR を指定し、 --service-subnet オプションでサービス用のカスタムサブネット CIDR を指定することで、サブネットの競合を回避できます。
  • 要求の送信元 IP アドレスが保持される VPN ソリューションを使用する場合は、ワーカー・ノードからオンプレミスのネットワークにクラスターの応答を戻すためのカスタム静的経路を作成できます。
  • 172.16.0.0/16、172.18.0.0/16、172.19.0.0/16、および 172.20.0.0/16 のサブネット範囲は、Red Hat OpenShift on IBM Cloud のコントロール・プレーン機能用に予約されているので使用できないことに注意してください。

他の VPC 内にあるリソースとの通信

同じアカウントで、ある VPC 全体を別の VPC に接続するには、IBM Cloud VPC VPN または IBM Cloud® Transit Gateway を使用します。

  • IBM Cloud VPC VPN を使用するには、まず、VPN を使用して 2 つの VPC を接続する手順に従って、各 VPC のサブネットに VPC ゲートウェイを作成し、2 つの VPC ゲートウェイの間の VPN 接続を作成します。 VPC 内のアクセス制御リスト (ACL) またはセキュリティー・グループをカスタマイズした場合は、それらの ACL およびセキュリティー・グループが、ワーカー・ノードが他の VPC 内のワーカー・ノードと通信できるようにする必要があることに注意してください。
  • IBM Cloud Transit Gateway の概説については、Transit Gateway 資料を参照してください。Transit Gateway インスタンスは、同じリージョンにある VPC 間をルーティングするように構成することも (ローカル・ルーティング)、異なるリージョンにある VPC 間をルーティングするように構成することも (グローバル・ルーティング) できます。

IBM Cloud クラシック・リソースとの通信

クラスターを IBM Cloud クラシック・インフラストラクチャー内のリソースに接続する必要がある場合は、VPC にクラシック・アクセスをセットアップするか、IBM Cloud Transit Gateway を使用します。

  • クラシック・アクセスが可能な VPC にするには、まず、クラシック・インフラストラクチャーへのアクセスのセットアップを参照してください。 VPC の作成時にクラシック・アクセスを有効にする必要があります。また、クラシック・アクセスを使用するように既存の VPC を変換することはできません。 さらに、リージョンごとに 1 つの VPC に対してのみクラシック・インフラストラクチャー・アクセス権限をセットアップできますが、1 つのリージョン内でクラシック・インフラストラクチャー・アクセス権限を持つ複数の VPC をセットアップすることはできません。
  • IBM Cloud Transit Gateway を使用するには、まず、Transit Gateway の資料を参照してください。 複数の VPC をクラシック・インフラストラクチャーに接続することができます。例えば、IBM Cloud Transit Gateway を使用して、複数のリージョンにある VPC の間で、IBM Cloud クラシック・インフラストラクチャーのリソースに対するアクセスを管理することができます。

ワーカー・ノードで実行されるアプリへの外部通信

クラスター外部からワーカー・ノードで実行されるアプリへのプライベート・トラフィック要求またはパブリック・トラフィック要求を許可します。

クラスター・アプリへのプライベート・トラフィック

クラスターにアプリをデプロイするときに、クラスターと同じプライベート・ネットワーク上のユーザーとサービスのみがアプリにアクセスできるようにすることができます。 プライベート・ロード・バランシングは、アプリを一般的に公開することなく、クラスター外からの要求で使用できるようにする場合に理想的です。 プライベート・ロード・バランシングを使用して、アプリのアクセス、要求ルーティング、およびその他の構成をテストしてから、後でパブリック・ネットワーク・サービスを使用してアプリをパブリックに公開することもできます。

クラスター外部からアプリへのプライベート・ネットワーク・トラフィック要求を許可するには、例えば、LoadBalancer サービスを作成して、プライベートな Kubernetes ネットワーク・サービスを使用します。 例えば、クラスター内に Kubernetes LoadBalancer サービスを作成すると、VPC のクラスター外部に VPC ロード・バランサーが自動的に作成されます。 この VPC ロード・バランサーはマルチゾーン対応であり、ワーカー・ノードで自動的に開かれるプライベート NodePort を介してアプリに対する要求を転送します。 VPC ALBとNLBの場合、 kube-lbaas-<cluster-id> という名前の セキュリティグループが ロードバランサーに自動的にアタッチされます。

詳しくは、プライベート外部ロード・バランシングの計画を参照してください。

クラスター・アプリへのパブリック・トラフィック

パブリック・インターネットからアプリにアクセスできるようにするには、パブリック・ネットワーキング・サービスを使用できます。 ワーカー・ノードがプライベート VPC サブネットにしか接続されていなくても、パブリック・ネットワーク・サービス用に作成された VPC ロード・バランサーによって、プライベート・ネットワーク上のアプリにパブリック URL が与えられ、パブリック要求をアプリに転送できるようになります。 公開したアプリのパブリック URL を知っていれば、だれでもアプリに要求を送信できます。

LoadBalancer サービスを作成するなどして、パブリック Kubernetes ネットワーク・サービスを使用できます。 例えば、クラスター内に Kubernetes LoadBalancer サービスを作成すると、VPC のクラスター外部に VPC ロード・バランサーが自動的に作成されます。 この VPC ロード・バランサーはマルチゾーン対応であり、ワーカー・ノードで自動的に開かれるプライベート NodePort を介してアプリに対する要求を転送します。 VPC ALBとNLBの場合、 kube-lbaas-<cluster-id> という名前の セキュリティグループが ロードバランサーに自動的にアタッチされます。

VPC クラスターのネットワーク・セットアップのシナリオ例

クラスター・ネットワークの基本を理解したところで、VPC クラスターの多様なネットワーク・セットアップでワークロードのニーズを満たすシナリオ例をいくつか見ていきましょう。

シナリオ: VPC クラスターでインターネット向けアプリのワークロードを実行する

このシナリオでは、インターネットから要求を送信できる VPC クラスターでワークロードを実行します。 エンド・ユーザーにアプリを利用できるようにしつつ、アプリへの不要なパブリック要求は拒否するように、セキュリティー・グループでパブリック・アクセスを制御します。 また、ワーカーは、プライベート・クラウド・サービス・エンドポイントをサポートしているすべての IBM Cloud サービスに自動的にアクセスできます。

インターネットに公開されるアプリケーション・ワークロードを実行するVPCクラスターのネットワーク設定。
インターネットに公開されるアプリケーション・ワークロードを実行するVPCクラスターのネットワーク設定

ワーカー間通信

このセットアップを実現するには、ワーカー・ノードをデプロイする各ゾーンに VPC サブネットを作成します。 Red Hat OpenShift のデフォルトのコンポーネント (Web コンソールや OperatorHub など) を実行するには、これらのサブネットにパブリック・ゲートウェイが必要です。 次に、これらの VPC サブネットを使用する VPC クラスターを作成します。

ワーカーとマスター間およびユーザーとマスター間の通信

パブリック・ネットワークとプライベート・ネットワークを介して、またはプライベート・ネットワークのみを介して、ワーカーとマスターおよびユーザーとマスターの通信を可能にすることを選択できます。

  • パブリック・サービス・エンドポイントおよびプライベート・クラウド・サービス・エンドポイント: ワーカー・ノードとマスターの通信は、プライベート・クラウド・サービス・エンドポイントを介してプライベート・ネットワーク経由で安全に確立されます。 デフォルトでは、許可されたクラスター・ユーザーによって開始されたすべてのマスター呼び出しは、パブリック・クラウド・サービス・エンドポイントを介して転送されます。
  • プライベート・サービス・エンドポイントのみ: ワーカー・ノードとクラスター・ユーザーからのマスターへの通信はどちらもプライベート・クラウド・サービス・エンドポイントを介してプライベート・ネットワーク経由で確立されます。 クラスター・ユーザーは、VPC ネットワーク内にいるか、または VPC の VPN 接続を介して接続する必要があります。

他のサービスまたはネットワークへのワーカー通信

アプリのワークロードに他の IBM Cloud サービスが必要な場合、プライベート・クラウド・サービス・エンドポイントをサポートしている IBM Cloud サービスとワーカー・ノードは、プライベート VPC ネットワーク経由で自動的かつ安全に通信できます。

ワーカー・ノードで実行されるアプリへの外部通信

アプリをテストした後、パブリック Kubernetes LoadBalancer サービスを作成するか、デフォルトのパブリック Ingress アプリケーション・ロード・バランサー (ALB) を使用して、アプリをインターネットに公開できます。 これらのサービスを使用する場合に VPC のクラスター外部に自動的に作成される VPC ロード・バランサーによって、トラフィックがアプリに転送されます。 VPC ALB に自動的に適用される kube-lbaas-<cluster-id> セキュリティー・グループを、自分が作成および管理するセキュリティー・グループに置き換えることで、クラスターのセキュリティーを向上させ、アプリへのパブリック・ネットワーク・トラフィックを制御できます。 ALB に適用すると、どのインバウンド・トラフィックが ALB を介してクラスターに許可されるかがセキュリティー・グループによって制御されます。

このシナリオ用のクラスターを使用して始めましょう。 高可用性 セットアップを計画したら、VPCクラスタの作成 を参照してください。

オンプレミス・データ・センターを VPC クラスターに拡張

このシナリオでは、VPC クラスターでワークロードを実行します。 ただし、それらのワークロードを、オンプレミスのデータ・センター内のプライベート・ネットワークにあるサービス、データベース、またはその他のリソースからのみアクセスできるようにする必要があります。 クラスター・ワークロードは、プライベート・ネットワークを介した通信をサポートする他のいくつかの IBM Cloud サービスにアクセスする必要がある場合があります。

オンプレミスデータセンターを拡張するVPCクラスターのネットワーク設定。
オンプレミスデータセンターを拡張するVPCクラスターのネットワーク設定

ワーカー間通信

このセットアップを実現するには、ワーカー・ノードをデプロイする各ゾーンに VPC サブネットを作成します。 Red Hat OpenShift のデフォルトのコンポーネント (Web コンソールや OperatorHub など) を実行するには、これらのサブネットにパブリック・ゲートウェイが必要です。 次に、これらの VPC サブネットを使用する VPC クラスターを作成します。

ワーカー・ノード、ポッド、およびサービスのデフォルト範囲と、オンプレミス・ネットワーク内のサブネットの間に、サブネットの競合がある可能性があることに注意してください。 VPC サブネットを作成するときに、カスタムのアドレス接頭部を選択し、それらのサブネットを使用してクラスターを作成することができます。 さらに、クラスターを作成する際に、 ibmcloud oc cluster create コマンドで --pod-subnet および --service-subnet オプションを使用することで、ポッドやサービスに対してカスタムサブネットの CIDR を指定することができます。

ワーカーとマスター間およびユーザーとマスター間の通信

クラスターを作成するときには、プライベート・クラウド・サービス・エンドポイントのみを有効にして、プライベート・ネットワークを介したワーカーとマスターの間の通信とユーザーとマスターの間の通信を許可します。 クラスター・ユーザーは、VPC ネットワーク内にいるか、または VPC の VPN 接続を介して接続する必要があります。

他のサービスまたはネットワークへのワーカー通信

クラスターをオンプレミスのデータ・センターに接続するために、VPC の VPN サービスをセットアップします。 IBM Cloud VPC の VPN は、VPC 全体をオンプレミス・データ・センターに接続します。 プライベート・クラウド・サービス・エンドポイントをサポートしている他の IBM Cloud サービスがアプリのワークロードに必要な場合、それらのサービスとワーカー・ノードは、プライベート VPC ネットワーク経由で自動的かつ安全に通信できます。

ワーカー・ノードで実行されるアプリへの外部通信

アプリをテストした後、プライベート Kubernetes LoadBalancer サービスを作成するか、デフォルトのプライベート Ingress アプリケーション・ロード・バランサー (ALB) を使用して、アプリをプライベート・ネットワークに公開できます。 これらのサービスを使用する場合に VPC のクラスター外部に自動的に作成される VPC ロード・バランサーによって、トラフィックがアプリに転送されます。 この VPC ロード・バランサーはアプリをプライベート・ネットワークにのみ公開するので、VPC サブネットに接続できるオンプレミスのシステムがアプリにアクセスできるようになることに注意してください。 クラスターのデフォルトの VPC セキュリティー・グループを変更して、クラスターのセキュリティーを向上させ、パブリック・トラフィック・アプリを制御することができます。 セキュリティー・グループは、ワーカー・ノードに許可するインバウンド・トラフィックを定義するルールで構成されます。

このシナリオ用のクラスターを使用して始めましょう。 高可用性 セットアップを計画したら、VPCクラスタの作成 を参照してください。

次のステップ

計画プロセスを続行するには、暗号化 のレベルを決定することによってクラスタ内の機密情報を保護する方法について学びます。 ネットワークの設定を始める準備ができたら、Secure by Default Cluster VPC Networking を理解する に進んでください。