管理クラスタの作成

このページでは、管理クラスタの作成方法について説明します。

構成ファイルの生成

クラスタを作成して管理するには、管理クラスタの構成ファイルが必要です。gkeadm を使用して管理ワークステーションを作成した場合、gkeadm により構成ファイルのテンプレートが生成され、一部のフィールドが入力されます。

管理ワークステーションの作成に gkeadm を使用しなかった場合、次のコマンドを実行すればテンプレートを生成できます。

gkectl create-config admin --config [OUTPUT_PATH]

ここで、[OUTPUT_PATH] は生成されたテンプレートの任意のパスです。--config フラグを含めない場合、gkectl はファイルに admin-cluster.yaml という名前を付け、現在のディレクトリに配置します。

構成ファイルの入力

bundlePath

gkeadm を使用して管理ワークステーションを作成した場合、このフィールドはすでに入力されています。それ以外の場合は、バンドル ファイルのパスを指定します。

vCenter

gkeadm を使用して管理ワークステーションを作成した場合、このセクションはすでに入力されています。それ以外の場合は、vCenter のフィールドに値を指定します。

network

クラスタノードから IP アドレスを取得する方法を決めます。次のオプションがあります。

  • DHCP サーバーから。network.ipMode.type を "dhcp" に設定する。

  • 指定した静的 IP アドレスのリストから。network.ipMode.type を "static" に設定し、静的 IP アドレスを提供するホスト構成ファイルを作成します。

network セクションの残りのフィールドに値を入力します。

loadBalancer

管理クラスタの Kubernetes API サーバー用に VIP を確保します。アドオン サーバーに別の VIP を設定します。loadBalancer.controlPlaneVIP と loadBalancer.addonsVIP の値として VIP を指定します。

使用する負荷分散の種類を決めます。次のオプションがあります。

  • Seesaw によるバンドルされた負荷分散。loadBalancer.kind を "Seesaw" に設定し、loadBalancer.seesaw セクションに入力します。

  • F5 BIG-IP による統合負荷分散。loadBalancer.kind を "F5BigIP" に設定し、f5BigIP セクションに入力します。

  • 手動負荷分散。loadBalancer.kind を "ManualLB" に設定し、manualLB セクションに入力します。

proxy

管理クラスタノードを持つネットワークがプロキシ サーバーの背後にある場合は、proxy セクションに入力します。

privateRegistry

GKE on-prem コンポーネントのコンテナ イメージを保持する場所を決めます。次のオプションがあります。

  • gcr.io。privateRegistry セクションには入力しないでください。

  • 独自の非公開 Docker レジストリ。privateRegistry セクションに入力します。

gcrKeyPath

gcrKeyPath に、許可リストに登録されたサービス アカウントの JSON キーファイルのパスを設定します。

stackdriver

stackdriver セクションに入力します。

cloudAuditLogging

Kubernetes 監査ログを Cloud Audit Logs と統合する場合は、cloudAuditLogging セクションに入力します。

構成ファイルの検証

管理クラスタの構成ファイルに入力したら、gkectl check-config を実行してファイルが有効であることを検証します。

gkectl check-config --config [CONFIG_PATH]

[CONFIG_PATH] は、管理クラスタの構成ファイルのパスです。

コマンドがエラー メッセージを返した場合は、問題を修正してファイルを再度検証します。

時間のかかる検証をスキップする場合は、--fast フラグを渡します。個別の検証をスキップするには、--skip-validation-xxx フラグを使用します。check-config コマンドについて詳しくは、プリフライト チェックの実行をご覧ください。

gkectl prepare の実行

gkectl prepare を実行して、vSphere 環境を初期化します。

gkectl prepare --config [CONFIG_PATH]

管理クラスタの作成

管理クラスタを作成します。

gkectl create admin --config [CONFIG_PATH]

[CONFIG_PATH] は、管理クラスタの構成ファイルのパスです。

gkectl create admin コマンドで、現在のディレクトリに kubeconfig という名前の kubeconfig ファイルが作成されます。この kubeconfig ファイルは後で管理クラスタとやり取りする際に必要になります。

管理クラスタが実行されていることを確認する

管理クラスタが実行されていることを確認します。

kubectl get nodes --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

ここで、[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 コントローラのログを調べてデバッグを試すことができます。

  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

管理クラスタのコントロール プレーン ノードの kubeconfig を使用した F5 BIG-IP の問題のデバッグ

GKE On-Prem をインストールすると、管理ワークステーションのホーム ディレクトリに kubeconfig ファイルが生成されます（internal-cluster-kubeconfig-debug という名前）。この kubeconfig ファイルは、管理コントロール プレーンが実行される管理クラスタのコントロール プレーン ノードを直接参照することを除いて、管理クラスタの kubeconfig と同じです。この internal-cluster-kubeconfig-debug ファイルを使用して、F5 BIG-IP の問題をデバッグできます。

gkectl check-config 検証が失敗: F5 BIG-IP パーティションが見つからない

現象

F5 BIG-IP パーティションが存在している場合でも見つからず、検証で不合格になります。

考えられる原因

F5 BIG-IP API に問題があると、検証が失敗することがあります。

解決策

もう一度 gkectl check-config を実行してみてください。

gkectl prepare --validate-attestations が失敗: ビルド証明書を検証できない

現象

オプションの --validate-attestations フラグを指定して gkectl prepare を実行すると、次のエラーが返されます。

could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY
考えられる原因

影響を受けるイメージの証明書が存在しない可能性があります。

解決策

管理ワークステーションの作成の説明に従って、管理ワークステーションの OVA をもう一度ダウンロードしてデプロイしてみてください。問題が解決しない場合は、Google にお問い合わせください。

ブートストラップ クラスタのログを使用したデバッグ

インストール時、GKE On-Prem により一時的なブートストラップ クラスタが作成されます。インストールが正常に完了した後、GKE On-Prem によってブートストラップ クラスタが削除され、管理クラスタとユーザー クラスタが残されます。通常、このクラスタを操作する理由はありません。

インストール中に問題が発生し、gkectl create cluster に --cleanup-external-cluster=false が渡された場合は、ブートストラップ クラスタのログを使用してデバッグすると便利です。Pod を見つけてログを取得できます。

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]

詳しくは、トラブルシューティングを参照してください。

次のステップ

ユーザー クラスタの作成