ユーザー クラスタを作成する（コントロール プレーン V2）

Version 1.15 

• Latest version
• Version 1.16
• Earlier versions (unsupported)

このドキュメントでは、コントロール プレーン V2 を有効にしてユーザー クラスタを作成する方法について説明します。

コントロール プレーン V2 では、ユーザー クラスタのコントロール プレーンはユーザー クラスタ自体の 1 つ以上のノードで実行されます。コントロール プレーン V2 は、クラスタ作成のデフォルトで推奨される設定です。

手順の概要

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

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

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

2. 構成ファイルの入力

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

3. （省略可）OS イメージを vSphere にインポートし、コンテナ イメージを以下に push します。

   プライベート レジストリ（該当する場合）。

   gkectl prepare を実行します。

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

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

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

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

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

準備

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

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

• ロード バランシングの概要を確認し、使用するロードバランサの種類に関する決定を再確認してください。バンドルされた MetalLB ロードバランサを使用することも、任意のロードバランサを手動で構成することもできます。手動ロード バランシングの場合は、ユーザー クラスタを作成する前にロードバランサを設定する必要があります。

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

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

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

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

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

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

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

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

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

name

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

gkeOnPremVersion

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

enableControlplaneV2

enableControlplaneV2 を true に設定します。

enableDataplaneV2

enableDataplaneV2 を true に設定します。

vCenter

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

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

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

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

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

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

個別の vSphere クラスタの使用

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

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

個別の vSphere データセンターの使用

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

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

個別の vCenter アカウントの使用

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

vCenter Server の個別のインスタンスの使用

特定の状況では、vCenter Server の独自のインスタンスを使用したユーザー クラスタの作成が合理的なことがあります。つまり、管理クラスタと関連ユーザー クラスタは、vCenter Server の異なるインスタンスを使用します。

たとえば、エッジ ロケーションで、vCenter Server を実行する物理マシンと ESXi を実行する 1 つ以上の物理マシンが必要になる場合があります。その後、vCenter Server のローカル インスタンスを使用して、データセンター、クラスタ、リソースプール、データストア、フォルダなど、vSphere オブジェクト階層を作成できます。

ユーザー クラスタの構成ファイルの vCenter セクション全体を入力します。特に、管理クラスタ構成ファイルで指定した vCenter Server アドレスとは異なる vCenter.address の値を指定します。次に例を示します。

vCenter:
  address: "vc-edge.example"
  datacenter: "vc-edge"
  cluster: "vc-edge-workloads"
  resourcePool: "vc-edge-pool
  datastore: "vc-edge-datastore
  caCertPath: "/usr/local/google/home/me/certs/edge-cacert.pem"
  credentials:
    fileRef:
      path: "credential.yaml"
      entry: "vCenter-edge"
  folder: "edge-vm-folder"

また、network.vCenter.networkName フィールドに入力します。

network

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

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

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

ワーカーノードに静的 IP アドレスを使用する場合は、network.ipMode.ipBlockFilePath フィールドに入力します。

ユーザー クラスタのコントロール プレーン ノードは、指定する静的アドレスのリストから IP アドレスを取得する必要があります。これは、ワーカーノードが DHCP サーバーからアドレスを取得する場合でも当てはまります。コントロール プレーン ノードの静的 IP アドレスを指定するには、network.controlPlaneIPBlock セクションに入力します。高可用性（HA）ユーザー クラスタが必要な場合は、3 つの IP アドレスを指定します。それ以外の場合は、1 つの IP アドレスを指定します。

hostConfig セクションに入力し、DNS サーバーと NTP サーバーを指定します。これらの DNS サーバーと NTP サーバーは、コントロール プレーン ノード用です。ワーカーノードに静的 IP アドレスを使用している場合、これらの DNS サーバーと NTP サーバーもワーカーノードに使用されます。

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

DHCP サーバーを使用するか、静的 IP アドレスのリストを指定するかにかかわらず、管理クラスタノードに十分な数の IP アドレスが必要です。必要な IP アドレスの数については、IP アドレスを計画するをご覧ください。

loadBalancer

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

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

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

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

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

advancedNetworking

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

multipleNetworkInterfaces

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

storage

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

masterNode

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

network.controlPlaneIPBlock セクションでコントロール プレーン ノードの IP アドレスを指定したことを思い出してください。

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 ブロック ファイルとユーザー クラスタ構成ファイルの例を示します。

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
      hostname: worker-vm-1
    - ip: 172.16.21.3
      hostname: worker-vm-2
    - ip: 172.16.21.4
      hostname: worker-vm-3
    - ip: 172.16.21.5
      hostname: worker-vm-4

user-cluster.yaml

cat user-cluster.yaml
apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.15.0-gke.581
enableControlplaneV2: true
enableDataplaneV2: true
network:
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  serviceCIDR: 10.96.0.0/20
  podCIDR: 192.168.0.0/16
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.6"
      hostname: "cp-vm-1"
    - ip: "172.16.21.7"
      hostname: "cp-vm-2"
    - ip: "172.16.21.8"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.21.30-172.16.21.39"
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  enableLoadBalancer: true
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

上記の例で理解しておくべき重要なポイントは、次のとおりです。

• ワーカーノードの静的 IP アドレスは、IP ブロック ファイルに指定されています。その IP ブロック ファイルには、ワーカーノードが 3 つしかない場合でも 4 つのアドレスがあります。その追加の IP アドレスは、クラスタのアップグレード、更新、自動修復に必要なものです。

• DNS サーバーと NTP サーバーは hostConfig セクションで指定されています。この例では、これらの DNS サーバーと NTP サーバーは、コントロール プレーン ノードおよびワーカーノードに使用されます。これは、ワーカーノードが静的 IP アドレスを持つためです。ワーカーノードが DHCP サーバーから IP アドレスを取得する場合、これらの DNS サーバーと NTP サーバーはコントロール プレーン ノードにのみ使用されます。

• コントロール プレーン ノード 3 つの静的 IP アドレスは、ユーザー クラスタ構成ファイルの network.controlPlaneIPBlock セクションで指定されます。このブロックに追加の IP アドレスは必要ありません。

• masterNode.replicas フィールドは 3 に設定されています。

• コントロール プレーン VIP と Ingress VIP は、どちらもワーカーノードとコントロール プレーン ノードと同じ VLAN にあります。

• LoadBalancer タイプの Service 用に確保された VIP は、ユーザー クラスタ構成ファイルの loadBalancer.metalLB.addressPools セクションで指定されています。これらの VIP は、ワーカーノードやコントロール プレーン ノードと同じ VLAN にあります。 このセクションで指定する VIP のセットには、Ingress VIP を含める必要があり、コントロール プレーン VIP を含めることはできません。

• ユーザー クラスタの構成ファイルには、vCenter セクションがありません。そのため、ユーザー クラスタは、管理クラスタと同じ vSphere リソースを使用します。

構成ファイルを検証する

ユーザー クラスタの構成ファイルに入力したら、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. （省略可）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: ユーザー クラスタの構成ファイルのパス

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

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

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 ファイルの名前と場所は、必要に応じて変更できます。

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

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

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

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

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

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

ユーザー クラスタをアップグレードする

Anthos clusters on VMware のアップグレードの手順を行います。

クラスタの削除

コントロール プレーン V2 が有効になっているユーザー クラスタを削除するには、ユーザー クラスタの削除の手順を実施します。

コントロール プレーン V2 が有効になっているユーザー クラスタを削除すると、データディスクが自動的に削除されます。

トラブルシューティング

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

次のステップ

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