以前のバージョンの GKE On-Prem のドキュメントを表示しています。最新のドキュメントをご覧ください

追加のユーザー クラスタの作成

このページでは、追加のユーザー クラスタを作成する方法について説明します。追加のユーザー クラスタを作成するには、クラスタのデプロイに使用する GKE On-Prem の構成ファイルのコピーを作成します。コピーしたファイルを新しいユーザー クラスタの想定に合わせて変更し、そのファイルを使用してクラスタを作成します。

作成する追加のユーザー クラスタごとに、GKE On-Prem 構成ファイルをコピーして変更する必要があります。

始める前に

  • 管理クラスタが実行中であることを確認します。管理クラスタは、GKE On-Prem をインストールしたときに作成しています
  • インストール中に gkectl で生成された config.yaml ファイルを見つけます。このファイルでは、管理クラスタとユーザー クラスタの仕様を定義します。このファイルをコピーして変更し、追加のユーザー クラスタを作成します。
  • 管理クラスタの kubeconfig ファイルを見つけます。このファイルは、config.yaml をコピーして変更するときに参照します。

制限事項

制約事項 説明
クラスタとノードの上限と下限

割り当てと上限をご覧ください。環境のパフォーマンスがこれらの上限に影響することがあります。

ユーザー クラスタ名の一意性

同じ Google Cloud プロジェクトに登録されているすべてのユーザー クラスタに一意の名前を付ける必要があります。

複数の vCenter および / または vSphere データセンターにデプロイできません

現時点では、管理クラスタと関連するユーザー クラスタのセットは、1 つの vCenter および / または vSphere データセンターにのみデプロイできます。同じ管理者クラスタとユーザー クラスタを複数の vCenter および / または vSphere データセンターにデプロイすることはできません。

作成後にクラスタ構成を宣言型の方法で変更できません 追加のクラスタの作成既存クラスタのサイズ変更はできますが、既存のクラスタを構成ファイルで変更することはできません。

十分な IP アドレスが使用可能なことを確認する

新しいユーザー クラスタに十分な IP アドレスが割り当てられていることを確認します。十分な IP アドレスがあることを確認する方法は、DHCP サーバーを使用しているか静的 IP かによって異なります。

DHCP

クラスタが作成されるネットワーク内の DHCP サーバーに十分な IP アドレスがあることを確認します。IP アドレスが、ユーザー クラスタで実行されているノードよりも多くなっている必要があります。

静的 IP

ロードバランサに十分な IP アドレスが割り当てられていることを確認し、クラスタの作成時にこれらの IP アドレスを指定します。

F5 BIG-IP パーティションを作成する

負荷分散に F55 BIG-IP を使用している場合は、新しいユーザー クラスタのパーティションを作成します。

構成ファイルをコピーする

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.yamladmincluster フィールドと usercluster フィールドを変更し、そのファイルを使用して追加のユーザー クラスタを作成します。

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.controlplanevipusercluster.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: 実行するこのタイプのノードの数。

F5 BIG-IP パーティションを構成する

F5 BIG-IP を負荷分散に使用している場合、前に新しいユーザー クラスタのパーティションを作成しています。次は、usercluster.bigip.partition フィールドでパーティションを構成します。次に例を示します。

usercluster:
...
bigip:
  partition: "my-new-user-f5-partition"
...

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

これまでの手順で create-user-cluster.yaml ファイルが作成されました。次はこのファイルを使用して、もう一つユーザー クラスタを作成します。

次のコマンドを実行します。

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 コマンドを詳細に実行する

-v5

stderr に対する gkectl エラーのロギング

--alsologtostderr

管理ワークステーションの gkectl ログを見つける

デバッグフラグを渡さない場合でも、次の管理ワークステーション ディレクトリで gkectl ログを表示できます。

/home/ubuntu/.config/syllogi/logs

管理クラスタで Cluster API ログを見つける

管理コントロール プレーンの起動後に VM が起動しない場合は、管理クラスタの Cluster API コントローラのログを調べてデバッグを試すことができます。

  1. kube-system Namespace で Cluster API コントローラ Pod の名前を確認します。ここで、[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイルのパスです。

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
  2. Pod のログを開きます。ここで、[POD_NAME] は Pod の名前です。必要に応じて、grep または同様のツールを使用してエラーを検索します。

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager