VPC クラスターのネットワーキングについて
クラスターを作成するときには、特定のクラスター・コンポーネントがお互いに通信し、クラスター外部のネットワークまたはサービスと通信できるように、ネットワークのセットアップを選択する必要があります。
- ワーカー間通信: すべてのワーカー・ノードが VPC サブネットを介してプライベート・ネットワークで相互に通信できる必要があります。
- ワーカーとマスターの間およびユーザーとマスターの間の通信: ワーカー・ノードと許可されたクラスター・ユーザーは、仮想プライベート・エンドポイントまたはクラウド・サービス・エンドポイントを介して Kubernetes マスターと安全に通信できます。
- 他のサービスまたはネットワークへのワーカー通信: ワーカー・ノードが、IBM Cloud などの他の IBM Cloud® Container Registry サービスや、オンプレミス・ネットワーク、他の 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 マスターへのワーカー・ノードの通信は、クラスターのバージョンに応じて異なる方法で確立されます。
- Kubernetes マスターへのワーカー・ノード通信は、 VPC 仮想プライベート・エンドポイント(VPE) を介して確立されます。 パブリック・クラウド・サービス・エンドポイントも有効にした場合は、パブリック・ネットワークまたはプライベート・ネットワークの障害から保護するために、パブリック・エンドポイントと VPE を半分ずつ使用してワーカーからマスターへのトラフィックが確立されます。
パブリックおよびプライベート・クラウド・サービスのエンドポイントまたは VPE を介した通信を保護するために、 Red Hat OpenShift on IBM Cloud は、クラスタの作成時に Kubernetes マスターノードとワーカーノードの間に Konnectivity 接続を自動的に設定します。 ワーカーノードはTLS証明書を通してマスターと安全に会話し、マスターはコネクティビティ接続を通してワーカーと会話する。
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 を使用します。
- 仮想プライベート・クラウド VPN を使用するには、まず、オンプレミスの VPN ゲートウェイを構成する方法と VPC に VPN ゲートウェイを作成し、VPC の VPN ゲートウェイとローカルの VPN ゲートウェイの間の接続を作成する方法を参照してください。 マルチゾーン・クラスターの場合は、ワーカー・ノードが存在するすべてのゾーンのサブネットに VPC ゲートウェイを作成する必要があります。
- Direct Link を使用するには、まず、IBM Cloud Direct Link Dedicated の注文を参照してください。 手順 8 で、Direct Link ゲートウェイに接続する VPC へのネットワーク接続を作成できます。
クラスターをオンプレミス・ネットワークに接続する場合は、次の有用な情報を確認してください。
- 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 の場合、kube-<vpc-id>
の形式で指定されたセキュリティー・グループが自動的に
ALB インスタンスに接続されます。
VPC ALB に接続されている kube-<vpc-id>
セキュリティー・グループは、Kubernetes マスターと通信するプライベート VPE ゲートウェイに使用されるものと同じセキュリティー・グループです。 このセキュリティ・グループを変更すると、クラスタと Kubernetes マスター間のネットワーク接続が中断される可能性があるため、変更しないでください。 代わりに、VPC ALB からセキュリティー・グループを削除し、自分が作成および管理する
セキュリティー・グループに置き換えることができます。
詳しくは、プライベート外部ロード・バランシングの計画を参照してください。
クラスター・アプリへのパブリック・トラフィック
パブリック・インターネットからアプリにアクセスできるようにするには、パブリック・ネットワーキング・サービスを使用できます。 ワーカー・ノードがプライベート VPC サブネットにしか接続されていなくても、パブリック・ネットワーク・サービス用に作成された VPC ロード・バランサーによって、プライベート・ネットワーク上のアプリにパブリック URL が与えられ、パブリック要求をアプリに転送できるようになります。 公開したアプリのパブリック URL を知っていれば、だれでもアプリに要求を送信できます。
LoadBalancer
サービスを作成するなどして、パブリック Kubernetes ネットワーク・サービスを使用できます。 例えば、クラスター内に Kubernetes LoadBalancer
サービスを作成すると、VPC のクラスター外部に VPC ロード・バランサーが自動的に作成されます。 この VPC
ロード・バランサーはマルチゾーン対応であり、ワーカー・ノードで自動的に開かれるプライベート NodePort を介してアプリに対する要求を転送します。 VPC ALB の場合、kube-<vpc-id>
の形式で指定されたセキュリティー・グループが自動的に ALB インスタンスに接続されます。
VPC ALB に接続されている kube-<vpc-id>
セキュリティー・グループは、Kubernetes マスターと通信するプライベート VPE ゲートウェイに使用されるものと同じセキュリティー・グループです。 このセキュリティ・グループを変更すると、クラスタと Kubernetes マスター間のネットワーク接続が中断される可能性があるため、変更しないでください。 代わりに、VPC ALB からセキュリティー・グループを削除し、自分が作成および管理する
セキュリティー・グループに置き換えることができます。
VPC クラスターのネットワーク・セットアップのシナリオ例
クラスター・ネットワークの基本を理解したところで、VPC クラスターの多様なネットワーク・セットアップでワークロードのニーズを満たすシナリオ例をいくつか見ていきましょう。
シナリオ: VPC クラスターでインターネット向けアプリのワークロードを実行する
このシナリオでは、インターネットから要求を送信できる VPC クラスターでワークロードを実行します。 エンド・ユーザーにアプリを利用できるようにしつつ、アプリへの不要なパブリック要求は拒否するように、セキュリティー・グループでパブリック・アクセスを制御します。 また、ワーカーは、プライベート・クラウド・サービス・エンドポイントをサポートしているすべての IBM Cloud サービスに自動的にアクセスできます。
ワーカー間通信
このセットアップを実現するには、ワーカー・ノードをデプロイする各ゾーンに 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-<vpc-id>
セキュリティー・グループを、自分が作成および管理するセキュリティー・グループに置き換えることで、クラスターのセキュリティーを向上させ、アプリへのパブリック・ネットワーク・トラフィックを制御できます。 ALB に適用すると、どのインバウンド・トラフィックが ALB を介してクラスターに許可されるかがセキュリティー・グループによって制御されます。
このシナリオ用のクラスターを使用して始めましょう。 高可用性 セットアップを計画したら、VPCクラスタの作成 を参照してください。
オンプレミス・データ・センターを VPC クラスターに拡張
このシナリオでは、VPC クラスターでワークロードを実行します。 ただし、それらのワークロードを、オンプレミスのデータ・センター内のプライベート・ネットワークにあるサービス、データベース、またはその他のリソースからのみアクセスできるようにする必要があります。 クラスター・ワークロードは、プライベート・ネットワークを介した通信をサポートする他のいくつかの IBM Cloud サービスにアクセスする必要がある場合があります。
ワーカー間通信
このセットアップを実現するには、ワーカー・ノードをデプロイする各ゾーンに 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 を理解する に進んでください。