ユーザー クラスタの作成

Version 1.14 

• 最新バージョン
• バージョン 1.16
• 以前のバージョン（サポート対象外）

このドキュメントでは、GKE on VMware のユーザー クラスタを作成する方法について説明します。ユーザー クラスタは、ワークロードを実行できる場所です。各ユーザー クラスタは、管理クラスタに関連付けられます。

管理クラスタとユーザー クラスタの詳細については、インストールの概要をご覧ください。

手順の概要

ユーザー クラスタの作成に関わる主な手順は以下のとおりです。

1. 管理ワークステーションに接続する

   管理ワークステーションは、ユーザー クラスタの作成に必要なツールを備えた VM です。

2. 構成ファイルの入力

   ユーザー クラスタ構成ファイル、認証情報構成ファイル、および状況により IP ブロック ファイルを完成させて、新しいクラスタの詳細を指定します。

3. （省略可）Seesaw ロードバランサを作成する

   Seesaw ロードバランサを使用する場合は、gkectl create loadbalancer を実行します。

4. （省略可）OS イメージを vSphere にインポートし、該当する場合はコンテナ イメージをプライベート レジストリに push します。

   gkectl prepare を実行します。

5. ユーザー クラスタを作成する

   gkectl create cluster を実行して、構成ファイルで指定されたとおりにクラスタを作成します。

6. ユーザー クラスタが実行されていることを確認する

   kubectl を使用してクラスタノードを表示します。

この手順が完了すると、ワークロードをデプロイできる実行中のユーザー クラスタが作成できます。

準備

• 管理ワークステーションと管理クラスタが作成されていることを確認します。

• IP アドレス計画のドキュメントを確認します。使用可能な IP アドレスが十分にあることを確認し、クラスタノードが DHCP または静的 IP アドレスを取得する方法を再確認します。静的 IP アドレスを使用する場合は、選択したアドレスを含む IP ブロック ファイルに入力する必要があります。

• ロード バランシングの概要を確認し、使用するロードバランサの種類に関する決定を再確認してください。特定のロードバランサについては、ユーザー クラスタを作成する前にロードバランサを設定する必要があります。

• vcenter セクションを確認します。管理クラスタとユーザー クラスタに別々の vSphere クラスタを使用するかどうか、さらに、別々のデータセンターを使用するかどうかを検討してください。

• nodePools セクションを確認します。必要なノードプールの数と、各プールで実行するオペレーティング システムを検討します。

1. 管理ワークステーションに接続する

管理ワークステーションへの SSH 接続を確立します。

gkeadm により、管理ワークステーションでコンポーネント アクセス サービス アカウントが有効にされたことを思い出してください。

このトピックの残りの手順はすべて、ホーム ディレクトリの管理ワークステーションで行います。

2. 構成ファイルに入力する

gkeadm が管理用ワークステーションを作成した際に、user-cluster.yaml という名前の構成ファイルが生成されました。この構成ファイルはユーザー クラスタの作成用です。

ユーザー クラスタの構成ファイルのドキュメントを詳しく調べて、構成ファイルをよく理解します。このドキュメントは別のタブまたはウィンドウで開いたままにしておくことをおすすめします。次の手順を実行する際にこれを参照するためです。

name

name フィールドにユーザー クラスタの名前を設定します。

gkeOnPremVersion

このフィールドはあらかじめ入力されています。GKE on VMware のバージョンを指定します。例: 1.11.0-gke.543

vCenter

管理クラスタの構成ファイルの vCenter セクションに設定する値はグローバルです。つまり、管理クラスタと管理クラスタに関連付けられたユーザー クラスタに適用されます。

作成する各ユーザー クラスタで、一部のグローバル vCenter 値をオーバーライドできます。

グローバル vCenter 値をオーバーライドするには、ユーザー クラスタ構成ファイルの vCenter セクションの関連するフィールドに入力します。

特に、管理クラスタとユーザー クラスタに別々の vSphere クラスタを使用する場合や、管理クラスタとユーザー クラスタに別々のデータセンターを使用する場合があります。

1 つのデータセンターと 1 つの vSphere クラスタを使用する

デフォルトのオプションでは、管理クラスタとユーザー クラスタの両方に 1 つのデータセンターと 1 つの vSphere クラスタを使用します。管理クラスタ構成ファイルの値は、ユーザー クラスタにも使用されます。ユーザー クラスタの構成ファイルには vCenter 値を設定しないでください。

別の vSphere クラスタにユーザー クラスタを作成する

独自の vSphere クラスタ内にユーザー クラスタを作成する場合は、ユーザー クラスタの構成ファイルで vCenter.cluster の値を指定します。

管理クラスタとユーザー クラスタが別々の vSphere クラスタにある場合、同じデータセンターまたは異なるデータセンターに配置できます。

別のデータセンターでユーザー クラスタを作成する

ユーザー クラスタと管理クラスタは、異なるデータセンターに配置できます。この場合は、これらのクラスタも別々の vSphere クラスタになります。

ユーザー クラスタの構成ファイルで vCenter.datacenter を指定する場合は、vCenter.datastore と vCenter.networkName も指定し、vCenter.cluster または vCenter.resourcePool のいずれかも指定する必要があります。

管理クラスタとユーザー クラスタに異なるデータセンターを使用するには、管理クラスタ データセンターの各ユーザー クラスタ コントロール プレーンに別のデータストアを作成することをおすすめします。そうすることで、管理クラスタ コントロール プレーンとユーザー クラスタ コントロール プレーンにデータストアに分離された障害発生ドメインが存在するようになります。ユーザー クラスタ コントロール プレーン ノードには管理クラスタ データストアを使用できますが、これによりユーザー クラスタ コントロール プレーン ノードと管理クラスタが同じデータストア障害ドメインに配置されます。

独自のデータセンター内に存在するユーザー クラスタの別の vCenter アカウント

ユーザー クラスタは、管理クラスタとは異なる vCenter.credentials を持つ別の vCenter アカウントを使用できます。管理クラスタの vCenter アカウントは管理クラスタのデータセンターにアクセスする必要がありますが、ユーザー クラスタの vCenter アカウントはユーザー クラスタ データセンターにのみアクセスする必要があります。

network

クラスタノードから IP アドレスを取得する方法を決めます。次のオプションがあります。

• 前もって設定した DHCP サーバーから。network.ipMode.type を "dhcp" に設定します。

• 指定した静的 IP アドレスのリストから。network.ipMode.type を "static" に設定し、静的 IP アドレスを提供する IP ブロック ファイルを作成します。IP ブロック ファイルの例については、入力済みの構成ファイルの例をご覧ください。

必要に応じて、[ネットワーク] セクションの残りのフィールドに入力します。

• クラスタノードに静的 IP アドレスを使用する場合は、network.ipMode.ipBlockFilePath フィールドと network.hostconfig セクションは必須です。network.hostconfig セクションには、クラスタノードで使用される NTP サーバー、DNS サーバー、DNS 検索ドメインに関する情報を掲載しています。

  Seesaw ロードバランサを使用している場合、クラスタノードに DHCP を使用する予定でも network.hostconfig セクションは必須です。

• network.podCIDR と network.serviceCIDR には、値が事前に設定されています。この値は、ネットワークですでに使用されているアドレスと競合しない限り変更できません。Kubernetes では、これらの範囲を使用してクラスタ内の Pod と Service に IP アドレスを割り当てます。

DHCP サーバーを使用するか、静的 IP アドレスのリストを指定するかにかかわらず、管理クラスタノードに十分な数の IP アドレスが必要です。これには、ユーザー クラスタのノードと、ユーザー クラスタのコントロール プレーンを実行する管理クラスタのノードが含まれます。必要な IP アドレスの数については、IP アドレスを計画するをご覧ください。

別の network.vCenter.networkName 値を持つユーザー クラスタ用のファイアウォール ルール

管理クラスタとユーザー クラスタは、それぞれの構成ファイルで、異なる VLAN と異なるデータセンターを表す別々の network.vCenter.networkName 値を使用できます。ただし、次の VLAN 間の通信が許可されている必要があります。

• ユーザーノードは、ユーザー クラスタのコントロール プレーン VIP アドレスのポート 443 と 8132 にアクセスし、そこから返信パケットを取得できます。

loadBalancer

ユーザー クラスタの Kubernetes API サーバー用に VIP を確保します。ユーザー クラスタの Ingress サービス用に別の VIP を確保します。loadBalancer.vips.controlPlaneVIP と loadBalancer.vips.ingressVIP の値として VIP を指定します。

詳細については、ユーザー クラスタ サブネットの VIP と管理クラスタ サブネットの VIP をご覧ください。

使用する負荷分散の種類を決めます。次のオプションがあります。

• MetalLB バンドルの負荷分散。loadBalancer.kind を "MetalLB" に設定します。また、loadBalancer.metalLB.addressPools セクションに入力し、少なくとも 1 つのノードプールの enableLoadBalancer を true に設定します。詳細については、MetalLB によるバンドルされた負荷分散をご覧ください。

• Seesaw によるバンドルされた負荷分散。loadBalancer.kind を "Seesaw" に設定し、loadBalancer.seesaw セクションに入力します。 詳細については、Seesaw によるバンドルされた負荷分散をご覧ください。

• F5 BIG-IP による統合負荷分散。loadBalancer.kind を "F5BigIP" に設定し、f5BigIP セクションに入力します。 詳細については、F5 BIG-IP による負荷分散をご覧ください。

• 手動負荷分散。loadBalancer.kind を "ManualLB" に設定し、manualLB セクションに入力します。詳細については、手動の負荷分散をご覧ください。

負荷分散のオプションの詳細については、負荷分散の概要をご覧ください。

enableDataplaneV2

ユーザー クラスタで Dataplane V2 を有効にするかどうかを決定し、それに応じて enableDataplaneV2 を設定します。

enableWindowsDataplaneV2

Windows ノードプールを作成する予定の場合は、Windows Dataplane V2 を有効にするかどうかを決定し、それに応じて enableWindowsDataplaneV2 を設定します。

advancedNetworking

下り（外向き） NAT ゲートウェイを作成する予定の場合は、advancedNetworking を true に設定します。

multipleNetworkInterfaces

Pod に複数のネットワーク インターフェースを構成するかどうかを決定し、それに応じて multipleNetworkInterfaces を設定します。

storage

vSphere CSI コンポーネントのデプロイを無効にする場合は、storage.vSphereCSIDisabled を true に設定します。

masterNode

ユーザー クラスタのコントロール プレーンは、管理クラスタ内のノードで実行されます。

masterNode セクションでは、ユーザー クラスタに必要なコントロール プレーンのノードの数を指定できます。コントロール プレーン ノードのデータストアと、ノードの自動サイズ変更を有効にするかどうかを指定することもできます。

nodePools

ノードプールとは、クラスタ内で同じ構成を持つノードのグループのことです。例えば、あるプールのノードは Windows を、別のプールのノードは Linux を実行することができます。

nodePools セクションに入力して、少なくとも 1 つのノードプールを指定する必要があります。

詳細については、ノードプールとノードプールの作成と管理をご覧ください。

antiAffinityGroups

antiAffinityGroups.enabled を true または false に設定します。

このフィールドは、GKE on VMware がユーザー クラスタノード用に Distributed Resource Scheduler（DRS）の反アフィニティ ルールを作成し、データセンター内の少なくとも 3 つの物理ホストに分散させるかどうかを指定します。

stackdriver

クラスタに対して Cloud Logging と Cloud Monitoring を有効にする場合は、stackdriver セクションに入力します。

デフォルトでは、このセクションは必須です。つまり、このセクションに入力しない場合、gkectl create cluster を実行する際に --skip-validation-stackdriver フラグを含める必要があります。

gkeConnect

ユーザー クラスタは Google Cloud フリートに登録されている必要があります。

gkeConnect セクションに値を入力し、フリート ホスト プロジェクトと関連するサービス アカウントを指定します。

usageMetering

クラスタで使用状況測定を有効にする場合は、usageMetering セクションに値を入力します。

cloudAuditLogging

クラスタの Kubernetes API サーバーの監査ログを Cloud Audit Logs と統合する場合は、cloudAuditLogging セクションに値を入力します。

入力済みの構成ファイルの例

入力済みの IP ブロック ファイルと、入力済みのユーザー クラスタ構成ファイルの例を以下に示します。この構成により、利用可能な機能のすべてではなく、一部が有効になります。

vc-01-ipblock-user.yaml

blocks:
  - netmask: 255.255.252.0
    gateway: 172.16.23.254
    ips:
    - ip: 172.16.20.21
      hostname: user-host1
    - ip: 172.16.20.22
      hostname: user-host2
    - ip: 172.16.20.23
      hostname: user-host3
    - ip: 172.16.20.24
      hostname: user-host4
    - ip: 172.16.20.25
      hostname: user-host5
    - ip: 172.16.20.26
      hostname: user-host6

vc-01-user-cluster.yaml

apiVersion: v1
kind: UserCluster
name: "gke-user-01"
gkeOnPremVersion: 1.11.0-gke.543
network:
  hostConfig:
    dnsServers:
    - "203.0.113.1"
    - "198.51.100.1"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: dhcp
    ipBlockFilePath: "vc-01-ipblock-user.yaml"
  serviceCIDR: 10.96.0.0/20
  podCIDR: 192.168.0.0/16
  vCenter:
    networkName: "vc01-net-1"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.32"
    ingressVIP: "172.16.21.30"
  kind: "MetalLB"
   metalLB:
    addressPools:
    - name: "gke-address-pool-01"
      addresses:
      - "172.16.21.30 - 172.16.21.39"
enableDataplaneV2: true
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 1
nodePools:
- name: "gke-node-pool-01"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  osImageType: "ubuntu_containerd"
antiAffinityGroups:
  enabled: true
gkeConnect:
  projectID: "my-project-123"
  registerServiceAccountKeyPath: "connect-register-sa-2203040617.json"
stackdriver:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  enableVPC: false
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
autoRepair:
  enabled: true

構成ファイルを検証する

ユーザー クラスタの構成ファイルに入力したら、gkectl check-config を実行してファイルが有効であることを検証します。

gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

以下を置き換えます。

• ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス

• USER_CLUSTER_CONFIG: ユーザー クラスタの構成ファイルのパス

コマンドがエラー メッセージを返した場合は、問題を修正してファイルを再度検証します。

時間のかかる検証をスキップする場合は、--fast フラグを渡します。個別の検証をスキップするには、--skip-validation-xxx フラグを使用します。check-config コマンドについて詳しくは、プリフライト チェックの実行をご覧ください。

3. （省略可）ユーザー クラスタの Seesaw ロードバランサを作成する

バンドル型の Seesaw ロードバランサを使用する場合は、このセクションの手順を行います。それ以外の場合は、このセクションをスキップします。

Seesaw ロードバランサの VM を作成して構成します。

gkectl create loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

4. （省略可）OS イメージを vSphere にインポートし、コンテナ イメージをプライベート レジストリに push する

次のいずれかに該当する場合は、gkectl prepare を実行します。

• ユーザー クラスタは、管理クラスタとは異なる vSphere データセンターにあります。

• ユーザー クラスタには、管理クラスタとは異なる vCenter Server があります。

• ユーザー クラスタが、管理クラスタで使用される非公開レジストリとは異なる非公開コンテナ レジストリを使用する。

gkectl prepare --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --bundle-path BUNDLE \
    --user-cluster-config USER_CLUSTER_CONFIG

以下を置き換えます。

• ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス

• BUNDLE: バンドル ファイルのパス。このファイルは、/var/lib/gke/bundles/ の管理ワークステーションにあります。次に例を示します。

  /var/lib/gke/bundles/gke-onprem-vsphere-1.14.0-gke.421-full.tgz
  

• USER_CLUSTER_CONFIG: ユーザー クラスタの構成ファイルのパス

5. ユーザー クラスタの作成

以下のようにユーザー クラスタを作成します。

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

ユーザー クラスタ kubeconfig ファイルを見つける

gkectl create cluster コマンドで、現在のディレクトリに USER_CLUSTER_NAME-kubeconfig という名前の kubeconfig ファイルが作成されます。この kubeconfig ファイルは後でユーザー クラスタとやり取りする際に必要になります。

kubeconfig ファイルには、ユーザー クラスタの名前が含まれています。クラスタ名を表示するには、次のコマンドを実行します。

kubectl config get-clusters --kubeconfig USER_CLUSTER_KUBECONFIG

出力に、クラスタの名前が表示されます。次に例を示します。

NAME
my-user-cluster

kubeconfig ファイルの名前と場所は、必要に応じて変更できます。

6. ユーザー クラスタが実行されていることを確認する

ユーザー クラスタが実行されていることを確認します。

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

USER_CLUSTER_KUBECONFIG は、ユーザー クラスタ kubeconfig ファイルのパスに置き換えます。

出力には、ユーザー クラスタノードが表示されます。次に例を示します。

my-user-cluster-node-pool-69-d46d77885-7b7tx   Ready ...
my-user-cluster-node-pool-69-d46d77885-lsvzk   Ready ...
my-user-cluster-node-pool-69-d46d77885-sswjk   Ready ...

トラブルシューティング

クラスタの作成とアップグレードに対するトラブルシューティングをご覧ください。

次のステップ

• Google Cloud コンソールからクラスタに接続する。
• アプリケーションをデプロイする