サポートとトラブルシューティング

このページでは、Kubernetes と Kubernetes Engine に関して利用可能なサポートおよびトラブルシューティングのリソースと、よくある問題の解決方法について説明します。

サポート

Kubernetes Engine および Kubernetes には、以下のサポート リソースがあります。

Kubernetes のバグと機能リクエスト

バグが発生した場合や機能をリクエストしたい場合は、GitHub で問題を提出してください。

問題を提出する前に、既存の問題を検索して、問題がまだ解決されていないことを確認してください。

バグを報告する場合は、問題を再現する方法について、次のような詳細情報を記載してください。

  • Kubernetes のバージョン: kubectl バージョン
  • クラウド プロバイダ、OS ディストリビューション、ネットワーク構成、Docker バージョン
  • 問題の再現手順

トラブルシューティング

以降のセクションで、Kubernetes Engine で発生する一般的な問題について説明します。

Kubernetes リソースのデバッグ

クラスタに関する問題が発生している場合は、Kubernetes のドキュメントでクラスタのトラブルシューティングをご覧ください。

アプリケーション、ポッド、またはコントローラ オブジェクトに問題がある場合は、アプリケーションのトラブルシューティングをご覧ください。

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 Monitoring APIStackdriver 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 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 を有効にしたときに作成され、プロジェクトの編集権限が与えられます。いずれかの時点で権限を編集するかアカウントを完全に削除した場合、クラスタの作成は失敗します。

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

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

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