/ sigノード
/ sig api-machinery

コードを調べると、ここでエラーが発生し

コードの説明は、おそらくEOF（IsProbableEOF）を想定しているが、この場合はそうではないようだということです。

/ assign @caesarxuchao

@rikatz貼り付けたコードをどのように追跡したか、詳しく説明していただけますか？

私の考えでは、リフレクターはエラー（コード）をどのように処理しても時計を再起動するので、回復の失敗を説明していません。

まさに@caesarxuchaoなので、これが私たちの質問です。

私は基本的にコードを介してエラーを追跡し、その部分に入るためにkubeletがその時に行っていたこと（秘密を監視）と交差することを追跡しました。

高度な方法ではありません。これがエラーコードの正確なポイントのようです。

問題は、接続が閉じているため、これがエラーであることを理解するのではなく、これがウォッチEOFであることを示すフラグがどこかにあるかどうかです。

同じ方法で別のノードに障害が発生し、発生回数が過去4日間から4日間に増加したことを除いて、追加するのに賢い方法は他にありません。

ボンドが他のノードでイベントを切断し、kubeletが回復している場合、マップを試みます-100％のイベントではなく、一部の回復では運が悪い可能性があります。

私たちもこれを見ていると思いますが、私たちは絆を持っていません。Calico cali*インターフェースのこれらのネットワーク化された「キャリアロスト」メッセージだけが見られ、それらはローカルvethデバイスです。

私もこれに遭遇しましたが、絆はありませんでした。 ノードを再起動すると問題は解決しますが、Kubeletサービスを再起動するだけでは問題は解決しません（すべてのAPI呼び出しが「Unauthorized」で失敗します）。

私もこれに遭遇しましたが、絆はありませんでした。 ノードを再起動すると問題は解決しますが、Kubeletサービスを再起動するだけでは問題は解決しません（すべてのAPI呼び出しが「Unauthorized」で失敗します）。

更新：十分な時間（1時間？）が経過した後、Kubeletを再起動すると問題が修正されました。

私はこれと同じ振る舞いを見ています。 Ubuntu 18.04.3LTSクリーンインストール。 ランチャー2.3.4で構築されたクラスター。 最近、これが定期的に発生するのを目にしましたが、kubeletを再起動するだけで修正される傾向があります。 昨夜、3つのワーカーノードすべてがこれと同じ動作を示しました。 クラスターを起動するように2を修正しました。 掘り下げている間、3番目はまだこの状態です。

CentOS 7、ランチャー（1.17.2）で新しく構築されたクラスターでも同じ問題が発生しています。 織りを使用しています。 3つのワーカーノードすべてがこの問題を示しています。 kubeletを再起動しても、ノード全体を再起動する必要があります。

/ sigノード
/ sig api-machinery

コードを調べると、ここでエラーが発生し

コードの説明は、おそらくEOF（IsProbableEOF）を想定しているが、この場合はそうではないようだということです。

同じ問題が発生しています。 ログから、問題が発生した後も、後続のすべての要求が同じ接続で送信されていることがわかりました。 クライアントはリクエストをapiserverに再送信しますが、アンダーレイhttp2ライブラリは古い接続を維持しているため、後続のすべてのリクエストはこの接続で送信され、同じエラーuse of closed connectionを受け取ります。

それで問題は、なぜhttp2がすでに閉じられた接続を維持しているのかということです。 多分それが維持した接続は確かに生きていますが、いくつかの中間接続は予期せず閉じられますか？

k8s1.17.3を使用するRaspberryPiクラスターでも同じ問題が頻繁に発生します。 いくつかの古い問題に基づいて、kubeAPIサーバーのhttp接続制限を1000 "--- http2-max-streams-per-connection = 1000"に設定しました。その後、2週間以上問題なく、再び起動しました。

kube-apiserverを再構築することは可能ですかhttps://github.com/kubernetes/apiserver/blob/b214a49983bcd70ced138bd2717f78c0cff351b2/pkg/server/secure_serving.go#L50
デフォルトでs.DisableHTTP2をtrueに設定しますか？
公式画像（ k8s.gcr.io/kube-apiserver:v1.17.3 ）のdockerfileはありますか？

ここでも同じです。（ubuntu18.04、kubernetes 1.17.3）

また、2つのクラスターでこれを観察しました。 根本的な原因については完全にはわかりませんが、少なくとも、ウォッチ数が非常に多いクラスターでこれが発生していることがわかりました。 ただし、kubeletごとに多数のウォッチを強制することによって再現することはできませんでした（ポッドごとに300シークレットでポッドを開始したため、Prometheusメトリックではポッドごとに300ウォッチになりました）。 また、非常に低いhttp2-max-streams-per-connection値を設定しても問題は発生しませんでしたが、少なくとも、予期しないスケジューラーとコントローラーマネージャーの動作を観察できました（無限の再監視ループなどの後で過負荷になった可能性があります。けれど）。

回避策として、すべてのノードがローカルcronジョブを介して毎晩kubletを再起動します。 10日前の今、私はそれが私のために働いていると言うことができます、私は私のノードでもう「閉じたネットワーク接続の使用」をしていません。

@sbiermann
これを投稿していただきありがとうございます。 cronjobに使用する時間間隔はどれくらいですか？

24時間

この問題も確認できます。まだ1.17.3を使用しておらず、現在Ubuntu19.10を実行しています。

Linux <STRIPPED>-kube-node02 5.3.0-29-generic #31-Ubuntu SMP Fri Jan 17 17:27:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

NAME                  STATUS   ROLES    AGE   VERSION       INTERNAL-IP   EXTERNAL-IP   OS-IMAGE       KERNEL-VERSION     CONTAINER-RUNTIME
STRIPPED-kube-node02   Ready    <none>   43d   v1.16.6   10.6.0.12     <none>        Ubuntu 19.10   5.3.0-29-generic   docker://19.3.3

これは、RancherOS1.5.5ノードのRancher2.3.5を介してデプロイされたKubernetes1.17.4でも確認できます。 kubeletを再起動するとうまくいくようですが、ノード全体を再起動する必要はありません。

私の根本的な原因は、RAMが不足に近づき、kswapd0が最大100％のCPU使用率になっていることです。これは、Kubernetesノードのswappinessを0に設定するのを忘れたためです。 swappinessを0に設定し、マシンにRAMを追加した後、この問題はまだ発生していません。

根本的な問題が「接続切れを使用したhttp2」であった場合は、kubeletを再起動すると問題が解決するはずです。 https://github.com/kubernetes/kubernetes/pull/48670は、TCP_USER_TIMEOUTを減らすことで問題を軽減できることを示唆しています。 https://github.com/golang/net/pull/55を開いて、クライアント側の接続ヘルスチェックをhttp2ライブラリに追加しましたが、着陸するまでにさらに時間がかかります。

kubeletを再起動しても問題が解決しない場合は、おそらく別の根本的な原因です。

ネットワークを再起動するとv1.17.2でも同じ問題が発生しますが、この問題が発生するのは1つのノードのみです（クラスターには5つのノードがあります）。再現できません。 kubeletを再起動すると、この問題は解決しました。

この問題を回避するにはどうすればよいですか？ 最新バージョンをアップグレードしますか、それとも他の方法で修正しますか？

このbashスクリプトを5分ごとに実行して修正しました。

#!/bin/bash
output=$(journalctl -u kubelet -n 1 | grep "use of closed network connection")
if [[ $? != 0 ]]; then
  echo "Error not found in logs"
elif [[ $output ]]; then
  echo "Restart kubelet"
  systemctl restart kubelet
fi

kubeletを再起動せずにパッチを作成しましたが、問題は解決したようです。
締め切りパッチ

diff --git a/staging/src/k8s.io/client-go/transport/cache.go b/staging/src/k8s.io/client-go/transport/cache.go
index 7c40848c79f..bd61b39551a 100644
--- a/staging/src/k8s.io/client-go/transport/cache.go
+++ b/staging/src/k8s.io/client-go/transport/cache.go
@@ -38,6 +38,8 @@ const idleConnsPerHost = 25

 var tlsCache = &tlsTransportCache{transports: make(map[tlsCacheKey]*http.Transport)}

+type dialFunc func(network, addr string) (net.Conn, error)
+
 type tlsCacheKey struct {
        insecure   bool
        caData     string
@@ -92,7 +94,7 @@ func (c *tlsTransportCache) get(config *Config) (http.RoundTripper, error) {
                TLSHandshakeTimeout: 10 * time.Second,
                TLSClientConfig:     tlsConfig,
                MaxIdleConnsPerHost: idleConnsPerHost,
-               Dial:                dial,
+               Dial:                setReadDeadlineAfterDial(dial, 30*time.Second),
        })
        return c.transports[key], nil
 }
@@ -111,3 +113,18 @@ func tlsConfigKey(c *Config) (tlsCacheKey, error) {
                serverName: c.TLS.ServerName,
        }, nil
 }
+
+func setReadDeadlineAfterDial(dialer dialFunc, timeout time.Duration) dialFunc {
+       return func(network, addr string) (net.Conn, error) {
+               c, err := dialer(network, addr)
+               if err != nil {
+                       return nil, err
+               }
+
+               if err := c.SetReadDeadline(time.Now().Add(timeout)); err != nil {
+                       return nil, err
+               }
+
+               return c, nil
+       }
+}

@mYmNeoクライアントを再構築する方法を説明していただけますか？

@mYmNeoクライアントを再構築する方法を説明していただけますか？

@ ik9999このパッチを適用してから、kubeletを再構築し、バイナリを置き換えます

@mYmNeoこの問題を再現してテストするにはどうすればよいですか？

このbashスクリプトを5分ごとに実行して修正しました

@ ik9999ありがとう、それは動作します。

cc @liggitt

SetReadDeadlineを設定すると、すべての時計が30秒ごとに閉じますか？

SetReadDeadlineを設定すると、すべての時計が30秒ごとに閉じますか？

はい。 これは、この問題を解決するための醜い方法です（接続を強制的に閉じます）。

ちょうど別のケース：

これは、Kube1.16.8クラスターでも見られます。 VMを再起動すると、ノードを良好な状態に戻すことができます（kubeletの再起動も機能したと思います）。

セットアップkubeletは、ローカルホストを介してローカルのhaproxyインスタンスと通信します。これは、複数のバックエンドマスターインスタンスへのtcpロードバランサーとして機能します。 追加するかどうかを調査します

option clitcpka    # enables keep-alive only on client side
option srvtcpka    # enables keep-alive only on server side

ロードバランサーインスタンスは、明示的な再起動の必要性を軽減し、完全な回復につながる可能性があります。 繰り返されるログの例

Apr  8 00:04:25 kube-bnkjtdvd03sqjar31uhg-cgliksp01-cgliksp-00001442 kubelet.service[6175]: E0408 00:04:25.472682    6175 reflector.go:123] object-"ibm-observe"/"sysdig-agent": Failed to list *v1.ConfigMap: Get https://172.20.0.1:2040/api/v1/namespaces/ibm-observe/configmaps?fieldSelector=metadata.name%3Dsysdig-agent&limit=500&resourceVersion=0: write tcp 172.20.0.1:22501->172.20.0.1:2040: use of closed network connection
Apr  8 00:04:25 kube-bnkjtdvd03sqjar31uhg-cgliksp01-cgliksp-00001442 kubelet.service[6175]: E0408 00:04:25.472886    6175 reflector.go:123] object-"default"/"default-token-gvbk5": Failed to list *v1.Secret: Get https://172.20.0.1:2040/api/v1/namespaces/default/secrets?fieldSelector=metadata.name%3Ddefault-token-gvbk5&limit=500&resourceVersion=0: write tcp 172.20.0.1:22501->172.20.0.1:2040: use of closed network connection

暫定的に誰かを助ける場合に備えて、それが私たちの特定の問題を解決する場合は、更新を投稿します。

総再生時間の絶対上限を設定する構成パラメーターがあるかどうか知りたいですか？ --streaming-idle-connection-timeoutが見つかりましたが、時計に固有のものはありません。

「etcdfailed：reason withheld」が原因でAPIサーバーが異常になった後、kube1.17.4でこれが発生しています。

こんにちは、みんな。 kubernetesバイナリをgolang1.14で再コンパイルしました。 問題が消えたようです

@mYmNeo golang 1.14 + kubernetes v1.17？

@mYmNeo golang 1.14 + kubernetes v1.17？

@pytimerコードを変更せずに、再コンパイルするだけで

おい！ ここで同じ問題が発生しました。k8s1.17.4で問題が解決した場合、go 1.14で1.17.5を再コンパイルできると思いますか？

残念ながら、go1.14に更新するには、いくつかの主要コンポーネントを更新する必要があるため、Kube1.17に戻される可能性はほとんどありません。 https://github.com/kubernetes/kubernetes/pull/88638で問題と進行状況を追跡でき

知っておくといい、thx

@calliclesは、go 1.14で再コンパイルすると問題が解決することが確認されていますか？

1.16.8でも同じ問題が発生しています。Kubeletがノードステータスの投稿を停止した理由と「閉じたネットワーク接続の使用」により、ノードがNotReadyになることがよくあります（場合によっては数日ごと、場合によっては数週間ごと）。ログを埋める

goはh2アップグレードの処理に問題がある可能性があります。
golang.org/x/net/http2/transport.go

    upgradeFn := func(authority string, c *tls.Conn) http.RoundTripper {
        addr := authorityAddr("https", authority)
        if used, err := connPool.addConnIfNeeded(addr, t2, c); err != nil {
            go c.Close()
            return erringRoundTripper{err}    <--- "use of closed network connection"  rised
        }

こんにちは、みんな。 kubernetesバイナリをgolang1.14で再コンパイルしました。 問題が消えたようです

@mYmNeo go 1.14で再コンパイルした後、問題を再現したことがありますか

こんにちは、みんな。 kubernetesバイナリをgolang1.14で再コンパイルしました。 問題が消えたようです

@mYmNeo go 1.14で再コンパイルした後、問題を再現したことがありますか

AFAIN、問題はもう存在しません。

残念ながら、go1.14に更新するには、いくつかの主要コンポーネントを更新する必要があるため、Kube1.17に戻される可能性はほとんどありません。 ＃88638で問題と進捗状況を追跡できます

go1.14が1.18にバックポートされるかどうかはすでに知っていますか？

go1.14が1.18にバックポートされるかどうかはすでに知っていますか？

私はそうは思わないでしょう。 etcdとbboltへの変更は、go1.14をサポートするために必要であるようです。これは、リリースブランチで通常行われるよりも大きな変更です。

@liggittわかりましたthx。 その間、（少なくともクラスターについては）緩和戦略が必要なようです:)

この問題はNICの障害後にのみ発生しますか？ v1.16.8クラスターでも同じエラーメッセージが表示されますが、関連するNIC障害はありません。

SANへの接続時に基盤となるVMでSCSIエラーが発生したインスタンスが少なくとも1つありました。 SCSIの問題は自然に解決しましたが、 kubeletは回復しませんでした。

--goaway-chanceオプションは1.18（＃88567）で追加されました。 このオプションはこの問題を軽減しますか？

いいえ。これは、kubeletが実際にAPIサーバーに到達して応答を返すことができる場合にのみ効果があります。

NICボンドが失敗すると（すぐに回復します）、すべての接続が切断され、手動で再起動しない限り、接続の再確立は再試行されません。

使用しているボンドモードを教えてください。 アクティブバックアップボンドを使用して、クラスターでこれを再現できません。

Kubernetes 1.16にアップグレードした後、 use of closed network connectionエラーが発生し始め、kubeletがapiserverに再接続せず、ノードがNotReadyのままになりました。 NICを停止する（リンクを上下に設定する）ことで問題を再現することはできませんでしたが、この動作は、より負荷の高いクラスターでのみ発生することに気付きました。

さらに掘り下げてみると、golangのサーバー側のクライアント側のデフォルトは1000であることがわかりました。したがって、kubeletがapiserverからhttp2ストリームの制限に達したというエラーを受け取った場合、再接続を試みたことはありません。 --http2-max-streams-per-connection=1000を設定した後、テスト中に最初に見つかったほど、ノードがNotReadyでスタックするという問題は見られませんでした。 これは、kubeletが再接続しないという問題を解決しませんでしたが、発生していた問題を軽減するのに役立ちました。

Kubernetes 1.16にアップグレードした後、 use of closed network connectionエラーが発生し始め、kubeletがapiserverに再接続せず、ノードがNotReadyのままになりました。 NICを停止する（リンクを上下に設定する）ことで問題を再現することはできませんでしたが、この動作は、より負荷の高いクラスターでのみ発生することに気付きました。

さらに掘り下げてみると、golangのサーバー側のクライアント側のデフォルトは1000であることがわかりました。したがって、kubeletがapiserverからhttp2ストリームの制限に達したというエラーを受け取った場合、再接続を試みたことはありません。 --http2-max-streams-per-connection=1000を設定した後、テスト中に最初に見つかったほど、ノードがNotReadyでスタックするという問題は見られませんでした。 これは、kubeletが再接続しないという問題を解決しませんでしたが、発生していた問題を軽減するのに役立ちました。

こんにちは、デフォルトのサーバー側httpsストリームはkube-apiserverで1000です。これは、クライアントの値と同じです。
https://github.com/kubernetes/kubernetes/blob/ae1103726f9aea1f9bbad1b215edfa47e0747dce/staging/src/k8s.io/apiserver/pkg/server/options/recommended.go#L62

@warmchangこれはapiextensionsapiserversとサンプルapiserverに当てはまると思います。
https://github.com/kubernetes/kubernetes/blob/ae1103726f9aea1f9bbad1b215edfa47e0747dce/staging/src/k8s.io/apiserver/pkg/server/options/recommended.go#L62

--http2-max-streams-per-connectionを設定せずにcurlテストを使用したテストでは、apiserverログに次のように記録されます（v1.16を使用）。
I0603 10:18:08.038531 1 flags.go:33] FLAG: --http2-max-streams-per-connection="0"

そして、curlリクエストは応答でこれを示します：
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!

--http2-max-streams-per-connection=1000を使用すると、curlリクエストが表示されます
* Connection state changed (MAX_CONCURRENT_STREAMS == 1000)!

@jmcmeek @treytabner 、その通りです。 コードを読み間違えました。 ：+1：

ここではkubernetes1.17.6と同じものを使用します。 kubeletがデッドhttp2接続を使用しているようです。
kube-apiserverとkubeletの間でデフォルト値MAX_CONCURRENT_STREAMS一貫性がないことに気づきました。

サーバー側の値を1000に設定するだけです。後で報告します。

ランチャー/ RKE

クラスター定義に追加：

 kube-api:
      extra_args:
        http2-max-streams-per-connection: '1000'

マスターノードを確認します。

docker exec -it kubelet bash
apt update && apt-get install -y nghttp2
nghttp -nsv https://127.0.0.1:6443
#Look for SETTINGS_MAX_CONCURRENT_STREAMS

APIserverでMAX_CONCURRENT_STREAMSを1000に設定しても、この問題には影響しません。
これはgolang http2 Transport欠陥が原因だと思いました。 上記を参照

今夜もこの問題が発生しました。
'MAX_CONCURRENT_STREAMS'を設定しても役に立たなかったようです☹️

こんにちは、みんな。 私はついにこの問題を突き止めたと思います。 昨夜も同じ問題が発生しました。 しかし、修正されたkubeletで正常に回復しました。

これはKubernetesのバグではなく、 client-goが使用しているgolangの標準のnet/httpパッケージに関するものです。
golang.org/x/net/http2/transport.go欠陥があると思います

すでにこれはgolangの公式に報告されています。 いくつかの議論を待っています。
https://github.com/golang/go/issues/39750

今のところ、 https：//github.com/golang/net/commit/0ba52f642ac2f9371a88bfdde41f4b4e195a37c0によって導入されたhttp2: perform connection health checkがデフォルトで有効になるようにコードを変更しました。
これは、この問題の助けになることがわかります。 しかし、少し反応が遅い。

接続切れの問題の書き込みからは回復しましたが、予想よりも少し時間がかかりました。

performing http2 healthCheckは、 healthCheck funcがreadIdleTimerによって呼び出されていることを証明するために、そこに残しておくつもりだったログメッセージであることに注意してください。

 Jun 23 03:14:45 vm10.company.com kubelet [22255]：E0623 03：14：45.912484 22255 kubelet_node_status.go：402]ノードステータスの更新中にエラーが発生しました。再試行します：ノード「vm10.company.com」の取得中にエラーが発生しました：Get 「https://vm10.company.com:8443/api/v1/nodes/vm10.company.com?timeout=10s」：書き込みtcp 16.155.199.4：39668-> 16.155.199.4：8443：閉じたネットワーク接続の使用
 Jun 23 03:14:45 vm10.company.com kubelet [22255]：E0623 03：14：45.912604 22255 kubelet_node_status.go：402]ノードステータスの更新中にエラーが発生しました。再試行します：ノード「vm10.company.com」の取得中にエラーが発生しました：Get 「https://vm10.company.com:8443/api/v1/nodes/vm10.company.com?timeout=10s」：書き込みtcp 16.155.199.4：39668-> 16.155.199.4：8443：閉じたネットワーク接続の使用
 Jun 23 03:14:45 vm10.company.com kubelet [22255]：E0623 03：14：45.912741 22255 kubelet_node_status.go：402]ノードステータスの更新中にエラーが発生しました。再試行します：ノード「vm10.company.com」の取得中にエラーが発生しました：Get 「https://vm10.company.com:8443/api/v1/nodes/vm10.company.com?timeout=10s」：書き込みtcp 16.155.199.4：39668-> 16.155.199.4：8443：閉じたネットワーク接続の使用
 Jun 23 03:14:46 vm10.company.com kubelet [22255]：E0623 03：14：46.367046 22255 controller.go：135]ノードリースが存在することを確認できませんでした。400ms後に再試行します。エラー：Get "https：// vm10.company.com:8443/apis/coordination.k8s.io/v1/namespaces/kube-node-lease/leases/vm10.company.com?timeout=10s "：tcp 16.155.199.4:39668->16.155を書き込みます。 199.4：8443：閉じたネットワーク接続の使用
 Jun 23 03:14:48 vm10.company.com kubelet [22255]：E0623 03：14：47.737579 22255 controller.go：135]ノードリースが存在することを確認できませんでした。800msで再試行します。エラー：Get "https：// vm10.company.com:8443/apis/coordination.k8s.io/v1/namespaces/kube-node-lease/leases/vm10.company.com?timeout=10s "：tcp 16.155.199.4:39668->16.155を書き込みます。 199.4：8443：閉じたネットワーク接続の使用
 Jun 23 03:14:49 vm10.company.com kubelet [22255]：E0623 03：14：49.113920 22255 Reflector.go：153] k8s.io/kubernetes/pkg/kubelet/kubelet.go:458：リストに失敗しました* v1.Node：Get "https://vm10.company.com:8443/api/v1/nodes?fieldSelector=metadata.name%3Dvm10.company.com&limit=500&resourceVersion=0"：write tcp 16.155.199.4:39668-> 16.155.199.4：8443：閉じたネットワーク接続の使用
 Jun 23 03:14:49 vm10.company.com kubelet [22255]：E0623 03：14：48.744770 22255 Reflector.go：153]オブジェクト-"kube-system" / "flannel-token-zvfwn"：リストに失敗しました* v1.Secret：「https://vm10.company.com:8443/api/v1/namespaces/kube-system/secrets?fieldSelector=metadata.name%3Dflannel-token-zvfwn&limit=500&resourceVersion=0」を取得：tcp16.155を書き込みます.199.4：39668-> 16.155.199.4：8443：閉じたネットワーク接続の使用
 Jun 23 03:14:49 vm10.company.com kubelet [22255]：E0623 03：14：49.599631 22255 Reflector.go：153]オブジェクト-"kube-system" / "coredns"：* v1.ConfigMapの一覧表示に失敗しました： 「https://vm10.company.com:8443/api/v1/namespaces/kube-system/configmaps?fieldSelector=metadata.name%3Dcoredns&limit=500&resourceVersion=0」を取得します。tcp16.155.199.4：39668-> 16.155を書き込みます。 199.4：8443：閉じたネットワーク接続の使用
 Jun 23 03:14:49 vm10.company.com kubelet [22255]：E0623 03：14：49.599992 22255 controller.go：135]ノードリースが存在することを確認できませんでした。1.6秒で再試行します。エラー：Get "https：/ /vm10.company.com:8443/apis/coordination.k8s.io/v1/namespaces/kube-node-lease/leases/vm10.company.com?timeout=10s "：write tcp 16.155.199.4:39668-> 16.155 .199.4：8443：閉じたネットワーク接続の使用
 Jun 23 03:14:49 vm10.company.com kubelet [22255]：E0623 03：14：49.600182 22255 Reflector.go：153] k8s.io/kubernetes/pkg/kubelet/kubelet.go:449：リストに失敗しました* v1.Service：Get "https://vm10.company.com:8443/api/v1/services?limit=500&resourceVersion=0"：write tcp 16.155.199.4:39668->16.155.199.4:8443：クローズドネットワークの使用繋がり
 Jun 23 03:14:49 vm10.company.com kubelet [22255]：E0623 03：14：49.600323 22255 Reflector.go：153]オブジェクト-"kube-system" / "kube-flannel-cfg"：リストに失敗しました* v1.ConfigMap：「https://vm10.company.com:8443/api/v1/namespaces/kube-system/configmaps?fieldSelector=metadata.name%3Dkube-flannel-cfg&limit=500&resourceVersion=0」を取得：tcp16.155を書き込みます.199.4：39668-> 16.155.199.4：8443：閉じたネットワーク接続の使用
 Jun 23 03:14:49 vm10.company.com kubelet [22255]：E0623 03：14：49.600463 22255 Reflector.go：153]オブジェクト-"core" / "registrypullsecret"：リストに失敗しました* v1.Secret：Get " https://vm10.company.com:8443/api/v1/namespaces/core/secrets?fieldSelector=metadata.name%3Dregistrypullsecret&limit=500&resourceVersion=0 "：write tcp 16.155.199.4:39668->16.155.199.4:8443：閉じたネットワーク接続の使用
 Jun 23 03:14:49 vm10.company.com kubelet [22255]：E0623 03：14：49.369097 22255 Reflector.go：153]オブジェクト-"kube-system" / "registrypullsecret"：* v1.Secretの一覧表示に失敗しました： 「https://vm10.company.com:8443/api/v1/namespaces/kube-system/secrets?fieldSelector=metadata.name%3Dregistrypullsecret&limit=500&resourceVersion=0」を取得します。tcp16.155.199.4：39668-> 16.155を書き込みます。 199.4：8443：閉じたネットワーク接続の使用
 Jun 23 03:25:39 vm10.company.com kubelet [22255]：E0623 03：25：39.543880 22255desired_state_of_world_populator.go：320]ポッド「fluentd-h76lr_core（e95c9200-3a0c」のボリューム「deployment-log-dir」の処理中にエラーが発生しました-4fea-bd7f-99ac1cc6ae7a） "：PVCコア/ itom-vol-claimの処理中にエラーが発生しました：APIサーバーからPVCをフェッチできませんでした：" https://vm10.company.com:8443/api/v1/namespaces/core/ persistentvolumeclaims / itom-vol-claim "：tcp 16.155.199.4：41512-> 16.155.199.4：8443を読む：閉じたネットワーク接続の使用
 Jun 23 03:25:39 vm10.company.com kubelet [22255]：E0623 03：25：39.666303 22255 kubelet_node_status.go：402]ノードステータスの更新中にエラーが発生しました。再試行します：ステータス "{\" status \ "のパッチに失敗しました： {\ "$ setElementOrder / Conditions \"：[{\ "type \"：\ "MemoryPressure \"}、{\ "type \"：\ "DiskPressure \"}、{\ "type \"：\ "PIDPressure \ "}、{\" type \ "：\" Ready \ "}]、\" Conditions \ "：[{\" lastHeartbeatTime \ "：\" 2020-06-22T19：25：29Z \ "、\" type \ "：\" MemoryPressure \ "}、{\" lastHeartbeatTime \ "：\" 2020-06-22T19：25：29Z \ "、\" type \ "：\" DiskPressure \ "}、{\" lastHeartbeatTime \ "： \ "2020-06-22T19：25：29Z \"、\ "type \"：\ "PIDPressure \"}、{\ "lastHeartbeatTime \"：\ "2020-06-22T19：25：29Z \"、\ "ノード「vm10.company.com」のtype \ "：\" Ready \ "}]}}"：パッチ "https://vm10.company.com:8443/api/v1/nodes/vm10.company.com/ status？timeout = 10s "：read tcp 16.155.199.4：41512-> 16.155.199.4：8443：閉じたネットワーク接続の使用
 Jun 23 03:25:49 vm10.company.com kubelet [22255]：E0623 03：25：49.553078 22255 kubelet_node_status.go：402]ノードステータスの更新中にエラーが発生しました。再試行します：ノード「vm10.company.com」の取得中にエラーが発生しました：Get 「https://vm10.company.com:8443/api/v1/nodes/vm10.company.com?timeout=10s」：tcp16.155.199.4:41718->16.155.199.4:8443を読む：閉じたネットワーク接続の使用
 Jun 23 03:25:49 vm10.company.com kubelet [22255]：E0623 03：25：49.560723 22255desired_state_of_world_populator.go：320]ポッド「fluentd-h76lr_core（e95c9200-3a0c-4fea」のボリューム「log-location」の処理中にエラーが発生しました-bd7f-99ac1cc6ae7a） "：PVCコア/ itom-logging-volの処理中にエラーが発生しました：APIサーバーからPVCをフェッチできませんでした：" https://vm10.company.com:8443/api/v1/namespaces/core/persistentvolumeclaims/ itom-logging-vol "：tcp 16.155.199.4：41718-> 16.155.199.4：8443を読み取ります：閉じたネットワーク接続の使用
 Jun 23 03:27:29 vm10.company.com kubelet [22255]：I0623 03：27：29.961600 22255 log.go：181] http2healthCheckを実行しています
 Jun 23 03:31:32 vm10.company.com kubelet [22255]：I0623 03：31：31.829860 22255 log.go：181] http2healthCheckを実行しています
 Jun 23 03:31:44 vm10.company.com kubelet [22255]：I0623 03：31：44.570224 22255 log.go：181] http2healthCheckを実行しています
 Jun 23 03:32:13 vm10.company.com kubelet [22255]：I0623 03：32：12.961728 22255 log.go：181] http2healthCheckを実行しています
 Jun 23 03:33:16 vm10.company.com kubelet [22255]：I0623 03：33：15.441808 22255 log.go：181] http2healthCheckを実行しています
 Jun 23 03:33:28 vm10.company.com kubelet [22255]：I0623 03：33：28.233121 22255 log.go：181] http2healthCheckを実行しています

use of closed network connection報告されなくなり、kubeletはReady状態に戻ります

スタック内の問題について、いくつかの新しい潜在的な洞察を得ました。 ある程度の自信を持って、特定の状況での接続番号に関する高負荷のために、ネットワーク/インフラストラクチャレベルでまれに接続が低下すると想定します。したがって、この場合、ネットワークインターフェイスの反転ではありませんでした。 特に、クライアント側でhttp2に切り替えたため、Prometheusフェデレーションで問題が発生しました。 設定することにより、HTTP2ヘルスモニタを有効にするhttp2.Transport.ReadIdleTimeout用いて実装としてgolang/net#55完全に私たちのためにフェデレーションの問題を解決しました。

apimachinery/pkg/util/net/http.go http.Transportをインスタンス化し、これを内部的にhttp2にアップグレードするため、値は現在公開されていません。これは、golang / net＃74がマージされるまでオプションを公開しません。

kubelet restart cronジョブ以外に他の回避策はありますか？ cronジョブを1週間実施しましたが、問題の発生を止めることはできませんでした。

v1.17.3でも同じ問題が発生します。

私が見つけたのは、特定のgolang.org/x/netバージョンを使用するk8sバージョンに問題があり、このパッケージは修正されているようです。
https://go-review.googlesource.com/c/net/+/198040

この問題のあるバージョン（v1.16.5〜最新リリース）
golang.org/x/net v0.0.0-20191004110552-13f9640d40b9

バージョンの修正（マスターブランチ）
golang.org/x/net v0.0.0-20200707034311-ab3426394381

golang.org/x/netパッケージを更新すると、この問題は修正されますか？

これを修正するために、維持されているk8sバージョン（v1,16、1.17、v1,18 ..）のリリースが計画されていますか？

私が見つけたのは、特定のgolang.org/x/netバージョンを使用するk8sバージョンに問題があり、このパッケージは修正されているようです。
https://go-review.googlesource.com/c/net/+/198040

上記の変更は、HTTP2ヘルスモニターを有効にする可能性を提供するだけですが、開発者が有効にする必要があります（デフォルトはオフです）。 さらに、実際に設定する、開発者にヘルスモニターへのアクセスを許可するプルリクエストが

現在、問題の解決に役立つことを期待して、独自のKubernetesディストリビューションのヘルスモニターを有効にするリフレクションベースのホットフィックスを統合しています。

-
イェンスエラト\ インプリント

@JensErat回答ありがとうございます。
その場合、この問題は古いバージョンのk8s（1.13、1.15、..）でも発生する可能性がありますか？

1か月以上前にノードディストリビューションをRancherOS（カーネル4.14.138）からUbuntu 18.04（カーネル5.3.0）に変更しましたが、それ以降、問題は発生していません。
私のクラスターの1つがRancherOSに残っており、この問題はすでに3回再現されています。

100％shureではありませんが、おそらくカーネルバージョンが重要です。

言いにくい。 私たちは間違いなく1.16から1.18の問題を観察しますが、以前はまれな奇妙な「クベレットスタックの発生」がありました。 私たちは少なくとも1年前からそのような問題を掘り下げましたが、何も相関させることはできませんでした（数週間すべての単一のインシデント、および4桁の数のkubeletが実行されています）。 1.16をインストールしてからさらに悪化しましたが、現在、根本的な（非常にまれで追跡が難しい...）ネットワークの問題がより頻繁に発生すると想定しています。 カーネル5.3.0-46-genericでUbuntu19.10を実行していますが、影響を受けます（実際に新しいパッチレベルを取得した可能性があります）。 実行している正確なカーネルバージョン/パッチレベルのヒントを教えてください。

-
イェンスエラト\ インプリント

5.3.0-59-genericです。 しかし、クブレテは40個しかないので、それでも偶然かもしれません。

私が上で言ったように。 この問題は、負荷の高いクラスターでより頻繁に発生します。 h2トランスポートhealthCheckを有効にする前に、ほぼ毎晩同じ問題が発生しました。
golangの公式に報告され

問題はカーネルに非常に近いネットワークソケットが原因であるため、トピックには少し遠いです。 カーネルを更新することは役立つかもしれませんし、そうでないかもしれません。 （追記：カーネル3.10でcentos 7を使用していますが、healthCheckを有効にする前にほぼ毎日発生します）
私が見た限りでは、net / httpのソースコードを読んで約3日間を費やし、h2トランスポートhealthCheckを有効にして、このような問題からの回復を支援しました。そうすることで、この奇妙な状況から本当に逃れました。
@JensErat healthCheckを有効にしてこの問題を解決するのに役立つ具体的な証拠はありますか？

@JensErat healthCheckを有効にしてこの問題を解決するのに役立つ具体的な証拠はありますか？

KubernetesクラスターごとにPrometheusフェデレーションを実行しています。 Prometheus 2.19.0はhttp2を導入しました（ただし、変更ログでこれについて言及するのを忘れており、コミットメッセージの本文に隠されていたため、git bisect、デプロイし、実行ごとに数時間待つ必要がありました...） 1日にフェデレーションがスタックした12件のインシデント。 私は最初にhttp2サポートに再度パッチを適用し（そして問題はなくなりました）、次に読み取りタイムアウトをgolang / net / x / http2で直接設定しました。 それ以来、フェデレーションダウンのインシデントは1つもありませんでした。

現在、パッチを適用したKubernetesリリースを一部のクラスターで展開する準備をしているため、数日でデータを取得できるはずです。 適切なデータが得られ次第、結果を確実に共有します。

-
イェンスエラト\ インプリント

現在、パッチを適用したKubernetesリリースを一部のクラスターで展開する準備をしているため、数日でデータを取得できるはずです。 適切なデータが得られ次第、結果を確実に共有します。

ご意見をいただきありがとうございます。 それはとても楽しいメッセージです。
根本的な原因はあまり明確ではありませんが、少なくとも私たちは災害から回復する方法を見つけています。 ：NS

k8s v1.14.3でも同じ問題が発生しており、kubeletを再起動すると問題を解決できます。

これはばかげていることは知っていますが、一時的な回避策として機能する必要があります。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kubelet-face-slapper
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: kubelet-face-slapper
  template:
    metadata:
      labels:
        app: kubelet-face-slapper
    spec:
      # this toleration is to have the daemonset runnable on master nodes
      # remove it if your masters can't run pods    
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/controlplane
        operator: Equal
        value: "true"
      - effect: NoExecute
        key: node-role.kubernetes.io/etcd
        operator: Equal
        value: "true"
      containers:
      - command:
        - /bin/sh
        - -c
        - while true; do sleep 40; docker logs kubelet --since 1m 2>&1 | grep -q "use
          of closed network connection" && (docker restart kubelet ; echo "kubelet
          has been restarted due to connection error") || echo "kubelet connection
          is ok" ;done
        image: docker:stable
        name: kubelet-face-slapper
        volumeMounts:
        - mountPath: /var/run/docker.sock
          name: docker-sock
      volumes:
      - hostPath:
          path: /var/run/docker.sock
          type: File
        name: docker-sock

（これは牧場主固有ですが、特権コンテナーとjournalctl / systemctlを使用することで、他のディストリビューションに簡単に適合させることができます）

sleepと--sinceは、クラスターのpod-eviction-timeout （デフォルトでは5m）よりも短くする必要があります

ところで-牧場主労働者ノードのdocker pause nginx-proxyは、kubeletに同じエラーメッセージを生成させます。

VMWarevSphereでK8Sを実行しているユーザーの一時的な回避策-K8SVMのDRSを

新しいgolanghttp2ヘルスチェック機能を使用した問題の軽減に関して非常に良いニュースがあります。問題はもうありません。 ここまでで、Prometheus、Kubernetes全体、およびいくつかの内部コンポーネントに「修正」（ベンダーのx/netコードの値のハードコード設定）を実装し、次のことを確認しました。

• Prometheusフェデレーションの問題はもうありません
• kubeletは、単一の「閉じた接続の使用」イベントを報告することがありますが、数秒以内に回復します（最大30秒のhttp2ヘルスチェックウィンドウを設定します）
• kubectlウォッチで問題が発生することがありました-パッチを適用したkubectlを使用している場合も発生しません
• 拡張E2Eテストスイートを実行して、統合を定期的に検証し、散発的なテストタイムアウトとフレークネスを観察しました。 何だと思う？ もうなくなった。

さらに、問題を引き起こす方法について新しい洞察を得ることができました。 ライブマイグレーションに関する@ vi7の観察結果は、ある程度の自信を持って確認できます（ただし、追跡することはできます）。少なくとも、実行しているNSXバージョンでは、ロードバランサーの変更によってこのような問題が発生する可能性があります（VMwareとのチケットがあります。将来的にリセットパケットを送信していることを確認してください）。 また、接続テーブルのオーバーフローなど、他の多くの理由で接続が途中でドロップされる可能性があります。

これは、Kubernetesの一部のユーザーにとって非常に厄介でやや大規模な問題です（IaaSレイヤー/ネットワークのある種の「破損」に依存していると思います）。 値を適切に設定するためにインターフェースを公開することについてのgolangの議論がありますが、リフレクションを通じてそれらの値を設定するPRマージアップストリームを取得する可能性はあると思いますか（x / netをフォークするよりも今のように良いと思います） ？ コードの提供は問題ありません（修正を検証すると、実際に再現することはできませんが、修正が機能するかどうかを確認できるほど頻繁に観察します）。

cc @liggitt

長期的な問題（自己メモ）

@JensErat回答ありがとうございます。
その場合、この問題は古いバージョンのk8s（1.13、1.15、..）でも発生する可能性がありますか？

Kubernetesv1.16.13の問題を確認できます
Kubernetesv1.15.9では問題は発生しませんでした

etcdスナップショットバックアップからkubenetesクラスターv1.16.14を復元すると。 このエラーはkubeletログに表示されます。
@ ik9999に感謝します。 kubeletを再起動すると、エラーがなくなります

[root@dev-k8s-master ~]# journalctl -u kubelet -n 1 | grep "use of closed network connection"
Aug 22 11:31:10 dev-k8s-master kubelet[95075]: E0822 11:31:10.565237   95075 reflector.go:123] k8s.io/client-go/informers/factory.go:134: Failed to list *v1beta1.CSIDriver: Get https://apiserver.cluster.local:6443/apis/storage.k8s.io/v1beta1/csidrivers?limit=500&resourceVersion=0: write tcp 192.168.160.243:58374->192.168.160.243:6443: use of closed network connection
[root@dev-k8s-master ~]# systemctl restart kubelet
[root@dev-k8s-master ssh]# journalctl -u kubelet -n 1 | grep "use of closed network connection"

1.17.3で同じ問題が発生しましたが、kubeletを再起動すると解決します。 それに対する安定した回避策はありますか、またはこれがいつ修正されるのですか？

v1.18.6同じ

@ rxwang662001
これは、アップストリームのgolangの問題が原因です。 確かなことの1つは、これはgo1.15では修正されないということです。
一方、Kubernetesコミュニティは、1.14LOLへの移行にまだ苦労しています。

通常、goは6か月ごとにリリースします。 すべてがうまくいけば、来年にはアップストリームでこの問題が解決される可能性があり、kubernetesが修正を採用するまではもう1年かかるかもしれません🥇！
（冗談です。これを今すぐスタックで修正したい場合は、h2TransportをハックしてhealthCheckが機能していることが証明されました。

一方、Kubernetesコミュニティは、1.14LOLへの移行にまだ苦労しています。

実際、go1.15プレリリースで認定するためのsig-scalabilityとsig-releaseによる優れた作業により、Kubernetes1.19はgo1.15でリリースされたばかりです。 go1.16でhttp / 2オプションを公開する作業が進行中のようですが、利用可能になり次第、それを利用する予定です。

実際、go1.15プレリリースで認定するためのsig-scalabilityとsig-releaseによる優れた作業により、Kubernetes1.19はgo1.15でリリースされたばかりです。

Opps。 厄介な冗談でごめんなさい。 v1.19リリースにはあまり注意を払っていませんでした。
K8Sでgo1.14を完全にスキップしたようですか？ わお。 それは大きな飛躍です👍

@povsister

ソリューションを共有していただきありがとうございます。 それをどのように機能させたかについて、もう少し詳しく教えてください。

今のところ、 golang / net @ 0ba52f6によって導入されたhttp2: perform connection health checkがデフォルトで有効になるようにコードを変更しました。
これは、この問題の助けになることがわかります。 しかし、少し反応が遅い。

どのようなコード変更を実施しましたか？ そして、どこで、どのファイルで？

@KarthikRangaraju
h2Transportを初期化するときにhealthCheckを有効にするには、このPRを参照してください。
または、リフレクション/安全でないオフセットハックを実行して、実行時にエクスポートされていないフィールドにアクセスすることもできます。

そして、そのようなことをする前に、golang / x / netを更新することを忘れないでください。

時々直面しますが、この問題を再現することはできませんでした。

症状の根本原因を特定できないため、問題なく症状を修正しています。

私たちのソリューション：

• 次のスクリプトは1時間ごとに実行されます。 kube設定ファイルを介してkubectlを介してkube-apiサーバーと通信します
  kubeletが使用します（この方法では、特権の昇格はありません）。
• マスターノードthinks自身のノードがNotReadyであるかどうかを尋ねます。 はいの場合、ファイルに対してtouchコマンドを実行して、kubeletの再起動をトリガーします
  これは、ファイルシステムの変更に対するkubelet-watcher.serviceによるwatchedであり、それに応じてkubeletを再起動します。

#!/bin/bash

while true; do
  node_status=$(KUBECONFIG=/etc/kubernetes/kubelet.conf kubectl get nodes | grep $HOSTNAME | awk '{print $2}')
  date=$(date)
  echo "${date} Node status for ${HOSTNAME}: ${node_status}"
  if [ ${node_status} == "NotReady" ]; then
    echo "${date} Triggering kubelet restart ..."
    # Running touch command on /var/lib/kubelet/config.yaml. This will trigger a kubelet restart.
    # /usr/lib/systemd/system/kubelet-watcher.path & /usr/lib/systemd/system/kubelet-watcher.service
    # are responsible for watching changes in this file
    # and will restart the kubelet process managed by systemd accordingly.
    touch /var/lib/kubelet/config.yaml
  fi

  # Runs ever 1 hour
  sleep 3600
done

# cat  /usr/lib/systemd/system/kubelet-watcher.path
[Path]
PathModified=/var/lib/kubelet/config.yaml

[Install]
WantedBy=multi-user.target

# cat /usr/lib/systemd/system/kubelet-watcher.service
[Unit]
Description=kubelet restarter

[Service]
Type=oneshot
ExecStart=/usr/bin/systemctl restart kubelet.service

[Install]
WantedBy=multi-user.target[root@den-iac-opstest-kube-node02 karthik]#

Kubernetes 1.19.0でも問題は解決しませんが、メッセージは少し異なります。
Sep 11 18:19:39 k8s-node3 kubelet[17382]: E0911 18:19:38.745482 17382 event.go:273] Unable to write event: 'Patch "https://192.168.1.150:6443/api/v1/namespaces/fhem/events/fhem-7c99f5f947-z48zk.1633c689ec861314": read tcp 192.168.1.153:34758->192.168.1.150:6443: use of closed network connection' (may retry after sleeping)
エラーメッセージに「（スリープ後に再試行できます）」が含まれるようになりました。

アップグレードgolangを待たずに、kubernetesでこれを完全に軽減することは可能ですか？ たとえば、「閉じたネットワーク接続の使用」などに遭遇した場合、client-goにトランスポートをスワップアウトさせることはできますか？

あるいは、HTTP 1.1を使用している場合でもこの問題は発生しますか、それとも純粋にHTTP 2に関連していますか？ HTTP 1.1は、免疫になり、巨大なドローバックを持っていない、それだけで設定に本当の簡単な回避策になるだろう場合はGODEBUG=http2client=0 kubelet、KUBE-プロキシ、および様々なコントロールプレーンプロセス、あるいはセットでGODEBUG=http2server=0変更をユニバーサルにするためのapiserverプロセスの

これらは実際にこの問題を軽減し、HTTP2を介して多重化しない場合の接続数の増加によるいくつかのパフォーマンスの問題以外の他の大きな落とし穴を引き起こさないと思いますか？

トランスポートが「閉じたネットワーク接続の使用」などに遭遇した場合、client-goにトランスポートをスワップアウトさせることはできますか？

あまり外科的ではありません...新しいクライアントを繰り返し構築する発信者に直面して一時的なポートの枯渇を回避するために、トランスポートは現在共有されています

この問題は、HTTP 1.1を使用している場合でも発生しますか、それとも純粋にHTTP 2に関連していますか？

私の知る限り、アイドル状態の接続はキープアライブプールに戻るため、HTTP 1.1でも同じ問題が発生する可能性があります（pingヘルスチェックメカニズムが利用できないため、HTTP 1.1を検出/軽減するオプションが少なくなります）。

クライアントを使用するプロジェクトに適切な回避策はありますか？ クライアントがいつ死んでいるのか、そしてそれを修正するために必要な最低限のことをどのように特定できますか（プロセスを再起動することが唯一の選択肢であるように聞こえます）？

クライアントがいつ死んでいるかをどのように特定できますか

同じURLに対してwrite tcp xxx use of closed network connectionエラーが繰り返し発生した場合。 これは、クライアントが停止していることを示しています。 Transport内の接続プールは、要求されたhost：portのデッドtcp接続をキャッシュしました。

クライアントを使用するプロジェクトに適切な回避策はありますか？

私の知る限り、 http.Clientを再構築すると、アプリケーション全体を再起動しなくてもこの問題を解決できます。

それを修正するために必要な最小限のことは何ですか

プロジェクトへのソースコードレベルのアクセスが必要です。 たぶん、上記のメカニズムを使用して、死んだクライアントを検出し、必要に応じて新しいクライアントを再構築できます。 古いクライアントを使用している人がいない場合は、ガベージコレクションが行われます。

プロジェクトにソースコードでアクセスできますが、kubernetesクライアントを使用しています。 ウォッチを実行すると、TCP接続がこのように切断されているかどうかが検出されないようです（ウォッチはHTTPトランザクションを処理しているため、処理するコードにエラーが発生することはありません）。

うん。 そうです、 http.Clientはkubernetesクライアントによって公開されていません。
現在、トップレベルのアプリケーションがこのような回避策をほとんどコストをかけずに実行することは絶望的です。
kubernetesクライアントがhttp.DefaultClient使用しない場合は、kubernetesクライアント全体を再構築することで修正できます。

ウォッチリクエストについては、悪化しています。 kubernetesクライアントはリクエストを再試行し続けているようで、上位のアプリケーションにエラーは表示されません。 私は今そのような状況について良い考えがありません。

ここで提案さuse of closed network connectionエラーが常に表示されます。

プルリクエストを作成してください。この主題を調査します。

単一のベアメタルクラスターでは、これが24時間ごとに約2〜4回発生するのがわかります。 1.17.12

これは、単一ノードクラスターであっても、api-serverポッドが再起動したときに発生します。 apiserverへの接続が失われたため、エラー番号の最小化方法により、apiserverが再起動する問題が解決されています。

マスターノードの前でhaproxyを使用していますが、LB構成でこれを防ぐ方法はあると思いますか？

@ shubb30あなたの解決策を私と共有してもよろしいですか？

問題が発生したときに、apiserverが再起動しないことを確認できます。 デーモンセットとシェルトリックを使用してログエントリを監視し、kubeletを再起動しています。これはかなりうまく機能していますが、一時的な回避策にすぎないと思います。

これは、回避策としてうまく機能しているものの修正バージョンです。

やあ、みんな！

このバックポートが役立つ可能性があると思いますか？
https://github.com/golang/go/issues/40423

朗報：golang / netマスターはhttp2トランスポートの構成をサポートしているため、タイムアウトを設定できるようになりました。 https://github.com/golang/net/commit/08b38378de702b893ee869b94b32f833e2933bd2

終わり。
PRはレビューのために開かれました。

もう1つの良いニュース：Kubernetesは標準のnet / httpパッケージにバンドルされているhttp2を使用しないため、次のGoリリースを待つ必要はありません。 この問題を修正するには、 https：//github.com/golang/net/commit/08b38378de702b893ee869b94b32f833e2933bd2を直接使用でき

ここで修正を提案しました。 https://github.com/kubernetes/kubernetes/pull/95898
依存関係を必要なバージョンに更新し、デフォルトでhttp2トランスポートヘルスチェックを有効にします。
これは、client-goを使用してapiserver（例：kubelet）と通信するアプリケーションが、「書き込みtcp xxxでのアプリのハング：閉じた接続の使用」の問題を取り除くのに役立つはずです。

コメントはお気軽にどうぞ。

言及された＃95898は、議論する必要がない理由で閉鎖されたようです。

この問題に関して他に更新はありますか？

https://github.com/kubernetes/kubernetes/pull/95981 （上記のリンク）は、http / 2修正をプルするために進行中です

この問題は、1.17.Xバージョンのkubernetesに固有のものですか？

@krmayankk正確にいつ開始されたかは完全には

@krmayankk v1.18.9でもこの問題が発生しましたが、バグのあるバージョンのRancherが原因で、ネットワークの使用率が非常に高くなりました。 別のバージョンにロールバックした後、問題は観察されませんでした。

この問題が発生しましたが、上記のコメントの回避策を使用して、小さな趣味のクラスターで「修正」しました。

回避策をsystemdユニットおよびタイマーとしてノードにデプロイするための小さなansible-playbookを作成しました。これにより、同様の設定で他のユーザーをしばらく節約できる可能性があります。

https://github.com/kubernetes/kubernetes/pull/95981およびhttps://github.com/kubernetes/kubernetes/issues/87615から1.18リリースブランチへのチェリーピック/バックポートの計画はありますか？

＃95981から1.17リリースブランチをチェリーピックする計画はありますか？

このコメントでは、古いリリースへのバックポートについて説明しています： https ：

答えは「大変で、物事を壊す可能性があるので、おそらくそうではない」だと思います。 質問されたときにv1.17を実行している人々に期待するのと同じ答えがあります。それでは、修正を取得するためにv1.20にアップグレードしてみませんか？ ：笑い：

これを少なくとも1.19にバックポートすると、修正が比較的早く利用可能になるため、すばらしいでしょう。 Dockerの廃止により、1.20を延期する人もいると思います。

これを少なくとも1.19にバックポートすると、修正が比較的早く利用可能になるため、すばらしいでしょう。

それはすでに行われています。

Dockerの廃止により、1.20を延期する人もいると思います。

非推奨の警告以外、dockerに関して1.20では何も変更されていません。 非推奨期間の終了時に、dockershimサポートは削除されます。

ラズビアン10の1.20でこれらのエラーが発生します。これに対する修正を取得することからどこから始めればよいでしょうか。 クラウド管理クラスターを実行するコストは、独自のクラスターで実行するよりもはるかに費用効果が高いようです

私自身の明確さのために、これは＃95981によって解決されるべきであるように見えます、そしてそれはそれを1.20に作り、1.19にバックポートされましたか？

95981は1.20にマージされ、＃96770で1.19にチェリーピックされました。

/選ぶ

@caesarxuchao ：この問題を解決します。

v1.16、v1.17、またはv1.18のバックポート/チェリーピックはありますか？

@chilicatはhttps://github.com/kubernetes/kubernetes/pull/95981#issuecomment-730561539を参照して