トラブルシューティング

以下のセクションでは、GKE On-Prem の使用中に発生する可能性のある問題とその解決方法について説明します。

始める前に

問題のトラブルシューティングを開始する前に、以下のセクションをご確認ください。

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]

管理ワークステーション

openssl で管理ワークステーション OVA を検証できない

現象

管理ワークステーションの OVA ファイルに対して openssl dgst を実行しても Verified OK が返されない

考えられる原因

OVA ファイルに問題があるため、正常な検証ができません。

解決策

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

Connect

ユーザー クラスタを登録できない

ユーザー クラスタの登録で問題が発生した場合は、Google にお問い合わせください。

アルファ版の登録解除中に作成されたクラスタ

Connect のドキュメントでユーザー クラスタの登録をご覧ください。

クラスタを削除して再作成することもできます。

アップグレード

アップグレード中のダウンタイムについて

リソース 説明
管理クラスタ

管理クラスタが停止しても、ユーザー クラスタのコントロール プレーンとワークロードは、ダウンタイムの原因となった障害の影響を受けない限り引き続き実行されます。
ユーザー クラスタのコントロール プレーン

通常、ユーザー クラスタ コントロール プレーンには目立ったダウンタイムはありません。ただし、Kubernetes API サーバーへの長時間実行の接続が切断され、再確立する必要がある場合があります。この場合、API 呼び出し元は、接続が確立するまで再試行する必要があります。最悪のケースでは、アップグレード中に最大 1 分間のダウンタイムが発生することがあります。
ユーザー クラスタノード

アップグレードでユーザー クラスタ ノードの変更が必要な場合、GKE On-Prem はノードをローリング方式で再作成し、これらのノードで実行されている Pod を再スケジュールします。ワークロードへの影響を防ぐには、適切な PodDisruptionBudgets とアンチ アフィニティ ルールを構成します。

ユーザー クラスタのサイズ変更

ユーザー クラスタのサイズ変更に失敗する

現象

ユーザー クラスタのサイズ変更操作が失敗します。

考えられる原因

サイズ変更操作が失敗する原因はいくつかあります。

解決策

サイズ変更が失敗する場合は、次の手順に従います。

  1. クラスタの MachineDeployment ステータスをチェックして、イベントやエラー メッセージがあるかどうかを確認します。

    kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]

  2. 新しく作成したマシンにエラーがあるかどうかを確認します。

    kubectl describe machine [MACHINE_NAME]

エラー: 「アドレスを割り振ることができません」

現象

ユーザー クラスタのサイズを変更すると、kubectl describe machine [MACHINE_NAME] が次のエラーを表示します。

Events:
   Type     Reason  Age                From                    Message
   ----     ------  ----               ----                    -------
   Warning  Failed  9s (x13 over 56s)  machineipam-controller  ipam: no addresses can be allocated
考えられる原因

ユーザー クラスタで使用可能な IP アドレスが不足しています。

解決策

クラスタに追加の IP アドレスを割り振ります。次に、影響を受けたマシンを削除します。

kubectl delete machine [MACHINE_NAME]

クラスタが正しく構成されている場合は、IP アドレスを使用して代替マシンが作成されます。

十分な数の IP アドレスが割り振られているが、クラスタにマシンを登録できない

現象

ネットワークには十分なアドレスが割り振られていますが、ユーザー クラスタへのマシンの登録が失敗します。

考えられる原因

IP が競合している可能性があります。対象の IP が別のマシンまたはロードバランサによって使用されている場合があります。

解決策

登録に失敗するマシンの IP アドレスが使用されていないことを確認します。競合がある場合は、環境内の競合を解消する必要があります。

その他

Terraform の vSphere プロバイダのセッション数の上限

GKE On-Prem は Terraform の vSphere プロバイダを使用して、vSphere 環境で VM を起動します。プロバイダのセッション数は最大 1,000 です。現在の実装では、使用後にアクティブなセッションが終了しません。実行中のセッションが多すぎると、503 エラーが発生する可能性があります。

セッションは 300 秒後に自動的に終了します。

現象

実行中のセッションが多すぎると、次のエラーが発生します。

Error connecting to CIS REST endpoint: Login failed: body:
  {"type":"com.vmware.vapi.std.errors.service_unavailable","value":
  {"messages":[{"args":["1000","1000"],"default_message":"Sessions count is
  limited to 1000. Existing sessions are 1000.",
  "id":"com.vmware.vapi.endpoint.failedToLoginMaxSessionCountReached"}]}},
  status: 503 Service Unavailable
考えられる原因

環境内で実行されている Terraform プロバイダのセッションが多すぎます。

解決策

現時点で、これは意図したとおりに機能しています。セッションは 300 秒後に自動的に終了します。詳細については、GitHub の問題 #618 をご覧ください。

Docker 用のプロキシの使用: oauth2: cannot fetch token

現象

プロキシの使用中に次のエラーが発生します。

oauth2: cannot fetch token: Post https://oauth2.googleapis.com/token: proxyconnect tcp: tls: oversized record received with length 20527
考えられる原因

HTTP ではなく HTTPS プロキシを指定した可能性があります。

解決策

Docker の構成で、プロキシ アドレスを https:// ではなく http:// に変更します。

ライセンスが有効であることを確認する

特に試用版ライセンスを使用している場合は、ライセンスが有効であることを確認してください。F5、ESXi ホスト、または vCenter ライセンスの有効期限が切れた場合、予期しないエラーが発生することがあります。