限定公開クラスタの作成

このページでは、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 ゾーン、リージョン クラスタまたは Autopilot クラスタの場合はデフォルトの Compute Engine リージョンを選択します。

gcloud config の使用

  • デフォルトのプロジェクト ID を設定します。
    gcloud config set project PROJECT_ID
  • ゾーンクラスタを使用する場合は、デフォルトのコンピューティング ゾーンを設定します。
    gcloud config set compute/zone COMPUTE_ZONE
  • Autopilot クラスタまたはリージョン クラスタを使用する場合は、デフォルトのコンピューティング リージョンを設定します。
    gcloud config set compute/region COMPUTE_REGION
  • gcloud を最新バージョンに更新します。
    gcloud components update
  • クラスタを作成するための適切な権限があることを確認します。少なくとも、Kubernetes Engine Cluster 管理者である必要があります。

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

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

gcloud

  • Standard クラスタの場合は、次のコマンドを実行します。

    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
    
  • Autopilot クラスタの場合は、次のコマンドを実行します。

    gcloud container clusters create-auto private-cluster-0 \
        --create-subnetwork name=my-subnet-0 \
        --enable-master-authorized-networks \
        --enable-private-nodes \
        --enable-private-endpoint
    

ここで

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

Console

  1. Cloud Console で Google Kubernetes Engine ページに移動します。

    Google Kubernetes Engine に移動

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

  3. [Standard] セクションまたは [Autopilot] セクションで、[構成] をクリックします。

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

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

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

  7. [外部 IP アドレスを使用してコントロール プレーンにアクセス] チェックボックスをオフにします。

  8. (Autopilot の場合は省略可): [コントロール プレーンの IP 範囲] を 172.16.0.32/28 に設定します。

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

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

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 は Pod 用と Service 用の 2 つのセカンダリ範囲を自動的に作成します。

gcloud コマンドライン ツールまたは GKE API を使用できます。

gcloud

  • Standard クラスタの場合は、次のコマンドを実行します。

    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
    
  • Autopilot クラスタの場合は、次のコマンドを実行します。

    gcloud container clusters create-auto private-cluster-1 \
        --create-subnetwork name=my-subnet-1 \
        --enable-master-authorized-networks \
        --enable-private-nodes
    

ここで

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

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 のプライマリ範囲。
  • Pod に使用されるセカンダリ範囲。

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-podsPod の IP アドレス用、my-servicesService の IP アドレス用です。

gcloud

ネットワークの作成

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

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

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

次に、ポッドのセカンダリ範囲を my-pods、サービスのセカンダリ範囲を my-services に設定して、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=10.4.0.0/14,my-services=10.0.32.0/20 \
    --enable-private-ip-google-access

限定公開クラスタの作成

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

  • Standard クラスタの場合は、次のコマンドを実行します。

    gcloud container clusters create private-cluster-2 \
        --zone us-central1-c \
        --enable-master-authorized-networks \
        --network my-net-0 \
        --subnetwork my-subnet-2 \
        --cluster-secondary-range-name my-pods \
        --services-secondary-range-name my-services \
        --enable-private-nodes \
        --enable-ip-alias \
        --master-ipv4-cidr 172.16.0.16/28 \
        --no-enable-basic-auth \
        --no-issue-client-certificate
    
  • Autopilot クラスタの場合は、次のコマンドを実行します。

    gcloud container clusters create-auto private-cluster-2 \
        --region us-central1 \
        --enable-master-authorized-networks \
        --network my-net-0 \
        --subnetwork my-subnet-2 \
        --cluster-secondary-range-name my-pods \
        --services-secondary-range-name my-services \
        --enable-private-nodes
    

Console

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

  1. 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」と入力し、[セカンダリ IP の範囲] に「10.0.32.0/20」と入力します。

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

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

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

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

限定公開クラスタの作成

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

  1. Cloud Console で Google Kubernetes Engine ページに移動します。

    Google Kubernetes Engine に移動

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

  3. [Standard] セクションまたは [Autopilot] セクションで、[構成] をクリックします。

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

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

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

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

  8. (Autopilot の場合は省略可)[コントロール プレーンの IP 範囲] を 172.16.0.16/28 に設定します。

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

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

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

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

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

  14. [コントロール プレーン承認済みネットワークを有効にする] チェックボックスをオンにします。

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

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

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

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

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

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

  • my-subnet-2 のプライマリ範囲。
  • セカンダリ範囲 my-pods
  • 承認したアドレス範囲(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: 既存の承認済みネットワークのリスト。Console で、または次のコマンドを実行して、承認済みネットワークを確認できます。

      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 に置き換えます。

  4. Cloud Shell で kubectl を使用して、限定公開クラスタにアクセスします。

    kubectl get nodes
    

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

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

gcloud

  • Standard クラスタの場合は、次のコマンドを実行します。

    gcloud container clusters create private-cluster-3 \
        --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
    
  • Autopilot クラスタの場合は、次のコマンドを実行します。

    gcloud container clusters create-auto private-cluster-3 \
        --create-subnetwork name=my-subnet-3 \
        --no-enable-master-authorized-networks \
        --enable-private-nodes
    

ここで

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

Console

  1. Cloud Console で Google Kubernetes Engine ページに移動します。

    Google Kubernetes Engine に移動

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

  3. [Standard] セクションまたは [Autopilot] セクションで、[構成] をクリックします。

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

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

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

  7. [外部 IP アドレスを使用してコントロール プレーンにアクセス] チェックボックスをオンのままにします。

  8. (Autopilot の場合は省略可)[コントロール プレーンの IP 範囲] を 172.16.0.32/28 に設定します。

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

  10. [コントロール プレーン承認済みネットワークを有効にする] チェックボックスをオフにします。

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

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

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

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

プライベート ノードにインターネットへの送信アクセスを提供する場合は、Cloud NAT を使用できます。

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

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

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

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

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

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

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

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

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

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

このセクションは、Standard モードで作成されたクラスタにのみ適用されます。

限定公開クラスタを作成するときに、デフォルトでは、コントロール プレーンのプライベート エンドポイントに対するグローバル アクセスが有効になっていません。コントロール プレーンのグローバル アクセスを有効にするには、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. [コントロール プレーン承認済みネットワークの編集] ダイアログで、[コントロール プレーン承認済みネットワークを有効にする] チェックボックスをオンにします。

  5. [変更を保存] をクリックします。

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

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

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_NAME \
    --network VPC_NAME \
    --no-export-custom-routes

以下を置き換えます。

  • PEERING_NAME: privateClusterConfig.peeringName の値。
  • VPC_NAME: 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 で Google Kubernetes Engine のページに移動します。

    Google Kubernetes Engine に移動

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

  3. [クラスタ] ページで、[ノード] タブをクリックします。

  4. [ノードプール] でノードプールの名前をクリックします。

  5. [ノードプールの詳細] ページの [インスタンス グループ] で、インスタンス グループの名前をクリックします。例: gke-private-cluster-0-default- pool-5c5add1f-grp

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

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

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

gcloud

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

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

gcloud compute networks subnets list \
    --network NETWORK_NAME

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

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

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

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

gcloud compute networks subnets describe SUBNET_NAME

SUBNET_NAME は、サブネットの名前に置き換えます。

出力には、ノード用のプライマリ アドレス範囲(最初の ipCidrRange フィールド)と Pod とサービス用のセカンダリ範囲(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 範囲] で、Pod のアドレス範囲とサービスのアドレス範囲を確認できます。

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

限定公開クラスタのエンドポイントを表示するには、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 で Google Kubernetes Engine のページに移動します。

    Google Kubernetes Engine に移動

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

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

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

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

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

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

kubectl run hello-deployment --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

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

このセクションでは、限定公開クラスタにファイアウォール ルールを追加する方法について説明します。デフォルトでは、クラスタ コントロール プレーンはポート 443(HTTPS)および 10250(kubelet)上のみでノードおよび Pod への 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 で Google Kubernetes Engine のページに移動します。

    Google Kubernetes Engine に移動

  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 の活用により、境界の外部から発生するリクエストからリソースとサービスを保護するサービス境界にプロジェクトを追加できます。

サービス境界の詳細については、サービス境界の詳細と構成をご覧ください。

Container Registry や Artifact Registry を GKE 限定公開クラスタと併用する場合、VPC Service Controls とこの限定公開クラスタを併用するための追加の手順を行う必要があります。詳細については、GKE 限定公開クラスタの Container Registry または Artifact 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 ネットワークで限定公開クラスタを使用している場合にも当てはまります。1 つの VPC ネットワークへの最大接続数は 25 です。つまり、作成できるのは固有のロケーションを 25 個使用した限定公開クラスタだけということになります。

VPC ネットワーク ピアリングの再利用は、同じロケーションのクラスタ(同じリージョン内のリージョン クラスタ、同じゾーン内のゾーンクラスタなど)にのみ適用されます。リージョン クラスタとゾーンクラスタの両方をそのリージョン内のすべてのゾーンに作成する場合は、リージョンごとに最大 4 つの VPC ネットワーク ピアリングを設定できます。

限定公開クラスタが VPC ネットワーク ピアリング接続を再利用するかどうかは、gcloud ツールまたは Google Cloud Console で確認できます。

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 private-cluster-2 private-cluster-3

Console

  1. Cloud Console で Google Kubernetes Engine のページに移動します。

    Google Kubernetes Engine に移動

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

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

ネットワークを削除する

gcloud

gcloud compute networks delete my-net-0

Console

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

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

  2. ネットワークのリストで、my-net-0 をクリックします。

  3. [VPC ネットワークの詳細] ページで、 [VPC ネットワークの削除] をクリックします。

  4. [ネットワークの削除] ダイアログで [削除] をクリックします。

要件、制約、制限

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

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

  • 既存の非限定公開クラスタを限定公開クラスタに変換することはできません。
  • 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 を静的にプロビジョニングする必要があります。
  • VPC でカスタムルートのエクスポートが有効になっている場合、Google IP の範囲と重複するルートを作成すると、クラスタが壊れる可能性があります。
  • 1 つのプロジェクトに追加できる承認済みネットワーク(許可済み CIDR ブロック)は最大 50 個です。詳しくは、承認済みネットワークを既存のクラスタに追加するをご覧ください。

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

  • クラスタ コントロール プレーンの RFC 1918 ブロックのサイズは、/28 でなければなりません。
  • GKE ではコントロール プレーンのアドレス ブロックとの重複を検出できますが、共有 VPC ネットワーク内の重複は検出できません。
  • 限定公開クラスタ内のすべてのノードはパブリック IP なしで作成され、Google の API とサービスへのアクセスが制限されます。プライベート ノードにインターネットへの送信アクセスを提供する場合は、Cloud NAT を使用できます。
  • 共有 VPC を使用している場合を除き、限定公開クラスタを作成すると、限定公開の Google アクセスが自動的に有効になります。NAT を使用してインターネットにアクセスしている場合を除き、限定公開の Google アクセスを無効にしないでください。
  • 2020 年 1 月 15 日より前に作成した限定公開クラスタは、ネットワークあたりの限定公開クラスタ数が最大 25 個に制限されます(ピアリングが他の目的で使用されないことが前提)。詳細は、VPC ピアリングの再利用をご覧ください。
  • すべての限定公開クラスタには、Google の VPC との間にピアリング ルートが必要ですが、一度に実行できるピアリング オペレーションは 1 つだけです。複数の限定公開クラスタを作成しようとすると、クラスタの作成がタイムアウトする場合があります。これを回避するには、後続の限定公開クラスタごとに既存の VPC ピアリング ルートが存在するように、限定公開クラスタを順次作成します。VPC で実行中のオペレーションがある場合、単一の限定公開クラスタを作成しようとしてもタイムアウトになることがあります。
  • 追加のノードに対応するサブネットのプライマリ IP 範囲を拡張する場合は、拡張サブネットのプライマリ IP アドレス範囲をマスター承認済みネットワークのリストに追加する必要があります。これを行わないと、マスターに関連する上り(内向き)許可ファイアウォール ルールが更新されず、拡張 IP アドレス空間に作成される新しいノードがマスターに登録できなくなります。そのため、新しいノードが継続的に削除され、置き換えられることで、停止に陥る可能性があります。このような停止は、ノードプールのアップグレードを行う場合や、liveness Probe の失敗によってノードが自動的に置き換えられる場合に発生することがあります。
  • 自動的に作成されたファイアウォール ルールよりも高い優先度のファイアウォール ルールまたは階層型ファイアウォール ポリシー ルールを作成しないでください。

トラブルシューティング

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

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

現象

限定公開クラスタを作成しようとすると、次のようなエラーが返される。

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 out.
Unable 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 を実行すると、クラスタで実行中の Pod で警告が表示されることがある。

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)
考えられる原因

限定公開クラスタ内のノードに外部 IP アドレスが指定されていないため、インターネット アクセスの要件を満たしていません。ただし、限定公開の Google アクセスが有効になっており、ネットワーク要件を満たしている場合、ノードから Google APIs とサービス(Artifact Registry、Container Registry など)にはアクセスできます。

解決策

次のいずれかの方法を使用します。

  • 限定公開クラスタのイメージを Docker Hub から Artifact Registry にコピーします。詳細については、サードパーティ レジストリからのコンテナの移行をご覧ください。

  • そのまま GKE で、mirror.gcr.io に、よくアクセスされる Docker Hub イメージのキャッシュに保存されたコピーがあるかどうかを調べます。

  • Docker Hub または別の公開リポジトリからイメージを pull する必要がある場合は、Cloud NAT または静的 0.0.0.0/0 ルートのターゲットであるインスタンス ベースのプロキシを使用します。

アドミッション 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 は失敗します。

解決策

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

ヘルスチェックに失敗したためクラスタを作成できない

現象

限定公開クラスタを作成すると、ヘルスチェックのステップが停止し、次のようなエラーが返される。

All cluster resources were brought up, but only 0 of 2 have registered.
考えられる原因

限定公開の Google アクセスでは *.gcr.io に DNS を構成する必要があります。

解決策

次のいずれかの方法を使用します。

作成された限定公開クラスタノードがクラスタに参加しない

多くの場合、限定公開クラスタで使用されている VPC でカスタム ルーティングとサードパーティ ネットワーク アプライアンスを使用すると、デフォルトのインターネット ゲートウェイではなく、アプライアンスにデフォルト ルート(0.0.0.0/0)がリダイレクトされます。コントロール プレーンの接続だけでなく、次の宛先に到達できるようにする必要があります。

  • *.googleapis.com
  • *.gcr.io
  • gcr.io

3 つのドメインすべてに対して限定公開の Google アクセスを構成します。このベスト プラクティスでは、インターネットにバインドされたトラフィックを制限しながら、新しいノードが起動してクラスタに参加できるようになります。

次のステップ