/सिग्नेचर नोड
/सिग एपीआई-मशीनरी

कोड में एक नज़र डालने पर त्रुटि यहाँ होती

कोड की व्याख्या यह है कि यह संभवतः EOF (IsProbableEOF) मानता है जबकि इस मामले में ऐसा नहीं लगता है।

/असाइन @caesarxuchao

@ricatz क्या आप विस्तार से

मेरा विचार यह है कि परावर्तक ने घड़ी को फिर से चालू कर दिया होगा, इससे कोई फर्क नहीं पड़ता कि यह त्रुटि ( कोड ) को कैसे संभालता है, इसलिए यह पुनर्प्राप्त करने में विफलता की व्याख्या नहीं करता है।

बिल्कुल सही @caesarxuchao तो यह हमारा सवाल है।

मैंने मूल रूप से कोड के माध्यम से इसे पकड़ने में त्रुटि को ट्रैक किया है और उस हिस्से में जाने के लिए उस समय क्यूबलेट क्या कर रहा था (रहस्य देखना) कर रहा था।

एक उन्नत तरीका नहीं है, इसके माध्यम से त्रुटि कोड का सटीक बिंदु प्रतीत होता है।

सवाल यह है कि, क्योंकि कनेक्शन बंद है, कहीं कहीं फ़्लैग कर रहा है कि यह घड़ी ईओएफ है, यह समझने के बजाय यह एक त्रुटि है?

मेरे पास जोड़ने के लिए और कुछ नहीं है, इसके अलावा हमारे पास एक और नोड विफल हो गया है, पिछले 4 दिनों से घटनाओं को बढ़ाकर 4 कर दिया गया है।

यदि अन्य नोड्स पर बॉन्ड डिस्कनेक्ट की घटनाएं हो रही हैं और यदि क्यूबलेट ठीक हो रहा है, तो मैप करने का प्रयास करेंगे - यह कुछ ठीक होने पर दुर्भाग्य हो सकता है, न कि 100% घटना।

मुझे लगता है कि हम इसे भी देख रहे हैं, लेकिन हमारे पास बॉन्ड नहीं हैं, हम केवल कैलिको cali* इंटरफेस के लिए इन नेटवर्क "कैरियर लॉस्ट" संदेशों को देखते हैं, और वे स्थानीय वीथ डिवाइस हैं।

मैंने इसका भी सामना किया है, जिसमें कोई बंधन शामिल नहीं है। नोड को पुनरारंभ करने से समस्या ठीक हो जाती है, लेकिन क्यूबलेट सेवा को फिर से शुरू करने से ऐसा नहीं होता है (सभी एपीआई कॉल "अनधिकृत" के साथ विफल हो जाते हैं)।

मैंने इसका भी सामना किया है, जिसमें कोई बंधन शामिल नहीं है। नोड को पुनरारंभ करने से समस्या ठीक हो जाती है, लेकिन क्यूबलेट सेवा को फिर से शुरू करने से ऐसा नहीं होता है (सभी एपीआई कॉल "अनधिकृत" के साथ विफल हो जाते हैं)।

अद्यतन: क्यूबलेट को पुनरारंभ करने से पर्याप्त समय (1 घंटा?) के बाद समस्या ठीक हो गई थी।

मैं वही व्यवहार देख रहा हूं। उबंटू 18.04.3 एलटीएस क्लीन इंस्टाल। रैंचर 2.3.4 के साथ बनाया गया क्लस्टर। मैंने इसे समय-समय पर हाल ही में देखा है और क्यूबलेट को फिर से शुरू करने से यह मेरे लिए ठीक हो जाता है। कल रात मेरे सभी 3 कार्यकर्ता नोड्स ने इसी तरह के व्यवहार का प्रदर्शन किया। मैंने अपने क्लस्टर को ऊपर लाने के लिए 2 को सही किया। तीसरा अभी भी इस राज्य में है जबकि मैं चारों ओर खुदाई कर रहा हूं।

हम CentOS 7 पर एक ही समस्या देख रहे हैं, क्लस्टर को नए सिरे से रैंचर (1.17.2) के साथ बनाया गया है। हम बुनाई का उपयोग कर रहे हैं। सभी 3 कार्यकर्ता नोड इस समस्या को दिखा रहे हैं। क्यूबलेट को पुनरारंभ करना हमारे लिए काम नहीं करता है, हमें पूरे नोड को पुनरारंभ करना होगा

/सिग्नेचर नोड
/सिग एपीआई-मशीनरी

कोड में एक नज़र डालने पर त्रुटि यहाँ होती

कोड की व्याख्या यह है कि यह संभवतः EOF (IsProbableEOF) मानता है जबकि इस मामले में ऐसा नहीं लगता है।

हम भी यही मुद्दा देख रहे हैं। लॉग से, हमने पाया कि समस्या होने के बाद भी बाद के सभी अनुरोध उसी कनेक्शन पर भेजे गए थे। ऐसा लगता है कि हालांकि क्लाइंट एपिसर्वर को अनुरोध फिर से भेज देगा, लेकिन अंडरले http2 लाइब्रेरी अभी भी पुराने कनेक्शन को बनाए रखती है, इसलिए बाद के सभी अनुरोध अभी भी इस कनेक्शन पर भेजे जाते हैं और वही त्रुटि प्राप्त होती है use of closed connection ।

तो सवाल यह है कि क्यों http2 अभी भी पहले से बंद कनेक्शन बनाए रखता है? हो सकता है कि जो कनेक्शन बनाए रखा गया है वह वास्तव में जीवित है लेकिन कुछ मध्यवर्ती कनेक्शन अप्रत्याशित रूप से बंद हो गए हैं?

मेरे पास रास्पबेरी पाई क्लस्टर के साथ k8s 1.17.3 के साथ बहुत बार एक ही समस्या है। कुछ पुराने मुद्दों के आधार पर, मैंने क्यूब एपीआई सर्वर http कनेक्शन सीमा को 1000 "- --http2-max-streams-per-connection=1000" पर सेट किया है, यह 2 सप्ताह से अधिक समय तक ठीक रहा, इसके बाद यह अब फिर से शुरू होता है।

क्या क्यूब-एपिसर्वर का पुनर्निर्माण संभव है https://github.com/kubernetes/apiserver/blob/b214a49983bcd70ced138bd2717f78c0cff351b2/pkg/server/secure_serving.go#L50
डिफ़ॉल्ट रूप से s.DisableHTTP2 को true ?
क्या आधिकारिक छवि ( k8s.gcr.io/kube-apiserver:v1.17.3 ) के लिए कोई डॉकरफाइल है?

यहाँ वही। (उबंटू 18.04, कुबेरनेट्स 1.17.3)

हमने इसे अपने दो समूहों में भी देखा। मूल कारण के बारे में पूरी तरह से निश्चित नहीं है, लेकिन कम से कम हम यह देखने में सक्षम थे कि क्लस्टर में बहुत अधिक घड़ी की संख्या के साथ ऐसा हुआ। मैं प्रति क्यूबलेट घड़ियों की उच्च संख्या को मजबूर करके पुन: उत्पन्न करने में सक्षम नहीं था (हालांकि प्रति पॉड 300 रहस्यों के साथ पॉड्स शुरू किया, जिसके परिणामस्वरूप प्रोमेथियस मेट्रिक्स में प्रति पॉड 300 घड़ियां भी हुईं)। इसके अलावा बहुत कम http2-max-streams-per-connection मान सेट करने से समस्या ट्रिगर नहीं हुई, लेकिन कम से कम मैं कुछ अप्रत्याशित शेड्यूलर और नियंत्रक-प्रबंधक व्यवहार का निरीक्षण करने में सक्षम था (शायद अंतहीन री-वॉच लूप या ऐसा कुछ के बाद ओवरलोड हो सकता है, हालांकि)।

वर्कअराउंड के रूप में मेरे सभी नोड्स स्थानीय क्रोनजॉब के माध्यम से हर रात कुबलेट को पुनरारंभ करते हैं। अब 10 दिन पहले, मैं कह सकता हूं कि यह मेरे लिए काम करता है, मेरे पास मेरे नोड्स पर "बंद नेटवर्क कनेक्शन का उपयोग" नहीं है।

@sbiermann
इसे पोस्ट करने के लिए आपका धन्यवाद। क्रोनजॉब के लिए आप किस समय अंतराल का उपयोग करते हैं?

चौबीस घंटे

मैं इस मुद्दे की पुष्टि भी कर सकता हूं, हम अभी तक 1.17.3 पर नहीं हैं, वर्तमान में उबंटू 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 पर भी इसकी पुष्टि कर सकता हूं। क्यूबलेट को पुनरारंभ करना मेरे लिए काम करता प्रतीत होता है, मुझे पूरे नोड को पुनरारंभ करने की आवश्यकता नहीं है।

मेरे लिए अंतर्निहित कारण यह प्रतीत होता है कि RAM समाप्त होने के करीब हो रही है और kswapd0 उसके कारण 100% CPU उपयोग प्राप्त कर रहा है, क्योंकि मैं अपने कुबेरनेट्स नोड्स के लिए स्वैपनेस को 0 पर सेट करना भूल गया था। स्वैपनेस को 0 पर सेट करने और मशीनों में कुछ रैम जोड़ने के बाद, मेरे लिए यह समस्या अभी तक दोबारा नहीं हुई है।

यदि अंतर्निहित समस्या "http2 मृत कनेक्शन का उपयोग कर रही थी", तो क्यूबलेट को पुनरारंभ करने से समस्या ठीक होनी चाहिए। https://github.com/kubernetes/kubernetes/pull/48670 ने सुझाव दिया कि TCP_USER_TIMEOUT को कम करने से समस्या कम हो सकती है। मैंने http2 लाइब्रेरी में क्लाइंट-साइड कनेक्शन स्वास्थ्य जांच जोड़ने के लिए https://github.com/golang/net/pull/55 खोला है, लेकिन इसे लैंड करने में अधिक समय लगने वाला है।

यदि क्यूबलेट को पुनरारंभ करने से समस्या हल नहीं होती है, तो शायद यह एक अलग मूल कारण है।

नेटवर्क को पुनरारंभ करते समय मेरे पास v1.17.2 के साथ एक ही समस्या है, लेकिन नोड में से केवल एक में यह समस्या है (मेरे क्लस्टर में पांच नोड हैं), मैं इसे पुन: पेश नहीं कर सकता। क्यूबलेट को पुनरारंभ करें इस समस्या को हल किया।

मैं इस मुद्दे से कैसे बच सकता हूं? नवीनतम संस्करण को अपग्रेड करें या इसे ठीक करने का कोई अन्य तरीका है?

मैंने हर 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

मैंने क्यूबलेट को पुनरारंभ किए बिना एक पैच बनाया है और ऐसा लगता है कि समस्या हल हो गई है।
समय सीमा पैच

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 इस पैच को लागू करें, फिर क्यूबलेट को फिर से बनाएं और बाइनरी को बदलें

@mYmNeo मैं इस मुद्दे को कैसे पुन: पेश कर सकता हूं और इसका परीक्षण कैसे कर सकता हूं?

मैंने हर 5 मिनट में इस बैश स्क्रिप्ट को चलाकर इसे ठीक किया है

@ ik9999 धन्यवाद, यह काम करता है।

सीसी @liggitt

क्या SetReadDeadline सेट करने का मतलब है कि सभी घड़ियाँ हर 30 सेकंड में बंद हो जाएँगी?

क्या SetReadDeadline सेट करने का मतलब है कि सभी घड़ियाँ हर 30 सेकंड में बंद हो जाएँगी?

हां। यह इस समस्या को हल करने का एक बदसूरत तरीका है (एक कनेक्शन बंद करने के लिए मजबूर करें)।

बस एक और मामला:

हम इसे क्यूब 1.16.8 क्लस्टर्स में भी देख रहे हैं। VM को रिबूट करने का उपयोग नोड को एक अच्छी स्थिति में वापस लाने के लिए किया जा सकता है (मुझे संदेह है कि क्यूबलेट पुनरारंभ भी काम करेगा)।

हमारा सेटअप क्यूबलेट लोकलहोस्ट पर एक स्थानीय हैप्रोक्सी इंस्टेंस से बात करता है जो कई बैकएंड मास्टर इंस्टेंस के लिए एक टीसीपी लोड बैलेंसर के रूप में कार्य करता है। अगर जोड़ रहे हैं तो हम जांच करने जा रहे हैं

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

एक अद्यतन पोस्ट करेंगे यदि यह हमारी विशिष्ट समस्या को हल करता है जो कि यहां किसी को भी अंतरिम में मदद करता है।

उत्सुक अगर घड़ी के समय पर पूर्ण ऊपरी बाउंड सेट करने के लिए कोई कॉन्फ़िगरेशन पैरामीटर है? मैंने पाया --स्ट्रीमिंग-निष्क्रिय-कनेक्शन-टाइमआउट लेकिन घड़ियों के लिए कुछ खास नहीं।

हम इसे क्यूब १.१७.४ में देख रहे हैं क्योंकि एपीआई सर्वर अस्वस्थ होने के कारण "आदि विफल: कारण रोक दिया गया है"।

हाय दोस्तों। मैंने गोलंग 1.14 के साथ कुबेरनेट्स बाइनरी को फिर से संकलित किया है। ऐसा लगता है कि समस्या गायब हो गई

@mYmNeo गोलांग 1.14 + कुबेरनेट्स v1.17?

@mYmNeo गोलांग 1.14 + कुबेरनेट्स v1.17?

@pytimer हम बिना किसी कोड को बदले 1.16.6 का उपयोग कर रहे हैं, बस पुन:

अरे! यहाँ एक ही मुद्दा मिला, k8s 1.17.4 क्या हमें लगता है कि अगर हम इस मुद्दे को हल करते हैं तो हम 1.14 के साथ 1.17.5 पुनः संकलित कर सकते हैं?

दुर्भाग्य से, go1.14 को अपडेट करने के लिए कई प्रमुख घटकों के अपडेट की आवश्यकता होती है, इसलिए क्यूब 1.17 पर वापस चुने जाने की संभावना नहीं है। आप https://github.com/kubernetes/kubernetes/pull/88638 में मुद्दों और प्रगति को ट्रैक कर सकते हैं

जानकर अच्छा लगा, thx

@callicles यह पुष्टि की गई है कि 1.14 के साथ पुन:

मुझे 1.16.8 पर एक समान समस्या दिखाई दे रही है - हर बार (कभी-कभी हर दो दिनों में, कभी-कभी हर दो हफ्ते में) नोड 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
        }

हाय दोस्तों। मैंने गोलंग 1.14 के साथ कुबेरनेट्स बाइनरी को फिर से संकलित किया है। ऐसा लगता है कि समस्या गायब हो गई

@mYmNeo क्या आपने कभी 1.14 के साथ पुन:

हाय दोस्तों। मैंने गोलंग 1.14 के साथ कुबेरनेट्स बाइनरी को फिर से संकलित किया है। ऐसा लगता है कि समस्या गायब हो गई

@mYmNeo क्या आपने कभी 1.14 के साथ पुन:

AFAIN, समस्या अब मौजूद नहीं है।

दुर्भाग्य से, go1.14 को अपडेट करने के लिए कई प्रमुख घटकों के अपडेट की आवश्यकता होती है, इसलिए क्यूब 1.17 पर वापस चुने जाने की संभावना नहीं है। आप #88638 . में मुद्दों और प्रगति को ट्रैक कर सकते हैं

क्या आप पहले से ही जानते हैं कि क्या go1.14 को 1.18 पर बैकपोर्ट किया जाएगा?

क्या आप पहले से ही जानते हैं कि क्या go1.14 को 1.18 पर बैकपोर्ट किया जाएगा?

मुझे ऐसी उम्मीद नहीं होगी। Etcd और bbolt में परिवर्तन go1.14 का समर्थन करने के लिए आवश्यक प्रतीत होता है, जो कि आम तौर पर रिलीज़ शाखाओं में किए गए बदलाव से बड़ा परिवर्तन है।

@liggitt ठीक है thx। ऐसा लगता है कि इस बीच हमें (कम से कम हमारे समूहों के लिए) शमन रणनीति की आवश्यकता है :)

क्या यह समस्या NIC के फेल होने के बाद ही होती है? हम अपने v1.16.8 क्लस्टर में वही त्रुटि संदेश देख रहे हैं, लेकिन कोई संबद्ध NIC विफलता नहीं है।

हमारे पास कम से कम एक उदाहरण था जहां अंतर्निहित VM में SAN से कनेक्ट करते समय SCSI त्रुटि थी। SCSI समस्या अपने आप हल हो गई, लेकिन kubelet कभी भी ठीक नहीं हुई।

--goaway-chance विकल्प 1.18(#88567) में जोड़ा गया था। क्या यह विकल्प इस समस्या को कम करेगा?

नहीं। इसका केवल तभी प्रभाव पड़ता है जब क्यूबलेट वास्तव में एपीआई सर्वर तक पहुंचने में सक्षम होता है और प्रतिक्रिया वापस प्राप्त करता है।

एक एनआईसी बांड विफल हो जाता है (जो लंबे समय के बाद ठीक नहीं होता है), इसके सभी कनेक्शन टूट जाएंगे और मैन्युअल रूप से पुनरारंभ होने तक उन्हें फिर से स्थापित करने का प्रयास नहीं करेंगे।

क्या आप कृपया बता सकते हैं कि आप किस बॉन्ड मोड का उपयोग कर रहे हैं? मैं इसे अपने क्लस्टर पर सक्रिय-बैकअप बॉन्ड के साथ पुन: पेश करने में सक्षम नहीं हूं।

Kubernetes 1.16 में अपग्रेड करने के बाद, हमने use of closed network connection त्रुटि और क्यूबलेट को एपिसर्वर से फिर से कनेक्ट नहीं होना भी देखना शुरू कर दिया, जिससे नोड्स NotReady में फंस गए। हम एनआईसी को हटाकर (लिंक डाउन/अप सेट करके) समस्या को पुन: उत्पन्न करने में सक्षम नहीं थे, लेकिन हमने देखा कि यह व्यवहार केवल उन क्लस्टर्स पर हुआ जो अधिक भारी लोड थे।

हमने और अधिक खुदाई की और पाया कि गोलंग में सर्वर-साइड क्लाइंट-साइड डिफ़ॉल्ट 1000 है , इसलिए मेरा अनुमान है कि एक बार क्यूबलेट को http2 स्ट्रीम सीमा को हिट करने के लिए एपिसर्वर से एक त्रुटि मिली, इसने फिर से जोड़ने की कोशिश कभी नहीं की। --http2-max-streams-per-connection=1000 सेट करने के बाद, हमने नोड के साथ NotReady में फंसने की समस्या को उतना नहीं देखा जितना मूल रूप से परीक्षण के दौरान पाया गया था। इसने क्यूबलेट को फिर से कनेक्ट नहीं करने के मुद्दे को हल नहीं किया, लेकिन इससे हमें उस समस्या को कम करने में मदद मिली जो हम देख रहे थे।

Kubernetes 1.16 में अपग्रेड करने के बाद, हमने use of closed network connection त्रुटि और क्यूबलेट को एपिसर्वर से फिर से कनेक्ट नहीं होना भी देखना शुरू कर दिया, जिससे नोड्स NotReady में फंस गए। हम एनआईसी को हटाकर (लिंक डाउन/अप सेट करके) समस्या को पुन: उत्पन्न करने में सक्षम नहीं थे, लेकिन हमने देखा कि यह व्यवहार केवल उन क्लस्टर्स पर हुआ जो अधिक भारी लोड थे।

हमने और अधिक खुदाई की और पाया कि गोलंग में सर्वर-साइड क्लाइंट-साइड डिफ़ॉल्ट 1000 है , इसलिए मेरा अनुमान है कि एक बार क्यूबलेट को http2 स्ट्रीम सीमा को हिट करने के लिए एपिसर्वर से एक त्रुटि मिली, इसने फिर से जोड़ने की कोशिश कभी नहीं की। --http2-max-streams-per-connection=1000 सेट करने के बाद, हमने नोड के साथ NotReady में फंसने की समस्या को उतना नहीं देखा जितना मूल रूप से परीक्षण के दौरान पाया गया था। इसने क्यूबलेट को फिर से कनेक्ट नहीं करने के मुद्दे को हल नहीं किया, लेकिन इससे हमें उस समस्या को कम करने में मदद मिली जो हम देख रहे थे।

नमस्ते, क्यूब-एपिसर्वर में डिफ़ॉल्ट सर्वर-साइड https स्ट्रीम 1000 है, यह क्लाइंट के मान के बराबर है।
https://github.com/kubernetes/kubernetes/blob/ae1103726f9aea1f9bbad1b215edfa47e0747dce/staging/src/k8s.io/apiserver/pkg/server/options/recommended.go#L62

@ वार्मचांग मुझे लगता है कि यह एपेक्स्टेंशन एपिसर्वर और नमूना एपिसर्वर पर लागू होता है:
https://github.com/kubernetes/kubernetes/blob/ae1103726f9aea1f9bbad1b215edfa47e0747dce/staging/src/k8s.io/apiserver/pkg/server/options/recommended.go#L62

--http2-max-streams-per-connection सेट किए बिना कर्ल परीक्षण के साथ एक परीक्षण में यह हमारे एपिसर्वर लॉग (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 कर्ल अनुरोध का उपयोग करता हूं तो दिखाता है
* Connection state changed (MAX_CONCURRENT_STREAMS == 1000)!

@jmcmeek @treytabner , आप सही कह रहे हैं। मैंने कोड को गलत तरीके से पढ़ा। :+1:

कुबेरनेट्स 1.17.6 का उपयोग करना और वही यहाँ। ऐसा लगता है कि क्यूबलेट एक मृत http2 कनेक्शन का उपयोग कर रहा है।
मैंने देखा है कि क्यूब-एपिसर्वर और क्यूबलेट के बीच MAX_CONCURRENT_STREAMS का असंगत डिफ़ॉल्ट मान।

बस सर्वर-साइड मान को 1000 पर सेट करें। बाद में रिपोर्ट करेंगे।

रैंचर/आरकेई

क्लस्टर परिभाषा में जोड़ें:

 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' सेट करने से कोई मदद नहीं मिली☹️

हाय दोस्तों। मुझे लगता है कि आखिरकार मैंने इस मुद्दे को ट्रैक कर लिया है। हमारे पास कल रात भी यही मुद्दा है। लेकिन एक संशोधित क्यूबलेट के साथ सफलतापूर्वक पुनर्प्राप्त किया गया।

यह कुबेरनेट्स बग नहीं है, यह गोलांग के मानक net/http पैकेज के बारे में है जिसका उपयोग client-go भी कर रहा है।
मेरा मानना ​​है कि golang.org/x/net/http2/transport.go में एक खामी है

इसकी सूचना गोलांग अधिकारी को पहले ही दे दी गई है। कुछ चर्चा की प्रतीक्षा में।
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 द्वारा कहा जाता है, यह साबित करने के लिए वहां छोड़ना चाहता हूं।

 जून 23 03:14:45 vm10.company.com क्यूबलेट [22255]: E0623 03:14: 45.912484 22255 kubelet_node_status.go:402] नोड स्थिति अपडेट करने में त्रुटि, पुनः प्रयास करेंगे: नोड "vm10.company.com" प्राप्त करने में त्रुटि: प्राप्त करें "https://vm10.company.com:8443/api/v1/nodes/vm10.company.com?timeout=10s": टीसीपी 16.155.199.4:39668->16.155.199.4:8443 लिखें: बंद नेटवर्क कनेक्शन का उपयोग
 जून 23 03:14:45 vm10.company.com क्यूबलेट [22255]: E0623 03: 14: 45.912604 22255 kubelet_node_status.go:402] नोड स्थिति अपडेट करने में त्रुटि, पुनः प्रयास करेंगे: नोड "vm10.company.com" प्राप्त करने में त्रुटि: प्राप्त करें "https://vm10.company.com:8443/api/v1/nodes/vm10.company.com?timeout=10s": टीसीपी 16.155.199.4:39668->16.155.199.4:8443 लिखें: बंद नेटवर्क कनेक्शन का उपयोग
 जून 23 03:14:45 vm10.company.com क्यूबलेट [22255]: E0623 03: 14: 45.912741 22255 kubelet_node_status.go:402] नोड स्थिति अपडेट करने में त्रुटि, पुनः प्रयास करेंगे: नोड "vm10.company.com" प्राप्त करने में त्रुटि: प्राप्त करें "https://vm10.company.com:8443/api/v1/nodes/vm10.company.com?timeout=10s": टीसीपी 16.155.199.4:39668->16.155.199.4:8443 लिखें: बंद नेटवर्क कनेक्शन का उपयोग
 जून 23 03:14:46 vm10.company.com क्यूबलेट [22255]: E0623 03:14: 46.367046 22255 कंट्रोलर.गो: 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.4:39668->16.155 लिखें। 199.4:8443: बंद नेटवर्क कनेक्शन का उपयोग
 जून 23 03:14:48 vm10.company.com क्यूबलेट [22255]: E0623 03:14: 47.737579 22255 कंट्रोलर.गो: 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.155 लिखें। 199.4:8443: बंद नेटवर्क कनेक्शन का उपयोग
 जून 23 03:14:49 vm10.company.com क्यूबलेट [22255]: E0623 03:14:49.113920 22255 परावर्तक.go:153] k8s.io/kubernetes/pkg/kubelet/kubelet.go:458: सूची में विफल * 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: बंद नेटवर्क कनेक्शन का उपयोग
 जून २३ ०३:१४:४९ vm10.company.com क्यूबलेट [२२२५५]: E0623 ०३:१४:४८.७४४७७० २२२५५ परावर्तक.गो:१५३] ऑब्जेक्ट-"क्यूब-सिस्टम"/"फलालैन-टोकन-जेडवीएफडब्ल्यूएन": सूची में विफल * v1.Secret: "https://vm10.company.com:8443/api/v1/namespaces/kube-system/secrets?fieldSelector=metadata.name%3Dflannel-token-zvfwn&limit=500&resourceVersion=0" प्राप्त करें: टीसीपी 16.155 लिखें .199.4:39668->16.155.199.4:8443: बंद नेटवर्क कनेक्शन का उपयोग
 जून २३ ०३:१४:४९ vm10.company.com क्यूबलेट [२२२५५]: E0623 ०३:१४:४९.५९९६३१ २२२५५ परावर्तक। "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.155 लिखें। 199.4:8443: बंद नेटवर्क कनेक्शन का उपयोग
 जून २३ ०३:१४:४९ vm10.company.com क्यूबलेट [२२२५५]: E0623 ०३:१४:४९.५९९९२ २२२५५ कंट्रोलर.गो:१३५] यह सुनिश्चित करने में विफल रहा कि नोड लीज मौजूद है, 1.6s में पुनः प्रयास करेगा, त्रुटि: "https: / प्राप्त करें" /vm10.company.com:8443/apis/coordination.k8s.io/v1/namespaces/kube-node-lease/leases/vm10.company.com?timeout=10s": टीसीपी 16.155.199.4:39668->16.155 लिखें .199.4:8443: बंद नेटवर्क कनेक्शन का उपयोग
 जून 23 03:14:49 vm10.company.com क्यूबलेट [22255]: E0623 03:14:49.600182 22255 परावर्तक.go:153] k8s.io/kubernetes/pkg/kubelet/kubelet.go:449: सूची में विफल * v1.सेवा: "https://vm10.company.com:8443/api/v1/services?limit=500&resourceVersion=0" प्राप्त करें: टीसीपी 16.155.199.4:39668->16.155.199.4:8443 लिखें: बंद नेटवर्क का उपयोग संबंध
 जून 23 03:14:49 vm10.company.com क्यूबलेट [22255]: E0623 03:14:49.600323 22255 परावर्तक। v1.ConfigMap: "https://vm10.company.com:8443/api/v1/namespaces/kube-system/configmaps?fieldSelector=metadata.name%3Dkube-flannel-cfg&limit=500&resourceVersion=0" प्राप्त करें: टीसीपी 16.155 लिखें .199.4:39668->16.155.199.4:8443: बंद नेटवर्क कनेक्शन का उपयोग
 जून २३ ०३:१४:४९ vm10.company.com क्यूबलेट [२२२५५]: E0623 ०३:१४:४९.६००४६३ २२२५५ परावर्तक। https://vm10.company.com:8443/api/v1/namespaces/core/secrets?fieldSelector=metadata.name%3Dregistrypullsecret&limit=500&resourceVersion=0": tcp 16.155.199.4:39668->16.155.199.4:8443 लिखें: बंद नेटवर्क कनेक्शन का उपयोग
 जून 23 03:14:49 vm10.company.com क्यूबलेट [22255]: E0623 03:14:49.369097 22255 परावर्तक.go:153] ऑब्जेक्ट- "क्यूब-सिस्टम"/"रजिस्ट्रीपुलसेक्रेट": *v1.Secret को सूचीबद्ध करने में विफल: "https://vm10.company.com:8443/api/v1/namespaces/kube-system/secrets?fieldSelector=metadata.name%3Dregistrypullsecret&limit=500&resourceVersion=0" प्राप्त करें: tcp 16.155.199.4:39668->16.155 लिखें। 199.4:8443: बंद नेटवर्क कनेक्शन का उपयोग
 जून 23 03:25:39 vm10.company.com क्यूबलेट [22255]: E0623 03:25:39.543880 22255 वांछित_स्टेट_ऑफ_वर्ल्ड_पॉप्युलेटर.गो: 320] पॉड "फ्लुएंट-h76lr_core(e95c9200-3a0c) के लिए वॉल्यूम "परिनियोजन-लॉग-डीआईआर" संसाधित करने में त्रुटि -4fea-bd7f-99ac1cc6ae7a)": पीवीसी कोर/itom-vol-दावा प्रसंस्करण त्रुटि: एपीआई सर्वर से पीवीसी लाने में विफल: प्राप्त करें "https://vm10.company.com:8443/api/v1/namespaces/core/ परसिस्टेंटवॉल्यूमक्लेम्स/आइटम-वॉल-क्लेम": पढ़ें tcp 16.155.199.4:41512->16.155.199.4:8443: क्लोज्ड नेटवर्क कनेक्शन का उपयोग
 जून 23 03:25:39 vm10.company.com क्यूबलेट [22255]: E0623 03:25:39.666303 22255 kubelet_node_status.go:402] नोड स्थिति अपडेट करने में त्रुटि, पुन: प्रयास करेगा: स्थिति पैच करने में विफल "{\"status\": {\"$setElementOrder/conditions\":[{\"type\":\"MemoryPressure\"},{\"type\":\"DiskPressure\"},{\"type\":\"PIDPressure\ "},{\"टाइप\":\"रेडी\"}],\"शर्तें\":[{\"lastHeartbeatTime\":\"2020-06-22T19:25:29Z\",\"type\ ":\"मेमोरीप्रेशर\"},{\"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" के लिए: पैच "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 पढ़ें: बंद नेटवर्क कनेक्शन का उपयोग
 जून 23 03:25:49 vm10.company.com क्यूबलेट [22255]: E0623 03:25:49.553078 22255 kubelet_node_status.go:402] नोड स्थिति अपडेट करने में त्रुटि, पुनः प्रयास करेंगे: नोड "vm10.company.com" प्राप्त करने में त्रुटि: प्राप्त करें "https://vm10.company.com:8443/api/v1/nodes/vm10.company.com?timeout=10s": पढ़ें tcp 16.155.199.4:41718->16.155.199.4:8443: बंद नेटवर्क कनेक्शन का उपयोग
 जून 23 03:25:49 vm10.company.com क्यूबलेट [22255]: E0623 03: 25: 49.560723 22255 वांछित_स्टेट_ऑफ_वर्ल्ड_पॉप्युलेटर.गो: 320] पॉड "फ्लुएंट-एच 76 एलआर_कोर (ई 95c9200-3a0c-4fea) के लिए वॉल्यूम "लॉग-लोकेशन" को संसाधित करने में त्रुटि -bd7f-99ac1cc6ae7a)": पीवीसी कोर/आइटम-लॉगिंग-वॉल्यूम को संसाधित करने में त्रुटि: एपीआई सर्वर से पीवीसी लाने में विफल: प्राप्त करें "https://vm10.company.com:8443/api/v1/namespaces/core/persistentvolumeclaims/ itom-लॉगिंग-वॉल्यूम": पढ़ें tcp 16.155.199.4:41718->16.155.199.4:8443: बंद नेटवर्क कनेक्शन का उपयोग
 जून 23 03:27:29 vm10.company.com क्यूबलेट [22255]: I0623 03:27:29.961600 22255 log.go:181] http2 स्वास्थ्य जांच कर रहा है
 जून 23 03:31:32 vm10.company.com क्यूबलेट [22255]: I0623 03:31:31.829860 22255 log.go:181] http2 स्वास्थ्य जांच कर रहा है
 जून 23 03:31:44 vm10.company.com क्यूबलेट [22255]: I0623 03:31:44.570224 22255 log.go:181] http2 स्वास्थ्य जांच कर रहा है
 जून 23 03:32:13 vm10.company.com क्यूबलेट [22255]: I0623 03:32:12.961728 22255 log.go:181] http2 स्वास्थ्य जांच कर रहा है
 जून 23 03:33:16 vm10.company.com क्यूबलेट [22255]: I0623 03:33:15.441808 22255 log.go:181] http2 स्वास्थ्य जांच कर रहा है
 जून 23 03:33:28 vm10.company.com क्यूबलेट [22255]: I0623 03:33:28.233121 22255 log.go:181] http2 स्वास्थ्य जांच कर रहा है

कोई और use of closed network connection रिपोर्ट नहीं की गई और क्यूबलेट तैयार स्थिति में वापस आ गया

हमें अपने स्टैक में इस मुद्दे में कुछ नई संभावित अंतर्दृष्टि मिली है। कुछ विश्वास के साथ हम विशिष्ट परिस्थितियों में कनेक्शन संख्याओं के संबंध में उच्च भार के कारण नेटवर्किंग/बुनियादी ढांचे के स्तर पर दुर्लभ कनेक्शन ड्रॉप मानते हैं, इसलिए हमारे मामले में यह नेटवर्क इंटरफेस फ़्लिपिंग नहीं था। इस वजह से प्रोमेथियस फेडरेशन के साथ हमारे पास विशेष रूप से क्योंकि उन्होंने क्लाइंट-साइड पर http2 पर स्विच किया था । स्थापना करके http2 स्वास्थ्य पर नजर रखने के सक्षम करने से http2.Transport.ReadIdleTimeout के साथ लागू के रूप में golang/net#55 पूरी तरह से हमारे लिए महासंघ मुद्दों का समाधान।

मूल्यों वर्तमान में के रूप में नहीं दिखाया गया हो apimachinery/pkg/util/net/http.go को दर्शाता है http.Transport और आंतरिक रूप से http2 को यह अपग्रेड किए जाने तक, जो विकल्प को उजागर नहीं किया गया है जब तक golang / नेट # 74 विलय कर दिया है।

क्या क्यूबलेट रीस्टार्ट क्रॉन जॉब के अलावा कोई अन्य वर्कअराउंड हैं? हमारे पास एक सप्ताह के लिए क्रॉन जॉब है और इसने समस्या को होने से नहीं रोका है।

मेरे पास 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

उल्लिखित परिवर्तन केवल _offers_ HTTP2 स्वास्थ्य मॉनिटर को सक्षम करने की संभावना है, लेकिन इसे डेवलपर्स द्वारा सक्षम करने की आवश्यकता है (डिफ़ॉल्ट बंद है)। इसके अलावा, इसे वास्तव में सेट नहीं किया जा सकता है , लेकिन डेवलपर्स को स्वास्थ्य मॉनिटर तक पहुंच प्रदान करने के लिए एक पुल अनुरोध है ।

मैं वर्तमान में एक प्रतिबिंब-आधारित हॉटफिक्स को एकीकृत कर रहा हूं जो हमारे कुबेरनेट्स वितरण के लिए स्वास्थ्य मॉनिटर को सक्षम बनाता है, इस उम्मीद में कि यह समस्या को हल करने में मदद करता है।

--
जेन्स इरेट \ छाप

@JensErat उत्तर के लिए धन्यवाद।
यदि हां, तो क्या यह समस्या k8s(1.13, 1.15, ..) के पुराने संस्करणों में भी हो सकती है?

मैंने एक महीने से अधिक समय पहले RancherOS (कर्नेल 4.14.138) से Ubuntu 18.04 (कर्नेल 5.3.0) में नोड्स डिस्ट्रो को बदल दिया, तब से यह समस्या सामने नहीं आई है।
मेरे क्लस्टर में से एक RancherOS पर छोड़ दिया गया है, इस मुद्दे को पहले से ही 3 बार पुन: पेश किया गया है।

100% श्योर नहीं, लेकिन शायद कर्नेल संस्करण मायने रखता है।

बताना कठिन है। हम निश्चित रूप से १.१६ से १.१८ के साथ इस मुद्दे का निरीक्षण (डी) करते हैं, लेकिन इससे पहले दुर्लभ अजीब "क्यूबलेट अटके हुए अवसर" हैं। हमने कम से कम एक साल से इस तरह के मुद्दों को पहले ही खोद लिया था, लेकिन कभी भी कुछ भी सहसंबंधित नहीं हो सका (एकल घटनाएं सभी कुछ हफ्तों में, और हमारे पास चार अंकों की संख्या में क्यूबलेट चल रहे हैं)। हालाँकि यह बहुत खराब हो गया था क्योंकि हमने 1.16 स्थापित किया था, लेकिन वर्तमान में हम अंतर्निहित (बहुत दुर्लभ और कठिन पता लगाने के लिए ...) को मानने में अधिक हैं नेटवर्किंग समस्याएँ अधिक बार होती हैं। हम कर्नेल 5.3.0-46-जेनेरिक के साथ उबंटू 19.10 चला रहे हैं, लेकिन प्रभावित हैं (इतनी अच्छी तरह से संभव है कि आपको वास्तव में एक नया पैचवेल मिला हो)। क्या आप संकेत दे सकते हैं कि आप कौन सा सटीक कर्नेल संस्करण/पैच स्तर चला रहे हैं?

--
जेन्स इरेट \ छाप

यह 5.3.0-59-generic । लेकिन हमारे पास केवल ~ ४० कुब्लेट हैं, इसलिए यह अभी भी एक संयोग हो सकता है।

जैसा कि मैंने ऊपर कहा। हैवी लोडेड क्लस्टर्स पर यह समस्या अधिक बार होती है। h2 ट्रांसपोर्ट हेल्थचेक को सक्षम करने से पहले हमने लगभग हर रात एक ही समस्या देखी।
इस मुद्दे के अनुसार

विषय से थोड़ा दूर, मेरा मतलब है, क्योंकि समस्या नेटवर्क सॉकेट के कारण होती है जो कर्नेल के बहुत करीब है। कर्नेल को अपडेट करने से मदद मिल सकती है, या नहीं। (पुनश्च: हम कर्नेल 3.10 के साथ सेंटोस 7 का उपयोग कर रहे हैं, यह स्वास्थ्य जांच को सक्षम करने से पहले लगभग हर रोज होता है)
जहाँ तक मैंने देखा, मैंने नेट/एचटीटीपी के सोर्स कोड को पढ़ने में लगभग ३ दिन बिताए, एच२ ट्रांसपोर्ट हेल्थचेक को सक्षम करने से इस तरह की समस्या से उबरने में मदद मिलेगी, और हम वास्तव में ऐसा करके इस विषम स्थिति से बच गए।
@JensErat क्या आपके पास स्वास्थ्य जांच को सक्षम करने के लिए कुछ ठोस सबूत हैं जो इस समस्या को हल करने में मदद करते हैं?

@JensErat क्या आपके पास स्वास्थ्य जांच को सक्षम करने के लिए कुछ ठोस सबूत हैं जो इस समस्या को हल करने में मदद करते हैं?

हम अपने प्रत्येक कुबेरनेट्स क्लस्टर के लिए प्रोमेथियस फेडरेशन चला रहे हैं। प्रोमेथियस 2.19.0 ने http2 को पेश किया (हालांकि वे चैंज में इसका उल्लेख करना भूल जाते हैं और यह एक प्रतिबद्ध संदेश निकाय में अच्छी तरह से छिपा हुआ था, मुझे प्रत्येक रन के लिए git bisect, तैनाती और कुछ घंटे इंतजार करना पड़ा ...) और हमने इसके बारे में देखा फेडरेशन के साथ रोजाना एक दर्जन घटनाएं अटकी मैंने पहले http2 समर्थन को फिर से पैच आउट किया (और समस्या समाप्त हो गई), और फिर सीधे गोलांग/नेट/एक्स/http2 में रीड टाइमआउट सेट करें। तब से, हमारे पास एक भी फेडरेशन डाउन घटना नहीं थी।

मैं वर्तमान में कुछ क्लस्टर्स पर एक पैच किए गए Kubernetes रिलीज़ को रोल आउट करने की तैयारी कर रहा हूँ, इसलिए हमारे पास कुछ दिनों में डेटा होना चाहिए। जैसे ही हमारे पास उचित डेटा होगा, हम निश्चित रूप से अपने परिणाम साझा करेंगे।

--
जेन्स इरेट \ छाप

मैं वर्तमान में कुछ क्लस्टर्स पर एक पैच किए गए Kubernetes रिलीज़ को रोल आउट करने की तैयारी कर रहा हूँ, इसलिए हमारे पास कुछ दिनों में डेटा होना चाहिए। जैसे ही हमारे पास उचित डेटा होगा, हम निश्चित रूप से अपने परिणाम साझा करेंगे।

आपकी प्रतिक्रिया के लिए धन्यवाद। यह बहुत ही सुखद संदेश है।
हालांकि मूल कारण बहुत स्पष्ट नहीं है, कम से कम हम आपदा से उबरने का एक तरीका खोज लेते हैं। :डी

हमारे पास k8s v1.14.3 के साथ एक ही समस्या है, और क्यूबलेट को पुनरारंभ करने से समस्या ठीक हो सकती है।

मुझे पता है कि यह मूर्खतापूर्ण है, लेकिन अस्थायी समाधान के रूप में काम करना चाहिए:

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 - docker pause nginx-proxy रैंचर वर्कर नोड पर क्यूबलेट एक ही त्रुटि संदेश उत्पन्न करता है।

उन लोगों के लिए अस्थायी समाधान जो VMWare vSphere पर K8S चला रहे हैं - K8S VMs के लिए DRS को

नई गोलांग http2 स्वास्थ्य जांच सुविधा का उपयोग करके समस्या के शमन के संबंध में हमारे पास कुछ बहुत अच्छी खबरें हैं: अब कोई समस्या नहीं है। अब तक, हमने प्रोमेथियस, संपूर्ण कुबेरनेट्स और कई आंतरिक घटकों में "फिक्स" (वेंडर किए गए x/net कोड में मूल्य की हार्डकोडेड सेटिंग) को लागू किया, यह देखते हुए:

• कोई प्रोमेथियस फेडरेशन अब और जारी नहीं करता है
• क्यूबलेट कभी-कभी अभी भी एकल "बंद कनेक्शन के उपयोग" घटनाओं की रिपोर्ट करता है, लेकिन सेकंड के भीतर ठीक हो जाता है (हम एक ~ 30 सेकंड http2 स्वास्थ्य जांच विंडो सेट करते हैं)
• कभी-कभी हमें kubectl घड़ियों के साथ समस्याएँ होती थीं -- पैच किए गए kubectl . का उपयोग करने पर भी चली जाती हैं
• हम अपने एकीकरण को नियमित रूप से सत्यापित करने के लिए एक विस्तारित E2E परीक्षण सूट चला रहे हैं, और छिटपुट परीक्षण समयबाह्य और चंचलता का अवलोकन किया है। अंदाज़ा लगाओ? अभी गया।

इसके अलावा, हम मुद्दों को ट्रिगर करने के तरीके के बारे में नई अंतर्दृष्टि प्राप्त करने में सक्षम हैं। मैं कुछ विश्वास के साथ लाइव माइग्रेशन के बारे में @ vi7 के अवलोकन की पुष्टि कर सकता हूं (हालांकि हम इसे नीचे ढूंढ सकते हैं), और कम से कम एनएसएक्स संस्करण के साथ हम लोड बैलेंसर परिवर्तन भी चला रहे हैं, ऐसे मुद्दों को ट्रिगर कर सकते हैं (हमारे पास वीएमवेयर के साथ टिकट है सुनिश्चित करें कि वे भविष्य में रीसेट पैकेट भेज रहे हैं)। और बहुत से अन्य कारणों के बीच में कनेक्शन छोड़ने की संभावना है, जैसे कनेक्शन टेबल ओवरफ्लो।

कुबेरनेट्स के कुछ उपयोगकर्ताओं के लिए यह एक बहुत ही कष्टप्रद और कुछ हद तक बड़ा मुद्दा है (IaaS परत/नेटवर्किंग के किसी प्रकार की "टूटने" के आधार पर, मुझे लगता है)। यद्यपि मूल्यों को ठीक से सेट करने के लिए एक इंटरफ़ेस को उजागर करने के बारे में गोलांग चर्चाएं हैं - क्या आपको लगता है कि पीआर मर्ज किए गए अपस्ट्रीम को प्रतिबिंब के माध्यम से उन मानों को सेट करने का कोई मौका है (अभी भी एक्स/नेट फोर्क करने से बेहतर है जैसे हम अभी करते हैं) ? हम कोड प्रदान करने के साथ ठीक हैं (और फिक्स को मान्य करते हुए, हम वास्तव में पुन: पेश नहीं कर सकते हैं, लेकिन यह पुष्टि करने में सक्षम होने के लिए अक्सर इसका निरीक्षण करें कि फिक्स काम करता है या नहीं)।

सीसी @liggitt

दीर्घकालिक मुद्दा (स्वयं को नोट)

@JensErat उत्तर के लिए धन्यवाद।
यदि हां, तो क्या यह समस्या k8s(1.13, 1.15, ..) के पुराने संस्करणों में भी हो सकती है?

मैं Kubernetes v1.16.13 के साथ समस्या देखने की पुष्टि कर सकता हूं
हमने कुबेरनेट्स v1.15.9 . के साथ समस्या नहीं देखी

जब मैं एक क्यूबनेट क्लस्टर v1.16.14 को etcd स्नैपशॉट बैकअप से पुनर्स्थापित करता हूं। यह त्रुटि क्यूबलेट लॉग में दिखाई देती है।
@ ik9999 को धन्यवाद। मैं क्यूबलेट को पुनरारंभ करता हूं तो त्रुटियां दूर हो जाती हैं

[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 पर एक ही मुद्दे से मिले, क्यूबलेट को फिर से शुरू करने से हल हो जाएगा। इसके लिए कोई स्थिर समाधान या यह कब तय किया जाएगा?

v1.18.6 वही

@rxwang662001
यह अपस्ट्रीम गोलांग समस्या के कारण होता है। एक बात निश्चित है कि यह 1.15 पर तय नहीं किया जाएगा।
इस बीच, कुबेरनेट्स समुदाय अभी भी 1.14 एलओएल जाने के लिए पलायन करने के लिए संघर्ष कर रहा है।

आम तौर पर, गो हर 6 महीने में रिलीज़ होती है। यदि सब कुछ ठीक से काम करता है, तो हो सकता है कि हम अगले वर्ष में इस मुद्दे को अपस्ट्रीम द्वारा हल करते हुए देख सकें, और शायद एक और वर्ष जब तक कुबेरनेट्स फिक्स !
(सिर्फ मजाक करने के लिए। यदि आप वास्तव में चाहते हैं कि यह अभी आप में ठीक हो जाए। स्वास्थ्य जांच को सक्षम करने के लिए h2Transport को हैक करें।

इस बीच, कुबेरनेट्स समुदाय अभी भी 1.14 एलओएल जाने के लिए पलायन करने के लिए संघर्ष कर रहा है।

वास्तव में, 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

अपना समाधान साझा करने के लिए धन्यवाद। क्या आप इस बारे में अधिक विवरण जोड़ सकते हैं कि आपने इसे कैसे काम किया?

अभी के लिए मैंने कोड को संशोधित करके http2: perform connection health check को golang/ net@0ba52f6 द्वारा पेश किया है जो डिफ़ॉल्ट रूप से सक्षम है।
यह इस समस्या में कुछ मददगार साबित होता है। लेकिन थोड़ा धीमा जवाब दिया।

आपने कौन से कोड परिवर्तन किए हैं? और कहाँ, किस फाइल में?

@कार्तिकरंगाराजू
h2Transport को प्रारंभ करते समय स्वास्थ्य जांच को सक्षम करने के लिए इस पीआर को देखें,
या आप रनटाइम पर निर्यात न किए गए फ़ील्ड तक पहुंचने के लिए कुछ प्रतिबिंब/असुरक्षित ऑफ़सेट हैक कर सकते हैं।

और, ऐसी चीजें करने से पहले गोलांग/एक्स/नेट को अपडेट करना न भूलें।

हम इस मुद्दे को पुन: पेश करने में सक्षम नहीं हैं, हालांकि हम समय-समय पर इसका सामना करते हैं।

चूंकि हम लक्षण के मूल कारण की पहचान करने में सक्षम नहीं हैं, हम लक्षण की परवाह किए बिना इसे ठीक कर रहे हैं।

हमारा समाधान:

• निम्नलिखित स्क्रिप्ट हर 1 घंटे में चलती है। यह क्यूब-एपीआई सर्वर से क्यूब कॉन्फ़िग फ़ाइल के माध्यम से कुबेक्टल के माध्यम से बात करता है
  क्यूबलेट उपयोग करता है (इस तरह कोई विशेषाधिकार वृद्धि नहीं है)।
• पूछता है कि क्या मास्टर नोड thinks इसका अपना नोड NotReady है। यदि हाँ, तो फ़ाइल पर touch कमांड चलाकर क्यूबलेट पुनरारंभ को ट्रिगर करता है
  फ़ाइल सिस्टम परिवर्तन के लिए kubelet-watcher.service द्वारा watched है और तदनुसार क्यूबलेट को पुनरारंभ करता है।

#!/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]#

कुबेरनेट्स 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)
इसमें अब त्रुटि संदेश में "(सोने के बाद पुनः प्रयास कर सकते हैं)" शामिल है।

क्या अपग्रेड गोलंग की प्रतीक्षा किए बिना इसे पूरी तरह से कुबेरनेट्स में कम करना संभव है? उदाहरण के लिए, क्या क्लाइंट-गो को परिवहन को स्वैप करने के लिए बनाया जा सकता है यदि यह "बंद नेटवर्क कनेक्शन का उपयोग" या कुछ और हिट करता है?

वैकल्पिक रूप से, क्या HTTP 1.1 का उपयोग करने पर भी यह समस्या उत्पन्न होगी, या यह विशुद्ध रूप से HTTP 2 से संबंधित है? यदि HTTP 1.1 प्रतिरक्षात्मक होगा और इसमें कोई बड़ा ड्रा बैक नहीं होगा, तो क्यूबलेट, क्यूब-प्रॉक्सी, और विभिन्न नियंत्रण-विमान प्रक्रियाओं पर GODEBUG=http2client=0 सेट करना या यहां तक ​​कि GODEBUG=http2server=0 परिवर्तन को सार्वभौमिक बनाने के लिए एपिसर्वर प्रक्रिया पर।

क्या हमें लगता है कि ये वास्तव में इस मुद्दे को कम कर देंगे और HTTP2 पर मल्टीप्लेक्सिंग नहीं होने पर कनेक्शन की संख्या में वृद्धि के कारण कुछ प्रदर्शन मुद्दों के अलावा अन्य प्रमुख नुकसान का कारण नहीं बनेंगे?

क्या क्लाइंट-गो परिवहन को स्वैप करने के लिए बनाया जा सकता है यदि यह "बंद नेटवर्क कनेक्शन का उपयोग" या कुछ हिट करता है?

बहुत शल्य चिकित्सा से नहीं... ट्रांसपोर्ट वर्तमान में साझा किए जाते हैं ताकि कॉल करने वालों के सामने क्षणिक बंदरगाह थकावट से बचा जा सके जो बार-बार नए ग्राहकों का निर्माण करते हैं

यदि HTTP 1.1 का उपयोग कर रहे हैं, या यह विशुद्ध रूप से HTTP 2 से संबंधित है, तो क्या यह समस्या अभी भी उत्पन्न होगी?

जहां तक ​​​​मुझे पता है, HTTP 1.1 एक ही समस्या का सामना कर सकता है क्योंकि निष्क्रिय कनेक्शन एक जीवित पूल में वापस जाते हैं (और इसका पता लगाने/कम करने के लिए कम विकल्प हैं क्योंकि पिंग स्वास्थ्य जांच तंत्र इसके लिए उपलब्ध नहीं है)

क्या क्लाइंट का उपयोग करने वाली परियोजनाओं के लिए कोई अच्छा समाधान है? हम कैसे पहचान सकते हैं कि ग्राहक कब मर गया है और इसे ठीक करने के लिए हमें न्यूनतम क्या करना होगा (ऐसा लगता है कि हमारी प्रक्रिया को फिर से शुरू करना ही एकमात्र विकल्प हो सकता है)?

हम कैसे पहचान सकते हैं कि ग्राहक कब मर गया है

जब आपको एक समान URL के लिए बार-बार write tcp xxx use of closed network connection त्रुटि मिलती है। यह इंगित करता है कि ग्राहक मर चुका है। ट्रांसपोर्ट के अंदर कनेक्शन पूल ने अनुरोधित होस्ट: पोर्ट के लिए एक मृत टीसीपी कनेक्शन कैश किया है।

क्या क्लाइंट का उपयोग करने वाली परियोजनाओं के लिए कोई अच्छा समाधान है?

जहां तक ​​​​मुझे पता है, http.Client पुन: निर्माण पूरे एप्लिकेशन को पुनरारंभ किए बिना इस समस्या को ठीक कर सकता है।

इसे ठीक करने के लिए हमें न्यूनतम क्या करना होगा?

इसके लिए प्रोजेक्ट के लिए सोर्स-कोड-लेवल एक्सेस की आवश्यकता होती है। हो सकता है कि आप मृत ग्राहक का पता लगाने के लिए ऊपर वर्णित तंत्र का उपयोग कर सकते हैं और जरूरत पड़ने पर एक नए ग्राहक का पुन: निर्माण कर सकते हैं। यदि कोई पुराने क्लाइंट का उपयोग नहीं कर रहा है, तो यह कचरा एकत्र किया जाएगा।

मेरे पास मेरे प्रोजेक्ट के लिए सोर्स कोड एक्सेस है, लेकिन हम कुबेरनेट्स क्लाइंट का उपयोग करते हैं। जब हम घड़ियाँ करते हैं, तो ऐसा लगता है कि यह कभी पता नहीं लगाता है कि क्या टीसीपी कनेक्शन इस तरह से टूट गया है (और चूंकि घड़ी HTTP लेनदेन को संभाल रही है, इसलिए हमारे कोड को संभालने के लिए कोई त्रुटि नहीं है)।

हां। आप सही हैं, कुबेरनेट्स क्लाइंट द्वारा http.Client का खुलासा नहीं किया गया है।
वर्तमान में शीर्ष स्तर के आवेदन के लिए कम लागत के साथ इस तरह के कामकाज करना निराशाजनक है।
यदि कुबेरनेट्स क्लाइंट http.DefaultClient उपयोग नहीं करता है, तो इसे पूरे कुबेरनेट्स क्लाइंट का पुन: निर्माण करके तय किया जा सकता है।

घड़ी अनुरोध के लिए, यह खराब हो रहा है। Kubernetes क्लाइंट फिर से प्रयास करने का अनुरोध करता है और ऊपरी एप्लिकेशन में कोई त्रुटि नहीं आती है। मुझे अब ऐसी स्थिति के बारे में कोई अच्छी जानकारी नहीं है।

यहां प्रस्तावित वर्कअराउंड कई हफ्तों से हमारे लिए काम कर रहा है। हमने इसे एक पायथन लिपि में बदल दिया जो हमारे सभी समूहों में एक डेमोंसेट के रूप में चलती है। हम आमतौर पर इसे सप्ताह में एक या दो बार कार्रवाई करते हुए देखते हैं (स्वचालित रूप से क्यूबलेट को पुनरारंभ करें) और परिणामस्वरूप हमारे क्लस्टर संचालन पर हमारा कोई नकारात्मक प्रभाव नहीं पड़ा है। हमने इसे परिवर्तनशील बना दिया है ताकि यह केवल 5 मिनट की अवधि में 2+ संदेशों को देखने पर क्यूबलेट को पुनरारंभ करे। हमने देखा कि कभी-कभी हम एक संदेश देख सकते थे, और यह कोई समस्या नहीं थी। जब समस्या होती है, तो आपको क्यूबलेट लॉग में लगातार use of closed network connection त्रुटि दिखाई देगी।

कृपया एक पुल अनुरोध बनाएं और हम इस विषय की जांच करेंगे।

एक बेयरमेटल क्लस्टर पर मैं देख रहा हूं कि यह हर 24 घंटे में लगभग 2-4 बार होता है। 1.17.12

यह तब होता है जब एपीआई-सर्वर पॉड पुनरारंभ होता है, यहां तक ​​​​कि सिंगल नोड क्लस्टर पर भी। एपिसर्वर से कनेक्शन खो गया है, इसलिए त्रुटि संख्या न्यूनतमकरण विधि समस्या को हल कर रही है कि एपिसर्वर पुनरारंभ क्यों हो रहा है।

मैं मास्टर नोड के सामने हैप्रोक्सी का उपयोग कर रहा हूं, क्या आपको लगता है कि कुछ एलबी कॉन्फ़िगरेशन के साथ इसे रोकने के लिए वैसे भी है?

@ shubb30 क्या आप मेरे साथ अपना समाधान साझा करना चाहते हैं?

मैं पुष्टि कर सकता हूं कि जब मैं समस्या का अनुभव करता हूं तो मेरे एपिसर्वर पुनरारंभ नहीं हो रहे हैं। मैं लॉग प्रविष्टि की निगरानी के लिए डेमोंसेट और शेल ट्रिक का उपयोग कर रहा हूं और फिर क्यूबलेट को फिर से शुरू कर रहा हूं, इसने काफी अच्छा काम किया है लेकिन मैं इसे केवल एक अस्थायी समाधान के रूप में देखता हूं।

वर्कअराउंड के रूप में हमारे लिए जो अच्छा काम कर रहा है, उसका एक संशोधित संस्करण यहां दिया गया है।

हे आप सभी!

क्या हम संभावित रूप से सोचते हैं कि यह बैकपोर्ट मदद कर सकता है?
https://github.com/golang/go/issues/40423

अच्छी खबर: गोलांग/नेट मास्टर के पास http2 ट्रांसपोर्ट को कॉन्फ़िगर करने के लिए समर्थन है, जो अब टाइमआउट सेट करने की अनुमति देता है! https://github.com/golang/net/commit/08b38378de702b893ee869b94b32f833e2933bd2

किया हुआ।
पीआर समीक्षा के लिए खोला गया।

एक और अच्छी खबर: कुबेरनेट्स मानक नेट/एचटीटीपी पैकेज में बंडल किए गए http2 का उपयोग नहीं करते हैं, इसलिए हमें अगले गो रिलीज की प्रतीक्षा करने की आवश्यकता नहीं है। हम इस समस्या को ठीक करने के लिए सीधे https://github.com/golang/net/commit/08b38378de702b893ee869b94b32f833e2933bd2 का उपयोग कर सकते हैं।

यहां एक फिक्स का प्रस्ताव दिया। https://github.com/kubernetes/kubernetes/pull/95898
यह आवश्यक संस्करण पर निर्भरता को अद्यतन करता है और डिफ़ॉल्ट रूप से http2 परिवहन स्वास्थ्य जांच को सक्षम करता है।
यह उन अनुप्रयोगों की मदद करनी चाहिए जो एपिसर्वर के साथ संवाद करने के लिए क्लाइंट-गो का उपयोग करते हैं (उदाहरण: क्यूबलेट) "ऐप हैंग एट राइट टीसीपी एक्सएक्सएक्स: क्लोज्ड कनेक्शन का उपयोग" समस्या से छुटकारा पाएं।

किसी भी टिप्पणी को छोड़ने के लिए स्वतंत्र महसूस करें।

ऐसा लगता है कि उल्लिखित #95898 उन कारणों से बंद हो गया जिनकी हमें चर्चा करने की आवश्यकता नहीं है।

क्या इस मुद्दे के संबंध में कोई अन्य अद्यतन है?

https://github.com/kubernetes/kubernetes/pull/95981 (ऊपर लिंक) http/2 फिक्स में खींचने के लिए प्रगति पर है

क्या यह समस्या कुबेरनेट्स के 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 शाखा जारी करने की कोई योजना है?

क्या #95981 से 1.17 रिलीज शाखा चुनने की कोई योजना है?

यह टिप्पणी पुराने रिलीज के बैकपोर्ट पर चर्चा करती है: https://github.com/kubernetes/kubernetes/pull/95981#issuecomment -730561539

मुझे लगता है कि उत्तर "यह कठिन है और चीजों को तोड़ सकता है इसलिए शायद नहीं"। किंडा वही जवाब जो मैं पूछे जाने पर v1.17 चलाने वाले लोगों से अपेक्षा करता हूं, तो ठीक करने के लिए v1.20 में अपग्रेड क्यों न करें? :हस रहा:

इसे कम से कम 1.19 पर बैकपोर्ट करना बहुत अच्छा होगा क्योंकि इससे फिक्स अपेक्षाकृत जल्द ही उपलब्ध हो जाएगा। मुझे संदेह है कि कुछ लोग डॉकर के बहिष्करण के कारण 1.20 पर रुकेंगे।

इसे कम से कम 1.19 पर बैकपोर्ट करना बहुत अच्छा होगा क्योंकि इससे फिक्स अपेक्षाकृत जल्द ही उपलब्ध हो जाएगा।

ऐसा पहले ही किया जा चुका है।

मुझे संदेह है कि कुछ लोग डॉकर के बहिष्करण के कारण 1.20 पर रुकेंगे।

1.20 में एक पदावन चेतावनी के अलावा डॉकटर के संबंध में कुछ भी नहीं बदला है। बहिष्करण अवधि के अंत में, डॉकशिम समर्थन हटा दिया जाएगा।

इन त्रुटियों को 1.20 पर एक रास्पियन 10 पर प्राप्त करना। इनमें से किसी के लिए एक फिक्स प्राप्त करने के साथ भी कोई कहां से शुरू होता है? ऐसा लगता है कि क्लाउड प्रबंधित क्लस्टर चलाने की लागत आपके अपने क्लस्टर पर चलाने की कोशिश करने से कहीं अधिक लागत प्रभावी है

मेरी अपनी स्पष्टता के लिए, ऐसा लगता है कि इसे #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 या पुराने संस्करणों में चेरी-पिक करने की योजना नहीं बना रहा हूं।