web-dev-qa-db-ja.com

「Net / httpに接続できません：TLSハンドシェイクタイムアウト」— KubectlがAzure Kubernetesサーバーに接続できないのはなぜですか？ （AKS）

私の質問（MSおよび他の人）は、この問題が発生している理由と、Microsoftサポートではなくユーザー/顧客自身がどのような回避策を実装できるのですか？

この問題に関して、明らかに「いくつかの」他の質問がありました。

  1. 管理されたAzure Kubernetes接続エラー
  2. Azure-AKS kubeに連絡できません-TLSハンドシェイクタイムアウト
  3. Azure Kubernetes：TLSハンドシェイクタイムアウト （Microsoftからのフィードバックがあります）

そして、AKSリポジトリに投稿された複数のGitHubの問題：

  1. https://github.com/Azure/AKS/issues/112
  2. https://github.com/Azure/AKS/issues/124
  3. https://github.com/Azure/AKS/issues/164
  4. https://github.com/Azure/AKS/issues/177
  5. https://github.com/Azure/AKS/issues/324

さらに、いくつかのTwitterスレッド：

  1. https://Twitter.com/ternel/status/955871839305261057

TL; DR

以下の回答の回避策にスキップ。

現在の最良の解決策は、ヘルプチケットを投稿して待機するか、AKSクラスターを再作成することです（複数回、指を交差させて、以下を参照してください）。 少なくとも、サポート層に関係なく、AKSをプレビューして、この特定の問題のサポートリクエストの重大度をアップグレードできるようにしてください。

クラスターのスケーリングを試すこともできます（アプリが破損しないことを前提としています）。

GitHubはどうですか？

上記のGitHubの問題の多くは解決済みとしてクローズされていますが、問題は解決しません。以前は、問題に関するアナウンスドキュメントがありましたが、問題が引き続き発生している場合でも、そのようなステータスの更新は現在利用できません。

  1. https://github.com/Azure/AKS/tree/master/annoucements

他の場所では見たことのないいくつかの新しい情報があるので、これを投稿しています。この問題を回避するためのその他の潜在的なオプションについて、誰かがアイデアを持っているかどうか疑問に思っています。

影響ありVM/Nodeリソース使用量

他の場所で言及されていない最初の部分は、上記のKubectlの「サーバーに接続できません：net/http：TLSハンドシェイクタイムアウト」問題の影響を受けているノード/ vms /インスタンスのリソース使用量です。

本番Node Utilization

影響を受けるクラスター上のノードは次のようになります。

net/http: TLS handshake timeout

使用率とネットワークioの低下は、ディスク使用率の増加と、問題が発生し始めた期間の両方と強く相関しています。

全体のNode/VM使用率は、実稼働サイトのトラフィック/更新のプッシュなどに関連するいくつかのバンプを伴う、過去30日間のこのチャートの前は一般にフラットです。

問題軽減後のメトリック（追加の事後分析）

上記のポイントまで、同じメトリックをNodeスケールアップしてからダウンした後）（これはたまたま問題を軽減しましたが、常に機能するとは限りません—下部の回答をご覧ください）：

enter image description here

CPUとネットワークの「ディップ」に注意してください？ここで、Net/http：TLSの問題が影響を受けましたus — AKSサーバーがKubectlから到達不能であったとき。リクエストに応答しないことに加えて、VM/Node=.

戻るとすぐに（＃ノードを1つずつ拡大し、縮小します-回避策の回答を参照）、メトリック（CPUなど）が通常に戻りました-そして、Kubectlから接続できました。これはおそらく、この動作からアラームを作成できることを意味します（そして、Azure DevOps側でこれについて質問する際に問題があります： https://github.com/Azure/AKS/issues/416 ）

ノードのサイズが問題の頻度に影響する可能性

GitHubのZimmergrenは、ベアボーンを小さなノードで実行するよりも、大きなインスタンスで問題が少ないことを示しています。これは理にかなっており、AKSサーバーがワークロードを分割する方法（次のセクションを参照）がインスタンスのサイズに基づいていることを示している可能性があります。

「ノードのサイズ（例：D2、A4など）:) A4以上を実行しているとき、A2を実行している場合よりもクラスターのほうが健全であることがわかりました。残念ながら、サイズの組み合わせやクラスター障害の経験があります）。 （ https://github.com/Azure/AKS/issues/268#issuecomment-375715435 ）

その他のクラスターサイズの影響の参照：

  1. giorgited（ https://github.com/Azure/AKS/issues/268#issuecomment-376390692 ）

より小さなクラスターを担当するAKSサーバーは、より頻繁にヒットする可能性がありますか？

1つのAzリージョンに複数のAKS管理「サーバー」が存在する

私が他の場所で言及していない次のことは、同じリージョンで複数のクラスターを並べて実行できるという事実です。この場合、1つのクラスター（この場合は本番用）が「net/http：TLSハンドシェイクタイムアウト」でヒットしますもう1つは正常に機能しており、Kubectlを介して通常どおり接続できます（この場合、これは同じステージング環境です）。

ユーザー（上記のZimmergrenなど）は、Nodeサイズがこの問題があなたに影響を与える可能性に影響を与えると感じているようです。また、ノードサイズがサブリージョンの方法に関連している可能性を示しているようです責任はサブリージョンのAKS管理サーバーに割り当てられます。

つまり、異なるクラスターサイズでクラスターを再作成すると、別の管理サーバーに移動する可能性が高くなり、問題が軽減され、複数の再作成が必要になる可能性が低くなります。

クラスター使用率のステージング

AKSクラスターはどちらも米国東部にあります。上記の「生産」クラスターメトリックへの参照として、「ステージング」クラスター（米国東部）のリソース使用率にCPU /ネットワークの大幅な低下はありませんIO — AND増加はありません同じ期間のディスクなどで：

net/http: TLS handshake timeout staging instance is reachable via kubectl.

同一の環境が異なる影響を受ける

両方のクラスターが同一のイングレス、サービス、ポッド、コンテナーを実行しているため、ユーザーが行っていることによってこの問題が発生することはほとんどありません。

再作成は一部の場合にのみ成功します

上記の複数のAKS管理サーバーのサブリージョンの責任は、githubで他のユーザーによって記述された動作で意味があります（ https://github.com/Azure/AKS/issues/112 ）他の人が再作成してもまだ問題がある間に、クラスタを再作成することができます（その後、連絡することができます）。

緊急事態=複数の再作成

緊急の場合（つまり、生産サイト...私たちのもののように...管理する必要があります）、次のことができます[〜＃〜]おそらく[〜＃〜] 別のAKS管理サーバーインスタンス（影響を受けていないインスタンス）にたまたま動作するクラスターを取得するまで再作成しますが、これは発生しない可能性があることに注意してください初めての試み— AKSクラスターの再作成は正確ではありません。

とはいえ...

影響を受けるノードのリソースは引き続き機能します

影響を受けるVMのコンテナ/イングレス/リソースはすべて正常に動作しているようで、稼働時間/リソースの監視（リストされている使用率の異常以外は）上記のグラフ）

この問題が発生する理由と、Microsoftサポート（現在チケットを持っている）ではなく、ユーザー自身がどの回避策を実装できるかを知りたい。アイデアがあれば教えてください。

原因の潜在的なヒント

  1. https://github.com/Azure/AKS/issues/164#issuecomment-36361311
  2. https://github.com/Azure/AKS/issues/164#issuecomment-365389154

なぜGKEがないのですか？

Azure AKSがプレビュー中であり、この問題のために多くの人がGKEに移行していることを理解しています（）。これまでのところ、私のAzureエクスペリエンスはこれまでのところポジティブであり、可能な限りソリューションを提供したいと考えています。

また... GKEは時折同様の問題に直面します。

  1. GKEのkubernetesでのTLSハンドシェイクタイムアウト

GKE上のノードをスケーリングすることで問題が解決するかどうかを確認したいと思います。

azureazure-kubernetes
14
Necevil

回避策1（全員に機能しない場合があります）

テストするための興味深いソリューション（私のために働いた）は、クラスター内のノードの数をスケールアップしてからダウンします...

enter image description here

  1. Azure Console — Kubernetes Serviceブレードにログインします。
  2. クラスターを1ノードずつスケールアップします。
  3. スケールが完了するのを待って、接続を試みます（できるはずです）。
  4. コストの増加を避けるため、クラスターを通常のサイズに縮小します。

別の方法として、コマンドラインからこれを行うことができます（おそらく）。

az aks scale --name <name-of-cluster> --node-count <new-number-of-nodes> --resource-group <name-of-cluster-resource-group>

それは厄介な問題であり、Webインターフェイスを使用したため、上記が同一であるか機能するかはわかりません

合計で約2分かかりました。クラスターを再作成/構成するよりもはるかに優れた状況の場合（場合によっては複数回...）

言われていること....

Zimmergrenは、スケーリングは真のソリューションではないという良い点をいくつか挙げています。

「クラスターがスケーリング後に一定期間自己修復した場合は時々機能しました。同じエラーで失敗することもありました。この問題に対するソリューションのスケーリングは考えていません。 GAワークロードについては、そのルーチンを信頼しません。確かにそうです。現在のプレビューでは、それは少しワイルドな西（そして予想）であり、クラスターを爆破して、これが継続的に失敗する場合、新しいものを作成します。」（ https://github.com/Azure/AKS/issues/268#issuecomment-395299308 ）

Azureサポートフィードバック

上記のスケーリングソリューションに出会ったときにサポートチケットを開いていたので、上記の動作についてフィードバック（または推測）を得ることができました。

「ノードの数が「az aks show」と「kubectl get nodes」の間で一致しない状態になった場合、クラスターのスケーリングが役立つ場合があることを知っています。これは似ている可能性があります。」

回避策の参照：

  1. GitHubユーザーはコンソールからノードをスケーリングし、問題を修正しました： https://github.com/Azure/AKS/issues/268#issuecomment-375722317

回避策は機能しませんか？

これで問題が解決しない場合は、以下のコメントを投稿してください。問題が発生する頻度、それ自体が解決するかどうか、このソリューションがAzure AKSユーザー全体で機能するかどうかの最新リストを維持しようとするためです。それは皆のために機能しないように）。

ユーザーのスケールアップ/ダウンDID

  1. omgsarge（ https://github.com/Azure/AKS/issues/112#issuecomment-395231681 ）
  2. Zimmergren（ https://github.com/Azure/AKS/issues/268#issuecomment-395299308 ）
  3. sercand —スケール操作自体が失敗しました—接続性に影響があるかどうかはわかりません（ https://github.com/Azure/AKS/issues/268#issuecomment-395301296 ）

スケールアップ/ダウンDID

  1. 私
  2. LohithChanda（ https://github.com/Azure/AKS/issues/268#issuecomment-395207716 ）
  3. Zimmergren（ https://github.com/Azure/AKS/issues/268#issuecomment-395299308 ）

Azure AKS固有のサポートにメールを送信

それでもこの問題に悩まされている場合は、aks-help @ service.Microsoft.comにメールを送信してください。

4
Necevil

上記の試みが機能しない場合、これがAzureサポートの公式ソリューションであるため、別の回答を追加します。私はしばらくこの問題を経験していないので、これを確認することはできませんが、それは私にとって理にかなっているようです（以前の経験に基づいて）。

このクレジット/ここにあるスレッド全体（ https://github.com/Azure/AKS/issues/14#issuecomment-42482869 ）

トンネリングの問題を確認する

  1. トンネルフロントポッドを実行しているエージェントノードへのssh
  2. トンネルフロントログを取得します： "docker ps"-> "docker logs"
  3. 上記のコマンドからfqdnを取得できる「nslookup」-> ipを解決する場合、つまりdnsが機能する場合は、次の手順に進みます
  4. 「ssh -vv azureuser @ -p 9000」->ポートが機能している場合は、次の手順に進みます
  5. 「docker exec -it/bin/bash」、「ping google.com 」と入力します。応答がない場合、つまりトンネルフロントポッドに外部ネットワークがない場合は、次の手順を実行します
  6. 「kubectl delete po -n kube-system」を使用してkube-proxyを再起動し、tunnelfrontと同じノードで実行されているkube-proxyを選択します。顧客は「kubectl get po -n kube-system -o wide」を使用できます

この特定の回避策は、[〜＃〜]おそらく[〜＃〜]自動化できると思います（確かにAzure側ですが、おそらくコミュニティ側）。

Azure AKS固有のサポートにメールを送信

それでもこの問題に悩まされている場合は、aks-help @ service.Microsoft.comにメールを送信してください。

1
Necevil

回避策2クラスターの再作成（やや明らか）

覚えておく必要がある詳細があるため、これを追加しています。元の質問で触れましたが、それは長くなりましたので、ここで再作成に関する特定の詳細を追加しています。

クラスターの再作成が常に機能するとは限りません

上記の私の最初の質問では、特定のAzureリージョンの責任を分割する複数のAKS Serverインスタンスがあります（考えています）。これらの一部またはすべてがこのバグの影響を受け、Kubectlを介してクラスターに到達できなくなる可能性があります。

つまり、クラスターを再作成し、同じAKSサーバーに何らかの方法で到達すると、おそらく新しいクラスターは[〜＃〜] also [〜＃〜]到達可能でなくて...

追加の再作成の試み

おそらく複数回再作成すると、最終的に他のAKSサーバーのいずれかに新しいクラスターを着陸させることになります（正常に機能しています）。私が知る限り、すべてのAKSサーバーがこの問題に一度に（もしあれば）打撃を受けるという兆候は見られません。

異なるクラスターNodeサイズ

ピンチ状態にあり、再作成が別のAKS管理サーバーに到達する可能性が最も高い（これを確認していません） —新しいクラスターを作成するときに、異なるNodeサイズを選択します（上記の最初の質問のNodeサイズセクションを参照）。

このチケットを開き、Azure DevOpsにNodeサイズが実際にどのクラスターがどのAKS管理サーバーによって管理されるかを決定することに関連するかどうかを尋ねます： https://github.com/ Azure/AKS/issues/416

サポートチケットの修正と自己修復

問題がときどき解決して消えてしまうことを示すユーザーが多いため、サポートが問題のあるAKSサーバーを実際に修正すると推測するのは合理的だと思います（他のユーザーのクラスターが修正される可能性があります-'Self Heal '）個々のユーザーのクラスターを修正するのではなく。

サポートチケットの作成

私にとって、上記は同じ問題を経験している他のユーザークラスターを修正するので、おそらくチケットを作成することはおそらく良いことを意味します。これは、この特定の問題のサポート問題の重大度エスカレーションを許可するための引数かもしれません。

これは、Azureサポートがまだ問題を完全に警告する方法をまだ理解していないことを示す適切な指標でもあると思います。その場合、サポートチケットの作成もその目的に役立ちます。

また、Azure DevOpsに、問題について警告するかどうかを尋ねました（CPUとネットワークIOメトリックの変更）に基づいて問題を簡単に視覚化した経験に基づいて： https：// github.com/Azure/AKS/issues/416

NOT（返事がない）の場合は、クラスタを再作成する予定であってもチケットを作成するのは理にかなっています。 Azure DevOpsに、そのクラスター管理サーバー上の他のユーザーの修正につながる問題を認識させます。

クラスターの再作成を簡単にするためのもの

私はこれに追加します（フィードバック/アイデアは大歓迎です）

  1. クラスターを作成するために使用されるすべてのYAMLファイルを保存する方法については慎重に（明白に）設計してアプリを頻繁に再デプロイしない場合でも。
  2. DNSの変更をスクリプト化して、新しいインスタンスへのポインティングを高速化します— DNSを利用する公開アプリケーション/サービスがある場合（Googleドメインのこの例のようなものですか？： https：//Gist.github。 com/cyrusboadway/5a7b715665f33c237996 、完全なドキュメントはこちら： https://cloud.google.com/dns/api/v1/ ）
0
Necevil

クラスターの1つでこの問題が発生しました。サポートチケットを送信し、5分後にエンジニアがコールして、APIサーバーを再起動してもよいかどうかを尋ねました。 2分後、再び機能しました。

理由は、メッセージングキューのタイムアウトに関するものでした。

0
Mats Iremark