/sig 노드
/sig API 기계

코드를 살펴보면 여기 에서 오류가 발생

코드에 대한 설명은 아마도 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.3 LTS 새로 설치합니다. rancher로 구축된 클러스터 2.3.4. 최근에 주기적으로 이런 일이 발생하는 것을 보았고 kubelet을 다시 시작하면 문제가 해결되는 경향이 있습니다. 어젯밤 내 작업자 노드 3개 모두에서 이와 동일한 동작이 나타났습니다. 내 클러스터를 가져오도록 2를 수정했습니다. 세 번째는 메신저를 파헤치는 동안 여전히 이 상태에 있습니다.

우리는 랜처(1.17.2)로 새로 구축된 클러스터인 CentOS 7에서 동일한 문제를 보고 있습니다. 우리는 직물을 사용하고 있습니다. 3개의 작업자 노드 모두에서 이 문제가 표시됩니다. kubelet을 다시 시작해도 작동하지 않습니다. 전체 노드를 다시 시작해야 합니다.

/sig 노드
/sig API 기계

코드를 살펴보면 여기 에서 오류가 발생

코드에 대한 설명은 아마도 EOF(IsProbableEOF)를 가정하지만 이 경우에는 그렇지 않은 것 같습니다.

우리는 또한 같은 문제를 보고 있습니다. 로그에서 우리는 문제가 발생한 후 모든 후속 요청이 여전히 동일한 연결에서 전송되었음을 발견했습니다. 클라이언트가 apiserver에 요청을 다시 보내지만 언더레이 http2 라이브러리는 여전히 이전 연결을 유지하므로 모든 후속 요청은 여전히 ​​이 연결에서 전송되고 동일한 오류 use of closed connection 수신한 것 같습니다.

그래서 질문은 왜 http2가 이미 닫힌 연결을 유지하는 것입니까? 유지 관리한 연결이 실제로 살아 있지만 일부 중간 연결이 예기치 않게 닫힐 수 있습니까?

k8s 1.17.3이 있는 Raspberry Pi 클러스터와 동일한 문제가 자주 발생합니다. 몇 가지 오래된 문제를 기반으로 kube API 서버 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이 있습니까?

여기도 마찬가지입니다.(우분투 18.04, 쿠버네티스 1.17.3)

우리는 또한 두 개의 클러스터에서 이것을 관찰했습니다. 근본 원인에 대해 완전히 확신할 수는 없지만 적어도 우리는 감시 수가 매우 많은 클러스터에서 이러한 일이 발생했음을 확인할 수 있었습니다. 하지만 kubelet당 많은 수의 시계를 강제로 재생산할 수 없었습니다(포드당 300개의 비밀로 포드를 시작했으며 Prometheus 메트릭에서 포드당 300개의 시계가 생성됨). 또한 매우 낮은 http2-max-streams-per-connection 값을 설정해도 문제가 발생하지 않았지만 최소한 예상치 못한 스케줄러 및 컨트롤러 관리자 동작을 관찰할 수 있었습니다(끝없는 다시 보기 루프 또는 이와 유사한 후에 과부하가 걸렸을 수 있음). 그렇지만).

해결 방법으로 모든 노드는 로컬 cronjob을 통해 매일 밤 kublet을 다시 시작합니다. 10일이 지난 지금, 나는 그것이 나에게 효과가 있다고 말할 수 있습니다. 제 노드에서 더 이상 "폐쇄 네트워크 연결 사용"이 없습니다.

@sbiermann
게시해 주셔서 감사합니다. cronjob에 어떤 시간 간격을 사용합니까?

24 시간

나는 또한 이 문제를 확인할 수 있습니다. 우리는 아직 1.17.3이 아니며 현재 Ubuntu 19.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

RancherOS 1.5.5 노드에서 Rancher 2.3.5를 통해 배포된 Kubernetes 1.17.4에서도 이를 확인할 수 있습니다. kubelet을 다시 시작하는 것이 효과가 있는 것 같으며 전체 노드를 다시 시작할 필요가 없습니다.

내 근본적인 원인은 내 Kubernetes 노드에 대해 swappiness를 0으로 설정하는 것을 잊었기 때문에 RAM이 거의 소모되고 kswapd0이 최대 100% CPU 사용량을 얻는 것 같습니다. swappiness를 0으로 설정하고 일부 RAM을 컴퓨터에 추가한 후에도 문제가 아직 발생하지 않았습니다.

근본적인 문제가 "죽은 연결을 사용하는 http2"인 경우 kubelet을 다시 시작하면 문제가 해결됩니다. https://github.com/kubernetes/kubernetes/pull/48670 제안 TCP_USER_TIMEOUT을 줄이면 문제를 완화할 수 있습니다. http2 라이브러리에 클라이언트 측 연결 상태 확인을 추가하기 위해 https://github.com/golang/net/pull/55 를 열었지만 착륙하는 데 더 많은 시간이 걸릴 것입니다.

kubelet을 다시 시작해도 문제가 해결되지 않으면 다른 근본 원인일 수 있습니다.

네트워크를 다시 시작할 때 v1.17.2와 동일한 문제가 있지만 노드 중 하나에만 이 문제가 있습니다(내 클러스터에는 5개의 노드가 있음). 재현할 수 없습니다. kubelet을 다시 시작하면 이 문제가 해결되었습니다.

이 문제를 어떻게 피할 수 있습니까? 최신 버전을 업그레이드하거나 수정하는 다른 방법이 있습니까?

5분마다 이 bash 스크립트를 실행하여 문제를 해결했습니다.

#!/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 client-go를 재구축하는 방법을 설명해 주시겠습니까?

@mYmNeo client-go를 재구축하는 방법을 설명해 주시겠습니까?

@ik9999 이 패치를 적용한 다음 kubelet을 다시 빌드하고 바이너리를 교체하십시오.

@mYmNeo 이 문제를 재현하고 테스트

5분마다 이 bash 스크립트를 실행하여 문제를 해결했습니다.

@ik9999 감사합니다. 작동합니다.

cc @liggitt

SetReadDeadline을 설정하면 모든 시계가 30초마다 닫힙니다.

SetReadDeadline을 설정하면 모든 시계가 30초마다 닫힙니다.

예. 이 문제를 해결하는 추악한 방법입니다(연결 강제 종료).

또 다른 경우:

우리는 이것을 Kube 1.16.8 클러스터에서도 볼 수 있습니다. VM을 재부팅하면 노드를 양호한 상태로 되돌릴 수 있습니다(kubelet 재시작도 효과가 있었을 것으로 생각됩니다).

설정 kubelet은 여러 백엔드 마스터 인스턴스에 대한 tcp 로드 밸런서 역할을 하는 localhost를 통해 로컬 haproxy 인스턴스와 통신합니다. 추가 여부를 조사할 예정입니다.

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 을 찾았지만 시계에 특정한 것은 없습니다.

kube 1.17.4에서 "etcd failed: 이유 보류"로 인해 API 서버가 비정상 상태인 것을 보고 있습니다.

안녕, 얘들아. golang 1.14로 kubernetes 바이너리를 다시 컴파일했습니다. 문제가 사라진 것 같습니다

@mYmNeo golang 1.14 + kubernetes v1.17?

@mYmNeo golang 1.14 + kubernetes v1.17 ?

@pytimer 우리는 다시 컴파일하는 코드를 변경하지 않고 1.16.6을 사용하고 있습니다. 근본 원인은 golang일 수 있다고 생각합니다.

이봐! 여기에 동일한 문제가 있습니다. k8s 1.17.4 문제가 해결되면 go 1.14로 1.17.5를 다시 컴파일할 수 있다고 생각합니까?

불행히도 go1.14로 업데이트하려면 몇 가지 주요 구성 요소에 대한 업데이트가 필요하므로 Kube 1.17로 되돌릴 가능성은 낮습니다. https://github.com/kubernetes/kubernetes/pull/88638 에서 문제와 진행 상황을 추적할 수 있습니다.

좋은 정보, thx

@callicles go 1.14로 다시 컴파일하면 문제가 해결되는 것으로 확인되었습니까?

1.16.8에서 동일한 문제가 발생합니다. Kubelet이 노드 상태 게시를 중단하고 "닫힌 네트워크 연결 사용"으로 인해 노드가 NotReady가 되어 매우 자주(때로는 며칠에 한 번, 때로는 몇 주에 한 번) 노드가 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
        }

안녕, 얘들아. golang 1.14로 kubernetes 바이너리를 다시 컴파일했습니다. 문제가 사라진 것 같습니다

@mYmNeo go 1.14로 다시 컴파일한 후 문제를 재현한 적이

안녕, 얘들아. golang 1.14로 kubernetes 바이너리를 다시 컴파일했습니다. 문제가 사라진 것 같습니다

@mYmNeo go 1.14로 다시 컴파일한 후 문제를 재현한 적이

AFAIN, 문제는 더 이상 존재하지 않습니다.

불행히도 go1.14로 업데이트하려면 몇 가지 주요 구성 요소에 대한 업데이트가 필요하므로 Kube 1.17로 되돌릴 가능성은 낮습니다. #88638에서 문제 및 진행 상황을 추적할 수 있습니다.

go1.14가 1.18로 백포트될 것인지 이미 알고 계십니까?

go1.14가 1.18로 백포트될 것인지 이미 알고 계십니까?

나는 그렇게 기대하지 않을 것이다. etcd 및 bbolt에 대한 변경 사항은 go1.14를 지원하는 데 필요한 것 같습니다. 이는 일반적으로 릴리스 분기에서 수행되는 것보다 더 큰 변경 사항입니다.

@liggitt 알겠습니다. (적어도 클러스터의 경우) 그 동안 완화 전략이 필요한 것 같습니다. :)

이 문제는 NIC 오류 후에만 발생합니까? v1.16.8 클러스터에서 동일한 오류 메시지가 표시되지만 연결된 NIC 오류는 없습니다.

SAN에 연결할 때 기본 VM에 SCSI 오류가 발생한 인스턴스가 하나 이상 있었습니다. SCSI 문제는 자체적으로 해결되었지만 kubelet 는 복구되지 않았습니다.

--goaway-chance 옵션이 1.18(#88567)에 추가되었습니다. 이 옵션을 사용하면 이 문제가 완화됩니까?

아니요. kubelet이 실제로 API 서버에 도달하고 응답을 받을 수 있는 경우에만 효과가 있습니다.

NIC 본드가 실패하면(오래지 않아 복구됨) 모든 연결이 끊어지고 수동으로 다시 시작하지 않는 한 연결을 다시 설정하려고 시도하지 않습니다.

어떤 본드 모드를 사용하고 있는지 알려주실 수 있습니까? 활성 백업 본드가 있는 클러스터에서 이를 재현할 수 없습니다.

Kubernetes 1.16으로 업그레이드한 후 use of closed network connection 오류와 kubelet이 apiserver에 다시 연결되지 않아 노드가 NotReady 상태로 유지되기 시작했습니다. NIC를 다운/다운 설정하여 문제를 재현할 수 없었지만 이 동작은 더 많이 로드된 클러스터에서만 발생했습니다.

우리는 더 파고 들었고 golang 의 서버측 클라이언트측 기본값은 1000 이라는 것을 발견했습니다. 다시 연결을 시도하지 않았습니다. --http2-max-streams-per-connection=1000 설정한 후 노드가 NotReady에서 멈추는 문제가 테스트 중에 처음 발견된 것만큼 보이지 않았습니다. 이것은 kubelet이 다시 연결되지 않는 문제를 해결하지 못했지만 우리가 보고 있던 문제를 완화하는 데 도움이 되었습니다.

Kubernetes 1.16으로 업그레이드한 후 use of closed network connection 오류와 kubelet이 apiserver에 다시 연결되지 않아 노드가 NotReady 상태로 유지되기 시작했습니다. NIC를 다운/다운 설정하여 문제를 재현할 수 없었지만 이 동작은 더 많이 로드된 클러스터에서만 발생했습니다.

우리는 더 파고 들었고 golang 의 서버측 클라이언트측 기본값은 1000 이라는 것을 발견했습니다. 다시 연결을 시도하지 않았습니다. --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 나는 이것이 apiextensions apiservers 및 샘플 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"

그리고 컬 요청은 응답에서 이것을 보여줍니다:
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!

--http2-max-streams-per-connection=1000 하면 curl 요청이 표시됩니다.
* Connection state changed (MAX_CONCURRENT_STREAMS == 1000)!

@jmcmeek @treytabner , 맞습니다. 코드를 잘못 읽었습니다. :+1:

kubernetes 1.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으로 성공적으로 복구되었습니다.

쿠버네티스 버그가 아니라 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" 노드 가져오기 오류 "https://vm10.company.com:8443/api/v1/nodes/vm10.company.com?timeout=10s": write 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" 노드 가져오기 오류: "https://vm10.company.com:8443/api/v1/nodes/vm10.company.com?timeout=10s": write 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" 노드 가져오기 오류 "https://vm10.company.com:8443/api/v1/nodes/vm10.company.com?timeout=10s": write 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 후에 다시 시도합니다. 오류: "https:// 가져오기" vm10.company.com:8443/apis/coordination.k8s.io/v1/namespaces/kube-node-lease/leases/vm10.company.com?timeout=10s": TCP 16.155.199.45:39668-.16.15 쓰기 199.4:8443: 폐쇄 네트워크 연결 사용
 Jun 23 03:14:48 vm10.company.com kubelet[22255]: E0623 03:14:47.737579 22255 controller.go:135] 노드 임대가 있는지 확인하지 못했습니다. 800ms 후에 다시 시도합니다. 오류: "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.15 쓰기 199.4:8443: 폐쇄 네트워크 연결 사용
 6월 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:list에 실패 *45 v1.Node: "https://vm10.company.com:8443/api/v1/nodes?fieldSelector=metadata.name%3Dvm10.company.com&limit=500&resourceVersion=0" 가져오기: 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] object-"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" 가져오기: tcp 16.15 쓰기 .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] object-"kube-system"/"coredns": *v1.ConfigMap 나열 실패: "https://vm10.company.com:8443/api/v1/namespaces/kube-system/configmaps?fieldSelector=metadata.name%3Dcoredns&limit=500&resourceVersion=0" 가져오기: tcp 16.155.199.4:39668-.16 쓰기 199.4:8443: 폐쇄 네트워크 연결 사용
 Jun 23 03:14:49 vm10.company.com kubelet[22255]: E0623 03:14:49.599992 22255 controller.go:135] 노드 임대가 있는지 확인하지 못했습니다. 1.6초 후에 다시 시도합니다. 오류: "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.1 쓰기 .199.4:8443: 폐쇄 네트워크 연결 사용
 6월 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:list에 실패 *44 v1.Service: "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] object-"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" 가져오기: 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.600463 22255 reflector.go:153] object-"core"/"registrypullsecret": *v1.Sec을 나열하지 못했습니다. https://vm10.company.com:8443/api/v1/namespaces/core/secrets?fieldSelector=metadata.name%3Dregistrypullsecret&limit=500&resourceVersion=0": TCP 16.155.199.4:396955->.16 쓰기 폐쇄 네트워크 연결 사용
 6월 23일 03:14:49 vm10.company.com kubelet[22255]: E0623 03:14:49.369097 22255 reflector.go:153] object-"kube-system"/"registrypullsecret": 비밀 나열 실패 *v1 "https://vm10.company.com:8443/api/v1/namespaces/kube-system/secrets?fieldSelector=metadata.name%3Dregistrypullsecret&limit=500&resourceVersion=0" 가져오기: tcp 16.155.199.5->.3966 쓰기 199.4:8443: 폐쇄 네트워크 연결 사용
 Jun 23 03:25:39 vm10.company.com kubelet[22255]: E0623 03:25:39.543880 22255 desired_state_of_world_populator.go:320] 오류 처리 볼륨 "deployment-log-dir" -4fea-bd7f-99ac1cc6ae7a)": PVC core/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] 노드 상태를 업데이트하는 동안 오류가 발생했습니다. 다시 시도합니다. "{\" 상태를 패치하지 못했습니다. {\"$setElementOrder/conditions\":[{\"type\":\"MemoryPressure\"},{\"type\":\"DiskPressure\"},{\"type\":\"PIDPressure\ "},{\"유형\":\"준비\"}],\"조건\":[{\"lastHeartbeatTime\":\"2020-06-22T19:25:29Z\",\"유형\ ":\"MemoryPressure\"},{\"lastHeartbeatTime\":\"2020-06-22T19:25:29Z\",\"type\":\"DiskPressure\"},{\"lastHeartbeatTime\": \"2020-06-22T19:25:29Z\",\"유형\":\"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": 읽기 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" 노드 가져오기 오류 "https://vm10.company.com:8443/api/v1/nodes/vm10.company.com?timeout=10s": 읽기 tcp 16.155.199.4:41718->16.155.199.4:8443: 폐쇄 네트워크 연결 사용
 Jun 23 03:25:49 vm10.company.com kubelet[22255]: E0623 03:25:49.560723 22255 desired_state_of_world_populator.go:320] pod "fluentd_92040-feca0320"에 대한 "log-location" 처리 오류 -bd7f-99ac1cc6ae7a)": PVC core/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] http2 healthCheck 수행 중
 Jun 23 03:31:32 vm10.company.com kubelet[22255]: I0623 03:31:31.829860 22255 log.go:181] http2 healthCheck 수행 중
 Jun 23 03:31:44 vm10.company.com kubelet[22255]: I0623 03:31:44.570224 22255 log.go:181] http2 healthCheck 수행 중
 Jun 23 03:32:13 vm10.company.com kubelet[22255]: I0623 03:32:12.961728 22255 log.go:181] http2 healthCheck 수행 중
 Jun 23 03:33:16 vm10.company.com kubelet[22255]: I0623 03:33:15.441808 22255 log.go:181] http2 healthCheck 수행 중
 Jun 23 03:33:28 vm10.company.com kubelet[22255]: I0623 03:33:28.233121 22255 log.go:181] http2 healthCheck 수행 중

더 이상 use of closed network connection 보고되지 않고 kubelet이 준비 상태로 돌아갑니다.

스택의 문제에 대한 몇 가지 새로운 잠재적 통찰력을 얻었습니다. 특정 상황에서 연결 번호에 대한 높은 부하로 인해 네트워킹/인프라 수준에서 드물게 연결이 중단된다고 가정하므로 이 경우 네트워크 인터페이스가 뒤집힌 것이 아닙니다. 특히 Prometheus 페더레이션이 클라이언트 측에서 http2로 전환되었기 때문에 문제가 심각했습니다 . 설정하여 http2 건강 모니터를 사용 http2.Transport.ReadIdleTimeout 로 구현 된 golang/net#55 완전히 우리를 위해 페더레이션 문제를 해결합니다.

값은 현재 apimachinery/pkg/util/net/http.go http.Transport apimachinery/pkg/util/net/http.go 인스턴스화하고 이를 내부적으로 http2로 업그레이드하므로 값이 노출되지 않습니다. 이는 golang/net#74가 병합될 때까지 옵션을 노출하지 않습니다.

kubelet restart cron 작업 외에 다른 해결 방법이 있습니까? 우리는 일주일 동안 cron 작업을 수행했으며 문제가 발생하는 것을 멈추지 않았습니다.

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, ..)에서도 이 문제가 발생할 수 있습니까?

한 달 전에 RancherOS(커널 4.14.138)에서 Ubuntu 18.04(커널 5.3.0)로 노드 배포판을 변경했는데 그 이후로 문제가 나타나지 않았습니다.
RancherOS에 남겨진 클러스터 중 하나는 이 문제가 이미 3번 재현되었습니다.

100% shure는 아니지만 아마도 커널 버전이 중요할 것입니다.

말하기 어렵다. 우리는 1.16에서 1.18까지의 문제를 확실히 관찰(d)했지만 이전에는 드문 이상한 "kubelet 중단 발생"이 모자였습니다. 우리는 이미 적어도 1년 이후로 이러한 문제를 파헤쳤지만 아무 상관 관계도 없었습니다(몇 주 동안 단일 사건이 발생했고 4자리 수의 kubelet이 실행 중임). 우리가 1.16을 설치한 이후로 훨씬 더 나빠졌지만, 현재 우리는 근본적인(또한 매우 드물고 추적하기 어려운...) 네트워킹 문제가 더 자주 발생한다고 가정합니다. 우리는 Kernel 5.3.0-46-generic으로 Ubuntu 19.10을 실행하고 있지만 영향을 받습니다(실제로 더 새로운 패치 수준을 얻을 수 있을 가능성이 높음). 실행 중인 정확한 커널 버전/패치 수준에 대한 힌트를 줄 수 있습니까?

--
옌스 에라트 \ 날인

5.3.0-59-generic 입니다. 그러나 우리에게는 ~ 40개의 kubletes만 있으므로 여전히 우연의 일치일 수 있습니다.

위에서 말했듯이. 이 문제는 로드가 많은 클러스터에서 더 자주 발생합니다. 우리는 h2 Transport healthCheck를 활성화하기 전에 거의 매일 밤 동일한 문제를 관찰했습니다.
golang 관계자 에게 보고된 문제 에 따르면 . 닫힌 소켓을 읽을 때 오류를 반환해야 하지만 절대 그렇지 않은 소켓 읽기 루프에서 문제가 발생합니다. 또한 연결 문제를 능동적으로 감지하기 위해 소켓을 작성할 때 오류 핸들 로직을 추가하는 것이 좋습니다. 그러나 며칠이 지난 후 그들은 그런 드문 문제에 신경 쓰지 않는 것 같습니다.

문제는 커널에 매우 근접한 네트워크 소켓으로 인해 발생하기 때문에 주제와는 조금 거리가 있습니다. 커널 업데이트가 도움이 될 수도 있고 그렇지 않을 수도 있습니다. (추신: 우리는 커널 3.10과 함께 centos 7을 사용하고 있습니다. 이는 healthCheck를 활성화하기 전에 거의 매일 발생합니다)
내가 본 바로는 net/http의 소스 코드를 읽는 데 약 3일을 보냈고 h2 transport healthCheck를 활성화하면 이러한 문제를 복구하는 데 도움이 되었고 그렇게 함으로써 이 이상한 상황에서 정말 벗어났습니다.
@JensErat 이 문제를 해결하는 데 도움이 되는 healthCheck 활성화에 대한 구체적인 증거가 있습니까?

@JensErat 이 문제를 해결하는 데 도움이 되는 healthCheck 활성화에 대한 구체적인 증거가 있습니까?

각 Kubernetes 클러스터에 대해 Prometheus 페더레이션을 실행하고 있습니다. Prometheus 2.19.0은 http2를 도입했습니다(변경 로그에 이것을 언급하는 것을 잊어버렸고 커밋 메시지 본문에 잘 숨겨져 있었습니다. 저는 git bisect, 배포 및 각 실행에 대해 몇 시간 기다려야 했습니다...) 하루에 페더레이션이 중단된 12개의 사건. 나는 먼저 http2 지원을 다시 패치했고(문제는 사라졌습니다), golang/net/x/http2에서 직접 읽기 제한 시간을 설정했습니다. 그 이후로 더 이상 단일 페더레이션 다운 사고가 발생하지 않았습니다.

저는 현재 일부 클러스터에서 패치된 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 (기본적으로 5

BTW - rancher 작업자 노드의 docker pause nginx-proxy 는 kubelet이 동일한 오류 메시지를 생성하도록 합니다.

VMWare vSphere에서 K8S를 실행하는 사람들을 위한 임시 해결 방법 - K8S VM에 대해 DRS 를

새로운 golang http2 상태 확인 기능을 사용하여 문제를 완화하는 것과 관련하여 아주 좋은 소식이 있습니다. 더 이상 문제가 없습니다. 지금까지 우리는 Prometheus, 전체 Kubernetes 및 여러 내부 구성 요소에서 "수정"(공급된 x/net 코드의 값 하드코딩 설정)을 구현하여 다음을 관찰했습니다.

• 더 이상 Prometheus 연합 문제 없음
• kubelet은 때때로 단일 "닫힌 연결 사용" 이벤트를 보고하지만 몇 초 이내에 복구됩니다(~30초 http2 상태 확인 창 설정).
• 때때로 kubectl 시계에 문제가 있었습니다. 패치된 kubectl을 사용하는 경우에도 사라집니다.
• 우리는 정기적으로 통합을 확인하기 위해 확장된 E2E 테스트 스위트를 실행하고 있으며 간헐적인 테스트 시간 초과 및 불안정성을 관찰했습니다. 뭔지 맞춰봐? 지금 갔다.

또한 문제를 유발하는 방법에 대한 새로운 통찰력을 얻을 수 있었습니다. 라이브 마이그레이션에 대한 @vi7 의 관찰은 자신 있게 확인할 수 있으며(추적할 수 있음) 최소한 우리가 실행하는 NSX 버전에서는 로드 밸런서 변경이 이러한 문제를 유발할 수 있습니다(VMware와 함께 그들이 미래에 재설정 패킷을 보내고 있는지 확인하십시오). 그리고 연결 테이블 오버플로와 같이 연결을 끊는 다른 많은 이유가 있을 수 있습니다.

이것은 일부 Kubernetes 사용자에게 매우 성가시고 다소 방대한 문제입니다(IaaS 계층/네트워킹의 일종의 "손상"에 따라 다름). 값을 적절하게 설정하기 위해 인터페이스를 노출하는 것에 대한 golang 토론이 있지만 -- 리플렉션을 통해 해당 값을 설정하는 PR 병합 업스트림을 얻을 가능성이 있다고 생각하십니까? ? 우리는 코드를 제공하는 데 문제가 없습니다(그리고 수정 사항의 유효성을 검사하면 실제로 재현할 수는 없지만 수정 사항이 작동하는지 확인할 수 있을 만큼 충분히 자주 관찰).

cc @liggitt

장기 문제(자신에 대한 메모)

@JensErat 답변 감사합니다.
그렇다면 이전 버전의 k8s(1.13, 1.15, ..)에서도 이 문제가 발생할 수 있습니까?

Kubernetes v1.16.13의 문제를 확인할 수 있습니다.
Kubernetes v1.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 문제로 인해 발생합니다. 한 가지 확실한 것은 이것이 go 1.15에서 수정되지 않을 것이라는 것입니다.
한편 Kubernetes 커뮤니티는 여전히 1.14 LOL로 마이그레이션하기 위해 고군분투하고 있습니다.

일반적으로 go는 6개월마다 릴리스됩니다. 모든 것이 잘 작동한다면 이 문제가 내년에 업스트림에서 해결되는 것을 볼 수 있고 kubernetes가 수정 사항을 적용할 때까지 1년 더 볼 수 있습니다 🥇 !
(농담입니다. 지금 스택에서 이 문제를 해결하고 싶다면 h2Transport를 해킹하여 healthCheck가 작동하는 것으로 판명되었습니다.

한편 Kubernetes 커뮤니티는 여전히 1.14 LOL로 마이그레이션하기 위해 고군분투하고 있습니다.

실제로 go1.15 프리릴리즈에서 자격을 얻기 위한 sig-scalability 및 sig-release의 훌륭한 작업으로 인해 Kubernetes 1.19는 go1.15에서 방금 출시되었습니다. go1.16에서 http/2 옵션을 노출하기 위한 작업이 진행 중인 것으로 보이며 가능한 한 빨리 이를 사용할 수 있을 것으로 기대합니다.

실제로 go1.15 프리릴리즈에서 자격을 얻기 위한 sig-scalability 및 sig-release의 훌륭한 작업으로 인해 Kubernetes 1.19는 go1.15에서 방금 출시되었습니다.

옵스. 어색한 농담 죄송합니다. 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에서 이를 완전히 완화할 수 있습니까? 예를 들어 "닫힌 네트워크 연결 사용"에 도달하면 클라이언트 이동이 전송을 교체하도록 만들 수 있습니까?

또는 HTTP 1.1을 사용하는 경우에도 이 문제가 계속 발생합니까, 아니면 순수하게 HTTP 2와 관련이 있습니까? HTTP 1.1이 면역이고 큰 단점이 없다면 kubelet, kube-proxy 및 다양한 제어 평면 프로세스에 GODEBUG=http2client=0 를 설정하거나 GODEBUG=http2server=0 변경 사항을 보편적으로 만들기 위해 apiserver 프로세스에

이것이 실제로 이 문제를 완화하고 HTTP2를 통해 멀티플렉싱하지 않을 때 연결 수의 증가로 인한 일부 성능 문제 이외의 다른 주요 함정을 일으키지 않을 것이라고 생각합니까?

client-go가 "닫힌 네트워크 연결 사용"에 도달하면 전송을 교체하도록 만들 수 있습니까?

그다지 외과적으로는 아닙니다... 새로운 클라이언트를 반복적으로 구성하는 호출자에 직면하여 임시 포트 고갈을 피하기 위해 현재 전송이 공유됩니다.

HTTP 1.1을 사용하는 경우 이 문제가 계속 발생합니까, 아니면 순수하게 HTTP 2와 관련이 있습니까?

내가 아는 한, 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 클라이언트는 요청을 계속 재시도하는 것으로 보이며 상위 응용 프로그램에 오류가 표시되지 않습니다. 나는 지금 상황에 대해 좋은 생각이 없습니다.

여기에 제안된 해결 방법은 몇 주 동안 효과가 있었습니다. 모든 클러스터에서 데몬셋으로 실행되는 파이썬 스크립트로 전환했습니다. 우리는 일반적으로 일주일에 한두 번(kubelet을 자동으로 다시 시작) 조치를 취하는 것을 보고 클러스터 운영에 부정적인 영향을 미치지 않았습니다. 5분 동안 2개 이상의 메시지가 표시되는 경우에만 kubelet을 다시 시작하도록 변수를 만들었습니다. 우리는 때때로 하나의 메시지를 볼 수 있음을 보았고 그것은 문제가 되지 않았습니다. 문제가 발생하면 kubelet 로그에 지속적으로 use of closed network connection 오류가 표시됩니다.

pullrequest를 생성해 주시면 이 주제를 조사하겠습니다.

단일 베어메탈 클러스터에서 24시간마다 약 2-4번 발생합니다. 1.17.12

단일 노드 클러스터에서도 api-server 포드가 다시 시작될 때 발생합니다. apiserver에 대한 연결이 끊어져 오류 번호 최소화 방법으로 apiserver가 다시 시작되는 문제를 해결합니다.

나는 마스터 노드 앞에서 haproxy를 사용하고 있습니다. 어쨌든 일부 LB 구성으로 이것을 방지할 수 있다고 생각하십니까?

@shubb30 솔루션을 공유하시겠습니까?

문제가 발생했을 때 내 apiserver가 다시 시작 되지 않는 것을 확인할 수 있습니다. 로그 항목을 모니터링한 다음 kubelet을 다시 시작하기 위해 daemonset 및 셸 트릭을 사용하고 있습니다. 이것은 꽤 잘 작동했지만 임시 해결 방법일 뿐입니다.

다음 은 해결 방법으로 잘 작동하는 수정된 버전입니다.

이봐 여러분!

이 백포트가 잠재적으로 도움이 될 수 있다고 생각합니까?
https://github.com/golang/go/issues/40423

좋은 소식: golang/net master는 http2 전송 구성을 지원하므로 이제 시간 제한을 설정할 수 있습니다! https://github.com/golang/net/commit/08b38378de702b893ee869b94b32f833e2933bd2

완료.
검토를 위해 PR이 열렸습니다.

또 다른 좋은 소식: Kubernetes는 표준 net/http 패키지에 번들된 http2를 사용하지 않으므로 다음 Go 릴리스를 기다릴 필요가 없습니다. https://github.com/golang/net/commit/08b38378de702b893ee869b94b32f833e2933bd2 를 직접 사용하여 이 문제를 해결할 수 있습니다.

여기에 수정 사항을 제안했습니다. https://github.com/kubernetes/kubernetes/pull/95898
필수 버전에 대한 종속성을 업데이트하고 기본적으로 http2 전송 상태 확인을 활성화합니다.
apiserver(예: kubelet)와 통신하기 위해 client-go를 사용하는 응용 프로그램이 "app hang at write tcp xxx: use of closed connection" 문제를 해결하는 데 도움이 됩니다.

의견을 남겨주세요.

언급된 #95898은 논의할 필요가 없는 이유로 폐쇄된 것 같습니다.

이 문제와 관련하여 다른 업데이트가 있습니까?

https://github.com/kubernetes/kubernetes/pull/95981 (위에 링크됨)이 http/2 수정 사항을 가져오기 위해 진행 중입니다.

이 문제는 kubernetes의 1.17.X 버전에만 해당됩니까?

@krmayankk 정확히 언제 시작되었는지 확실하지 않습니다. 그러나 적어도 1.17-1.19에는 이 문제가 있습니다. #95980은 그것을 고쳤어야 했습니다(다음 1.20 릴리스의 일부가 될 것이며 어제 베타에 포함되지 않았습니다)

@krmayankk 우리는 v1.18.9에서도 이 문제를 보았지만 매우 높은 네트워크 사용량을 유발한 버그가 있는 Rancher 버전에 의해 트리거되었습니다. 다른 버전으로 롤백한 후 문제가 관찰되지 않았습니다.

이 문제가 있었지만 이제 위의 설명에 있는 해결 방법을 사용하여 작은 취미 클러스터에서 "고정"했습니다.

나는 시스템 단위 및 타이머로 노드에 해결 방법을 배포하기 위해 작은 실행 가능한 플레이북 을 작성

https://github.com/kubernetes/kubernetes/pull/95981 및 https://github.com/kubernetes/kubernetes/issues/87615 에서 1.18 릴리스 분기를 체리 선택/백포트할 계획이 있습니까?

1.17 릴리스 분기에서 #95981을 체리픽할 계획이 있습니까?

이 의견은 이전 릴리스에 대한 백포트에 대해 설명합니다. https://github.com/kubernetes/kubernetes/pull/95981#issuecomment -730561539

대답은 "힘들고 물건을 부술 수 있으므로 아마도 그렇지 않을 것"이라고 생각합니다. 질문을 받았을 때 v1.17을 실행하는 사람들에게서 기대할 수 있는 것과 같은 대답입니다. 그러면 수정을 위해 v1.20으로 업그레이드하지 않겠습니까? :웃음:

이것을 1.19 이상으로 백포팅하면 비교적 빨리 수정 사항을 사용할 수 있으므로 좋을 것입니다. Docker의 사용 중단으로 인해 일부 사람들이 1.20을 보류할 것이라고 생각합니다.

이것을 1.19 이상으로 백포팅하면 비교적 빨리 수정 사항을 사용할 수 있으므로 좋을 것입니다.

이미 완료되었습니다.

Docker의 사용 중단으로 인해 일부 사람들이 1.20을 보류할 것이라고 생각합니다.

사용 중단 경고 외에 도커와 관련하여 1.20에서 변경된 사항은 없습니다. 사용 중단 기간의 끝에서, 지원이 제거됩니다 dockershim.

raspbian 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. 나는 그것을 1.18 또는 이전 버전으로 선택하지 않을 계획입니다.