このページでは、Google Distributed Cloud のトポロジ ドメインで使用する管理クラスタを作成する方法について説明します。管理クラスタは、ワークロードを実行するユーザー クラスタを管理します。トポロジ ドメインを使用するには、Google Distributed Cloud バージョン 1.31 以降が必要です。
トポロジ ドメインを設定するには、高度なクラスタを有効にする必要があります。高度なクラスタ プレビューには次の制限事項があります。
- 高度なクラスタは、新しい 1.31 クラスタのクラスタ作成時にのみ有効にできます。
- 高度なクラスタを有効にすると、クラスタを 1.32 にアップグレードできなくなります。高度なクラスタはテスト環境でのみ有効にします。
このページは、技術インフラストラクチャの設定、モニタリング、管理を行う管理者、アーキテクト、オペレーターを対象としています。 Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。
管理クラスタの詳細については、インストールの概要をご覧ください。
手順の概要
管理クラスタの作成に関わる主な手順は次のとおりです。
- 管理構成ファイルに入力する
- 管理クラスタ構成ファイルを完成させて、新しい管理クラスタの詳細を指定します。
- vSphere インフラストラクチャ構成ファイルに入力する
- vSphere インフラストラクチャ構成ファイルでトポロジ ドメインの詳細を指定します。
- IP ブロック ファイルに入力する
- IP ブロック ファイルで、ゲートウェイ、ネットマスク、コントロール プレーン ノードの IP アドレスを指定します。
- OS イメージを取得する
- 通常の Google Distributed Cloud バンドルをダウンロードします。次に、
gkectl prepareを実行します。これにより、OS イメージが vSphere にインポートされ、該当する場合はコンテナ イメージがプライベート レジストリに push されます。
- 管理クラスタを作成する。
gkectlを使用して、完成した構成ファイルで指定した新しい管理クラスタを作成します。Google Distributed Cloud で、管理クラスタを作成する際には、Docker の Kubernetes（kind）クラスタをデプロイして、管理クラスタの作成に必要な Kubernetes コントローラを一時的にホストします。この一時的なクラスタは、ブートストラップ クラスタと呼ばれます。ユーザー クラスタは、ブートストラップ クラスタを使用せずに管理クラスタを管理することによって作成およびアップグレードされます。
- 管理クラスタが実行されていることを確認します。
kubectlを使用してクラスタノードを表示します。
この手順が完了すると、実行中の管理クラスタが作成され、トポロジ ドメイン内のユーザー クラスタの作成と管理が可能になります。
始める前に
管理ワークステーションを作成するの説明に従って、管理ワークステーションを設定してログインできることを確認します。管理ワークステーションには、管理クラスタの作成に必要なツールが備わっています。このドキュメントのすべての手順は管理ワークステーションで行います。
IP アドレス計画のドキュメントを確認します。3 つのコントロールプレーン ノードとコントロールプレーンの VIP に十分な IP アドレスが利用できることを確認します。
手動ロード バランシング用にロードバランサを構成します。管理クラスタを作成する前に、ロードバランサを設定する必要があります。
privateRegistryセクションを確認し、Google Distributed Cloud コンポーネントにパブリック レジストリとプライベート レジストリのどちらを使用するかを決定します。osImageType フィールドで今後のことを考えて、管理クラスタノードで実行するオペレーティング システムの種類を決定します。
組織でアウトバウンド トラフィックがプロキシ サーバーを通過する必要がある場合は、必要な API と Artifact Registry のアドレスを許可リストに登録してください。
vCenter Server の各インスタンスにアクセスするために必要な情報を収集します。この情報は、vSphere インフラストラクチャ構成ファイルの
SecretセクションとVSphereInfraConfig.credentials.vCentersセクションに入力するために必要です。必要な情報を取得する方法については、以下をご覧ください。
管理クラスタ構成ファイルに入力する
gkeadm を使用して管理ワークステーションを作成した場合、admin-cluster.yaml という名前の構成ファイルが生成されます。
管理ワークステーションの作成に gkeadm を使用しなかった場合は、管理ワークステーションで次のコマンドを実行して admin-cluster.yaml を生成します。
gkectl create-config admin
この構成ファイルは、管理クラスタの作成用です。
管理クラスタの構成ファイルのドキュメントを詳しく調べて、構成ファイルをよく理解します。このドキュメントは別のタブまたはウィンドウで開いたままにしておくことをおすすめします。次の手順を実行する際にこれを参照するためです。
name
管理クラスタの名前を指定する場合は、name フィールドに入力します。
bundlePath
バンドルは、クラスタ コンポーネントを含む zip ファイルです。管理ワークステーションに含まれています。このフィールドはあらかじめ入力されています。
enableAdvancedCluster
enableAdvancedCluster を true に設定します。これにより、トポロジ ドメインの設定に必要な高度なクラスタが有効になります。
infraConfigFilePath
vSphere インフラストラクチャ構成ファイルのフルパスを infraConfigFilePath フィールドに追加します。
vCenter
このセクション全体を削除します。代わりに、vSphere インフラストラクチャ構成ファイルで vCenter Server 情報を構成します。
network
構成ファイルから次の行を削除します。
network.hostConfigセクション全体。この情報は、トポロジ ドメインごとに vSphere インフラストラクチャ構成ファイルで構成されます。network.vCenter.networkNameフィールド。このフィールドは、トポロジ ドメインごとに vSphere インフラストラクチャ構成ファイルで構成されます。network.controlPlaneIPBlockセクション全体。ゲートウェイ、ネットマスク、コントロール プレーン ノードの IP アドレスは、IP ブロック ファイルで構成されます。
network.ipMode.ipBlockFilePathを IP ブロック ファイルのパスに設定します。network.ipMode.typeをstaticに設定します。network.podCIDR フィールドと network.serviceCIDR フィールドには、値が事前に設定されています。この値は、ネットワークですでに使用されているアドレスと競合しない限り変更できません。Kubernetes では、これらの範囲を使用してクラスタ内の Pod と Service に IP アドレスを割り当てます。
loadBalancer
loadBalancer.kindを"ManualLB"に設定し、manualLBセクションを削除します。管理クラスタの Kubernetes API サーバー用に VIP を確保します。
loadBalancer.vips.controlPlaneVIPの値として VIP を指定します。
詳細については、管理クラスタ サブネット内の VIP をご覧ください。
antiAffinityGroups
antiAffinityGroups.enabled を false に設定します。Distributed Resource Scheduler（DRS）の反アフィニティ ルールは、トポロジ ドメインではサポートされていません。
adminMaster
管理クラスタのコントロール プレーン ノードの CPU とメモリを指定する場合は、
adminMasterセクションのcpusとmemoryMBフィールドに入力します。管理クラスタには 3 つのコントロール プレーン ノードが必要です。
adminMasterセクションのreplicasフィールドを3に設定します。コントロール プレーン ノードが使用する特定のトポロジ ドメインを指定する場合は、トポロジ ドメイン名を
adminMaster.topologyDomainsフィールドに追加します。ここで名前を指定しない場合、vSphere インフラストラクチャ構成ファイルのvSphereInfraConfig.defaultTopologyDomainに名前を設定する必要があります。
proxy
管理クラスタノードを持つネットワークがプロキシ サーバーの背後にある場合は、proxy セクションに入力します。
privateRegistry
Google Distributed Cloud コンポーネントのコンテナ イメージを保持する場所を決定します。次のオプションがあります。
Artifact Registry
独自の非公開 Docker レジストリ。
独自の非公開レジストリを使用する場合は、
privateRegistryセクションに入力します。
componentAccessServiceAccountKeyPath
Google Distributed Cloud は、コンポーネント アクセス サービス アカウントを使用して、Artifact Registry からクラスタ コンポーネントをダウンロードします。このフィールドには、コンポーネント アクセス サービス アカウントの JSON キーファイルのパスが格納されます。
このフィールドはあらかじめ入力されています。
gkeConnect
gkeConnect セクションに入力して、 Google Cloud フリートに管理クラスタを登録します。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 のサービス名）を無効にします。手順については、サービスの無効化をご覧ください。
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 とリージョンが同じでない場合、クラスタの作成は失敗します。
cloudAuditLogging
クラスタの Kubernetes API サーバーの監査ログを Cloud Audit Logs と統合する場合は、cloudAuditLogging セクションに値を入力します。
新しいクラスタについては、次の要件に注意してください。
enableAdvancedClusterはtrueに設定されているため、cloudAuditLogging.serviceAccountKeyPathとstackdriver.serviceAccountKeyPathに同じパスを指定する必要があります。cloudAuditLogging.projectIDの ID は、gkeConnect.projectIDとstackdriver.projectIDの ID と同じでなければなりません。cloudAuditLogging.clusterLocationで設定された Google Cloud リージョンは、stackdriver.clusterLocationとgkeConnect.locationで設定されたリージョンと同じである必要があります（フィールドが構成ファイルに含まれている場合）。さらに、gkeOnPremAPI.enabledがtrueの場合、gkeOnPremAPI.locationに同じリージョンを設定する必要があります。
プロジェクト ID とリージョンが同じでない場合、クラスタの作成は失敗します。
clusterBackup
このセクションを削除します。vSphere データストアへの管理クラスタのバックアップはサポートされていません。
autoRepair
管理クラスタのノードの自動修復を有効にする場合は、autoRepair.enabled を true に設定します。
secretsEncryption
enableAdvancedCluster が true に設定されているため、このセクションを削除します。
osImageType
osImageType を設定します。ubuntu_cgroupv2 または ubuntu_containerd に設定します。
preparedSecrets
preparedSecrets フィールドを削除します。トポロジ ドメインが有効になっている場合、準備済み認証情報はサポートされていません。
入力済みの構成ファイルの例
入力済みの管理クラスタ構成ファイルの例を以下に示します。この構成により、利用可能な機能のすべてではなく、一部が有効になります。
vc-01-admin-cluster.yaml
apiVersion: v1
kind: AdminCluster
name: "gke-admin-01"
bundlePath: "/var/lib/gke/bundles/gke-onprem-vsphere-1.31.0-gke.1-full.tgz"
enableAdvancedCluster: true
infraConfigFilePath: "/my-config-folder/vsphere-infrastructure-config.yaml"
network:
serviceCIDR: "10.96.232.0/24"
podCIDR: "192.168.0.0/16"
ipMode:
type: "static"
ipBlockFilePath: "/my-config-folder/admin-cluster-ipblock.yaml"
loadBalancer:
vips:
controlPlaneVIP: "172.16.20.59"
kind: "ManualLB"
antiAffinityGroups:
enabled: false
adminMaster:
cpus: 4
memoryMB: 16384
replicas: 3
topologyDomains: "admin-cluster-domain"
componentAccessServiceAccountKeyPath: "sa-key.json"
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"
disableVsphereResourceMetrics: false
autoRepair:
enabled: true
osImageType: "ubuntu_containerd"
vSphere インフラストラクチャ構成ファイルに入力する
vSphere インフラストラクチャ構成ファイルのテンプレートを、管理クラスタ構成ファイルの infraConfigFilePath フィールドで指定したディレクトリ内のファイルにコピーします。管理クラスタとすべてのマネージド ユーザー クラスタには、vSphere インフラストラクチャ構成ファイルが 1 つだけあります。
Secret
vSphere インフラストラクチャ構成ファイルの Secret セクションに入力します。このセクションでは、各 vCenter Server の認証情報を格納する vSphere 認証情報 Secret について説明します。
VSphereInfraConfig.name
VSphereInfraConfig,name フィールドに入力します。
VSphereInfraConfig.credentials.vCenters
Secret ごとに、対応する VSphereInfraConfig.credentials.vCenters セクションを追加します。
VSphereInfraConfig,topologyDomains
VSphereInfraConfig.topologyDomains セクションに入力して、トポロジ ドメインを定義します。
IP ブロック ファイルに入力する
IP ブロック ファイルのテンプレートを、管理クラスタ構成ファイルの network.ipMode.ipBlockFilePath フィールドで指定したディレクトリ内のファイルにコピーします。ゲートウェイ、ネットマスク、3 つのコントロール プレーン ノードの IP アドレスを追加します。コントロール プレーン ノードの IP アドレスごとに、トポロジ ドメインの例に示すように isControlPlane: true を追加します。
OS イメージを取得する
通常の Google Distributed Cloud バンドルを管理ワークステーションにダウンロードします。
gcloud storage cp gs://gke-on-prem-release/gke-onprem-bundle/VERSION/gke-onprem-vsphere-VERSION.tgz /var/lib/gke/bundles/gke-onprem-vsphere-VERSION.tgz
VERSIONは、インストールする Google Distributed Cloud のバージョンに置き換えます。このコマンドは、通常のバンドルをダウンロードします。高度なクラスタではサポートされていないため、完全なバンドルはダウンロードしないでください。
gkectl prepareを実行して、vSphere 環境を初期化します。gkectl prepare --config ADMIN_CLUSTER_CONFIG
ADMIN_CLUSTER_CONFIGは、管理クラスタ構成のパスに置き換えます。gkectl prepareコマンドによって、以下の準備タスクが実行されます。OS イメージを vSphere にインポートして、VM テンプレートとしてマークします。
非公開 Docker レジストリを使用している場合は、コンテナ イメージをレジストリに push します。
必要に応じて、コンテナ イメージのビルド証明書を検証します。これにより、イメージが Google によって作成、署名されていることと、デプロイの準備ができていることを確認します。
管理クラスタを作成する
管理クラスタを作成します。
gkectl create admin --configADMIN_CLUSTER_CONFIG
障害発生後に管理クラスタの作成を再開する
管理クラスタの作成が失敗またはキャンセルされた場合は、create コマンドを再度実行してください。
gkectl create admin --config ADMIN_CLUSTER_CONFIG
管理クラスタの kubeconfig ファイルを見つける
gkectl create admin コマンドで、現在のディレクトリに kubeconfig という名前の kubeconfig ファイルが作成されます。この kubeconfig ファイルは後で管理クラスタとやり取りする際に必要になります。
kubeconfig ファイルには、管理クラスタの名前が含まれています。クラスタ名を表示するには、次のものを実行します。
kubectl config get-clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG
出力には、クラスタの名前が表示されます。次に例を示します。
NAME gke-admin-tqk8x
kubeconfig ファイルの名前と場所は、必要に応じて変更できます。
管理クラスタが実行されていることを確認する
管理クラスタが実行されていることを確認します。
kubectl get nodes --kubeconfig ADMIN_CLUSTER_KUBECONFIG
ADMIN_CLUSTER_KUBECONFIG は、管理クラスタ kubeconfig ファイルのパスに置き換えます。
出力には、管理クラスタノードが表示されます。次に例を示します。
admin-cp-vm-1 Ready control-plane,master ... admin-cp-vm-2 Ready control-plane,master ... admin-cp-vm-3 Ready control-plane,master ...
PodTemplate を設定する
トポロジラベルは、トポロジ ドメイン内のノードのラベルに入力されます。トポロジ ドメインの設定で、トポロジ キーとしてデフォルトの制約 "topology.kubernetes.io/zone" を使用している場合を除き、Deployment、StatefulSet、または ReplicaSet の Pod テンプレートでトポロジ キーを構成する必要があります。
たとえば、トポロジラベルでキーを "topology.examplepetstore.com/zone" と定義したとします。PodTemplate で、topologySpreadConstraints.topologyKey フィールドの値としてキーを指定します。これにより、Kubernetes スケジューラはトポロジ ドメインに Pod を分散して、高可用性を確保し、障害が発生した場合に単一の領域に過度に集中するのを防ぐことができます。
topologySpreadConstraints の構成の詳細については、Kubernetes ドキュメントの Pod トポロジの分散制約をご覧ください。
ファイルをバックアップする
管理クラスタの kubeconfig ファイルをバックアップすることをおすすめします。つまり、管理ワークステーションから別の場所に kubeconfig ファイルをコピーします。その後、管理ワークステーションにアクセスできなくなった場合、または管理ワークステーションの kubeconfig ファイルが誤って削除された場合でも、管理クラスタにアクセスできます。
管理クラスタの秘密 SSH 鍵のバックアップも作成することをおすすめします。その後、管理クラスタにアクセスできなくなった場合でも、SSH を使用して管理クラスタノードに接続できます。これにより、管理クラスタへの接続に関する問題のトラブルシューティングと調査が可能になります。
管理クラスタから SSH 鍵を抽出して admin-cluster-ssh-key という名前のファイルに保存します。
kubectl --kubeconfigADMIN_CLUSTER_KUBECONFIG get secrets -n kube-system sshkeys \ -o jsonpath='{.data.vsphere_tmp}' | base64 -d > admin-cluster-ssh-key
これで、選択した別の場所に admin-cluster-ssh-key をバックアップできるようになりました。
トラブルシューティング
クラスタの作成とアップグレードに対するトラブルシューティングをご覧ください。