限定公開クラスタ

このページでは、Google Kubernetes Engine(GKE)での限定公開クラスタの動作について説明します。限定公開クラスタの作成と管理の方法についても説明します。

限定公開クラスタは、内部 IP アドレスのみに依存する VPC ネイティブ クラスタの一種です。限定公開クラスタ内のノード、Pod と Service には一意のサブネット IP アドレス範囲が必要です。

限定公開クラスタは、Standard クラスタまたは Autopilot クラスタで構成できます。

特定のプライベート ノードに対して送信インターネット アクセスを提供する場合は、Cloud NAT を使用するか、独自の NAT ゲートウェイを使用します。

アーキテクチャ

限定公開クラスタは、外部 IP アドレスを持たないノードを使用します。つまり、インターネット上のクライアントはノードの IP アドレスに接続できません。たとえば、ノードがインターネット ルーティングが可能なパブリック IP アドレスを持たないため、限定公開クラスタでホストされている NodePort タイプの Service は、外部クライアントにアクセスできません。

一般公開クラスタとは異なり、限定公開クラスタにはコントロール プレーンのプライベート エンドポイントとコントロール プレーンのパブリック エンドポイントの両方があります。コントロール プレーンのプライベート エンドポイントには一意の /28 IP アドレス範囲を指定する必要があります。また、コントロール プレーンのパブリック エンドポイントを無効にすることもできます。

次の図は、限定公開クラスタのアーキテクチャの概要を示しています。

限定公開クラスタのアーキテクチャ

ノードが内部 IP アドレスを使用していても、外部クライアントはクラスタ内の Service に接続できます。次に例を示します。

  • Service マニフェストから spec.loadBalancerSourceRanges を省略すると、インターネット上に送信元 IP アドレスを持つ外部クライアントは LoadBalancer タイプの外部 Service に接続できます。

  • NodePort または ClusterIP タイプの Service を作成し、外部 Ingress を使用して Service を外部クライアントに公開できます。

限定公開クラスタで限定公開の Google アクセスを使用する

クラスタと同じプロジェクトで VPC ネットワークを使用する限定公開クラスタの場合、GKE は、クラスタの作成時に限定公開クラスタによって使用されるサブネットで限定公開の Google アクセスを有効にします。限定公開クラスタが共有 VPC サービス プロジェクト内で作成されている場合、共有 VPC ホスト プロジェクトのネットワーク管理者、プロジェクト オーナー、プロジェクト編集者は、限定公開クラスタによって使用されるサブネットで限定公開の Google アクセスを手動で有効にする必要があります。

共有 VPC クラスタを除き、限定公開クラスタではデフォルトで限定公開の Google アクセスが有効になっています。共有 VPC クラスタでは、限定公開の Google アクセスを手動で有効にする必要があります。

限定公開の Google アクセスにより、プライベート ノードとそのワークロードは Google のプライベート ネットワークを介して Google Cloud APIs とサービスにアクセスできるようになります。たとえば、限定公開のクラスタが Artifact Registry からコンテナ イメージにアクセスし、Cloud Logging にログを送信するには、限定公開の Google アクセスが必要です。

限定公開クラスタ内のコントロール プレーン

各 GKE クラスタには、コントロール プレーン(マスター)が管理する Kubernetes API サーバーがあります。

コントロール プレーンは、Google が所有するプロジェクトの VPC ネットワーク内の仮想マシン(VM)上で動作します。リージョン クラスタには複数のコントロール プレーンがあり、各コントロール プレーンは独自の VM で実行されます。

限定公開クラスタでは、コントロール プレーンの VPC ネットワークが VPC ネットワーク ピアリングによりクラスタの VPC ネットワークに接続します。VPC ネットワークにはクラスタノードが存在し、Google 所有の Google Cloud VPC ネットワークにはクラスタのコントロール プレーンが存在します。

ノードとコントロール プレーンの間のトラフィックは、すべて内部 IP アドレスを使用してルーティングされます。VPC ネットワーク ピアリングを使用してクラスタの VPC ネットワークを 3 番目のネットワークに接続する場合、3 番目のネットワークはコントロール プレーンの VPC ネットワーク内のリソースに到達できません。これは、VPC ネットワーク ピアリングは、直接ピアリングされたネットワーク間の通信のみをサポートしており、3 番目のネットワークとコントロール プレーン ネットワークとピアリングできないためです。詳細については、VPC ネットワーク ピアリングに関する制限をご覧ください。

VPC ネットワーク ピアリングの再使用

2020 年 1 月 15 日以降に作成された限定公開クラスタは、これらのクラスタが同じロケーションに存在し、同じ VPC ネットワークを使用する場合に、共通の VPC ネットワーク ピアリング接続を使用します。この場合、ロケーションは、Google Cloud リージョンまたは Google Cloud ゾーンのいずれか意味します。

  • ゾーンクラスタの場合: ゾーンに最初に作成する限定公開クラスタが、クラスタの VPC ネットワークとの新しい VPC ネットワーク ピアリング接続を生成します。同じゾーンと VPC ネットワークで作成した追加のゾーン限定公開クラスタは、同じピアリング接続を使用します。

  • リージョン クラスタの場合: リージョンに最初に作成する限定公開クラスタが、クラスタの VPC ネットワークとの新しい VPC ネットワーク ピアリング接続を生成します。同じリージョンと VPC ネットワークで作成した追加のリージョン限定公開クラスタは、同じピアリング接続を使用します。

  • ゾーンクラスタがリージョン クラスタと同じリージョンに属している場合でも、GKE はゾーンクラスタとリージョン クラスタに共通のピアリングを使用しません。

次の例でこの動作を説明します。それぞれの例で 1 つの VPC ネットワーク ピアリング接続を使用しています。

  • us-east1-b ゾーンの 2 つ以上のゾーン限定公開クラスタ。同じ VPC ネットワークを使用しています。

  • us-east1 リージョンの 2 つ以上のリージョン限定公開クラスタ。同じ VPC ネットワークを使用しています。

ただし、us-east1-b の 1 つ以上のゾーン限定公開クラスタと、同じ VPC ネットワークを使用する us-east1 の 1 つ以上のリージョン クラスタには、2 つの VPC ネットワーク ピアリング接続が必要です。

限定公開クラスタと接続の詳細については、VPC ネットワーク ピアリングの再利用をご覧ください。

限定公開クラスタ内のエンドポイント

限定公開クラスタのコントロール プレーンには、プライベート エンドポイントとパブリック エンドポイントがあります。限定公開以外のクラスタのコントロール プレーンには、パブリック エンドポイントしかありません。

プライベート エンドポイント
プライベート エンドポイントは、コントロール プレーンの VPC ネットワーク内の内部 IP アドレスです。限定公開クラスタでは、ノードは常にコントロール プレーンのプライベート エンドポイントと通信します。構成によっては、プライベート エンドポイントにも接続する kubectl などのツールでクラスタを管理できます。限定公開クラスタと同じサブネットを使用する VM は、プライベート エンドポイントにもアクセスできます。
パブリック エンドポイント
これは、コントロール プレーンの外部 IP アドレスです。デフォルトでは、kubectl などのツールはそのパブリック エンドポイント上のコントロール プレーンと通信します。

クラスタ エンドポイントへのアクセス

エンドポイントへのアクセスを制御するには、次のいずれかの構成を使用します。

  • パブリック エンドポイント アクセスが無効: これは最も安全なオプションで、コントロール プレーンに対するすべてのインターネット アクセスが阻止されます。Cloud Interconnect または Cloud VPN を使用してオンプレミス ネットワークから Google Cloud への接続を構成している場合に適しています。

    パブリック エンドポイントへのアクセスを無効にするには、プライベート エンドポイントの承認済みネットワークを構成する必要があります。この構成を行わないと、クラスタと同じサブネット内のクラスタノードまたは VM からのみ、プライベート エンドポイントへの接続が許可されます。この設定で承認済みネットワークを内部 IP アドレスにする必要があります。

  • パブリック エンドポイント アクセスが有効、承認済みネットワークが有効: この構成では、承認済みネットワークがコントロール プレーンのパブリック エンドポイントに適用されます。これは、Cloud Interconnect または Cloud VPN を使用してクラスタの VPC ネットワークに接続していないソース ネットワークからクラスタを管理する必要がある場合に適しています。

  • パブリック エンドポイント アクセスが有効、承認済みネットワークが無効: これはデフォルトで、最も制限の少ないオプションです。承認済みネットワークが有効でないため、承認されていれば、送信元 IP アドレスからクラスタを管理できます。

次の表に、エンドポイントへのアクセス方法を示します。

パブリック エンドポイント アクセスが無効 パブリック エンドポイント アクセスが有効、
承認済みネットワークが有効
パブリック エンドポイント アクセスが有効、
承認済みネットワークが無効
セキュリティ コントロール プレーンへの最高度の制限付きアクセスコントロール プレーンのパブリック エンドポイントへのクライアント アクセスが遮断されます。コントロール プレーンへのアクセスは、内部 IP アドレスから行う必要があります。 定義した内部 IP アドレスと外部 IP アドレスの両方からのコントロール プレーンへの制限付きアクセス。 任意の IP アドレスからコントロール プレーンへのアクセス。
詳細な構成手順 パブリック エンドポイントへのクライアント アクセス権のない限定公開クラスタの作成 パブリック エンドポイントへのアクセスが制限された限定公開クラスタの作成 パブリック エンドポイントへ無制限にアクセス可能な限定公開クラスタの作成
Cloud Console の構成オプション
  1. [VPC ネイティブを有効にする] を選択します。
  2. [限定公開クラスタ] を選択します。
  3. [外部 IP アドレスを使用してコントロール プレーンにアクセス] をクリアします。
    [コントロール プレーン承認済みネットワークを有効にする] は自動的に有効になります。
  1. [VPC ネイティブを有効にする] を選択します。
  2. [限定公開クラスタ] を選択します。
  3. [外部 IP アドレスを使用してコントロール プレーンにアクセス] を選択します。
  4. [コントロール プレーン承認済みネットワークを有効にする] を選択します。
  1. [VPC ネイティブを有効にする] を選択します。
  2. [限定公開クラスタ] を選択します。
  3. [外部 IP アドレスを使用してコントロール プレーンにアクセス] を選択します。
  4. [コントロール プレーン承認済みネットワークを有効にする] をオフにします。
gcloud のクラスタ作成フラグ --enable-ip-alias
--enable-private-nodes
--enable-private-endpoint
--enable-master-authorized-networks
--enable-ip-alias
--enable-private-nodes
--enable-master-authorized-networks
--enable-ip-alias
--enable-private-nodes
--no-enable-master-authorized-networks
ノードとコントロール プレーン間の通信

ノードは常にプライベート エンドポイントを使用してコントロール プレーンと通信します。

ノードと API サーバー間の Webhook 通信

targetPort が 443 以外のサービスを使用する Webhook には、これを許可するファイアウォール ルールが必要です。詳しくは、特定のユースケースに対するファイアウォール ルールの追加をご覧ください。

コントロール プレーン(マスター)承認済みネットワーク

ノードと Pod 以外の内部 IP アドレスからコントロール プレーンへのアクセスに必要です。

ノードの内部 IP アドレス範囲を明示的に承認する必要はありません。クラスタのサブネットのプライマリ IP アドレス範囲内のアドレスは、常にプライベート エンドポイントとの通信が許可されます。

コントロール プレーンにアクセスできる追加の内部 IP アドレスを指定するには、--master-authorized-networks を使用します。パブリック エンドポイントへのアクセスが無効になっているため、承認済みネットワークのリストに外部 IP アドレスを含めることができません。

外部 IP アドレスとノードおよび Pod 以外の内部 IP アドレスからコントロール プレーンにアクセスする場合に必要です。

コントロール プレーンにアクセスできる、外部 IP アドレスとノードおよび Pod 以外の内部 IP アドレスを指定するには、--master-authorized-networks を使用します。

使用されません。

承認済みネットワークを有効にせずにコントロール プレーンのパブリック エンドポイントへのアクセスを有効にした場合、コントロール プレーンのパブリック エンドポイントへのアクセスは制限されません。

kubectl を使用したアクセス

ノードから: 常にプライベート エンドポイントを使用します。kubectl は、プライベート エンドポイントを使用するように構成する必要があります。

クラスタの VPC ネットワーク内の他の VM から: 他の VM は、クラスタと同じリージョンにあり、その内部 IP アドレスがマスター承認済みネットワークのリストに含まれている場合、またはクラスタのノードと同じサブネットに存在する場合のみ、kubectl を使用してプライベート エンドポイントと通信できます。kubectl を、プライベート エンドポイントを使用するように構成する必要があります。

パブリック IP アドレスから: 不可。

ノードから: 常にプライベート エンドポイントを使用します。kubectl を、プライベート エンドポイントを使用するように構成する必要があります。

クラスタの VPC ネットワーク内の他の VM から: 他の VM は、クラスタと同じリージョンにあり、その内部 IP アドレスがマスター承認済みネットワークのリストに含まれている場合、またはクラスタのノードと同じサブネットに存在する場合のみ、kubectl を使用してプライベート エンドポイントと通信できます。kubectl を、プライベート エンドポイントを使用するように構成する必要があります。

パブリック IP アドレスから: パブリック IP アドレスを持つマシンは、パブリック IP アドレスが承認済みネットワークのリストに含まれている場合にのみ、kubectl を使用してパブリック エンドポイントと通信できます。これには、Google Cloud の外のマシンと外部 IP アドレスを持つ Google Cloud VM が含まれます。

ノードから: 常にプライベート エンドポイントを使用します。kubectl は、プライベート エンドポイントを使用するように構成する必要があります。

クラスタの VPC ネットワーク内の他の VM から: 他の VM は、クラスタと同じリージョンにある場合にのみ、kubectl を使用してプライベート エンドポイントと通信できます。kubectl を、プライベート エンドポイントを使用するように構成する必要があります。

パブリック IP アドレスから: パブリック IP アドレスを持つマシンは、kubectl を使用してパブリック エンドポイントと通信できます。これには、Google Cloud の外のマシンと外部 IP アドレスを持つ Google Cloud VM が含まれます。

次のステップ