このページでは、追加のユーザー クラスタを作成する方法について説明します。追加のユーザー クラスタを作成するには、クラスタのデプロイに使用する GKE On-Prem の構成ファイルのコピーを作成します。コピーしたファイルを新しいユーザー クラスタの想定に合わせて変更し、そのファイルを使用してクラスタを作成します。
作成する追加のユーザー クラスタごとに、GKE On-Prem 構成ファイルをコピーして変更する必要があります。
始める前に
- 管理クラスタが実行中であることを確認します。管理クラスタは、GKE On-Prem をインストールしたときに作成しています。
- インストール中に
gkectlで生成されたconfig.yamlファイルを見つけます。このファイルでは、管理クラスタとユーザー クラスタの仕様を定義します。このファイルをコピーして変更し、追加のユーザー クラスタを作成します。 - 管理クラスタの
kubeconfigファイルを見つけます。このファイルは、config.yamlをコピーして変更するときに参照します。
構成ファイルをコピーする
gkectl create-config を使用して生成し、環境に合わせて変更した GKE On-Prem 構成ファイルをコピーします。コピーの名前を変更し、別のファイル名を使用します。
cp [CONFIG_FILE] [NEW_USER_CLUSTER_CONFIG]
ここで、[NEW_USER_CLUSTER_CONFIG] は構成ファイルのコピーに選択した名前です。この手順では、このファイルを create-user-cluster.yaml とします。
create-user-cluster.yaml で、次のフィールドを変更する必要があります。
admincluster: 管理クラスタの仕様。ファイルからadminclusterの仕様を完全に削除します。usercluster: ユーザー クラスタの仕様。
次のセクションでは、create-user-cluster.yaml の admincluster フィールドと usercluster フィールドを変更し、そのファイルを使用して追加のユーザー クラスタを作成します。
コピーしたファイルで、次のフィールドを変更する必要がある場合があります。
gkeplatformversion。クラスタで実行する Kubernetes バージョンを指定します（これは GKE On-Prem プラットフォーム バージョンではありません。今後のリリースでは、このフィールドの名前は変更されます）。
admincluster の仕様を削除する
既存の管理クラスタから追加のユーザー クラスタを作成する場合は、admincluster 仕様全体を削除する必要があります。
そのためには、仕様とそのすべてのサブフィールドを削除します。
usercluster の仕様やそのサブフィールドは削除しないでください。
usercluster の仕様を変更する
次のセクションで説明するように、usercluster フィールドを変更します。
ユーザー クラスタの名前を変更する
usercluster.clustername フィールドのユーザー クラスタ名を変更します。新しいユーザー クラスタには、既存のユーザー クラスタと異なる名前を付けます。
ユーザー クラスタのノードに IP アドレスを予約する
DHCP を使用している場合は、ノードの作成に十分な IP があることを確認します。
静的 IP の場合、ユーザー クラスタに事前定義された IP アドレスを含む usercluster.ipblockfilepath に指定されたファイルを変更します。または、必要な IP を含む別の静的 IP YAML ファイルを指定します。
ロードバランサに IP アドレスを予約する
F5 BIG-IP ロードバランサを使用している場合は、ユーザー クラスタのロードバランサ コントロール プレーンと受信用の 2 つの IP アドレスを予約します。対応するフィールドは usercluster.vips.controlplanevip と usercluster.vips.ingressvip です。
マシンの要件を変更する（省略可）
このユーザー クラスタのコントロール プレーン ノードまたはワーカーノードで異なる量の CPU またはメモリを使用する場合や、クラスタで追加または少数のノードを実行する場合は、次のフィールドに値を設定します。
usercluster.masternode
usercluster.masternode.cpus: 使用する CPU コアの数。usercluster.masternode.memorymb: 使用するメモリ容量（MB）usercluster.masternode.replicas: 実行するこのタイプのノードの数。値は1または3にする必要があります。
usercluster.workernode
usercluster.workernode.cpus: 使用する CPU コアの数。usercluster.workernode.memorymd: 使用するメモリ容量（MB）usercluster.workernode.replicas: 実行するこのタイプのノードの数。
ユーザー クラスタを作成する
これまでの手順で create-user-cluster.yaml ファイルが作成されました。次に、このファイルを使用して、もう 1 つユーザー クラスタを作成します。
次のコマンドを実行します。
gkectl create cluster --config create-user-cluster.yaml --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]
ここで
- create-user-cluster.yaml は、作成した構成ファイルです。このファイルに別の名前を付けている可能性があります。
- [ADMIN_CLUSTER_KUBECONFIG] は、既存の管理クラスタの
kubeconfigを指します。
トラブルシューティング
詳しくは、トラブルシューティングをご覧ください。
gkectl を使用してクラスタの問題を診断する
クラスタの問題を特定し、クラスタの情報を Google と共有するために、gkectl diagnose コマンドを使用します。クラスタの問題を診断するをご覧ください。
デフォルトのロギング動作
gkectl と gkeadm では、デフォルトのロギング設定を使用するだけで十分です。
-
デフォルトでは、ログエントリは次のように保存されます。
gkectlの場合、デフォルトのログファイルは/home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).logで、このファイルはgkectlを実行するローカル ディレクトリのlogs/gkectl-$(date).logファイルにシンボリック リンクされます。gkeadmの場合、デフォルトのログファイルは、gkeadmを実行するローカル ディレクトリのlogs/gkeadm-$(date).logです。
- すべてのログエントリは、ターミナルに出力されていない場合（
--alsologtostderrがfalseの場合）でもログファイルに保存されます。 -v5詳細レベル（デフォルト）は、サポートチームが必要とするログエントリすべてを対象としています。- ログファイルには、実行されたコマンドと失敗メッセージも含まれます。
サポートが必要な場合は、サポートチームにログファイルを送信することをおすすめします。
ログファイルにデフォルト以外の場所を指定する
gkectl ログファイルにデフォルト以外の場所を指定するには、--log_file フラグを使用します。指定したログファイルは、ローカル ディレクトリにシンボリック リンクされません。
gkeadm ログファイルにデフォルト以外の場所を指定するには、--log_file フラグを使用します。
管理クラスタで Cluster API ログを見つける
管理コントロール プレーンの起動後に VM が起動しない場合は、管理クラスタの Cluster API コントローラのログを調べてデバッグを試すことができます。
kube-systemNamespace で Cluster API コントローラ Pod の名前を確認します。ここで、[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイルのパスです。kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
Pod のログを開きます。ここで、[POD_NAME] は Pod の名前です。必要に応じて、
grepまたは同様のツールを使用してエラーを検索します。kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager