トラブルシューティング

kubectl コマンドが見つかりません

最初に、次のコマンドを実行して kubectl バイナリをインストールします。

sudo gcloud components update kubectl

$PATH 環境変数を変更するかどうかを確認するメッセージが表示されたら、「yes」を選択します。この変数を変更すると、ファイルの完全なパスを入力せずに kubectl コマンドを使用できます。

または、次の行を ~/.bashrc(macOS では ~/.bash_profile、または使用しているシェルが環境変数を格納するその他の場所)に追加します。

export PATH=$PATH:/usr/local/share/google/google-cloud-sdk/bin/

最後に、次のコマンドを実行して、更新された .bashrc(または .bash_profile)ファイルをロードします。

source ~/.bashrc

kubectl コマンドを実行すると「connection refused」(接続は拒否されました)というエラーが表示されます

次のコマンドを使用してクラスタのコンテキストを設定します。

gcloud container clusters get-credentials CLUSTER_NAME

CLUSTER_NAME に何を入力すればよいかわからない場合は、次のコマンドを使用してクラスタを一覧表示します。

gcloud container clusters list

kubectl コマンドを実行すると「API バージョンのネゴシエーションができませんでした」というエラーが表示されます

kubectl に認証情報があることを確認します。

gcloud auth application-default login

kubectllogsattachexecport-forward コマンドがハングします

これらのコマンドは、クラスタのマスターがクラスタ内のノードと通信できることを前提にして動作します。ただし、マスターはクラスタのノードと同じ Compute Engine ネットワーク内にはないので、SSH トンネルを利用してセキュアな通信を実現しています。

Kubernetes Engine は SSH 公開鍵を Compute Engine プロジェクトのメタデータに保存します。Google 提供のイメージを使用するすべての Compute Engine VM はプロジェクトの共通メタデータとインスタンスのメタデータを定期的にチェックし、承認済みユーザーの VM のリストに追加する SSH 認証鍵がないかどうかを確認します。また、Kubernetes Engine はマスターの IP アドレスからクラスタ内の各ノードへの SSH アクセスを許可するファイアウォール ルールを Compute Engine ネットワークに追加します。

上記の kubectl コマンドのいずれかが動作しない場合、マスターがノードへの SSH トンネルを開くことができない可能性があります。次のような問題がないかどうかを確認してください。

  1. クラスタにノードが存在しない。

    クラスタ内のノードの数を減らして 0 にした場合、SSH トンネルは動作しません。

    この問題を修正するには、クラスタのサイズを変更してノードを 1 台以上配置します。

  2. クラスタ内のポッドが終了状態のまま復帰しないため、存在しなくなったノードをクラスタから削除できない。

    この問題は Kubernetes バージョン 1.1 にのみ影響しますが、クラスタのサイズの変更を繰り返した場合に発生する可能性があります。

    この問題を修正するには、終了状態のまま数分以上経過しているポッドを削除します。これによって古いノードがマスターの API から削除され、新しいノードに置き換えられます。

  3. ネットワークのファイアウォール ルールでマスターへの SSH アクセスを許可していない。

    すべての Compute Engine ネットワークは「default-allow-ssh」というファイアウォール ルールを使用して作成されます。このルールでは有効な秘密鍵を持つすべての IP アドレスからの SSH アクセスが許可されます。また、Kubernetes Engine は gke-<cluster_name>-<random-characters>-ssh 形式のクラスタごとの SSH ルールも挿入します。このルールでは、クラスタのマスター IP からクラスタのノードへの SSH アクセスが個別に許可されます。どちらのルールも存在しない場合、マスターは SSH トンネルを開くことができません。

    この問題を修正するには、マスターの IP アドレスからすべてのクラスタのノード上にあるタグの付いた VM へのアクセスを許可するファイアウォール ルールを再度追加します。

  4. プロジェクトの「sshKeys」用の共通メタデータ エントリがいっぱいになっている。

    プロジェクトの「sshKeys」というメタデータ エントリのサイズが 32 KiB の上限に近づいていると、Kubernetes Engine は SSH トンネルを開くための SSH 認証鍵を追加できません。プロジェクトのメタデータを確認するには gcloud compute project-info describe [--project=PROJECT] を実行し、sshKeys のリストの長さを調べます。

    この問題を修正するには、不要になった SSH 認証鍵を削除します。

  5. クラスタ内の VM でメタデータ フィールドに認証鍵「sshKeys」を設定している。

    VM のノード エージェントではプロジェクト全体の SSH 認証鍵よりもインスタンスごとの sshKeys が優先されるため、クラスタのノードで SSH 認証鍵を個別に設定している場合、ノードはプロジェクトのメタデータ内にあるマスターの SSH 認証鍵を無視します。確認するには、gcloud compute instances describe <VM-name> を実行し、メタデータに「sshKeys」フィールドがあるかどうかを調べます。

    この問題を修正するには、インスタンスのメタデータからインスタンスごとの SSH 認証鍵を削除します。

これらの機能はクラスタの正常な動作に必須ではないことに注意してください。クラスタのネットワークを外部アクセスから完全に遮断した場合、これらのような機能が動作しなくなることに注意してください。

クラスタからの指標が Stackdriver に表示されません

プロジェクトで Stackdriver Montioring API および Stackdriver Logging API を有効にしてあること、および Stackdriver でプロジェクトを表示できることを確認します。

問題が解決しない場合は、次の原因が考えられます。

  1. クラスタでモニタリングを有効にしてあることを確認します。

    Developers Console や gcloud を使用して作成したクラスタではモニタリングがデフォルトで有効になりますが、次のコマンドを実行するか、Developers Console でマウスをクリックしてクラスタの詳細を表示することで、有効かどうかを確認できます。

    gcloud container clusters describe cluster-name
    

    有効な場合は、gcloud コマンドライン ツールの出力で "monitoringService" が "monitoring.googleapis.com" と表示されるか、Developers Console で Cloud Monitoring が有効と表示されます。

    モニタリングが有効になっていない場合は、次のコマンドを実行して有効にします。

    gcloud alpha container clusters update cluster-name --monitoring-service=monitoring.googleapis.com
    
  2. クラスタを作成してから、またはモニタリングを有効にしてからどれくらいの時間が経過していますか?

    新しいクラスタの指標が Stackdriver Monitoring に表示されるまでに最長で 1 時間かかります。

  3. heapster がクラスタの "kube-system" 名前空間で実行されていますか?

    クラスタがいっぱいでスケジュールに失敗している可能性があります。kubectl get pods --namespace=kube-system を呼び出して、実行されているかどうかを確認してください。

  4. クラスタのマスターはノードと通信できますか?

    Stackdriver Monitoring はこの通信に依存します。kubectl logs [POD-NAME] を実行することで、通信できるかどうかを確認できます。このコマンドがエラーを返す場合、SSH トンネルが問題の原因である可能性があります。こちらのセクションをご確認ください。

Stackdriver Logging エージェントに関する問題が発生している場合は、エージェントのトラブルシューティング ドキュメントをご覧ください。

詳細については、Stackdriver のドキュメントをご覧ください。

エラー 404: gcloud container コマンドを呼び出したときにリソースが「見つかりませんでした」

gcloud コマンドライン ツールに対して再度認証を実行します。

gcloud auth login

エラー 400: アカウントに編集権限がありません

お使いの Compute Engine サービス アカウントが削除または編集されています。

このアカウントは Compute Engine API を有効にしたときに作成され、プロジェクトの編集権限が与えられます。いずれかの時点で権限を編集するかアカウントを完全に削除した場合、クラスタの作成は失敗します。

この問題を解決するには、アカウントを作成し直すか、アカウントのプロジェクトの編集権限を復元します。

アプリケーションのデバッグ

Kubernetes のドキュメントには、ポッドやレプリケーション コントローラに関する問題などについてアプリケーションをデバッグする方法、およびデバッグ サービスに関する説明が記載されています。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Kubernetes Engine のドキュメント