Google Distributed Cloud では、ワークロードは 1 つ以上のユーザー クラスタで実行されます。このページでは、Google Distributed Cloud のトポロジ ドメインで使用するユーザー クラスタを作成する方法について説明します。トポロジ ドメインを使用するには、Google Distributed Cloud バージョン 1.31 以降が必要です。
トポロジ ドメインを設定するには、高度なクラスタを有効にする必要があります。プレビュー版の高度なクラスタには次の制限事項があります。
- 高度なクラスタは、新しい 1.31 クラスタのクラスタ作成時にのみ有効にできます。
- 高度なクラスタを有効にすると、クラスタを 1.32 にアップグレードできなくなります。高度なクラスタはテスト環境でのみ有効にしてください。
このページは、技術インフラストラクチャの設定、モニタリング、管理を行う管理者、アーキテクト、オペレーターを対象としています。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザー ロールとタスクをご覧ください。
始める前に
管理ワークステーションを作成するの説明に従って、管理ワークステーションを設定してログインできることを確認します。管理ワークステーションには、ユーザー クラスタの作成に必要なツールが備わっています。このドキュメントで説明する操作はすべて管理ワークステーションで行います。
まだ設定していない場合は、次のドキュメントの説明のとおりに 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.33.100-gke.89。
ユーザー クラスタの構成ファイルのドキュメントを参照して、構成ファイルについてよく理解してください。このドキュメントは別のタブまたはウィンドウで開いたままにしておくことをおすすめします。次の手順を実行する際にこれを参照するためです。
name
name フィールドにユーザー クラスタの名前を設定します。
gkeOnPremVersion
このフィールドはあらかじめ入力されています。ここには Google Distributed Cloud のバージョンを指定します。例: 1.33.100-gke.89
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
storage.vSphereCSIDisabled を true に設定して、vSphere CSI コンポーネントのデプロイを無効にします。
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.tagsを除くnodePools[i].vsphereセクションのすべてのフィールドを削除します。この情報は、vSphere インフラストラクチャ構成ファイルでトポロジ ドメインごとに指定します。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 フィールドを削除します。トポロジ ドメインが有効になっている場合、準備済み認証情報はサポートされません。
schedulerConfiguration
kube-scheduler に渡される追加の構成を設定する場合は、構成ファイルに schedulerConfiguration セクションを追加します。
入力済みの構成ファイルの例
以下に、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.33.100-gke.89
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 ブロック ファイルに入力する
ユーザー クラスタ構成ファイルの network.ipMode.ipBlockFilePath フィールドで指定したディレクトリ内のファイルに、IP ブロック ファイルのテンプレートをコピーします。管理クラスタ用と各ユーザー クラスタ用に個別の 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 を分散して、高可用性を確保し、障害が発生した場合に単一の領域に過度に集中するのを防ぐことができます。
トラブルシューティング
クラスタの作成とアップグレードに対するトラブルシューティングをご覧ください。