限定公開クラスタの作成

このページでは、VPC ネイティブ クラスタの一種であるプライベート Google Kubernetes Engine(GKE)クラスタを作成する方法について説明します。限定公開クラスタでは、ノードに内部 IP アドレスのみがあるため、ノードと Pod がデフォルトでインターネットから隔離されています。

ノードの内部 IP アドレスは、クラスタ用に選択したサブネットのプライマリ IP アドレス範囲から取得されます。Pod IP アドレスと Service IP アドレスは、同じサブネットの 2 つのサブネット セカンダリ IP アドレス範囲から取得できます。詳しくは、VPC ネイティブ クラスタの IP 範囲をご覧ください。

GKE バージョン 1.14.2 以降では、プライベート範囲(RFC 1918 と他のプライベート範囲を含む)と非公開で使用されたパブリック IP アドレス範囲など、内部 IP アドレス範囲がサポートされています。有効な内部 IP アドレス範囲の一覧については、VPC のドキュメントをご覧ください。

限定公開クラスタの仕組みについて詳しくは、限定公開クラスタをご覧ください。

始める前に

次の手順に進む前に、要件、制約、制限をよく理解してください。

作業を始める前に、次のことを確認してください。

次のいずれかの方法で gcloud のデフォルトの設定を指定します。

  • gcloud init。デフォルトの設定全般を確認する場合に使用します。
  • gcloud config。プロジェクト ID、ゾーン、リージョンを個別に設定する場合に使用します。

gcloud init の使用

エラー One of [--zone, --region] must be supplied: Please specify location を受信した場合は、このセクションの内容を実施します。

  1. gcloud init を実行して、次の操作を行います。

    gcloud init

    リモート サーバーで SSH を使用している場合は、--console-only フラグを指定して、コマンドがブラウザを起動しないようにします。

    gcloud init --console-only
  2. 手順に従って gcloud を承認し、Google Cloud アカウントを使用します。
  3. 新しい構成を作成するか、既存の構成を選択します。
  4. Google Cloud プロジェクトを選択します。
  5. デフォルトの Compute Engine ゾーンを選択します。

gcloud config の使用

  • デフォルトのプロジェクト ID を設定します。
    gcloud config set project project-id
  • ゾーンクラスタを使用する場合は、デフォルトのコンピューティング ゾーンを設定します。
    gcloud config set compute/zone compute-zone
  • リージョン クラスタを使用する場合は、デフォルトのコンピューティング リージョンを設定します。
    gcloud config set compute/region compute-region
  • gcloud を最新バージョンに更新します。
    gcloud components update

コントロール プレーンへのアクセス

限定公開クラスタでは、コントロール プレーン(マスター)にプライベート エンドポイントとパブリック エンドポイントがあります。クラスタ エンドポイントへのアクセスを制御するための構成の組み合わせが 3 つあります。

  • パブリック エンドポイント アクセスが無効。パブリック エンドポイントへのクライアント アクセス権のない限定公開クラスタが作成されます。
  • パブリック エンドポイント アクセスが有効、承認済みネットワークが有効。パブリック エンドポイントへのアクセスが制限された限定公開クラスタが作成されます。
  • パブリック エンドポイント アクセスが有効、承認済みネットワークが無効。パブリック エンドポイントに無制限にアクセスできる限定公開クラスタが作成されます。

上記の構成オプションの違いの概要については、「クラスタ エンドポイントへのアクセス」をご覧ください。

パブリック エンドポイントへのクライアント アクセス権のない限定公開クラスタの作成

このセクションでは、private-cluster-0 という名前の限定公開クラスタを作成します。このクラスタには限定公開ノードはありますが、パブリック エンドポイントへのクライアント アクセス権はありません。

gcloud

次のコマンドを実行します。

gcloud container clusters create private-cluster-0 \
    --create-subnetwork name=my-subnet-0 \
    --enable-master-authorized-networks \
    --enable-ip-alias \
    --enable-private-nodes \
    --enable-private-endpoint \
    --master-ipv4-cidr 172.16.0.32/28 \
    --no-enable-basic-auth \
    --no-issue-client-certificate

ここで

  • --create-subnetwork name=my-subnet-0 を指定すると、GKE によって my-subnet-0 という名前のサブネットが自動的に作成されます。
  • --enable-master-authorized-networks を指定すると、パブリック エンドポイントへのアクセスが承認された IP アドレス範囲に制限されます。
  • --enable-ip-alias を指定すると、クラスタが VPC ネイティブになります。
  • --enable-private-nodes は、クラスタのノードに外部 IP アドレスがないことを示します。
  • --enable-private-endpoint は、クラスタがコントロール プレーン API エンドポイントのプライベート IP アドレスを使用して管理されていることを示します。
  • --master-ipv4-cidr 172.16.0.32/28 は、コントロール プレーンの内部 IP アドレス範囲を指定します。この設定はこのクラスタでは永続的です。RFC 1918 以外の内部 IP アドレスの使用がサポートされています。
  • --no-enable-basic-auth は、クラスタの基本認証を無効にすることを示します。
  • --no-issue-client-certificate は、クライアント証明書の発行を無効にします。

Console

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine のメニューに移動

  2. [クラスタを作成] ボタンをクリックします。

  3. [名前] に「my-subnet-0」と入力します。

  4. ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。

  5. [ネットワーク] と [ノードのサブネット] を default に設定したままにします。これにより、GKE によってクラスタのサブネットが生成されます。

  6. [限定公開クラスタ] チェックボックスをオンにします。

  7. [外部 IP アドレスを使用したマスターへのアクセス] チェックボックスをオフにします。

  8. [マスター IP 範囲] を 172.16.0.32/28 に設定します。

  9. ナビゲーション パネルの [クラスタ] の下の [セキュリティ] をクリックします。

  10. [クライアント証明書を発行する] チェックボックスがオフになっていることを確認します。

  11. [作成] をクリックします。

API

公開アクセス可能なコントロール プレーンを持つクラスタを作成するには、privateClusterConfig リソースの enablePrivateEndpoint: true フィールドを指定します。

この時点では、コントロール プレーンにアクセスできる唯一の IP アドレスです。

  • my-subnet-0 のプライマリ範囲。
  • Pod に使用されるセカンダリ範囲。

たとえば、my-subnet-0 のプライマリ範囲に VM を作成したとします。その VM で、コントロール プレーンの内部 IP アドレスを使用するように kubectl を構成できます。

my-subnet-0 の外部からコントロール プレーンにアクセスする場合は、プライベート エンドポイントにアクセスするために少なくとも 1 つのアドレス範囲を承認する必要があります。

デフォルト ネットワーク内の VM が、クラスタと同じリージョンで my-subnet-0 とは別のサブネットにあるとします。

例:

  • my-subnet-0: 10.0.0.0/22
  • Pod のセカンダリ範囲: 10.52.0.0/14
  • VM のアドレス: 10.128.0.3

VM にコントロール プレーンへのアクセスを承認するには、次のコマンドを使用します。

gcloud container clusters update private-cluster-0 \
    --enable-master-authorized-networks \
    --master-authorized-networks 10.128.0.3/32

パブリック エンドポイントへのアクセスが制限された限定公開クラスタの作成

この構成を使用してプライベート クラスタを作成すると、自動生成されたサブネットまたはカスタム サブネットを使用できます。

自動生成されたサブネットの使用

このセクションでは、private-cluster-1 という名前の限定公開クラスタを作成します。GKE は、このクラスタにクラスタノードのサブネットを自動的に生成します。サブネットでは、限定公開の Google アクセスが有効になっています。サブネット内で、GKE はポッド用とサービス用の 2 つのセカンダリ範囲を自動的に作成します。

gcloud

次のコマンドを実行します。

gcloud container clusters create private-cluster-1 \
    --create-subnetwork name=my-subnet-1 \
    --enable-master-authorized-networks \
    --enable-ip-alias \
    --enable-private-nodes \
    --master-ipv4-cidr 172.16.0.0/28 \
    --no-enable-basic-auth \
    --no-issue-client-certificate

ここで

  • --create-subnetwork name=my-subnet-1 を指定すると、GKE によって my-subnet-1 という名前のサブネットが自動的に作成されます。
  • --enable-master-authorized-networks を指定すると、パブリック エンドポイントへのアクセスが承認された IP アドレス範囲に制限されます。
  • --enable-ip-alias を指定すると、クラスタが VPC ネイティブになります。
  • --enable-private-nodes は、クラスタのノードに外部 IP アドレスがないことを示します。
  • --master-ipv4-cidr 172.16.0.0/28 は、コントロール プレーンの内部 IP アドレス範囲を指定します。この設定はこのクラスタでは永続的です。RFC 1918 以外の内部 IP アドレスの使用がサポートされています。
  • --no-enable-basic-auth は、クラスタの基本認証を無効にします。
  • --no-issue-client-certificate は、クライアント証明書の発行を無効にします。

Console

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine のメニューに移動

  2. [クラスタを作成] ボタンをクリックします。

  3. [名前] に「my-subnet-1」と入力します。

  4. ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。

  5. [ネットワーク] と [ノードのサブネット] を default に設定したままにします。これにより、GKE によってクラスタのサブネットが生成されます。

  6. [限定公開クラスタ] チェックボックスをオンにします。

  7. 承認済み外部 IP 範囲からアクセス可能なコントロール プレーンを作成するには、[外部 IP アドレスを使用したマスターへのアクセス] チェックボックスをオンのままにします。

  8. [マスター IP 範囲] を 172.16.0.0/28 に設定します。

  9. [マスター承認済みネットワークを有効にする] チェックボックスをオンにします。

  10. ナビゲーション パネルの [クラスタ] の下の [セキュリティ] をクリックします。

  11. [クライアント証明書を発行する] チェックボックスがオフになっていることを確認します。

  12. [作成] をクリックします。

API

Cluster API リソースの privateClusterConfig フィールドを指定します。

{
  "name": "private-cluster-1",
  ...
  "ipAllocationPolicy": {
    "createSubnetwork": true,
  },
  ...
    "privateClusterConfig" {
      "enablePrivateNodes": boolean # Creates nodes with internal IP addresses only
      "enablePrivateEndpoint": boolean # false creates a cluster control plane with a publicly-reachable endpoint
      "masterIpv4CidrBlock": string # CIDR block for the cluster control plane
      "privateEndpoint": string # Output only
      "publicEndpoint": string # Output only
  }
}

この時点で、クラスタ コントロール プレーンにアクセスできる IP アドレスは次のものに限られます。

  • my-subnet-1 のプライマリ範囲。
  • ポッドに使用されるセカンダリ範囲。

VPC ネットワークの外に、203.0.113.0/29 の範囲のアドレスを持つマシンのグループがあるとします。これらのマシンのパブリック エンドポイントへのアクセスを承認するには、次のコマンドを入力します。

gcloud container clusters update private-cluster-1 \
    --enable-master-authorized-networks \
    --master-authorized-networks 203.0.113.0/29

コントロール プレーンにアクセスできる唯一の IP アドレスは次のとおりです。

  • my-subnet-1 のプライマリ範囲。
  • Pod に使用されるセカンダリ範囲。
  • 承認したアドレス範囲(203.0.113.0/29 など)。

カスタム サブネットの使用

このセクションでは、private-cluster-2 という名前の限定公開クラスタを作成します。ネットワーク my-net-0 を作成します。クラスタノード用にサブネット my-subnet-2 を作成し、プライマリ範囲を 192.168.0.0/20 に指定します。サブネットには 2 つのセカンダリ アドレス範囲があります。my-pods-1ポッド の IP アドレス用、my-services-1サービス の IP アドレス用です。

gcloud

ネットワークの作成

まず、クラスタ用のネットワークを作成します。次のコマンドによって、ネットワーク my-net-0 が作成されます。

gcloud compute networks create my-net-0 \
    --subnet-mode custom

サブネットとセカンダリ範囲の作成

次に、ポッドのセカンダリ範囲を my-pods-2、サービスのセカンダリ範囲を my-services-2 に設定して、my-net-0 ネットワークに my-subnet-2 サブネットを作成します。

gcloud compute networks subnets create my-subnet-2 \
    --network my-net-0\
    --region us-central1 \
    --range 192.168.0.0/20 \
    --secondary-range my-pods-2=10.4.0.0/14,my-services-2=10.0.32.0/20 \
    --enable-private-ip-google-access

限定公開クラスタの作成

作成したネットワーク、サブネット、セカンダリ範囲を使用して、限定公開クラスタ private-cluster-1 を作成します。

gcloud container clusters create private-cluster-1 \
    --zone us-central1-c \
    --enable-master-authorized-networks \
    --network my-net-0 \
    --subnetwork my-subnet-2 \
    --cluster-secondary-range-name my-pods-2 \
    --services-secondary-range-name my-services-2 \
    --enable-private-nodes \
    --enable-ip-alias \
    --master-ipv4-cidr 172.16.0.16/28 \
    --no-enable-basic-auth \
    --no-issue-client-certificate

Console

ネットワーク、サブネット、セカンダリ範囲の作成

  1. Google Cloud Console の [VPC ネットワーク] ページにアクセスします。

    [VPC ネットワーク] ページに移動

  2. [VPC ネットワークを作成] をクリックします。

  3. [名前] に「my-net-0」と入力します。

  4. [サブネット作成モード] が [カスタム] に設定されていることを確認します。

  5. [新しいサブネット] の [名前] に「my-subnet-2」と入力します。

  6. [リージョン] プルダウン リストで、目的のリージョンを選択します。

  7. [IP アドレス範囲] に「192.168.0.0/20」と入力します。

  8. [セカンダリ IP 範囲を作成する] をクリックします。[サブネット範囲の名前] に「my-services-1」と入力し、[セカンダリ IP の範囲] に「10.0.32.0/20」と入力します。

  9. [IP の範囲を追加] をクリックします。[サブネット範囲の名前] に「my-pods-1」と入力し、[セカンダリ IP の範囲] に「10.4.0.0/14」と入力します。

  10. [限定公開の Google アクセス] で [オン] をクリックします。

  11. [完了] をクリックします。

  12. [作成] をクリックします。

限定公開クラスタの作成

サブネットを使用する限定公開クラスタを作成します。

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine のメニューに移動

  2. [クラスタを作成] ボタンをクリックします。

  3. [名前] に「private-cluster-2」と入力します。

  4. ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。

  5. [限定公開クラスタ] チェックボックスをオンにします。

  6. 承認済み外部 IP 範囲からアクセス可能なコントロール プレーンを作成するには、[外部 IP アドレスを使用したマスターへのアクセス] チェックボックスをオンのままにします。

  7. [マスター IP 範囲] を 172.16.0.16/28 に設定します。

  8. [ネットワーク] プルダウン リストで、[my-net-1] を選択します。

  9. [ノードのサブネット] プルダウン リストで、[my-subnet-2] を選択します。

  10. [セカンダリ範囲を自動的に作成する] チェックボックスをオフにします。

  11. [Pod のセカンダリ CIDR 範囲] プルダウン リストで、[my-pods-1] を選択します。

  12. [Service のセカンダリ CIDR 範囲] プルダウン リストで、[my-services-1] を選択します。

  13. [マスター承認済みネットワークを有効にする] チェックボックスをオンにします。

  14. ナビゲーション パネルの [クラスタ] の下の [セキュリティ] をクリックします。

  15. [クライアント証明書を発行する] チェックボックスがオフになっていることを確認します。

  16. [作成] をクリックします。

この時点では、コントロール プレーンにアクセスできる唯一の IP アドレスです。

  • my-subnet-2 のプライマリ範囲。
  • セカンダリ範囲 my-pods-1

my-net-1 の外に、203.0.113.0/29 の範囲のアドレスを持つマシンのグループがあるとします。これらのマシンのパブリック エンドポイントへのアクセスを承認するには、次のコマンドを入力します。

gcloud container clusters update private-cluster-1 \
    --enable-master-authorized-networks \
    --master-authorized-networks 203.0.113.0/29

この時点では、コントロール プレーンにアクセスできる唯一の IP アドレスです。

  • my-subnet-2 のプライマリ範囲。
  • セカンダリ範囲 my-pods-1
  • 承認したアドレス範囲(203.0.113.0/29 など)。

Cloud Shell を使用した限定公開クラスタへのアクセス

前の演習で作成した限定公開クラスタ private-cluster-1 にはパブリック エンドポイントがあり、承認済みネットワークが有効になっています。Cloud Shell を使用してクラスタにアクセスする場合は、Cloud Shell のパブリック IP アドレスをクラスタの承認済みネットワークのリストに追加する必要があります。

手順は次のとおりです。

  1. Cloud Shell のコマンドライン ウィンドウで、dig を使用して Cloud Shell の外部 IP アドレスを検索します。

    dig +short myip.opendns.com @resolver1.opendns.com
    
  2. Cloud Shell の外部アドレスをクラスタの承認済みネットワークのリストに追加します。

    gcloud container clusters update private-cluster-1 \
        --zone us-central1-c \
        --enable-master-authorized-networks \
        --master-authorized-networks existing-auth-nets,shell-IP/32
    

    ここで

    • existing-auth-nets は、承認済みネットワークの既存のリストです。承認済みネットワークは、コンソールまたは次のコマンドで確認できます。

      gcloud container clusters describe private-cluster-1 --format "flattened(masterAuthorizedNetworksConfig.cidrBlocks[])"
      
    • shell-IP は、Cloud Shell の外部 IP アドレスです。

  3. kubectl を使用してクラスタにアクセスできるように、認証情報を取得します。

    gcloud container clusters get-credentials private-cluster-1 \
        --zone us-central1-a \
        --project project-id
    

    ここで、project-id は、プロジェクト ID です。

Cloud Shell で kubectl を使用して、限定公開クラスタにアクセスできるようになりました。例:

kubectl get nodes

パブリック エンドポイントへ無制限にアクセス可能な限定公開クラスタの作成

このセクションでは、任意の IP アドレスでコントロール プレーンにアクセスできる限定公開クラスタを作成します。

gcloud

次のコマンドを実行します。

gcloud container clusters create private-cluster-2 \
    --create-subnetwork name=my-subnet-3 \
    --no-enable-master-authorized-networks \
    --enable-ip-alias \
    --enable-private-nodes \
    --master-ipv4-cidr 172.16.0.32/28 \
    --no-enable-basic-auth \
    --no-issue-client-certificate

ここで

  • --create-subnetwork name=my-subnet-3 を指定すると、GKE によって my-subnet-3 という名前のサブネットが自動的に作成されます。
  • --no-enable-master-authorized-networks は、クラスタの承認済みネットワークを無効にします。
  • --enable-ip-alias を指定すると、クラスタが VPC ネイティブになります。
  • --enable-private-nodes は、クラスタのノードに外部 IP アドレスがないことを示します。
  • --master-ipv4-cidr 172.16.0.32/28 は、コントロール プレーンの内部アドレス範囲を指定します。この設定はこのクラスタでは永続的です。RFC 1918 以外の内部 IP アドレスの使用がサポートされています。
  • --no-enable-basic-auth は、クラスタの基本認証を無効にすることを示します。
  • --no-issue-client-certificate は、クライアント証明書の発行を無効にします。

Console

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine のメニューに移動

  2. [クラスタを作成] ボタンをクリックします。

  3. [名前] に「private-cluster-2」と入力します。

  4. ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。

  5. [ネットワーク] と [ノードのサブネット] を default に設定したままにします。これにより、GKE によってクラスタのサブネットが生成されます。

  6. [限定公開クラスタ] オプションを選択します。

  7. [外部 IP アドレスを使用したマスターへのアクセス] チェックボックスをオンにしたままにします。

  8. [マスター IP 範囲] を 172.16.0.32/28 に設定します。

  9. [マスター承認済みネットワークを有効にする] チェックボックスをオフにします。

  10. ナビゲーション パネルの [クラスタ] の下の [セキュリティ] をクリックします。

  11. [クライアント証明書を発行する] チェックボックスがオフになっていることを確認します。

  12. [作成] をクリックします。

その他の限定公開クラスタ構成

前述の構成に加えて、次の構成で限定公開クラスタを実行できます。

プライベート ノードにインターネットへの送信アクセスを許可する

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

共有 VPC ネットワーク内での限定公開クラスタの作成

共有 VPC ネットワーク内で限定公開クラスタを作成する方法については、共有 VPC のドキュメントをご覧ください。

Windows Server コンテナ アプリケーションを限定公開クラスタにデプロイする

Windows Server コンテナ アプリケーションを限定公開クラスタにデプロイする方法については、Windows ノードプールのドキュメントをご覧ください。

グローバルにコントロール プレーンのプライベート エンドポイントにアクセスする

コントロール プレーンのプライベート エンドポイントは、コントロール プレーンの VPC ネットワーク内の内部 TCP / UDP ロードバランサによって実装されます。内部 TCP / UDP ロードバランサにアクセスできるのは、内部クライアントか、Cloud VPN トンネルと Cloud Interconnect VLAN アタッチメント経由で接続しているクライアントです。

デフォルトでは、これらのクライアントはロードバランサと同じリージョンに配置されている必要があります。

コントロール プレーンのグローバル アクセスを有効にすると、内部 TCP / UDP ロードバランサにグローバルにアクセスできるようになります。クライアント VM とオンプレミス システムは、承認済みネットワークの構成に従って、任意のリージョンからコントロール プレーンのプライベート エンドポイントに接続できます。

内部 TCP / UDP ロードバランサとグローバル アクセスの詳細については、内部ロードバランサと接続ネットワークをご覧ください。

コントロール プレーンのプライベート エンドポイント グローバル アクセスを有効にする

限定公開クラスタを作成するときに、デフォルトでは、コントロール プレーンのプライベート エンドポイントに対するグローバル アクセスが有効になっていません。コントロール プレーンのグローバル アクセスを有効にするには、gcloud または Google Cloud Console を使用します。

gcloud

enable-master-global-access フラグを追加して、コントロール プレーンのプライベート エンドポイントへのグローバル アクセスが有効な限定公開クラスタを作成します。

gcloud container clusters create cluster-name \
  --enable-private-nodes \
  --enable-ip-alias \
  --master-ipv4-cidr=172.16.16.0/28 \
  --enable-master-global-access

既存の限定公開クラスタのコントロール プレーンのプライベート エンドポイントへのグローバル アクセスを有効にすることもできます。

gcloud container clusters update cluster-name \
  --enable-master-global-access

Console

コントロール プレーンのグローバル アクセスを有効にした新しい限定公開クラスタを作成するには、次の手順を行います。

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine のメニューに移動

  2. [クラスタを作成] ボタンをクリックします。

  3. [名前] を入力します。

  4. ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。

  5. [限定公開クラスタ] チェックボックスをオンにします。

  6. [マスター グローバル アクセス] チェックボックスをオンにします。

  7. 必要に応じて他のフィールドを構成します。

  8. [作成] をクリックします。

既存の限定公開クラスタでコントロール プレーンのグローバル アクセスを有効にするには、次の手順を行います。

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine のメニューに移動

  2. 鉛筆の形をしたクラスタの編集ボタンをクリックします。

  3. [マスター グローバル アクセス] プルダウン リストから [有効] を選択します。

  4. [保存] をクリックします。

コントロール プレーンのプライベート エンドポイント グローバル アクセスを確認する

コントロール プレーンのプライベート エンドポイントへのグローバル アクセスが有効になっているかどうか確認するには、次のコマンドを実行して出力を表示します。

gcloud container clusters describe cluster-name

出力の privateClusterConfig セクションで masterGlobalAccessConfig のステータスを確認できます。

privateClusterConfig:
  enablePrivateNodes: true
  masterIpv4CidrBlock: 172.16.1.0/28
  peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer
  privateEndpoint: 172.16.1.2
  publicEndpoint: 34.68.128.12
  masterGlobalAccessConfig:
    enabled: true

オンプレミス ネットワークからコントロール プレーンのプライベート エンドポイントに接続する

GKE 限定公開クラスタを作成してコントロール プレーンのパブリック エンドポイントを無効にした場合も、kubectl のようなツールを使用して、オンプレミス ネットワークからコントロール プレーンのプライベート エンドポイントに接続できます。このセクションでは、オンプレミス ネットワークからコントロール プレーンのプライベート エンドポイントにアクセスするために必要なネットワーク要件について説明します。

次の図は、オンプレミス ネットワークと GKE コントロール プレーン ノード間のルーティング パスを示しています。

オンプレミス VPC とクラスタ コントロール プレーン間のルーティングを示す図

オンプレミス ネットワークからコントロール プレーンのプライベート エンドポイントに接続するには、次の作業を行います。

  1. クラスタの VPC ネットワークとコントロール プレーンの VPC ネットワークとのピアリングを特定します。

    gcloud container clusters describe cluster-name
    

    このコマンドの出力には、クラスタの privateClusterConfig.peeringName フィールドが含まれます。これは、クラスタとコントロール プレーンの VPC ネットワークとの間のピアリングの名前です。例:

    privateClusterConfig:
    enablePrivateNodes: true
    masterIpv4CidrBlock: 172.16.1.0/28
    peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer
    privateEndpoint: 172.16.1.2
    publicEndpoint: 34.68.128.12
    
  2. ピアリング関係のカスタムルートをコントロール プレーンの VPC ネットワークにエクスポートするように VPC ネットワークを構成します。コントロール プレーンの VPC ネットワークは、カスタムルートをインポートするように構成されています。これにより、コントロール プレーンのパスがオンプレミス リソースに返送されます。

    前のステップで特定したピアリング接続に対して、カスタムルートのエクスポートを有効にし、ピアリング接続を更新します。

  3. オンプレミス ネットワークからコントロール プレーンの VPC ネットワークへのトラフィックのパスを指定するには、次のいずれかを行います。

    • Cloud Interconnect と Cloud VPN の場合: Cloud Router のカスタムルート アドバタイズを使用してコントロール プレーンの CIDR 範囲をアドバタイズします。コントロール プレーンのグローバル アクセスが無効になっている場合、このカスタムルート アドバタイズは、クラスタと同じリージョン内の Cloud Router の BGP セッションに存在している必要があります。コントロール プレーンのグローバル アクセスが有効になっている場合、このカスタムルート アドバタイズは任意のリージョンの Cloud Router に配置できます。詳細は、カスタム IP 範囲のアドバタイジングをご覧ください。

    • 動的ルーティングを使用しない従来の Classic VPN トンネルの場合: オンプレミス ルーターでコントロール プレーンの CIDR 範囲の静的ルートを構成する必要があります。

オンプレミスのルート アドバタイズに関する考慮事項

オンプレミス ネットワークがクラスタの VPC ネットワーク内の Cloud Router にアドバタイズする CIDR は、次の条件に従う必要があります。

  • クラスタの VPC はデフォルト ルートを受け入れますが、コントロール プレーンの VPC ネットワークは 0.0.0.0/0 の宛先(デフォルト ルート)で常にルートを拒否します。これは、コントロール プレーンの VPC ネットワークにすでにローカルのデフォルト ルートが設定されているためです。ローカルのルートは常に優先されます。オンプレミス ルーターが VPC ネットワークでデフォルト ルートをアドバタイズする場合、特定のオンプレミス宛先もアドバタイズして、コントロール プレーンがオンプレミス ネットワークへのリターンパスを返す必要があります。これら特定の宛先は、VPC ネットワークでより範囲の狭いカスタム動的ルートになります。これら特定のルートは、VPC ネットワーク ピアリングを介してコントロール プレーンの VPC ネットワークで承認されます。

  • コントロール プレーンの VPC ネットワークが他の幅広いルートを受け入れると、Google API とサービスのパブリック IP アドレスへの接続は切断されます。一例として、宛先 0.0.0.0/1128.0.0.0/1 を持つルートをアドバタイズしないでください。代わりの方法については、前の説明をご覧ください。

  • Cloud Router の上限に注意してください。特に、学習したルートの一意の宛先の最大数に注意してください。

カスタムルートのエクスポートを無効にする

VPC からカスタムルートのエクスポートを無効にするには:

gcloud compute networks peerings update peering --network network --no-export-custom-routes

ここで

  • peeringprivateClusterConfig.peeringName の値です。
  • network は VPC の名前です。

peeringName を確認するには、カスタムルートのエクスポートを有効にする手順の最初のステップをご覧ください。

ノードに外部 IP アドレスがないことを確認する

プライベート クラスタの作成後は、クラスタのノードに外部 IP アドレスがないことを確認します。

gcloud

次のコマンドを実行します。

kubectl get nodes --output wide

出力の EXTERNAL-IP 列は空になります。

STATUS ... VERSION        EXTERNAL-IP  OS-IMAGE ...
Ready      v.8.7-gke.1                 Container-Optimized OS from Google
Ready      v1.8.7-gke.1                Container-Optimized OS from Google
Ready      v1.8.7-gke.1                Container-Optimized OS from Google

Console

  1. Cloud Console の GKE メニューに移動します。

    GKE メニューに移動

  2. クラスタのリストで、目的のクラスタをクリックします。

  3. [ノードプール] で、インスタンス グループの名前をクリックします。たとえば、gke-private-cluster-0-default-pool-5c5add1f-grp などです。

  4. インスタンスのリストで、インスタンスに外部 IP アドレスが指定されていないことを確認します。

クラスタのサブネットとセカンダリ アドレス範囲の表示

クラスタの作成後に、ユーザーまたは GKE によってクラスタに指定されたサブネットとセカンダリ アドレス範囲を表示できます。

gcloud

すべてのサブネットの一覧表示

クラスタのネットワークのサブネットを一覧表示するには、次のコマンドを実行します。

gcloud compute networks subnets list --network network

ここで、network は限定公開クラスタのネットワークです。自動的に作成されたサブネットでクラスタを作成した場合は、default を使用します。

コマンド出力で、クラスタのサブネットの名前を見つけます。

クラスタのサブネットの表示

自動的に作成されたサブネットについての情報を取得します。

gcloud compute networks subnets describe subnet-name

ここで、subnet-name はサブネットの名前です。

出力には、ノード用のプライマリ アドレス範囲(最初の ipCidrRange フィールド)と Pod と Service 用のセカンダリ範囲(secondaryIpRanges の下)が表示されます。

...
ipCidrRange: 10.0.0.0/22
kind: compute#subnetwork
name: gke-private-cluster-1-subnet-163e3c97
...
privateIpGoogleAccess: true
...
secondaryIpRanges:
- ipCidrRange: 10.40.0.0/14
  rangeName: gke-private-cluster-1-pods-163e3c97
- ipCidrRange: 10.0.16.0/20
  rangeName: gke-private-cluster-1-services-163e3c97
...

Console

  1. Cloud Console の [VPC ネットワーク] ページにアクセスします。

    [VPC ネットワーク] ページに移動

  2. サブネットの名前をクリックします。たとえば、gke-private-cluster-0-subnet-163e3c97 などです。

  3. [IP アドレス範囲] で、サブネットのプライマリ アドレス範囲を確認できます。これはノードに使用される範囲です。

  4. [セカンダリ IP 範囲] で、ポッドのアドレス範囲とサービスのアドレス範囲を確認できます。

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

限定公開クラスタのエンドポイントの表示には、gcloud コマンドライン ツールまたは Cloud Console を使用できます。

gcloud

次のコマンドを実行します。

gcloud container clusters describe cluster-name

出力には、プライベート エンドポイントとパブリック エンドポイントの両方が表示されます。

...
privateClusterConfig:
enablePrivateEndpoint: true
enablePrivateNodes: true
masterIpv4CidrBlock: 172.16.0.32/28
privateEndpoint: 172.16.0.34
publicEndpoint: 35.239.154.67

Console

  1. Cloud Console の GKE メニューに移動します。

    GKE メニューに移動

  2. リストで、目的のクラスタをクリックします。

  3. [詳細] タブの [クラスタ] で、[エンドポイント] フィールドを探します。

イメージ レジストリからコンテナ イメージを pull する

限定公開クラスタでは、コンテナ ランタイムはコンテナ イメージを Container Registry から pull できますが、インターネット上の他のコンテナ イメージ レジストリからイメージを pull することはできません。これは、限定公開クラスタ内のノードには外部 IP アドレスがなく、デフォルトでは Google ネットワーク外のサービスと通信できないためです。

限定公開クラスタ内のノードが、限定公開の Google アクセスが有効に設定されたサブネット上にある場合、Container Registry などの Google サービスと通信できます。

次のコマンドは、Google が所有する Container Registry リポジトリからサンプル イメージを pull する Deployment を作成します。

kubectl run hello-deployment --image gcr.io/google-samples/hello-app:2.0

特定のユースケースに対するファイアウォール ルールの追加

このセクションでは、限定公開クラスタにファイアウォール ルールを追加する方法について説明します。デフォルトでは、クラスタ コントロール プレーンはポート 443(HTTPS)および 10250(kubelet)上のみでノードへの TCP 接続を開始するようにファイアウォール ルールによって制限されています。一部の Kubernetes 機能では、他のポート上でアクセスを許可するためにファイアウォール ルールを追加する必要があります。

追加のファイアウォール ルールを必要とする Kubernetes 機能は次のとおりです。

ファイアウォール ルールを追加すると、クラスタ コントロール プレーンから次のポートへのトラフィックが許可されます。

  • 各ノードの指定ポート(hostPort)。
  • これらのノードで実行されている各 Pod の指定ポート。
  • こうしたノードで実行されている各 Service の指定ポート。

ファイアウォール ルールの詳細は、Cloud Load Balancing ドキュメントのファイアウォール ルールをご覧ください。

ファイアウォール ルールを限定公開クラスタに追加するには、使用するクラスタ コントロール プレーンの CIDR ブロックとターゲットを記録する必要があります。記録したらルールを作成します。

手順 1. コントロール プレーンの CIDR ブロックの表示

ファイアウォール ルールを追加するには、クラスタ コントロール プレーンの CIDR ブロックが必要です。

gcloud

次のコマンドを実行します。

gcloud container clusters describe cluster-name

cluster-name は限定公開クラスタの名前です。

コマンド出力で、masterIpv4CidrBlock フィールドの値をメモしておきます。

Console

  1. Cloud Console の GKE メニューに移動します。

    GKE メニューに移動

  2. 目的のクラスタを選択します。

[詳細] タブの [クラスタ] で、[マスター アドレスの範囲] フィールドの値をメモしておきます。

手順 2. 既存のファイアウォール ルールの表示

クラスタの既存のファイアウォール ルールが使用するターゲット(この場合は宛先ノード)を指定する必要があります。

gcloud

次のコマンドを実行します。

gcloud compute firewall-rules list \
    --filter 'name~^gke-cluster-name' \
    --format 'table(
        name,
        network,
        direction,
        sourceRanges.list():label=SRC_RANGES,
        allowed[].map().firewall_rule().list():label=ALLOW,
        targetTags.list():label=TARGET_TAGS
    )'

コマンド出力で、[ターゲット] フィールドの値をメモしておきます。

Console

  1. Cloud Console の [ファイアウォール ルール] メニューに移動します。

    [ファイアウォール ルール] メニューに移動

  2. [リソースをフィルタします] ボックスに「gke-cluster-name」と入力します。

結果として出力される [ターゲット] フィールドの値をメモしておきます。

手順 3. ファイアウォール ルールの追加

gcloud

次のコマンドを実行します。

gcloud compute firewall-rules create firewall-rule-name \
    --action ALLOW \
    --direction INGRESS \
    --source-ranges master-CIDR-block \
    --rules protocol:port \
    --target-tags target

ここで

  • firewall-rule-name は、ファイアウォール ルールに付ける名前です。
  • master-CIDR-block は、以前に収集したクラスタ コントロール プレーンの CIDR ブロック(masterIpv4CidrBlock)です。
  • protocol: port は、目的のポートとそのプロトコル(tcp または udp)です。
  • target は、以前に収集した目標(Targets)値です。

Console

  1. Cloud Console の [ファイアウォール ルール] メニューに移動します。

    [ファイアウォール ルール] メニューに移動

  2. [ファイアウォール ルールを作成] をクリックします。

  3. [名前] ボックスに、ファイアウォール ルールに付ける名前を入力します。

  4. [ネットワーク] プルダウン リストで、関連するネットワークを選択します。

  5. [トラフィックの方向] で [上り] をオンにします。

  6. [一致したときのアクション] で [許可] をオンにします。

  7. [ターゲット] プルダウン リストで、[指定されたターゲットタグ] を選択します。

  8. [ターゲットタグ] ボックスに、以前に収集したターゲット値を入力します。

  9. [ソースフィルタ] プルダウン リストで、[IP 範囲] を選択します。

  10. [ソース IP の範囲] ボックスに、以前に収集したクラスタ コントロール プレーンの CIDR ブロックを入力します。

  11. [プロトコルとポート] で [指定したプロトコルとポート] をオンにし、関連するプロトコル(TCP または UDP)のボックスをオンにして、そのボックスに目的のポートを入力します。

  12. [作成] をクリックします。

VPC Service Controls による限定公開クラスタの保護

VPC Service Controls を使用して GKE 限定公開クラスタの保護を強化します。

VPC Service Controls は GKE 限定公開クラスタ向けの追加のセキュリティ機能を提供して、データ漏洩のリスクを低減します。VPC Service Controls の活用により、境界の外部から発生するリクエストからリソースとサービスを保護するサービス境界にプロジェクトを追加できます。

サービス境界の詳細については、VPC Service Controls のドキュメントのサービス境界の構成のページをご覧ください。

Container Registry と GKE 限定公開クラスタを併用する場合、VPC Service Controls とこの限定公開クラスタを併用するための追加の手順を行う必要があります。詳細については、GKE 限定公開クラスタの Container Registry の設定ページをご覧ください。

VPC ピアリングの再利用

2020 年 1 月 15 日以降に作成した限定公開クラスタは、VPC ネットワーク ピアリング接続を再利用します

2020 年 1 月 15 日より前に作成した限定公開クラスタは、一意の VPC ネットワーク ピアリング接続を使用します。各 VPC ネットワークは最大 25 個の他の VPC ネットワークとピアリングできます。つまり、これらのクラスタはネットワーク当たりの限定公開クラスタ数が最大 25 個に制限されることになります(ピアリングが他の目的で使用されないことが前提)。

この機能は、以前のリリースには移植されていません。古い限定公開クラスタで VPC ネットワーク ピアリングを再利用できるようにするには、クラスタを削除して再作成する必要があります。クラスタをアップグレードしても、既存の VPC ネットワーク ピアリング接続は再利用されません。

各ロケーションは、限定公開クラスタの VPC ピアリング再利用が有効になっていれば、最大 75 個のクラスタをサポートできます。ゾーンとリージョンは別々のロケーションとして扱われます。たとえば、最大 75 個の限定公開ゾーンクラスタを us-east1-aに作成し、さらに 75 個の限定公開リージョン クラスタを us-east1に作成できます。これは、共有 VPC ネットワークで限定公開クラスタを使用している場合にも当てはまります。ひとつの VPC ネットワークへの最大接続数は 25 です。つまり、作成できるのは固有のロケーションを 25 個使用した限定公開クラスタだけということになります。

限定公開クラスタが VPC ピアリング接続を再利用しているかどうか調べることができます。

gcloud

gcloud container clusters describe cluster-name \
--zone=zone-name \
--format="value(privateClusterConfig.peeringName)"

クラスタが VPC ピアリング接続を再利用している場合、出力は gke-n で始まります。例: gke-n34a117b968dee3b2221-93c6-40af-peer

Console

クラスタの詳細ページで「VPC ピアリング」行を調べます。クラスタが VPC ピアリング接続を再利用している場合、出力は gke-n で始まります。例: gke-n34a117b968dee3b2221-93c6-40af-peer

クリーンアップ

このページのタスクを完了したら、アカウントで不要な請求が発生しないように、以下の手順でリソースを削除します。

クラスタを削除する

gcloud

gcloud container clusters delete -q private-cluster-0 private-cluster-1

Console

  1. Cloud Console の GKE メニューに移動します。

    GKE メニューに移動

  2. 各クラスタを選択します。

  3. [削除] をクリックします。

ネットワークを削除する

gcloud

gcloud compute networks delete net-0

Console

  1. Cloud Console の VPC ネットワーク ページに移動します。

    [VPC ネットワーク] ページに移動

  2. ネットワークのリストの [net-0] で、ゴミ箱アイコンをクリックします。

  3. 各サブネットの横にあるゴミ箱アイコンをクリックします。

要件、制約、制限

限定公開クラスタには次の要件があります。

限定公開クラスタには次の制約があります。

  • 既存の非限定公開クラスタを限定公開クラスタに変換することはできません。
  • 1.16.9 より前、または 1.17.0 から 1.17.4 までのバージョンを実行しているクラスタでは、クラスタ コントロール プレーンは 172.17.0.0/16 の CIDR から到達できません。
  • 1.14.4 より前のバージョンを実行しているクラスタでは、クラスタ コントロール プレーン、ノード、Pod、または Service の IP 範囲が 172.17.0.0/16 と重複してはなりません。
  • コントロール プレーンの IP 範囲に 172.17.0.0/16 を使用する場合、ノード、Pod、Service の IP アドレスにはこの範囲を使用できません。この制限は、バージョン 1.14.4 以降を実行するゾーンクラスタと、バージョン 1.16.9~1.17.0 または 1.17.4 以降を実行するリージョン クラスタに適用されます。
  • クラスタ コントロール プレーンとクラスタノード間の VPC ピアリングの削除、クラスタ コントロール プレーンからポート 10250 上のノードへの上り(内向き)トラフィックを許可するファイアウォール ルールの削除、デフォルトのインターネット ゲートウェイへのデフォルト ルートの削除を行うと、限定公開クラスタは機能しなくなります。デフォルト ルートの削除後に限定公開クラスタを再び起動するには、制限された VIP を静的にプロビジョニングする必要があります。
  • 1 つのプロジェクトに追加できる承認済みネットワーク(許可済み CIDR ブロック)は最大 50 個です。詳しくは、承認済みネットワークを既存のクラスタに追加するをご覧ください。

限定公開クラスタには次の制限があります。

  • クラスタ コントロール プレーンの RFC 1918 ブロックのサイズは、/28 でなければなりません。
  • GKE ではコントロール プレーンのアドレス ブロックとの重複を検出できますが、共有 VPC ネットワーク内の重複は検出できません。
  • 限定公開クラスタ内のすべてのノードはパブリック IP なしで作成され、Google の API とサービスへのアクセスが制限されます。プライベート ノードにインターネットへの送信アクセスを提供するには、Cloud NAT を使用するか、独自の NAT ゲートウェイを管理します。ノードが Google の API およびサービスと通信できるようにするには、サブネットで限定公開の Google アクセスを有効にします
  • 2020 年 1 月 15 日より前に作成した限定公開クラスタは、ネットワーク当たりの限定公開クラスタ数が最大 25 個に制限されます(ピアリングが他の目的で使用されないことが前提)。詳細は、VPC ピアリングの再利用をご覧ください。
  • すべての限定公開クラスタには、Google の VPC との間にピアリング ルートが必要ですが、一度に実行できるピアリング オペレーションは 1 つだけです。複数の限定公開クラスタを作成しようとすると、クラスタの作成がタイムアウトする場合があります。これを回避するには、後続の限定公開クラスタごとに既存の VPC ピアリング ルートが存在するように、限定公開クラスタを順次作成します。VPC で実行中のオペレーションがある場合、単一の限定公開クラスタを作成しようとしてもタイムアウトになることがあります。

トラブルシューティング

以降のセクションでは、限定公開クラスタに関連する一般的な問題を解決する方法について説明します。

クラスタがアクティブピアと重複している

現象
限定公開クラスタを作成しようとすると、Google Compute Engine: An IP range in the peer network overlaps with an IP range in an active peer of the local network. などのエラーが発生する。
考えられる原因
重複コントロール プレーン CIDR を選択している。
解決策
クラスタを削除して別のコントロール プレーン CIDR を使用して再作成します。

クラスタにアクセスできない

現象
限定公開クラスタを作成した後、クラスタに対して kubectl コマンドを実行しようとすると、Unable to connect to the server: dial tcp [IP_ADDRESS]: connect: connection timed outUnable to connect to the server: dial tcp [IP_ADDRESS]: i/o timeout などのエラーが返される。
考えられる原因
kubectl がクラスタ コントロール プレーンと通信できません。
解決策

ネットワークからクラスタ コントロール プレーンへの接続を許可するには、クラスタに承認済みネットワークを追加する必要があります。

クライアントがクラスタとは異なるリージョンから kubectl コマンドを使用する場合は、コントロール プレーンのプライベート エンドポイント グローバル アクセスが有効になっているかを確認してください。詳細については、コントロール プレーンのプライベート エンドポイントにアクセスするをご覧ください。

フラグが設定されていないためクラスタを作成できない

現象
gcloud container clusters create がエラー(Cannot specify --enable-private-endpoint without --enable-private-nodes. など)を返す。
考えられる原因
必要なフラグが指定されていない。
解決策
必要なフラグを指定してください。プライベート ノードを有効にしないと、クラスタ コントロール プレーンのプライベート エンドポイントを有効にできません。

IPv4 CIDR ブロックが重複しているためクラスタを作成できない

現象
gcloud container clusters create がエラー(The given master_ipv4_cidr 10.128.0.0/28 overlaps with an existing network 10.128.0.0/20. など)を返す。
考えられる原因
指定したコントロール プレーン CIDR ブロックが、VPC 内の既存のサブネットと重複している。
解決策
既存のサブネットと重複しない --master-ipv4-cidr の CIDR ブロックを指定します。

サブネットを作成できない

現象
自動サブネットを使用して限定公開クラスタを作成するか、カスタム サブネットを作成すると、An IP range in the peer network overlaps with an IP range in one of the active peers of the local network. というエラーが発生することがある。
考えられる原因
指定したコントロール プレーンの CIDR 範囲が、クラスタ内の別の IP 範囲と重複している。これは、限定公開クラスタを最近削除して、同じコントロール プレーン CIDR を使用して新しい限定公開クラスタを作成しようとする場合にも発生します。
解決策
別の CIDR 範囲を使用してみてください。

公開 Docker Hub からイメージを pull できない

現象
クラスタで実行中のポッドにで、kubectl describe を使用すると Failed to pull image: rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) などの警告が表示される。
考えられる原因
限定公開クラスタ内のノードが、公共のインターネットへの送信アクセスを許可されていない。Container Registry を含む Google API やサービスへのアクセスが制限されている。
解決策
Docker Hub から直接イメージを取得することはできません。代わりに、Container Registry でホストされているイメージを使用します。Container Registry の Docker Hub ミラーは限定公開クラスタからアクセスできますが、完全に信頼できるアクセスではありません。ミラーはキャッシュにすぎないため、イメージは定期的に削除され、限定公開クラスタは Docker Hub にフォールバックできません。

アドミッション Webhook のタイムアウトをトリガーする API リクエスト

現象

targetPort 443 以外でサービスを使用するアドミッション Webhook をトリガーする API がタイムアウトし、リクエストが失敗する。

Error from server (Timeout): request did not complete within requested timeout 30s
考えられる原因

デフォルトのファイアウォールでは、ポート 443(HTTPS)と 10250(kubelet)以外のノードへの TCP 接続は許可されません。トラフィックを許可するカスタム ファイアウォール ルールがない場合、443 以外のポートで Pod との通信を試みるアドミッション Webhook は失敗します。

解決策

特定のユースケースにファイアウォール ルールを追加します。

次のステップ