Google Distributed Cloud では、ワークロードは 1 つ以上のユーザー クラスタで実行されます。このページでは、Google Distributed Cloud のトポロジ ドメインで使用するユーザー クラスタを作成する方法について説明します。トポロジ ドメインを使用するには、Google Distributed Cloud バージョン 1.31 以降が必要です。
トポロジ ドメインを設定するには、高度なクラスタを有効にする必要があります。高度なクラスタ プレビューには次の制限事項があります。
- 高度なクラスタは、新しい 1.31 クラスタのクラスタ作成時にのみ有効にできます。
- 高度なクラスタを有効にすると、クラスタを 1.32 にアップグレードできなくなります。高度なクラスタはテスト環境でのみ有効にします。
このページは、技術インフラストラクチャの設定、モニタリング、管理を行う管理者、アーキテクト、オペレーターを対象としています。 Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。
始める前に
管理ワークステーションを作成するの説明に従って、管理ワークステーションを設定してログインできることを確認します。管理ワークステーションには、ユーザー クラスタの作成に必要なツールが備わっています。このドキュメントのすべての手順は管理ワークステーションで行います。
まだ設定していない場合は、次のドキュメントの説明に沿って Google Cloud リソースを設定します。
ユーザー クラスタを作成する前に、ユーザー クラスタを管理するための管理クラスタが必要です。まだ作成していない場合は、管理ワークステーションとトポロジ ドメインで使用する管理クラスタを作成します。
インストールするユーザー クラスタのバージョンを決定します。通常、ユーザー クラスタを作成するときに、管理クラスタと同じバージョンをインストールします。ユーザー クラスタに別のバージョンをインストールする場合は、バージョン ルールをご覧ください。
IP アドレスの計画に関するドキュメントを参照して、十分な IP アドレスが利用できることを確認します。
手動ロード バランシング用にロードバランサを構成します。ユーザー クラスタを作成する前に、ロードバランサを設定する必要があります。
必要なノードプールの数と、各プールで実行するオペレーティング システムについて検討します。
vCenter Server の各インスタンスにアクセスするために必要な情報を収集します。この情報は、vSphere インフラストラクチャ構成ファイルの
SecretセクションとVSphereInfraConfig.credentials.vCentersセクションに入力するために必要です。必要な情報を取得する方法については、以下をご覧ください。
手順の概要
gkectl を使用してユーザー クラスタを作成する主な手順は次のとおりです。
- ユーザー クラスタの構成ファイルに入力する
- ユーザー クラスタの構成ファイルで、新しいクラスタの詳細を指定します。
- IP ブロック ファイルに入力する
- ゲートウェイ、ネットマスク、コントロール プレーン ノードの IP アドレスを指定します。必要に応じて、IP ブロック ファイルでワーカーノードの IP アドレスも指定します。
- ユーザー クラスタを作成する
gkectl create clusterを実行して、構成ファイルに指定されたとおりにクラスタを作成します。
- ユーザー クラスタが実行されていることを確認する
kubectlを使用してクラスタノードを表示します。
この手順が完了すると、ワークロードをデプロイできる実行中のユーザー クラスタが作成できます。
ユーザー クラスタの構成ファイルに入力する
gkeadm を使用して管理ワークステーションを作成した場合、gkeadm によりユーザー クラスタの構成ファイル user-cluster.yaml のテンプレートが生成されます。また、gkeadm によって一部のフィールドに入力されます。
管理ワークステーションの作成に gkeadm を使用していない場合、gkectl を使用してユーザー クラスタの構成ファイルのテンプレートを生成できます。
ユーザー クラスタの構成ファイルのテンプレートを生成するには:
gkectl create-config cluster --config=OUTPUT_FILENAME --gke-on-prem-version=VERSION
次のように置き換えます。
OUTPUT_FILENAME: 生成されたテンプレートに対する任意のパス。このフラグを省略すると、gkectl はファイルに user-cluster.yaml という名前を付け、現在のディレクトリに配置します。
VERSION: 目的のバージョン番号。例: gkectl create-config cluster --gke-on-prem-version=1.31.0-gke.889。
ユーザー クラスタの構成ファイルのドキュメントを詳しく調べて、構成ファイルをよく理解します。このドキュメントは別のタブまたはウィンドウで開いたままにしておくことをおすすめします。次の手順を実行する際にこれを参照するためです。
name
name フィールドにユーザー クラスタの名前を設定します。
gkeOnPremVersion
このフィールドはあらかじめ入力されています。ここには Google Distributed Cloud のバージョンを指定します。例: 1.31.0-gke.889
enableAdvancedCluster
enableAdvancedCluster を true に設定します。
enableControlplaneV2
バージョン 1.30 以降のすべてのユーザー クラスタに Controlplane V2 が必要です。enableControlplaneV2 を true に設定します。
Controlplane V2 が有効になっている場合、ユーザー クラスタのコントロール プレーンはそのユーザー クラスタのノードで実行されます。
enableDataplaneV2
enableDataplaneV2 を true に設定します。
vCenter
このセクション全体を削除します。代わりに、トポロジ ドメインごとに vSphere インフラストラクチャ構成ファイルで vCenter 情報を構成します。
network
構成ファイルから次の行を削除します。
network.hostConfigセクション全体。この情報は、トポロジ ドメインごとに vSphere インフラストラクチャ構成ファイルで構成されます。network.vCenter.networkNameフィールド。このフィールドは、トポロジ ドメインごとに vSphere インフラストラクチャ構成ファイルで構成されます。network.controlPlaneIPBlockセクション全体。ゲートウェイ、ネットマスク、コントロール プレーン ノードの IP アドレスは、IP ブロック ファイルで構成されます。
network.ipMode.ipBlockFilePathを IP ブロック ファイルのパスに設定します。ワーカーノードから IP アドレスを取得する方法を決めます。次のオプションがあります。
前もって設定した DHCP サーバーから。
network.ipMode.typeを"dhcp"に設定します。IP ブロック ファイルで指定した静的 IP アドレスのリストから。
network.ipMode.typeを"static"に設定する。
ユーザー クラスタのコントロール プレーン ノードは、IP ブロック ファイルで指定した静的アドレスのリストから IP アドレスを取得する必要があります。これは、ワーカーノードが DHCP サーバーからアドレスを取得する場合でも当てはまります。
DHCP サーバーを使用するか、静的 IP アドレスのリストを指定するかにかかわらず、ユーザー クラスタに十分な数の IP アドレスが必要です。必要な IP アドレスの数については、IP アドレスを計画するをご覧ください。
network.podCIDR と network.serviceCIDR には、値が事前に設定されています。この値は、ネットワークですでに使用されているアドレスと競合しない限り変更できません。Kubernetes では、これらの範囲を使用してクラスタ内の Pod と Service に IP アドレスを割り当てます。
loadBalancer
ユーザー クラスタの Kubernetes API サーバー用に VIP を確保します。
loadBalancer.vips.controlPlaneVIPの値として VIP を指定します。ユーザー クラスタの Ingress サービス用に別の VIP を確保します。
loadBalancer.vips.ingressVIPの値として VIP を指定します。loadBalancer.kindを"ManualLB"に設定し、manualLBセクションに入力します。詳細については、手動の負荷分散をご覧ください。
advancedNetworking
下り（外向き） NAT ゲートウェイを作成する予定の場合は、advancedNetworking を true に設定します。
multipleNetworkInterfaces
multipleNetworkInterfaces を false に設定します。トポロジ ドメインでは、Pod の複数のネットワーク インターフェースはサポートされていません。
storage
vSphere CSI コンポーネントのデプロイを無効にするには、storage.vSphereCSIDisabled を true に設定します。
masterNode
ユーザー クラスタのコントロール プレーン ノードの CPU とメモリを指定する場合は、
masterNodeセクションのcpusとmemoryMBフィールドに入力します。高可用性（HA）クラスタのみがサポートされます。
replicasフィールドを3に設定して、クラスタに 3 つのコントロール プレーン ノードがあることを指定します。コントロール プレーン ノードの自動サイズ変更を有効にするには、
autoResize.enabledをtrueに設定します。masterNode.vsphereセクション全体を削除します。masterNode.topologyDomainsフィールドに、コントロール プレーン ノードを配置するトポロジ ドメインの名前を入力します。
nodePools
ノードプールとは、クラスタ内のワーカーノードのグループで、すべてが同じ構成です。たとえば、ノードプールごとに個別のトポロジ ドメインを設定できます。nodePools セクションに、少なくとも 1 つのノードプールを指定する必要があります。
指定するノードプールごとに、以下を行います。
nodePools[i].topologyDomainsフィールドに、ノードプールを配置するトポロジ ドメインの名前を入力します。nodePools[i].vsphereセクションのnodePools[i].vsphere.tagsを除くすべてのフィールドを削除します。この情報は、トポロジ ドメインごとに vSphere インフラストラクチャ構成ファイルで指定します。
# advanced-cluster-change #
nodePools[i].osImageType を ubuntu_cgroupv2 または ubuntu_containerd に設定します。
ノードプールに関する一般的な情報については、ノードプールとノードプールの作成と管理をご覧ください。
antiAffinityGroups
antiAffinityGroups.enabled を false に設定します。Distributed Resource Scheduler（DRS）の反アフィニティ ルールは、トポロジ ドメインではサポートされていません。
stackdriver
stackdriver セクションに入力して、クラスタで Cloud Logging と Cloud Monitoring を有効にします。
次の要件に注意してください。
stackdriver.projectIDの ID は、gkeConnect.projectIDとcloudAuditLogging.projectIDの ID と同じでなければなりません。stackdriver.clusterLocationで設定された Google Cloud リージョンは、cloudAuditLogging.clusterLocationとgkeConnect.locationで設定されたリージョンと同じである必要があります。さらに、gkeOnPremAPI.enabledがtrueの場合、gkeOnPremAPI.locationに同じリージョンを設定する必要があります。
プロジェクト ID とリージョンが同じでない場合、クラスタの作成は失敗します。
gkeConnect
ユーザー クラスタは、 Google Cloud フリートに登録されている必要があります。
gkeConnect セクションに値を入力し、フリート ホスト プロジェクトと関連するサービス アカウントを指定します。gkeConnect.projectID の ID は、stackdriver.projectID と cloudAuditLogging.projectID に設定された ID と同じでなければなりません。プロジェクト ID が同じでない場合、クラスタの作成は失敗します。
必要に応じて、gkeConnect.location で Fleet サービスと Connect サービスを実行するリージョンを指定できます。このフィールドを含めない場合、クラスタはこれらのサービスのグローバル インスタンスを使用します。
構成ファイルに gkeConnect.location を含める場合、指定するリージョンは、cloudAuditLogging.clusterLocation、stackdriver.clusterLocation、gkeOnPremAPI.location で構成されたリージョンと同じにする必要があります。リージョンが同じでない場合、クラスタの作成は失敗します。
gkeOnPremAPI
このセクションでは、クラスタを GKE On-Prem API に登録する方法について説明します。
トポロジ ドメインを使用するクラスタで使用できるクラスタ ライフサイクル管理ツールは gkectl コマンドライン ツールのみです。 Google Cloud コンソール、Google Cloud CLI、Terraform は、トポロジ ドメインを使用するクラスタではサポートされていませんが、必要に応じて、クラスタの作成時に GKE On-Prem API にクラスタを登録できます。
Google Cloud プロジェクトで GKE On-Prem API が有効になっている場合、プロジェクト内のすべてのクラスタは、stackdriver.clusterLocation で構成されたリージョンの GKE On-Prem API に自動的に登録されます。gkeOnPremAPI.location リージョンは、cloudAuditLogging.clusterLocation、gkeConnect.location、stackdriver.clusterLocation で指定されたリージョンと同じリージョンにする必要があります。
GKE On-Prem API のプロジェクトにすべてのクラスタを登録する場合は、始める前にの手順に沿って、プロジェクト内の GKE On-Prem API を有効にしてから使用します。
GKE On-Prem API にクラスタを登録しない場合は、このセクションを追加して、
gkeOnPremAPI.enabledをfalseに設定します。プロジェクトにクラスタを登録しない場合は、プロジェクトでgkeonprem.googleapis.com（GKE On-Prem API のサービス名）を無効にします。手順については、サービスの無効化をご覧ください。
cloudAuditLogging
クラスタの Kubernetes API サーバーの監査ログを Cloud Audit Logs と統合する場合は、cloudAuditLogging セクションに値を入力します。
次の要件に注意してください。
# advanced-cluster-change #
cloudAuditLogging.serviceAccountKeyPath を stackdriver.serviceAccountKeyPath と同じパスに設定します。
cloudAuditLogging.projectIDの ID は、gkeConnect.projectIDとstackdriver.projectIDの ID と同じでなければなりません。cloudAuditLogging.clusterLocationのリージョンは、gkeConnect.locationで設定されたリージョン（フィールドが構成ファイルに含まれている場合）およびstackdriver.clusterLocationと同じリージョンにする必要があります。さらに、gkeOnPremAPI.enabledがtrueの場合、gkeOnPremAPI.locationに同じリージョンを設定する必要があります。
プロジェクト ID とリージョンが同じでない場合、クラスタの作成は失敗します。
preparedSecrets
preparedSecrets フィールドを削除します。トポロジ ドメインが有効になっている場合、準備済み認証情報はサポートされていません。
入力済みの構成ファイルの例
こちらは 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
- netmask: 255.255.255.0
gateway: 100.115.223.254
ips:
- ip: 100.115.222.205
hostname: cp-1
isControlPlane: true
- ip: 100.115.222.206
hostname: cp-2
isControlPlane: true
- ip: 100.115.222.207
hostname: cp-3
isControlPlane: true
user-cluster.yaml
cat user-cluster.yaml
apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.31.0-gke.889
enableAdvancedCluster: true
enableControlplaneV2: true
enableDataplaneV2: true
network:
ipMode:
type: "static"
ipBlockFilePath: "user-ipblock.yaml"
serviceCIDR: 10.96.0.0/20
podCIDR: 192.168.0.0/16
loadBalancer:
vips:
controlPlaneVIP: "100.115.222.200"
ingressVIP: "172.16.21.30"
kind: "ManualLB"
manualLB:
ingressHTTPNodePort: 32527
ingressHTTPSNodePort: 30139
controlPlaneNodePort: 30968
masterNode:
cpus: 4
memoryMB: 8192
replicas: 3
nodePools:
- name: "worker-node-pool1"
cpus: 4
memoryMB: 8192
replicas: 3
topologyDomains:
- "domain1"
antiAffinityGroups:
enabled: false
gkeConnect:
projectID: "my-project-123"
location: "us-central1"
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
上記の例で理解しておくべき重要なポイントは、次のとおりです。
nodePools.replicasフィールドが3に設定されているため、"worker-node-pool"には 3 つのワーカーノードがあります。network.ipMode.typeが"static"に設定されているため、すべてのワーカーノードが静的 IP アドレスを使用します。コントロール プレーン ノードとワーカーノードの IP アドレスは、IP ブロック ファイルで指定されます。その IP ブロック ファイルには、ワーカーノードが 3 つしかない場合でも 4 つのアドレスがあります。追加のワーカーノード IP アドレスは、クラスタのアップグレード、更新、自動修復中に必要になります。コントロール プレーン ノードの IP アドレスには
isControlPlane: trueフラグが設定されています。アドバンスト クラスタ、Controlplane V2、Dataplane V2 が有効になっています。
masterNode.replicasフィールドが3に設定されているため、クラスタには高可用性コントロール プレーンがあります。コントロール プレーン VIP はコントロール プレーン ノードと同じ VLAN にあり、上り（内向き）VIP はワーカーノードと同じ VLAN にあります。
IP ブロック ファイルに入力する
IP ブロック ファイルのテンプレートを、ユーザー クラスタ構成ファイルの network.ipMode.ipBlockFilePath フィールドで指定したディレクトリ内のファイルにコピーします。管理クラスタと各ユーザー クラスタに個別の IP ブロック ファイルを作成します。
ゲートウェイ、ネットマスク、コントロール プレーン ノードの IP アドレスを IP ブロック ファイルに追加します。コントロール プレーン ノードの IP アドレスごとに、前の例に示すように isControlPlane: true を追加します。高可用性（HA）ユーザー クラスタが必要な場合は、3 個の IP アドレスを指定します。それ以外の場合は、1 個の IP アドレスを指定します。コントロール プレーン ノードに指定する IP アドレスの数は、ユーザー クラスタ構成ファイルの masterNode.replicas フィールドの数と一致する必要があります。
network.ipMode.type が "static" に設定されている場合は、ワーカーノードの IP アドレスを IP ブロック ファイルに追加します。クラスタのアップグレード、更新、自動修復中に使用する追加の IP アドレスを 1 つ指定してください。
IP ブロック ファイル内の各ゲートウェイ アドレスは、vSphere インフラストラクチャ構成ファイルの topologyDomains[i].network.gateway フィールドで指定されたアドレスと一致する必要があります。詳細については、トポロジ ドメインの例をご覧ください。
ユーザー クラスタを作成する
次のコマンドを実行して、ユーザー クラスタを作成します。
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 ファイルの名前と場所は、必要に応じて変更できます。
ユーザー クラスタが実行されていることを確認する
ユーザー クラスタが実行されていることを確認します。
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
PodTemplate を設定する
トポロジラベルは、トポロジ ドメイン内のノードのラベルに入力されます。トポロジ ドメインの設定で、トポロジ キーとしてデフォルトの制約 "topology.kubernetes.io/zone" を使用している場合を除き、Deployment、StatefulSet、または ReplicaSet の Pod テンプレートでトポロジ キーを構成する必要があります。
たとえば、トポロジラベルでキーを "topology.examplepetstore.com/zone" と定義したとします。PodTemplate で、topologySpreadConstraints.topologyKey フィールドの値としてキーを指定します。これにより、Kubernetes スケジューラはトポロジ ドメインに Pod を分散して、高可用性を確保し、障害が発生した場合に単一の領域に過度に集中するのを防ぐことができます。
トラブルシューティング
クラスタの作成とアップグレードに対するトラブルシューティングをご覧ください。