このページは Cloud Translation API によって翻訳されました。

アップグレードのトラブルシューティング

Autopilot Standard

このページでは、Google Kubernetes Engine（GKE）クラスタのアップグレードに関する問題を解決する方法について説明します。

さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。

問題: コントロールプレーンのアップグレード後に kube-apiserver が異常になる

クラスタの GKE バージョンのコントロールプレーンの手動アップグレードを開始すると、次の問題が発生します。一部のユーザーがデプロイしたアドミッション Webhook では、システムコンポーネントが正常に機能するために必要な許可のある RBAC ロールが作成されないことがあります。コントロールプレーンのアップグレード中に、Google Cloud は Kubernetes API サーバー（kube-apiserver）コンポーネントを再作成します。Webhook が API サーバーコンポーネントの RBAC ロールをブロックしている場合、API サーバーは起動せず、クラスタのアップグレードは完了しません。

Webhook が正しく機能していても、新しく作成されたコントロールプレーンから Webhook に到達できないため、クラスタのアップグレードが失敗する可能性があります。

gcloud CLI のエラーメッセージは次のようになります。

FAILED: All cluster resources were brought up, but: component "KubeApiserverReady" from endpoint "readyz of kube apiserver is not successful" is unhealthy.

失敗した Webhook を特定するには、次の情報を使用して RBAC 呼び出しの GKE 監査ログを確認します。

protoPayload.resourceName="RBAC_RULE"
protoPayload.authenticationInfo.principalEmail="system:apiserver"

RBAC_RULE は、RBAC ロールの完全な名前です（rbac.authorization.k8s.io/v1/clusterroles/system:controller:horizontal-pod-autoscaler など）。

失敗した Webhook の名前が次の形式でログに表示されます。

admission webhook WEBHOOK_NAME denied the request

この問題を解決するには、次のことを試してください。

制約を調整して、system: 接頭辞を持つ ClusterRole を作成および更新できるようにする。
システム RBAC ロールの作成と更新のリクエストをインターセプトしないように Webhook を調整する。
Webhook を無効にする。

原因

Kubernetes は、最新のマイナーバージョンのデフォルトポリシーを使用して、デフォルトのシステム RBAC ロールを自動調整{track-name="k8sLink" track-type="troubleshooting"}します。システムロールのデフォルトのポリシーは、新しい Kubernetes バージョンで変更される可能性があります。

この調整を行うために、GKE はクラスタ内の ClusterRoles と ClusterRoleBinding を作成または更新します。デフォルトの RBAC ポリシーが使用する権限のスコープにより、作成リクエストまたは更新リクエストをインターセプトして拒否する Webhook がある場合、API サーバーは新しいマイナーバージョンで機能しません。

問題: Standard クラスタのアップグレード後にワークロードが強制排除される

次のすべてに該当する場合、クラスタアップグレード後にワークロードが強制排除のリスクにさらされる可能性があります。

クラスタのコントロールプレーンが新しい GKE バージョンを実行している場合。システムワークロードにはより多くのスペースが必要です。
既存のノードに、新しいシステムワークロードと既存のワークロードを実行するための十分なリソースがない。
クラスタオートスケーラーがクラスタで無効になっている。

この問題を解決するには、次のことを試してください。

問題: コントロールプレーンのバージョンとノードのバージョンに互換性がない

クラスタのコントロールプレーンで実行されている Kubernetes のバージョンと、クラスタのノードプールで実行されている Kubernetes のバージョンを確認します。クラスタのノードプールのいずれかがコントロールプレーンの 2 つ前のマイナーバージョンよりも古い場合、クラスタで問題が生じる可能性があります。

GKE チームはユーザーに代わって定期的にクラスタコントロールプレーンのアップグレードを行います。コントロールプレーンは、新しい安定版の Kubernetes にアップグレードされます。デフォルトでは、クラスタのノードで自動アップグレードが有効になっています。無効にすることはおすすめしません。

クラスタのノードの自動アップグレードが無効になっている場合、ノードプールバージョンをコントロールプレーンと互換性のあるバージョンに手動でアップグレードしなければ、コントロールプレーンが時間の経過とともに自動的にアップグレードされるため、最終的には、ノードとの互換性がなくなります。クラスタのコントロールプレーンとノードの間に互換性がない場合、予期しない問題が発生する可能性があります。

Kubernetes バージョンとバージョンスキューのサポートポリシーにより、コントロールプレーンは、コントロールプレーンの 2 つ前までのマイナーバージョンのノードと互換性が保証されています。たとえば、Kubernetes 1.19 コントロールプレーンは Kubernetes 1.19、1.18、1.17 のノードと互換性があります。この問題を解決するには、ノードプールのバージョンをコントロールプレーンと互換性のあるバージョンに手動でアップグレードします。

アップグレードプロセスにより、影響を受けるノードで実行されているワークロードが中断されることが懸念される場合は、次の手順でワークロードを新しいノードプールに移行します。

互換性のあるバージョンで新しいノードプールを作成する。
既存のノードプールのノードを閉鎖する。
必要に応じて、既存のノードプールで実行されているワークロードを更新して、ラベル cloud.google.com/gke-nodepool:NEW_NODE_POOL_NAME の nodeSelector を追加する。ここで、NEW_NODE_POOL_NAME は新しいノードプールの名前です。これにより、GKE はこれらのワークロードを新しいノードプールのノードに配置します。
既存のノードプールをドレインする。
新しいノードプールでワークロードが正常に実行されていることを確認する。問題がなければ、古いノードプールを削除できます。ワークロードの中断が発生した場合は、既存のノードプール内のノードの閉鎖を解除し、新しいノードをドレインして、既存のノードでワークロードを再スケジュールします。問題のトラブルシューティングを行ってから、もう一度お試しください。

問題: [ノード割り当て可能] を構成した後、Pod が保留状態になる

[ノード割り当て可能] を構成してノードのバージョンをアップグレードすると、実行中の Pod が保留中に変わることがあります。

アップグレード後に Pod が保留中になる場合は、次のことをおすすめします。

Pod の CPU リクエストとメモリリクエストがピーク時の使用量を超えていないことを確認する。オーバーヘッド用に CPU とメモリを予約している GKE では、Pod はこのリソースをリクエストできません。実際の使用量よりも多くの CPU またはメモリをリクエストする Pod では、他の Pod がこのリソースをリクエストすることができなくなり、クラスタが十分に活用されないことがあります。詳細については、リソースリクエストを含む Pod のスケジュール設定をご覧ください。
クラスタのサイズの変更を検討する。手順については、クラスタのサイズ変更をご覧ください。
クラスタをダウングレードして、この変更を元に戻す。手順については、クラスタまたはノードプールの手動アップグレードをご覧ください。

Kubernetes スケジューラー指標を Cloud Monitoring に送信し、スケジューラー指標を表示するようにクラスタを構成する。

次のステップ