このページでは、Google Kubernetes Engine(GKE)Autopilot クラスタの問題を解決する方法について説明します。
クラスタに関する問題
クラスタを作成できない: 0 個のノードが登録されている
次の問題は、無効になっている IAM サービス アカウントまたは必要な権限がない IAM サービス アカウントで Autopilot クラスタを作成しようとすると発生します。クラスタの作成が失敗し、次のエラー メッセージが表示されます。
All cluster resources were brought up, but: only 0 nodes out of 2 have registered.
この問題を解決するには、次の操作を行います。
使用するデフォルトの Compute Engine サービス アカウントまたはカスタム IAM サービス アカウントが無効になっているかどうかを確認します。
gcloud iam service-accounts describe SERVICE_ACCOUNT
SERVICE_ACCOUNT
を、サービス アカウントのメールアドレス(my-iam-account@my-first-project.iam.gserviceaccount.com
など)に置き換えます。サービス アカウントが無効になっている場合、出力は次のようになります。
disabled: true displayName: my-service-account email: my-service-account@my-project.iam.gserviceaccount.com ...
サービス アカウントが無効になっている場合は、有効にします。
gcloud iam service-accounts enable SERVICE_ACCOUNT
サービス アカウントが有効になっていてもエラーが解決しない場合は、GKE に必要な最小限の権限をサービス アカウントに付与します。
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:SERVICE_ACCOUNT" \
--role roles/container.nodeServiceAccount
クラスタにノードがない場合、Namespace が終了中の状態のままになる
次の問題は、クラスタをゼロノードにスケールダウンした後にクラスタ内の Namespace を削除すると発生します。metrics-server
コンポーネントは、レプリカがゼロであるため、Namespace の削除リクエストを受け入れることはできません。
この問題を診断するには、次のコマンドを実行します。
kubectl describe ns/NAMESPACE_NAME
NAMESPACE_NAME
は Namespace の名前に置き換えます。
次のような出力が表示されます。
Discovery failed for some groups, 1 failing: unable to retrieve the complete
list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to
handle the request
この問題を解決するには、任意のワークロードをスケールアップして GKE をトリガーし、新しいノードを作成します。ノードの準備が整うと、Namespace 削除リクエストが自動的に完了します。GKE により Namespace が削除されたら、ワークロードを再びスケールダウンします。
スケーリングに関する問題
ノードのスケールアップが失敗した: Pod がスケジュールされない可能性がある
次の問題は、Google Cloud プロジェクトでシリアルポート ロギングが無効になっていると発生します。GKE Autopilot クラスタでは、ノードの問題を効果的にデバッグするために、シリアルポート ロギングが必要です。シリアルポート ロギングが無効になっていると、Autopilot はワークロードを実行するノードをプロビジョニングできません。
Kubernetes イベントログのエラー メッセージは、次のようになります。
LAST SEEN TYPE REASON OBJECT MESSAGE
12s Warning FailedScaleUp pod/pod-test-5b97f7c978-h9lvl Node scale up in zones associated with this pod failed: Internal error. Pod is at risk of not being scheduled
シリアルポートのロギングは、compute.disableSerialPortLogging
制約を適用する組織のポリシーによって組織レベルで無効になっていることがあります。シリアルポート ロギングは、プロジェクト レベルまたは仮想マシン(VM)インスタンス レベルで無効になっていることもあります。
この問題を解決するには、次の操作を行います。
- Google Cloud 組織のポリシー管理者に、Autopilot クラスタを含むプロジェクトで
compute.disableSerialPortLogging
制約を削除するよう依頼してください。 - この制約を適用する組織のポリシーがない場合は、プロジェクト メタデータでシリアルポート ロギングを有効にすることを試してください。この操作には、
compute.projects.setCommonInstanceMetadata
IAM 権限が必要です。
ノードのスケールアップが失敗した: Pod のゾーンリソース超過
次の問題は、新しいノードがリソース上限に違反するため、Autopilot が特定のゾーンの Pod に新しいノードをプロビジョニングしない場合に発生します。
ログのエラー メッセージは次のようになります。
"napFailureReasons": [
{
"messageId": "no.scale.up.nap.pod.zonal.resources.exceeded",
...
このエラーは、ノードの自動プロビジョニングでゾーン内の Pod にノードグループがまったくプロビジョニングされなかった場合の noScaleUp
イベントを示しています。
このエラーが発生した場合は、次の点を確認してください。
- Pod に十分なメモリと CPU がある。
- Pod IP アドレスの CIDR 範囲が、予想される最大クラスタサイズをサポートするのに十分な大きさである。
ワークロードに関する問題
Pod が保留状態のままになる
Pod が使用するノードを具体的に選択した場合に、ノードで実行する必要がある Pod と DaemonSet のリソース リクエストの合計が、ノードに割り当て可能な最大容量を超えると、Pod が Pending
ステータスで停止することがあります。これにより、Pod が Pending
ステータスになり、スケジュール設定されないままになる可能性があります。
この問題を回避するには、デプロイしたワークロードのサイズを評価して、サポートされる Autopilot の最大リソース リクエストの範囲内であることを確認します。
通常のワークロード Pod をスケジュールする前に DaemonSet のスケジュールを設定してみることもできます。
特定のノードにおける一貫して信頼性の低いいワークロード パフォーマンス
GKE バージョン 1.24 以降では、特定のノード上のワークロードで中断、クラッシュ、またはそれと同様の信頼性の低い動作が繰り返し発生する場合は、次のコマンドでノードを閉鎖して、GKE に問題のあるノードを通知できます。
kubectl drain NODE_NAME --ignore-daemonsets
NODE_NAME
は、問題のあるノードの名前に置き換えます。ノード名を確認するには、kubectl get nodes
を実行します。
GKE は次の処理を行います。
- ノードから既存のワークロードを強制排除し、そのノードでワークロードのスケジュール設定を停止します。
- 他のノード上の Deployment や StatefulSet などのコントローラによって管理されている、強制排除されたワークロードを自動的に再作成します。
- ノードに残っているワークロードを終了し、時間をかけてノードを修復または再作成します。
- Autopilot を使用する場合、GKE はノードを直ちにシャットダウンして置き換え、構成済みの PodDisruptionBudgets を無視します。