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 サブネットのパブリック・ゲートウェイを有効にします。 パブリック・ゲートウェイは、いつでもサブネットに接続したり、サブネットから切り離したりできます。

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

VPC の作成時にクラシック・アクセスを有効にする場合に、クラシック・アクセス用のデフォルトのアドレス接頭部を使用すると、ユーザーが作成するサブネットの IP 範囲が自動的に決定されます。 しかし、クラシック・アクセス VPC のサブネットのデフォルトの IP 範囲は、IBM Cloud Kubernetes Service のコントロール・プレーンのサブネットと競合しています。 代わりに、 自動デフォルトアドレスプレフィックスなしで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 の範囲は禁止されています。

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

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

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

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

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

Kubernetes マスターへのワーカー・ノードの通信は、クラスターのバージョンに応じて異なる方法で確立されます。

• Kubernetes マスターへのワーカー・ノード通信は、 VPC 仮想プライベート・エンドポイント(VPE) を介して確立されます。 パブリック・クラウド・サービス・エンドポイントも有効にした場合は、パブリック・ネットワークまたはプライベート・ネットワークの障害から保護するために、パブリック・エンドポイントと VPE を半分ずつ使用してワーカーからマスターへのトラフィックが確立されます。

パブリックおよびプライベート・クラウド・サービスのエンドポイントまたは VPE を介した通信を保護するために、 IBM Cloud Kubernetes Service は、クラスタの作成時に 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を指定することで、サブネットの競合を回避できます。
• ご使用の 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 コントロール・プレーン機能用に予約されているため、禁止されています。

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

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

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

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

クラスター外部からアプリへのプライベート・ネットワーク・トラフィック要求を許可するには、例えば、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 からセキュリティー・グループを削除し、自分が作成および管理する セキュリティー・グループに置き換えることができます。

インターネットから LoadBalancer サービスまたは ALB へのインバウンド・ネットワーク・トラフィックを可能にするために、サブネット上にパブリック・ゲートウェイを置く必要はないことに注意してください。 パブリック・ゲートウェイが必要になるのは、ワーカー・ノードからパブリック・エンドポイントにアウトバウンド要求を行えるようにする場合だけです。 詳しくは、パブリック外部ロード・バランシングの計画を参照してください。

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

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

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

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

シナリオ: 制限付きでパブリックに送信できるインターネット向けアプリのワークロードを VPC クラスターで実行する

このシナリオでは、インターネットから要求を送信できる VPC クラスターでワークロードを実行します。 エンド・ユーザーにアプリを利用できるようにしつつ、アプリへの不要なパブリック要求は拒否するように、パブリック・アクセスを制御します。 一方、ワーカー・ノードからパブリック・エンドポイントへのパブリック送信を制限付きで可能にし、そのパブリック送信をクラスター内で制御および分離する必要がある場合もあります。 例えば、プライベート・クラウド・サービス・エンドポイントをサポートしていないためにパブリック・ネットワーク経由でアクセスしなければならない IBM Cloud サービスに、アプリ・ポッドからアクセスする必要がある場合などです。

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

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

次のステップ

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