kubectl：サーバーからのエラー：現在開いているSSHトンネルはありません

Question

Google Container Engineでいくつかのコンテナを実行しています。 ある日はすべて問題なく、翌日私のコンテナにはもうattachを入れることができません。またはexec、または他のドッカーコマンド。

ポッドを削除して新しいインスタンスをインスタンス化するようにしましたが、助けになりませんでした。 その後、ノードを削除し、新しいノードが作成されるのを待ち、配置されたポッドも助けになりませんでした。

$ kubectl attach www-controller-dev-xxxxx 

Error from server: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-xxxxxxxxxxxxxxxxxxxxxxxx"? 

他に何を試すことができますか？

クラスタを削除して再作成した後に問題が発生した可能性がありますが、わかりません。それ以前にそれをしたことは決して問題ではありませんでした。

Answer 1

クラスタのマスターがクラスタ内のノード と通信できるようにするというコマンドは、添付ファイルのようなものです。ただし、マスタはクラスタのノードと同じCompute Engineネットワークに属していないため、SSHトンネルを使用してセキュアな 通信を有効にしています。

コンテナエンジンは、Compute EngineプロジェクトにSSH公開鍵を置きます。 metadata。 Google提供の画像を使用するすべてのCompute Engine VMは、プロジェクトの一般的なメタデータ とそのインスタンスのSSHキーのメタデータを定期的にチェックして、承認済みのユーザー のVMのリストに追加します。 Container Engineは、Compute Engineネットワークにファイアウォールルールを追加して、マスターのIPアドレスからクラスター内の各ノード へのSSHアクセスを許可します。

kubectl attach（またはlogs、exec、およびport-forward）が機能しない場合、マスターがSSHトンネルをノードに開くことができない可能性があります。 への根本的な問題は、あなたがこれらの潜在的 原因を確認する必要があり、何であるかを決定します。

1. クラスタがどのノードを持っていません。

   クラスタ内のノード数をゼロに縮小した場合、SSH トンネルは機能しません。

   修正するには、少なくとも1つのノードを持つように、 resize your cluster を修正します。

2. クラスタ内のポッドが停止状態になって、もはや存在しなくなったノードがクラスタから削除されないようにしました。

   これはKubernetesバージョン1.1にのみ影響しますが、 はクラスタのサイズ変更を繰り返すことで発生する問題です。

   修正するには、数分間以上終了状態になっていた delete the pods を修正してください。 古いノードはマスターのAPIから削除され、 が新しいノードに置き換えられます。

3. ネットワークのファイアウォールルールでは、マスターへのSSHアクセスが許可されていません。

   すべてのCompute Engineネットワークは、 「default-allow-ssh」というファイアウォールルールを使用して作成され、すべてのIPアドレスからのSSHアクセスを許可します（ には有効な秘密鍵が必要です）。 Container Engineは、クラスタのマスターIPから具体的にはクラスタのノード へのSSHアクセスを可能にする形式 "gke --- ssh" の各クラスタに対してSSHルール を挿入します。これらのルールがどちらも存在しない場合、マスターは SSHトンネルを開くことができません。それを修正する

   、 re-add a firewall rule マスターのIPアドレスからのすべてのクラスタのノードでのタグ付きのVMへのアクセスを可能にします。

4. sshKeysのプロジェクトの共通メタデータエントリがいっぱいです。

   「sshKeys」という名前のプロジェクトのメタデータエントリが32KiBサイズ 限界に近い場合には、コンテナエンジンはそれを オープンSSHトンネルをできるように、独自のSSHキーを追加することができません。 gcloud compute project-info describe [--project=PROJECT]を実行してプロジェクトのメタデータを確認してから、 sshKeysのリストの長さを確認してください。

   修正するには、不要になった delete some of the SSH keys を修正してください。

5. クラスタ内のVM上で、キー "sshKeys"でメタデータフィールドを設定しました。

   VM上のノード・エージェントは、インスタンスごとのsshKeysは、プロジェクト全体のためにSSH鍵を好む、 ので、あなたは、具体的クラスタのノード上のすべてのSSHキーを設定した場合、プロジェクトのメタデータで、その後 マスターのSSH鍵になるではありませんノードによって尊重される。 チェックするには、gcloud compute instances describe <VM-name>を実行し、 のメタデータに「sshKeys」フィールドがないか探します。

   これを修正するには、インスタンスメタデータから delete the per-instance SSH keys を修正します。

これは、これらの機能は、クラスタの正しい 機能するために必要とされないことは注目に値します。クラスタのネットワークを にすべての外部アクセスからロックしたままにしたい場合は、それは問題ありません。これらのような機能は結果として機能しませんので、ご注意ください。

Answer 2

あまり良い答えが、それは私が得た唯一のものです：

初めてクラスタを削除するには助けにはなりませんでした。 2回目にクラスタを削除したとき（翌日）、今度はkubectl attachとkubectl execに戻ってきました。

Google Containerプラットフォームの一時的な問題であっても、クラスタを再作成しても何の問題もありませんでした。