ワーカー・ノード用の VLAN 接続

ワーカー・ノード間で情報を送受信できるように、すべてのワーカー・ノードをプライベート VLAN に接続する必要があります。 ワーカー・ノードおよびプライベート・アプリ・サービスにプライベート IP アドレスを割り当てるために使用されるプライベート・サブネットは、そのプライベート VLAN から取得されます。 パブリック VLAN にも接続するワーカー・ノードのクラスターを作成することができます。 ワーカー・ノードおよびパブリック・アプリ・サービスにパブリック IP アドレスを割り当てるために使用されるパブリック・サブネットは、パブリック VLAN から取得されます。 しかし、パブリックネットワークインターフェースからアプリケーションを保護する必要がある場合は 、 Calico ネットワークポリシー を作成したり、外部ネットワークのワークロードを エッジワーカーノード に分離するなど、クラスターを保護するためのいくつかのオプションが用意されています。

ゾーンで初めてクラスターを作成すると、そのゾーンのパブリックVLANとプライベートVLANが、 IBM Cloud インフラストラクチャアカウントに自動的にプロビジョニングされます。 ワーカー・ノードをプライベート VLAN にのみ接続するように指定した場合、そのゾーン内のプライベート VLAN のみが自動的にプロビジョンされます。 それ以降、そのゾーンにクラスターを作成するたびに、使用する VLAN のペアを指定できます。 VLAN は複数のクラスターで共有できるので、お客様用に作成された同一のパブリック VLAN とプライベート VLAN を何度も使用することができます。

VLAN、サブネット、および IP アドレスについて詳しくは、IBM Cloud Kubernetes Service でのネットワーキングの概要を参照してください。

カスタム・サブネットを使用してクラスターを作成する必要がありますか? 既存のサブネットを使用したクラスターの作成を確認してください。

複数のサブネットおよび VLAN 間のワーカー・ノード通信

状況によっては、クラスター内のコンポーネントが複数のプライベート VLAN 間で通信できるようにする必要があります。 例えば、複数ゾーン・クラスターを作成する場合や、1 つのクラスターに複数の VLAN が存在する場合、同じ VLAN 上に複数のサブネットが存在する場合は、同じ VLAN 上にあってもサブネットが異なるワーカー・ノード、または異なる VLAN 上にあるワーカー・ノードは、そのままでは相互通信できません。 ユーザーが IBM Cloud インフラストラクチャー・アカウントで Virtual Routing and Forwarding (VRF) または VLAN スパンニングを有効にする必要があります。

• Virtual Routing and Forwarding (VRF): VRF は、インフラストラクチャー・アカウント内のすべてのプライベート VLAN およびサブネットが相互に通信できるようにします。 さらに、ワーカーとマスターがプライベート・クラウド・サービス・エンドポイントを介して通信し、プライベート・クラウド・サービス・エンドポイントをサポートする他の IBM Cloud インスタンスと通信できるようにするには、VRF が必要です。 VRF が既に有効になっているかどうかを確認するには、ibmcloud account show コマンドを使用します。 VRF を有効にするには、ibmcloud account update --service-endpoint-enable true を実行します。 このコマンド出力によって、アカウントで VRF およびサービス・エンドポイントを使用できるようにするためのサポート Case を開くように求めるプロンプトが出されます。 VRF を有効にする場合は、アカウントの VLAN スパンニングは不要になります。これは、すべての VLAN が通信できるようになるためです。 VRF を有効にすると、同じ IBM Cloud アカウントのプライベート VLAN に接続されているすべてのシステムが、クラスター・ワーカー・ノードと通信できるようになります。 Calico プライベート・ネットワーク・ポリシーを適用すれば、クラスターをプライベート・ネットワーク上の他のシステムから切り離せます。
• VLAN スパニング: VRF ではなく VLAN スパニングを有効にすることを選択した場合、プライベート クラウド サービス エンドポイントを有効にすることはできません。 VRFを有効にできない、または有効にしたくない場合、例えば、プライベートネットワーク上でマスターにアクセスする必要がない場合や、パブリックVLAN経由でマスターにアクセスするためにゲートウェイアプライアンスを使用している場合などに、VLANスパニングを有効にします。 例えば、既存のゲートウェイアプライアンスがあり、その後クラスタを追加した場合、クラスタ用に作成された新しいポータブルサブネットはゲートウェイアプライアンスには設定されませんが、VLANスパニングによりサブネット間のルーティングが可能になります。

パブリック・サービス・エンドポイントのみ

アカウントの VRF を有効にしない、または有効にできない場合、ご使用のワーカー・ノードは自動的に、パブリック・クラウド・サービス・エンドポイントを介してパブリック VLAN 経由で Kubernetes マスターに接続できます。

• ワーカー・ノードとマスターの通信は、パブリック・クラウド・サービス・エンドポイントを介してパブリック・ネットワーク経由で安全に確立されます。
• 許可されたクラスター・ユーザーのみが、パブリック・クラウド・サービス・エンドポイントを介してパブリックからマスターにアクセスできます。 クラスター・ユーザーはインターネット経由で Kubernetes マスターに安全にアクセスし、例えば kubectl コマンドを実行したりできます。
• オプションで、コンテキスト・ベースの制限 を使用してクラスタのパブリックおよびプライベート・サービス・エンドポイントへのアクセスを保護することができます。

パブリック・クラウドとプライベート・クラウドのサービス・エンドポイント

パブリックからでもプライベートからでもクラスター・ユーザーが利用できるマスターにするには、パブリック・クラウド・サービス・エンドポイントおよびプライベート・クラウド・サービス・エンドポイントを有効にします。 IBM Cloud アカウントに VRF が必要です。また、アカウントでサービス・エンドポイントを使用できるようにする必要があります。 VRF およびサービス・エンドポイントを有効にするには、ibmcloud account update --service-endpoint-enable true を実行します。

• ワーカー・ノードがパブリック VLAN とプライベート VLAN に接続されている場合、ワーカー・ノードとマスターの通信は、プライベート・クラウド・サービス・エンドポイントを介するプライベート・ネットワークと、パブリック・クラウド・サービス・エンドポイントを介したパブリック・ネットワークの両方を経由して確立されます。 ワーカーからマスターへのトラフィックをパブリック・エンドポイントとプライベート・エンドポイントに半分ずつルーティングすると、マスターからワーカーへの通信が、パブリック・ネットワークまたはプライベート・ネットワークの可能性のある障害から保護されます。 ワーカー・ノードがプライベート VLAN のみに接続されている場合、ワーカー・ノードとマスターの通信は、プライベート・クラウド・サービス・エンドポイントを介したプライベート・ネットワーク経由のみで確立されます。
• 許可されたクラスター・ユーザーは、パブリック・クラウド・サービス・エンドポイントを介してパブリックからマスターにアクセスできます。 許可されたクラスター・ユーザーは、IBM Cloud プライベート・ネットワークの中で作業している場合、または VPN 接続または IBM Cloud Direct Link 経由でプライベート・ネットワークに接続している場合に、プライベート・クラウド・サービス・エンドポイントを介して、プライベートにマスターにアクセスできます。 ユーザーが VPN 接続または IBM Cloud Direct Link 接続を介してマスターにアクセスできるように、プライベート・ロード・バランサーを介してマスター・エンドポイントを公開する必要があります。
• オプションで、コンテキスト・ベースの制限 を使用してクラスタのパブリックおよびプライベート・サービス・エンドポイントへのアクセスを保護することができます。

プライベート・サービス・エンドポイントのみ

マスターにプライベートでのみアクセスできるようにするには、プライベート・クラウド・サービス・エンドポイントを有効にします。 IBM Cloud アカウントに VRF が必要です。また、アカウントでサービス・エンドポイントを使用できるようにする必要があります。 VRF およびサービス・エンドポイントを有効にするには、ibmcloud account update --service-endpoint-enable true を実行します。 プライベート・クラウド・サービス・エンドポイントのみを使用すると、請求対象の帯域幅および従量制帯域幅の課金は発生しません。

• ワーカー・ノードとマスターの通信は、プライベート・クラウド・サービス・エンドポイントを介してプライベート・ネットワーク経由で安全に確立されます。
• 許可されたクラスター・ユーザーは、IBM Cloud プライベート・ネットワークの中で作業している場合、または VPN 接続または DirectLink 経由でプライベート・ネットワークに接続している場合に、プライベートにマスターにアクセスできます。 ユーザーが VPN 接続または DirectLink 接続を介してマスターにアクセスできるように、プライベート・ロード・バランサーを介してマスター・エンドポイントを公開する必要があります。
• オプションで、コンテキスト・ベースの制限 を使用してクラスタのパブリックおよびプライベート・サービス・エンドポイントへのアクセスを保護することができます。

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

ワーカー・ノードは、IBM Cloud インフラストラクチャー・プライベート・ネットワークを介して プライベート・クラウド・サービス・エンドポイントをサポートする他の IBM Cloud サービス (IBM Cloud® Container Registry など) と自動的かつ安全に通信できます。 IBM Cloud サービスがプライベート・クラウド・サービス・エンドポイントをサポートしていない場合は、パブリック・ネットワークを介してサービスと安全に通信できるように、ワーカー・ノードをパブリック VLAN に接続する必要があります。

Calico ポリシーまたはゲートウェイ・アプライアンスを使用してワーカー・ノードのパブリック・ネットワークまたはプライベート・ネットワークを制御する場合は、パブリック・クラウド・サービス・エンドポイントをサポートするサービスのパブリック IP アドレスへのアクセス、およびオプションでプライベート・クラウド・サービス・エンドポイントをサポートするサービスのプライベート IP アドレスへのアクセスを許可する必要があります。

• Calico ポリシーでサービスのパブリック IP アドレスへのアクセスを許可する
• Calico ポリシーでプライベート・クラウド・サービス・エンドポイントをサポートするサービスのプライベート IP アドレスへのアクセスを許可する
• サービスのパブリック IP アドレスへのアクセス、およびゲートウェイ・アプライアンス・ファイアウォール内のプライベート・クラウド・サービス・エンドポイントをサポートするサービスのプライベート IP アドレスへのアクセスを許可する

プライベート・ネットワークを介してオンプレミス・データ・センター内のリソースと通信するための IBM Cloud® Direct Link

クラスターを IBM Cloud Private などのオンプレミスのデータ・センターに接続する場合は、IBM Cloud Direct Link をセットアップします。 IBM Cloud Direct Link を使用して、パブリック・インターネット経由で経路指定せずに、リモート・ネットワーク環境と IBM Cloud Kubernetes Service の間の直接のプライベート接続を作成します。

パブリック・ネットワークを介してオンプレミス・データ・センター内のリソースと通信するための strongSwan IPSec VPN 接続

• パブリックおよびプライベートVLANに接続されているワーカーノード ： strongSwan IPSec VPN サービスを直接クラスタ内にセットアップします。 strongSwan IPSec VPN サービスは、業界標準の Internet Protocol Security (IPSec) プロトコル・スイートに基づき、インターネット上にセキュアなエンドツーエンドの通信チャネルを確立します。 クラスターとオンプレミス・ネットワークの間にセキュアな接続をセットアップするためには、クラスター内のポッドに直接、strongSwan IPSec VPN サービスを構成してデプロイします。

• プライベート VLAN のみに接続されたワーカー・ノード: Virtual Router Appliance (Vyatta) などのゲートウェイ・アプライアンスで IPSec VPN エンドポイントをセットアップします。 次に、クラスターに strongSwan IPSec VPN サービスを構成して、ゲートウェイの VPN エンドポイントを使用します。 strongSwan を使用しない場合は、VRA を使用して、直接、VPN 接続をセットアップできます。

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

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

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

クラスターにアプリをデプロイするときに、クラスターと同じプライベート・ネットワーク上のユーザーとサービスのみがアプリにアクセスできるようにすることができます。 プライベート・ロード・バランシングは、アプリを一般的に公開することなく、クラスター外からの要求で使用できるようにする場合に理想的です。 プライベート・ロード・バランシングを使用して、アプリのアクセス、要求ルーティング、およびその他の構成をテストしてから、後でパブリック・ネットワーク・サービスを使用してアプリをパブリックに公開することもできます。 クラスターの外部からのアプリへのプライベート・トラフィック要求を許可するには、プライベート NodePort、NLB、Ingress ALB などのプライベート Kubernetes ネットワーク・サービスを作成します。 その後、Calico pre-DNAT ポリシーを使用して、プライベート・ネットワーク・サービスのパブリック NodePort へのトラフィックをブロックできます。 詳しくは、プライベート外部ロード・バランシングの計画を参照してください。

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

パブリック・インターネットからアプリに外部からアクセスできるようにするために、パブリック NodePort、ネットワーク・ロード・バランサー (NLB)、および Ingress アプリケーション・ロード・バランサー (ALB) を作成します。 パブリック・ネットワーク・サービスは、アプリにパブリック IP アドレスを提供する (サービスによってはパブリック URL も提供する) ことによって、このパブリック・ネットワーク・インターフェースに接続します。 アプリをパブリックに公開すると、アプリにセットアップされたパブリック・サービス IP アドレスまたは URL を知っているだれもがアプリに要求を送信できるようになります。 その後、Calico の pre-DNAT ポリシーを使用して、パブリック・ネットワーク・サービスへのトラフィックを制御できます。例えば、特定の送信元の IP アドレスや CIDR からのトラフィックだけを許可し、他のすべてのトラフィックをブロックしたりできます。 詳しくは、パブリック外部ロード・バランシングの計画を参照してください。

さらにセキュリティを強化するために、ネットワークのワークロードをエッジワーカーノードに分離することができます。

エッジ・ワーカー・ノードを使用すると、外部的にアクセスされる、パブリック VLAN に接続されたワーカー・ノードの数を減らし、ネットワークのワークロードを分離することができるので、クラスターのセキュリティーが改善されます。 ワーカー・ノードにエッジ・ノードとしてラベルを付けると、NLB ポッドと ALB ポッドは、指定されたそれらのワーカー・ノードにのみデプロイされます。 さらに、エッジノード上で他のワークロードが実行されないように、 エッジノードを汚染することができます。 その後、パブリックとプライベートの両方の NLB と ALB をエッジ・ノードにデプロイできます。 例えば、ワーカー・ノードがプライベート VLAN にのみ接続されているが、クラスター内のアプリへのパブリック・アクセスを許可する必要がある場合、エッジ・ノードがパブリック VLAN およびプライベート VLAN に接続されるエッジ・ワーカー・プールを作成できます。 パブリック NLB および ALB をこれらのエッジ・ノードにデプロイして、それらのワーカーのみがパブリック接続を処理するようにすることができます。

インターネット向けワークロードが含まれる、クラシック・クラスターでのワーカー間通信

このセットアップを行うには、ワーカー・ノードをパブリック VLAN およびプライベート VLAN に接続して、クラスターを作成します。

パブリック VLAN とプライベート VLAN の両方を使用してクラスターを作成した場合、後でそのクラスターからすべてのパブリック VLAN を削除することはできません。 クラスターからすべてのパブリック VLAN を削除すると、複数のクラスター・コンポーネントが作業を停止します。 代わりに、プライベート VLAN のみに接続された新規ワーカー・プールを作成します。

インターネット向けワークロードが含まれる、クラシック・クラスターでのワーカーとマスター間およびユーザーとマスター間の通信

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

• パブリック・クラウド・サービス・エンドポイントおよびプライベート・クラウド・サービス・エンドポイント: ご使用のアカウントで VRF を有効にし、サービス・エンドポイントを使用できるようにする必要があります。 ワーカー・ノードとマスターの通信は、プライベート・クラウド・サービス・エンドポイントを介するプライベート・ネットワークと、パブリック・クラウド・サービス・エンドポイントを介するパブリック・ネットワークの両方を経由して確立されます。 許可されたクラスター・ユーザーは、パブリック・クラウド・サービス・エンドポイントを介してパブリックからマスターにアクセスできます。
• パブリック・サービス・エンドポイント: アカウントの VRF を有効にしない、または有効にできない場合、ワーカー・ノードと許可されたクラスター・ユーザーは、パブリック・クラウド・サービス・エンドポイントを介してパブリック・ネットワークを介して自動的に Kubernetes マスターに接続できます。

インターネット向けワークロードが含まれる、他のサービスまたはネットワークへのワーカー通信

ワーカー・ノードは、IBM Cloud インフラストラクチャー・プライベート・ネットワークを介してプライベート・クラウド・サービス・エンドポイントをサポートする他の IBM Cloud サービスと自動的かつ安全に通信できます。 IBM Cloud サービスがプライベート・クラウド・サービス・エンドポイントをサポートしていない場合、ワーカーはパブリック・ネットワークを介してサービスと安全に通信できます。 パブリック・ネットワークまたはプライベート・ネットワークの分離に Calico ネットワーク・ポリシーを使用することで、ワーカー・ノードのパブリック・インターフェースまたはプライベート・インターフェースをロックダウンできます。 これらの Calico 分離ポリシーで、使用するサービスのパブリック IP アドレスおよびプライベート IP アドレスへのアクセスを許可することが必要な場合があります。

ワーカー・ノードが IBM Cloud アカウント外のプライベート・ネットワーク内のサービスにアクセスする必要がある場合は、クラスターで strongSwan IPSec VPN サービスを構成およびデプロイするか、IBM Cloud IBM Cloud Direct Link サービスを利用してこのようなネットワークに接続します。

インターネット向けワークロードが含まれる、ワーカー・ノードで実行されるアプリへの外部通信

クラスター内のアプリをインターネットに公開するには、パブリック・ネットワーク・ロード・バランサー (NLB) または Ingress アプリケーション・ロード・バランサー (ALB) のサービスを作成します。 エッジ・ノードとしてラベル付けされたワーカー・ノードのプールを作成することにより、クラスターのセキュリティーを向上させることができます。 パブリック・ネットワーク・サービスのポッドはエッジ・ノードにデプロイされるため、外部トラフィック・ワークロードはクラスター内の少数のワーカーにのみ分離されます。 許可リスト・ポリシーやブロック・リスト・ポリシーなどの Calico pre-DNAT ポリシーを作成することで、アプリを公開するネットワーク・サービスへのパブリック・トラフィックをさらに制御できます。

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

ワーカー間の通信、ゲートウェイ・アプライアンスを使用したワーカーとマスター間およびユーザーとマスター間の通信

ワーカー・ノードをプライベート VLAN 上にのみセットアップし、アカウントの VRF を有効にしない、または有効にできない場合は、パブリック・ネットワークを介してワーカー・ノードとマスターの間のネットワーク接続を提供するよう、ゲートウェイ・アプライアンスを構成する必要があります。 例えば、 Virtual Router Appliance をセットアップすることを選択できます。

カスタム・ネットワーク・ポリシーをゲートウェイ・アプライアンスにセットアップして、クラスターのための専用ネットワーク・セキュリティーを設定し、ネットワーク侵入を検出して対処できます。 パブリック・ネットワークでファイアウォールをセットアップする場合は、マスターとワーカー・ノードが通信できるように、リージョンごとに必要なポートとプライベート IP アドレスを開く必要があります。 プライベート・ネットワークにもこのファイアウォールを構成する場合も、ワーカー・ノード間の通信を許可し、クラスターがプライベート・ネットワークを介してインフラストラクチャー・リソースにアクセスできるように、必要なポートとプライベート IP アドレスを開く必要があります。 サブネットが同じ VLAN 上および複数の VLAN 間で経路指定できるように、アカウントの VLAN スパンニングを有効にする必要もあります。

ゲートウェイ・アプライアンスを使用した、他のサービスまたはネットワークへのワーカー通信

ワーカー・ノードとアプリを IBM Cloud 外部の外部のオンプレミス・ネットワークまたはサービスに安全に接続するには、ゲートウェイ VPN エンドポイントを使用するように、ゲートウェイ・アプライアンス上に IPSec VPN エンドポイントをセットアップし、クラスター内の strongSwan IPSec VPN サービスをセットアップします。 strongSwan を使用しない場合は、VRA を使用して、直接、VPN 接続をセットアップできます。

ワーカー・ノードは、ゲートウェイ・アプライアンスを介して IBM Cloud 外部の他の IBM Cloud サービスおよびパブリック・サービスと安全に通信できます。 使用するサービスのみのパブリック IP アドレスおよびプライベート IP アドレスにアクセスできるようにファイアウォールを構成できます。

ゲートウェイ・アプライアンスを使用した、ワーカー・ノード上で実行されるアプリへの外部通信

クラスター内のアプリへのプライベート・アクセスを提供するには、プライベート・ネットワーク・ロード・バランサー (NLB) または Ingress アプリケーション・ロード・バランサー (ALB) を作成して、アプリをプライベート・ネットワークにのみ公開します。 クラスター内のアプリへの限定パブリック・アクセスを提供する必要がある場合は、パブリック NLB または ALB を作成してアプリを公開できます。 すべてのトラフィックがゲートウェイ・アプライアンス・ファイアウォールを通過するため、ファイアウォールでサービスのポートと IP アドレスを開き、これらのサービスへのインバウンド・トラフィックを許可することで、アプリを公開するネットワーク・サービスへのパブリック・トラフィックおよびプライベート・トラフィックを制御できます。

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

プライベート・クラスターでのワーカー間通信

このセットアップを行うには、ワーカー・ノードをプライベート VLAN のみに接続してクラスターを作成します。 プライベート・クラウド・サービス・エンドポイントのみを介してプライベート・ネットワークを経由してクラスター・マスターとワーカー・ノードの間の接続を提供するには、ご使用のアカウントで VRF を有効にし、サービス・エンドポイントを使用できるようにする必要があります。 VRF が有効な場合、クラスターはプライベート・ネットワーク上のすべてのリソースから可視であるため、Calico プライベート・ネットワーク・ポリシーを適用することで、プライベート・ネットワーク上の他のシステムからクラスターを分離できます。

ワーカー・ノード、ポッド、およびサービスのデフォルト範囲と、オンプレミス・ネットワーク内のサブネットの間に、サブネットの競合がある可能性があることに注意してください。 IBM が提供するサブネットを使用せずにクラスタを作成するには、 --no-subnet オプションを含めます。 クラスターの作成後に、クラスターにカスタム・サブネットを追加できます。 さらに、クラスタを作成する際に ibmcloud ks cluster create コマンドの --pod-subnet および --service-subnet オプションを使用することで、ポッドおよびサービスにカスタムサブネットCIDRを指定することができます。

プライベート・クラスターのワーカーとマスターおよびユーザーとマスターの間の通信

許可されたクラスター・ユーザーが、IBM Cloud プライベート・ネットワークの中で作業している場合、またはクラシック VPN 接続や IBM Cloud Direct Link などを介してプライベート・ネットワークに接続している場合は、プライベート・クラウド・サービス・エンドポイントを介して Kubernetes マスターにアクセスできます。 ただし、プライベート・クラウド・サービス・エンドポイントを介した Kubernetes マスターとの通信には、IP アドレス範囲 166.X.X.X を使用する必要があります。この範囲はクラシック VPN 接続でも IBM Cloud Direct Link でもルーティングすることはできません。 プライベート・ネットワーク・ロード・バランサー (NLB) を使用して、クラスター・ユーザーのマスターのプライベート・クラウド・サービス・エンドポイントを公開できます。 プライベート NLB は、ユーザーが VPN または IBM Cloud Direct Link 接続を使用してアクセスできる内部 10.X.X.X IP アドレス範囲として、マスターのプライベート・クラウド・サービス・エンドポイントを公開します。 プライベート・クラウド・サービス・エンドポイントのみを有効にする場合は、Kubernetes ダッシュボードを使用するか、パブリック・クラウド・サービス・エンドポイントを一時的に有効にして、プライベート NLB を作成できます。

プライベート・クラスターの他のサービスまたはネットワークへのワーカー通信

ワーカー・ノードは、IBM Cloud インフラストラクチャー・プライベート・ネットワークを介して、IBM Cloud などのプライベート・クラウド・サービス・エンドポイントをサポートする他の IBM Cloud® Container Registry サービスと自動的かつ安全に通信できます。 例えば、IBM Cloudant のすべての標準プラン・インスタンスの専用ハードウェア環境は、プライベート・クラウド・サービス・エンドポイントをサポートします。 IBM Cloud サービスがプライベート・クラウド・サービス・エンドポイントをサポートしていない場合、クラスターはそのサービスにアクセスできません。

プライベートクラスタのワーカーノード上で動作するアプリケーションへの外部通信

クラスター内のアプリへのプライベート・アクセスを提供するには、プライベート・ネットワーク・ロード・バランサー (NLB) または Ingress アプリケーション・ロード・バランサー (ALB) を作成します。 これらの Kubernetes ネットワーク・サービスは、NLB IP があるサブネットへの接続を持つオンプレミス・システムがアプリにアクセスできるように、アプリをプライベート・ネットワークのみに公開します。

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