一般的な問題のトラブルシューティング

このページでは、GKE on AWS の一般的な問題を解決する方法について説明します。

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

一般的なエラー メッセージ

以降のセクションでは、一般的なエラー メッセージの原因と解決策について説明します。

サーバーにリソースがない

クラスタに実行中のノードプールがない場合、または Connect ゲートウェイがノードプールに接続できない場合、error: the server doesn't have a resource type "services" などのエラーが発生することがあります。ノードプールのステータスを確認するには、次のコマンドを実行します。

gcloud container aws node-pools list \
    --cluster-name CLUSTER_NAME \
    --location LOCATION

次のように置き換えます。

  • CLUSTER_NAME: クラスタの名前
  • LOCATION: クラスタを管理する Google Cloud のロケーション

出力には、クラスタのノードプールのステータスが含まれます。ノードプールが表示されない場合は、ノードプールを作成します

禁止ユーザー

お使いのユーザー名にクラスタに対する管理者アクセス権がない場合は、次のエラーが発生します。

Error from server (Forbidden): users "administrator@example.com" is forbidden:
User "system:serviceaccount:gke-connect:connect-agent-sa" cannot impersonate
resource "users" in API group "" at the cluster scope

追加のユーザーを構成するには、クラスタの作成時に --admin-users フラグを渡します。

Connect ゲートウェイを使用していてクラスタに接続できない場合は、次の手順をお試しください。

  1. クラスタの承認済みユーザーを取得します。

    gcloud container aws clusters describe CLUSTER_NAME \
        --format 'value(authorization.admin_users)'
    

    CLUSTER_NAME をクラスタ名で置き換えます。

    出力には、クラスタに対する管理者権限があるユーザー名が含まれます。例:

    {'username': 'administrator@example.com'}
    
  2. Google Cloud CLI で現在認証されているユーザー名を取得します。

    gcloud config get-value account
    

    出力には、Google Cloud CLI で認証済みのアカウントが含まれます。gcloud containers aws clusters describegcloud config get-value account の出力が一致しない場合は、gcloud auth login を実行し、クラスタに対する管理者権限を持つユーザーとして認証を行います。

kubectl コマンドに関する問題

次のセクションでは、kubectl コマンドが応答しない場合や失敗する場合の解決方法について説明します。

kubectl コマンドが応答しない

クラスタが 1.25 より前の Kubernetes バージョンを実行していて、kubectl コマンドが応答しない、またはタイムアウトする場合、最も一般的な理由は、ノードプールがまだ作成されていないことです。デフォルトでは、GKE on AWS は、インターネットに接続可能なエンドポイントとして Connect ゲートウェイを使用する kubeconfig ファイルを生成します。これが機能するには、クラスタのノードプールで gke-connect-agent Deployment が実行されている必要があります。

詳細な診断情報を確認するには、次のコマンドを実行します。

kubectl cluster-info -v=9

動作しているノードプールがない場合、connectgateway.googleapis.com へのリクエストは 404 cannot find active connections for cluster エラーで失敗します。

Kubernetes バージョン 1.25 以降のクラスタでは、gke-connect-agent がコントロール プレーンで実行され、ノードプールは必要ありません。kubectl コマンドが応答しない場合は、Cloud Logging でコントロール プレーン コンポーネントのログを確認します。

kubectl exec、attach、port-forward コマンドが失敗する

Connect ゲートウェイを使用しているときに、kubectl execkubectl attachkubectl port-forward コマンドがメッセージ「error: unable to upgrade connection」で失敗することがあります。これは、Connect ゲートウェイを Kubernetes API Server エンドポイントとして使用する場合の制限事項です。

この問題を回避するには、kubeconfig を使用してクラスタのプライベート エンドポイントを指定します。プライベート エンドポイントを介してクラスタにアクセスする手順については、kubectl 用のクラスタ アクセスを構成するをご覧ください。

kubectl のログがリモートエラーで失敗する: tls: 内部エラー

この問題は、コントロール プレーン API ロールに権限がない場合に発生することがあります。たとえば、AWS ロールに ec2:DescribeDhcpOptions 権限がない場合に発生することがあります。この場合、ノードからの証明書署名リクエストは承認されず、ワーカーノードには有効な証明書がありません。

この問題かどうかを判断するには、次のコマンドを実行して、承認されなかった保留中の証明書署名リクエストがあるかどうかを確認します。

kubectl get csr

この問題を解決するには、AWS ロールが要件に一致していることを確認します。

kubectl の一般的なトラブルシューティング

Connect ゲートウェイを使用する場合:

  • Google Cloud プロジェクトで Connect ゲートウェイが有効になっていることを確認します。

    gcloud services enable connectgateway.googleapis.com
    
  • Kubernetes バージョン 1.25 より前のクラスタの場合は、少なくとも 1 つの Linux ノードプールが実行され、gke-connect-agent が実行されていることを確認します。詳細については、クラスタ接続のトラブルシューティングをご覧ください。

  • Kubernetes バージョン 1.25 以降のクラスタの場合は、Cloud Logginggke-connect-agent ログを確認します。

Kubernetes Service(LoadBalancer)や Kubernetes Ingress が機能しない

AWS Elastic Load Balancer(ELB/NLB/ALB)が作成されても、想定どおりに動作しない場合は、サブネットのタグ付けに問題がある可能性があります。詳細については、ロードバランサのサブネットをご覧ください。

Arm ノードの Pod がクラッシュする

Arm ノードに Pod をデプロイするときに、コンテナ イメージが Arm アーキテクチャ用にビルドされていないと、次の問題が発生します。

問題を特定するには、次の操作を行います。

  1. Pod のステータスを取得します。

    kubectl get pods
    
  2. クラッシュした Pod のログを取得します。

    kubectl logs POD_NAME
    

    POD_NAME は、クラッシュした Pod の名前に置き換えます。

    Pod ログのエラー メッセージは、次のようになります。

    exec ./hello-app: exec format error
    

この問題を解決するには、コンテナ イメージが Arm アーキテクチャをサポートしていることを確認します。マルチ アーキテクチャ イメージのビルドをおすすめします。

クラスタを削除できない

クラスタを削除しようとしたときに次のようなエラーが発生した場合、GKE Multi-Cloud API ロールが存在しない可能性があります。

ERROR: (gcloud.container.aws.clusters.delete) FAILED_PRECONDITION: Could not
assume role
"arn:aws:iam::ACCOUNT_NUMBER:role/gke123456-anthos-api-role"
through service account
"service-123456789@gcp-sa-gkemulticloud.iam.gserviceaccount.com".
Please make sure the role has a trust policy allowing the GCP service agent to
assume it: WebIdentityErr failed to retrieve credentials

問題を解決するには、GKE Multi-Cloud API ロールの作成の説明に従います。同じ名前と権限を持つロールを再作成する場合は、コマンドを再試行できます。

次のステップ