Kubernetes: [परीक्षण गुच्छे] मास्टर-स्केलेबिलिटी सुइट्स

• शुद्धता का कार्य अधिकतर समय-समय पर होने के कारण विफल हो रहा है (हमारे शेड्यूल को इसी प्रकार समायोजित करने की आवश्यकता है) क्योंकि ई 2 का एक समूह है जो हाल ही में सुइट में जोड़ा गया है (जैसे https://github.com/kubernetes/kubernetes/pull/59391)
• 100-नोड फ्लेक्स के लिए, हमारे पास https://github.com/kubernetes/kubernetes/issues/60500 है (और मेरा मानना ​​है कि यह संबंधित है .. जाँचने की आवश्यकता है)।
• प्रदर्शन की नौकरी के लिए, मेरा मानना ​​है कि एक प्रतिगमन है (पिछले कुछ रनों से ऐसा लगता है जैसे यह पॉड-स्टार्टअप लेटेंसी के आसपास है)। शायद sth और भी।

मैं इस सप्ताह के दौरान कुछ समय के लिए उन्हें प्राप्त करने की कोशिश करूँगा (मुक्त चक्र atm की कमी)।

@shyamjvs इस मुद्दे के लिए कोई अद्यतन है?

https://k8s-testgrid.appspot.com/sig-release-master-blocking#gce -scale-correctness

मैंने उस पर एक संक्षिप्त नज़र डाली। और या तो कुछ परीक्षण (एस) अति धीमी गति से कर रहे हैं या कुछ कुछ लटका हुआ है। पिछले रन से लॉग के बराबर:

62571 I0301 23:01:31.360] Mar  1 23:01:31.348: INFO: Running AfterSuite actions on all node
62572 I0301 23:01:31.360]
62573 W0302 07:32:00.441] 2018/03/02 07:32:00 process.go:191: Abort after 9h30m0s timeout during ./hack/ginkgo-e2e.sh --ginkgo.flakeAttempts=2 --ginkgo.skip=\[Serial\]|\[Disruptive      \]|\[Flaky\]|\[Feature:.+\]|\[DisabledForLargeClusters\] --allowed-not-ready-nodes=50 --node-schedulable-timeout=90m --minStartupPods=8 --gather-resource-usage=master --gathe      r-metrics-at-teardown=master --logexporter-gcs-path=gs://kubernetes-jenkins/logs/ci-kubernetes-e2e-gce-scale-correctness/80/artifacts --report-dir=/workspace/_artifacts --dis      able-log-dump=true --cluster-ip-range=10.64.0.0/11. Will terminate in another 15m
62574 W0302 07:32:00.445] SIGABRT: abort

8h30m के भीतर कोई परीक्षण समाप्त नहीं हुआ

https://k8s-testgrid.appspot.com/sig-release-master-blocking#gce -scale- प्रदर्शन

वास्तव में एक प्रतिगमन की तरह लगता है। मुझे लगता है कि प्रतिगमन रन के बीच कहीं हुआ:
105 (जो अभी भी ठीक था)
108 (जो दृष्टिगत रूप से उच्च स्टार्टअप समय था)

हम यह देखने के लिए kubemark-5000 में देखने का प्रयास कर सकते हैं कि क्या यह वहां भी दिखाई दे रहा है।

Kubmark-5000 बहुत स्थिर है। इस ग्राफ पर 99 वाँ प्रतिशत (शायद प्रतिगमन पहले भी हुआ था, लेकिन मुझे लगता है कि यह कहीं 105 और 108 के बीच है):

Corretness परीक्षणों के बारे में - gce-big-correctness भी विफल हो रहा है।
हो सकता है कि कुछ परीक्षण जो उस समय जोड़े गए हों, बहुत लंबा है?

@ Wojtek-t देखने के लिए बहुत बहुत धन्यवाद। Wrt performance job - मुझे भी दृढ़ता से महसूस होता है कि एक प्रतिगमन है (हालांकि मैं उन्हें ठीक से देख नहीं पाया)।

हो सकता है कि कुछ परीक्षण जो उस समय जोड़े गए हों, बहुत लंबा है?

मैं थोड़ी देर पहले यह देख रहा था। और 2 संदिग्ध बदलाव मुझे मिले:

• # 59391 - इसमें स्थानीय भंडारण के आसपास परीक्षणों का एक समूह जोड़ा गया (इस बदलाव के बाद रनआउट होना शुरू हुआ)
• पॉड एंटी-एफिनिटी वाले स्टेटफुलसेट को नोड्स में फैले वॉल्यूम का उपयोग करना चाहिए (यह परीक्षण 3.5 - 5hr के लिए चल रहा है) - https://k8s-gubernator.appspot.com/build/kubernetes-jenkins-logs/ci-kubernetes-e2e -gce पैमाने-शुद्धता / 79

cc @ kubernetes / sig-storage-बग्स

/ असाइन

कुछ स्थानीय संग्रहण परीक्षण क्लस्टर में प्रत्येक नोड का उपयोग करने की कोशिश करेंगे, यह सोचकर कि क्लस्टर आकार उतना बड़ा नहीं है। मैं अधिकतम नोड्स को कैप करने के लिए एक फिक्स जोड़ूंगा।

कुछ स्थानीय संग्रहण परीक्षण क्लस्टर में प्रत्येक नोड का उपयोग करने की कोशिश करेंगे, यह सोचकर कि क्लस्टर आकार उतना बड़ा नहीं है। मैं अधिकतम नोड्स को कैप करने के लिए एक फिक्स जोड़ूंगा।

धन्यवाद @ msau42 - यह बहुत अच्छा होगा।

Https://k8s-testgrid.appspot.com/sig-release-master-blocking#gce -scale- प्रदर्शन सूट पर वापस जाना

मैंने 105 तक के रन और 108 और उसके बाद रन बनाए।
पॉड स्टार्टअप समय के लिए सबसे बड़ा अंतर कदम पर दिखाई देता है:

10% worst watch latencies: 

[इसका नाम भ्रामक है - नीचे बताएंगे]

105 रन तक, यह आम तौर पर इस तरह दिखता था:

I0129 21:17:43.450] Jan 29 21:17:43.356: INFO: perc50: 1.041233793s, perc90: 1.685463015s, perc99: 2.350747103s

108 रन से शुरू, यह अधिक दिखता है:

Feb 12 10:08:57.123: INFO: perc50: 1.122693874s, perc90: 1.934670461s, perc99: 3.195883331s

मूल रूप से इसका मतलब है कि ~ 0.85 वृद्धि और यह मोटे तौर पर हम अंतिम परिणाम में देखते हैं।

अब - वह "वॉच लैग" क्या है।
यह मूल रूप से "क्यूबलेट ने देखा कि फली चल रही है" के बीच एक समय है जब परीक्षण "फली अद्यतन चलाने के लिए अपने राज्य की स्थापना" का अवलोकन किया।
वहाँ कुछ संभावना है जहाँ हम वापस पा सकते हैं:

• रिपोर्टिंग स्थिति में क्यूबलेट को धीमा कर दिया जाता है
• क्यूबलेट qps-starved है (और इस प्रकार रिपोर्टिंग स्थिति में धीमी है)
• एपसेवर धीमा है (उदाहरण के लिए सीपीयू-भूखा) और इस प्रकार प्रसंस्करण अनुरोध धीमा (या तो लिखो, देखो, या दोनों)
• परीक्षण सीपीयू-भुखमरी है और इस प्रकार आने वाली घटनाओं को धीमा कर देता है

चूँकि हम वास्तव में फली के "शेड्यूल -> स्टार्ट" के बीच अंतर नहीं मानते हैं, जो यह बताता है कि यह शायद सबसे अधिक क्षम्य नहीं है (क्योंकि प्रसंस्करण अनुरोध और घड़ी उस रास्ते पर भी है), और यह शायद सबसे धीमा क्यूबलेट नहीं है भी (क्योंकि यह फली शुरू होता है)।

इसलिए मुझे लगता है कि सबसे अधिक संभावना परिकल्पना है:

• क्यूबलेट qps-starved (या sth है जो इसे जल्दी से स्टेटस अपडेट भेजने से रोकता है)
• परीक्षण सीपीयू-तारांकित (या उस तरह sth) है

टेस्ट उस समय बिल्कुल नहीं बदला। इसलिए मुझे लगता है कि यह शायद सबसे पहला है।

उस ने कहा, मैं 105 और 108 रन के बीच विलय किए गए पीआर के माध्यम से चला गया और अब तक कुछ भी उपयोगी नहीं पाया।

मुझे लगता है कि अगला कदम यह है:

• सबसे धीमी पॉड्स में देखें (सबसे धीमी गति के बीच भी O (1s) अंतर प्रतीत होता है) और देखें कि क्या अपडेट स्टेटस रिक्वेस्ट भेजे जाने के बाद अंतर "के" पहले "है"

इसलिए मैंने उदाहरण पॉड्स में देखा। और मैं यह पहले से ही देख रहा हूँ:

I0209 10:01:19.960823       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-16-5pl6z/pods/density-latency-pod-3115-fh7hl/status: (1.615907ms) 200 [[kubelet/v1.10.0 (l    inux/amd64) kubernetes/05944b1] 35.196.200.5:37414]
...
I0209 10:01:22.464046       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-16-5pl6z/pods/density-latency-pod-3115-fh7hl/status: (279.153µs) 429 [[kubelet/v1.10.0 (li    nux/amd64) kubernetes/05944b1] 35.196.200.5:37414]
I0209 10:01:23.468353       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-16-5pl6z/pods/density-latency-pod-3115-fh7hl/status: (218.216µs) 429 [[kubelet/v1.10.0 (li    nux/amd64) kubernetes/05944b1] 35.196.200.5:37414]
I0209 10:01:24.470944       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-16-5pl6z/pods/density-latency-pod-3115-fh7hl/status: (1.42987ms) 200 [[kubelet/v1.10.0 (li    nux/amd64) kubernetes/05944b1] 35.196.200.5:37414]

I0209 09:57:01.559125       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-35-gjzmd/pods/density-latency-pod-2034-t7c7h/status: (1.836423ms) 200 [[kubelet/v1.10.0 (l    inux/amd64) kubernetes/05944b1] 35.229.43.12:37782]
...
I0209 09:57:04.452830       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-35-gjzmd/pods/density-latency-pod-2034-t7c7h/status: (231.2µs) 429 [[kubelet/v1.10.0 (linu    x/amd64) kubernetes/05944b1] 35.229.43.12:37782]
I0209 09:57:05.454274       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-35-gjzmd/pods/density-latency-pod-2034-t7c7h/status: (213.872µs) 429 [[kubelet/v1.10.0 (li    nux/amd64) kubernetes/05944b1] 35.229.43.12:37782]
I0209 09:57:06.458831       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-35-gjzmd/pods/density-latency-pod-2034-t7c7h/status: (2.13295ms) 200 [[kubelet/v1.10.0 (li    nux/amd64) kubernetes/05944b1] 35.229.43.12:37782]

I0209 10:01:53.063575       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-5-6w4kv/pods/density-latency-pod-3254-586j7/status: (1.410064ms) 200 [[kubelet/v1.10.0 (li    nux/amd64) kubernetes/05944b1] 35.196.212.60:3391
...
I0209 10:01:55.259949       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-5-6w4kv/pods/density-latency-pod-3254-586j7/status: (10.4894ms) 429 [[kubelet/v1.10.0 (lin    ux/amd64) kubernetes/05944b1] 35.196.212.60:33916]
I0209 10:01:56.266377       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-5-6w4kv/pods/density-latency-pod-3254-586j7/status: (233.931µs) 429 [[kubelet/v1.10.0 (lin    ux/amd64) kubernetes/05944b1] 35.196.212.60:33916]
I0209 10:01:57.269427       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-5-6w4kv/pods/density-latency-pod-3254-586j7/status: (182.035µs) 429 [[kubelet/v1.10.0 (lin    ux/amd64) kubernetes/05944b1] 35.196.212.60:33916]
I0209 10:01:58.290456       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-5-6w4kv/pods/density-latency-pod-3254-586j7/status: (13.44863ms) 200 [[kubelet/v1.10.0 (li    nux/amd64) kubernetes/05944b1] 35.196.212.60:33916]

इसलिए यह स्पष्ट है कि समस्या "429" से संबंधित है।

क्या स्वामी के खाते में कोटा होने के कारण वे थ्रॉटल एपीआई कॉल हैं?

क्या स्वामी के खाते में कोटा होने के कारण वे थ्रॉटल एपीआई कॉल हैं?

जैसा कि मैंने शुरू में सोचा था कि यह थ्रॉटलिंग नहीं है। ये एफ़िसर पर 429 हैं (कारण किसी कारण से या तो धीमी एफ़िसर्वर हो सकता है, या एफ़ीसर पर आने वाले अधिक अनुरोध)।

ओह ठीक। यह बहुत अच्छी खबर नहीं है।

/ मील का पत्थर स्पष्ट

/ मील का पत्थर v1.10

/ मील का पत्थर स्पष्ट

@cjwagner : आप मील का पत्थर स्थापित करने के लिए kubernetes-milestone-maintainers github टीम के सदस्य होने चाहिए।

/ मील का पत्थर v1.9

@cjwagner : आप मील का पत्थर स्थापित करने के लिए kubernetes-milestone-maintainers github टीम के सदस्य होने चाहिए।

लगता है जैसे पीआर https://github.com/kubernetes/kubernetes/pull/60740 ने टाइमआउट मुद्दों को तय किया - त्वरित प्रतिक्रिया के लिए धन्यवाद @ msau42 ।
हमारी शुद्धता नौकरियां (2k और 5k दोनों) अब वापस हरे रंग की हैं:

• https://k8s-testgrid.appspot.com/sig-scalability-gce#gce -large-correctness
• https://k8s-testgrid.appspot.com/sig-scalability-gce#gce -scale-correctness

तो उन वॉल्यूम परीक्षणों के बारे में मेरा संदेह वास्तव में सही था :)

एसीके। चालू
ETA: 9/3/2018
जोखिम: k8s प्रदर्शन पर संभावित प्रभाव

इसलिए मैंने इसमें थोड़ा सा खुदाई की और हमारे 5k-नोड परीक्षण के लिए पॉड-स्टार्टअप लेटेंसी के ग्राफ से, मुझे लगता है कि प्रतिगमन b / w में 108 और 109 रन हो सकता है (99% ile देखें):

मैं अंतर के माध्यम से जल्दी से बह गया और निम्नलिखित परिवर्तन मुझे संदेहास्पद लगता है:

"सभी तरह से नीचे NewRequest से अनुरोध-टाइमआउट पारित करने की अनुमति दें" # 51042

PR, API कॉल के क्वेरी पैरामीटर के रूप में क्लाइंट के टाइमआउट के प्रसार को सक्षम कर रहा है। और मैं वास्तव में उन 2 रनों में (अपीज़र लॉग्स से) PATCH node/status कॉल्स में निम्नलिखित अंतर देखता हूँ:

रन-108:

I0207 22:01:06.450385       1 wrap.go:42] PATCH /api/v1/nodes/gce-scale-cluster-minion-group-1-2rn2/status: (11.81392ms) 200 [[kubelet/v1.10.0 (linux/amd64) kubernetes/11104d7] 35.227.96.23:47270]
I0207 22:01:03.857892       1 wrap.go:42] PATCH /api/v1/nodes/gce-scale-cluster-minion-group-3-9659/status: (8.570809ms) 200 [[kubelet/v1.10.0 (linux/amd64) kubernetes/11104d7] 35.196.85.108:43532]
I0207 22:01:03.857972       1 wrap.go:42] PATCH /api/v1/nodes/gce-scale-cluster-minion-group-3-wc4w/status: (8.287643ms) 200 [[kubelet/v1.10.0 (linux/amd64) kubernetes/11104d7] 35.229.110.22:50530]

रन-109:

I0209 21:01:08.551289       1 wrap.go:42] PATCH /api/v1/nodes/gce-scale-cluster-minion-group-2-89f2/status?timeout=10s: (71.351634ms) 200 [[kubelet/v1.10.0 (linux/amd64) kubernetes/05944b1] 35.229.77.215:51070]
I0209 21:01:08.551310       1 wrap.go:42] PATCH /api/v1/nodes/gce-scale-cluster-minion-group-2-3ms3/status?timeout=10s: (70.705466ms) 200 [[kubelet/v1.10.0 (linux/amd64) kubernetes/05944b1] 35.227.84.87:49936]
I0209 21:01:08.551394       1 wrap.go:42] PATCH /api/v1/nodes/gce-scale-cluster-minion-group-3-wc02/status?timeout=10s: (70.847605ms) 200 [[kubelet/v1.10.0 (linux/amd64) kubernetes/05944b1] 35.196.125.143:53662]

मेरी परिकल्पना यह है कि, PATCH कॉल के लिए 10s के टाइमआउट को जोड़ने के कारण, वे कॉल अब सर्वर-साइड पर लंबे समय तक चल रहे हैं (IIUC इस टिप्पणी को सही ढंग से)। इसका मतलब है कि वे अब लंबी अवधि के लिए इनफ्लाइट-कतार में हैं। इस तथ्य के साथ, कि इस तरह के बड़े समूहों में बड़ी मात्रा में PATCH कॉल होती हैं, जो PUT pod/status कॉल के लिए अग्रणी है, जो कि इनफ्लो-कतार में पर्याप्त बैंडविड्थ प्राप्त करने में असमर्थ हैं और इसलिए 429s के साथ वापस आ गए हैं। परिणामस्वरूप, पॉड-स्टेटस को अपडेट करने में क्यूबलेट-साइड देरी बढ़ गई है। यह कहानी ऊपर @ wojtek-t की टिप्पणियों के साथ अच्छी तरह से फिट बैठती है।

मैं इस परिकल्पना को सत्यापित करने के लिए और अधिक सबूत इकट्ठा करने की कोशिश करूंगा।

इसलिए मैंने जाँच की कि टेस्ट रन के दौरान PATCH node-status विलंबताएँ कैसे बदलती हैं, और यह वास्तव में ऐसा लगता है कि उस समय के आसपास 99 वाँ प्रतिशत (शीर्ष रेखा देखें) में वृद्धि हुई है। हालाँकि यह स्पष्ट नहीं है कि यह हुआ b / w 108 और 109 रन (हालांकि मेरा मानना ​​है कि ऐसा ही है)

[संपादित करें: मेरी पूर्व टिप्पणी में उन 429s के लिए गलत उल्लेख किया गया था (ग्राहक एनपीडी था, क्यूबलेट नहीं)]

मेरे पास अब अधिक सहायक साक्ष्य हैं:

रन -108 में , हमारे पास ~ 479k PATCH node/status कॉल थे जिन्हें 429 मिला:

{
        "metric": {
          "__name__": "apiserver_request_count",
          "client": "kubelet/v1.10.0 (linux/amd64) kubernetes/11104d7",
          "code": "429",
          "contentType": "resource",
          "resource": "nodes",
          "scope": "",
          "subresource": "status",
          "verb": "PATCH"
        },
        "value": [
          0,
          "479181"
        ]
      },

और रन-109 में , हमारे पास ~ 757k है:

{
        "metric": {
          "__name__": "apiserver_request_count",
          "client": "kubelet/v1.10.0 (linux/amd64) kubernetes/05944b1",
          "code": "429",
          "contentType": "resource",
          "resource": "nodes",
          "scope": "",
          "subresource": "status",
          "verb": "PATCH"
        },
        "value": [
          0,
          "757318"
        ]
      },

और ... यह देखो:

रन -108 में:

{
        "metric": {
          "__name__": "apiserver_request_count",
          "client": "kubelet/v1.10.0 (linux/amd64) kubernetes/11104d7",
          "code": "429",
          "contentType": "namespace",
          "resource": "pods",
          "scope": "",
          "subresource": "status",
          "verb": "UPDATE"
        },
        "value": [
          0,
          "28594"
        ]
      },

और रन 109 में:

{
        "metric": {
          "__name__": "apiserver_request_count",
          "client": "kubelet/v1.10.0 (linux/amd64) kubernetes/05944b1",
          "code": "429",
          "contentType": "namespace",
          "resource": "pods",
          "scope": "",
          "subresource": "status",
          "verb": "UPDATE"
        },
        "value": [
          0,
          "33224"
        ]
      },

मैंने कुछ अन्य आसन्न रन के लिए संख्या की जाँच की:

• रन-104 के लिए यह 21187 है
• रन -105 के लिए यह 22003 है
• रन -108 के लिए यह 28594 है

- कि पीआर विलय कर दिया -

• रन-109 के लिए यह 33224 है
• रन -110 के लिए यह 30977 है
• रन -१११ के लिए यह १५६१५ है

जबकि यह थोड़ा अलग लगता है, कुल मिलाकर यह नहीं की तरह दिखता है। 429 के बारे में 25% की वृद्धि हुई।

और PATCH node-status क्यूबलेट्स से आ रहा है जो 429 से प्राप्त किया गया है, यहां बताया गया है कि नंबर कैसे दिखते हैं:

• रन-104 = 313348
• रन -१०५ = ३० ९ १३६
• रन -१० = ४ 108 ९ १1१

- कि पीआर विलय कर दिया -

• रन- 109 = 757318
• रन -११० = -५२०६२
• रन -१११ = २ ९ ६३६।

यह भी अलग-अलग है, लेकिन आम तौर पर यह बढ़ रहा है।

99%% ile PATCH node-status कॉल विलंबता भी आम तौर पर बढ़ी हुई लगती है (जैसा कि मैं https://github.com/kubernetes/kubernetes/issues/60589#issuecament-370573938 पर भविष्यवाणी कर रहा था):

run-104 (798ms), run-105 (783ms), run-108 (826ms)

run-109 (878ms), run-110 (869ms), run-111 (806ms)

Btw - उपरोक्त सभी मेट्रिक्स को लिखता है, 108 एक सामान्य से बेहतर रन लगता है और 111 एक बेहतर-से-सामान्य रन लगता है।

मैं एक बड़े 5k क्लस्टर को मैन्युअल रूप से चलाकर कल इसे सत्यापित करने का प्रयास करूंगा।

thanks for triage @shyamjvs

इसलिए मैंने ~ HEAD के खिलाफ 5k क्लस्टर के खिलाफ दो बार घनत्व परीक्षण किया, और परीक्षण आश्चर्यजनक रूप से 4.510015461s और 4.623276837s रूप में 99% ile pod स्टार्टअप विलंबता के साथ दोनों बार पारित हुआ। हालाँकि, 'वॉच लेटेंसीज़' ने, यह दिखाया कि @ wojtek-t ने https://github.com/kubernetes/kubernetes/issues/60589#issuecomment -369951288 पर बताया

पहले भाग में यह था:

INFO: perc50: 1.123056294s, perc90: 1.932503347s, perc99: 3.061238209s

और दूसरा रन था:

INFO: perc50: 1.121218293s, perc90: 1.996638787s, perc99: 3.137325187s

अब मैं जाँच करूँगा कि पहले क्या मामला था।

https://github.com/kubernetes/kubernetes/issues/60589#issuecomment -+३७,०५,७३,९३८ - मैं नहीं यकीन है कि मैं इस हाँ अनुसरण कर रहा हूँ कर रहा हूँ - हम समय समाप्ति जोड़ा है, लेकिन डिफ़ॉल्ट टाइमआउट IIRC 10s से भी बड़ा है - तो यह केवल मदद करनी चाहिए चीजों को बदतर मत बनाओ।

मुझे लगता है कि हम अभी भी यह नहीं समझ पाए हैं कि हम 429 से अधिक क्यों देखते हैं (तथ्य यह है कि यह किसी भी तरह 429 से संबंधित है जिसका मैंने पहले से ही उल्लेख किया है https://github.com/kubernetes/kubernetes/issues/60589#issuecommentment-370036377)

और आपकी संख्या के बारे में - मुझे यकीन नहीं है कि प्रतिगमन 109 चल रहा था - हो सकता है कि दो प्रतिगमन थे - एक 105 और 108 के बीच और दूसरा 109 में।

हम्म ... मैं आपके द्वारा बताई गई संभावनाओं से इनकार नहीं करता (ऊपर सिर्फ मेरी परिकल्पना थी)।
मैं वर्तमान में सत्यापित करने के लिए द्विभाजन (अभी 108 की प्रतिबद्ध के खिलाफ) कर रहा हूं।

मेरा मानना ​​है कि 108 चलने से पहले प्रतिगमन अधिक मजबूत और मजबूत है।
एक उदाहरण के रूप में, एपीआई कॉल की विलंबता पहले से 108 रन में बढ़ जाती है।

पैच नोड स्थिति:
90%: 198ms (105) 447ms (108) 444ms (109)

फली स्थिति:
99%: 83ms (105) 657ms (108) 728ms (109)

मुझे लगता है कि मैं जो कहना चाह रहा हूं वह है:

• 429 की संख्या एक परिणाम है और हमें उस पर बहुत अधिक समय नहीं बिताना चाहिए
• मूल कारण या तो धीमी आपी कॉल या उन की बड़ी संख्या है

हम स्पष्ट रूप से 108 में धीमी एपीआई कॉल को देख रहे हैं। सवाल यह है कि क्या हम बड़ी संख्या में भी देखते हैं।

इसलिए मुझे लगता है कि अनुरोध क्यों धीमी गति से हो रहे हैं - तीन मुख्य संभावनाएं हैं

1. बहुत अधिक अनुरोध हैं (पहली नज़र से ऐसा नहीं लगता है)

2. हमने प्रसंस्करण के पथ पर कुछ जोड़ा (जैसे अतिरिक्त प्रसंस्करण) या ऑब्जेक्ट स्वयं बड़े हैं

3. मास्टर मशीन पर कुछ और (जैसे शेड्यूलर) अधिक सीपीयू का उपभोग कर रहा है और इस प्रकार एपेस्वर को अधिक भूखा कर रहा है

इसलिए मैंने और @ wojtek-t ने ऑफलाइन चर्चा की और हम दोनों अब सहमत हैं कि 108 से पहले काफी संभावना है। कुछ बिंदुओं को जोड़ना:

बहुत अधिक अनुरोध हैं (पहली नज़र से ऐसा नहीं लगता है)

मेरे लिए न तो मामला प्रतीत होता है

हमने प्रसंस्करण के पथ पर कुछ जोड़ा (जैसे अतिरिक्त प्रसंस्करण) या ऑब्जेक्ट स्वयं बड़े हैं

मेरी भावना यह क्यूबलेट में एपीसर्वर के विपरीत होने की अधिक संभावना है (क्योंकि हम पैच में कोई दृश्य परिवर्तन नहीं देख रहे हैं / कुबार्क -5000 पर विलंबता डालते हैं)

मास्टर मशीन पर कुछ और (जैसे शेड्यूलर) अधिक सीपीयू का उपभोग कर रहा है और इस प्रकार एपेस्वर को अधिक भूखा कर रहा है

IMO यह मामला नहीं है क्योंकि हम अपने मास्टर पर काफी कुछ सीपीयू / मेम सुस्त कर रहे हैं। मास्टर घटकों के usages में पर-डैश किसी भी काफी वृद्धि का सुझाव नहीं देता है।

उस ने कहा, मैंने थोड़ी खुदाई की और "सौभाग्य से" ऐसा लगता है जैसे हम घड़ी की विलंबता में इस वृद्धि को 2k-नोड क्लस्टर के लिए भी देख रहे हैं:

INFO: perc50: 1.024377533s, perc90: 1.589770858s, perc99: 1.934099611s

INFO: perc50: 1.03503718s, perc90: 1.624451701s, perc99: 2.348645755s

बाइसेक्टिंग को थोड़ा आसान बनाना चाहिए।

दुर्भाग्य से, उन घड़ी की विलंबता में भिन्नता एक-बंद की तरह लगती है (यह अन्यथा लगभग समान है)। सौभाग्य से, हमारे पास प्रतिगमन के एक विश्वसनीय संकेतक के रूप में PUT pod-status विलंबता है। मैंने कल द्विशताब्दी के 2 राउंड चलाए और इस अंतर को कम कर दिया (~ 80 कमिट्स)। मैंने उनके माध्यम से स्किम किया और उस पर संदेह किया:

• # 58990 - पॉड-स्टेटस में एक नया क्षेत्र जोड़ता है (हालांकि मुझे यकीन नहीं है कि हमारे परीक्षणों में भरा जाएगा, जहां IIUC पूर्वनिर्धारण नहीं हो रहे हैं - लेकिन जांच की आवश्यकता है)
• # 58645 - अपडेट वर्जन सर्वर संस्करण 3.2.14 पर

मुझे वास्तव में संदेह है कि # 58990 यहां से संबंधित है - नॉमिनेटेडनाम एक स्ट्रिंग है जिसमें एक नोड नाम होता है। यहां तक ​​कि अगर यह हर समय भरा होगा, तो वस्तु आकार में परिवर्तन नगण्य होना चाहिए।

@ wojtek-t - जैसा कि आप ऑफ़लाइन सुझाव दे रहे थे, यह वास्तव में ऐसा लगता है जैसे हम kub एन्क्रिप्शन में एक अलग संस्करण (3.2.16) का उपयोग कर रहे हैं (https://github.com/kubernetes/kubernetes/blob/master//estest/kubemark/ start-kubemark.sh # L62) जो इस प्रतिगमन को वहां न देखने का संभावित कारण है :)

cc @jpbetz

हम अब हर जगह 3.2.16 का उपयोग कर रहे हैं।

उफ़ .. हर्ष के लिए क्षमा करें - मैं कमिट्स के गलत संयोजन को देख रहा था।

BTW - कि PUT फली / स्थिति विलंबता में वृद्धि बड़े वास्तविक समूहों में लोड परीक्षण में भी दिखाई देती है।

इसलिए मैंने थोड़ा और खुदाई की और ऐसा लगता है जैसे हमने उस समय के आसपास की अधिक से अधिक विलंबता को सामान्य रूप से लिखने के लिए अनुरोध करना शुरू कर दिया है (जिससे मुझे संदेह है कि और अधिक परिवर्तन हो सकता है):

वास्तव में, मैं वोट देता हूं कि कम से कम समस्या यहाँ है:
https://github.com/kubernetes/kubernetes/pull/58990/commits/384a86caa92bdb7cf9ac96b10a6ef333d2d60519#fiff -c73f80ad83608f18657d22a06950d929R2402

मुझे आश्चर्य होगा कि यह पूरी समस्या होगी, लेकिन इसमें योगदान हो सकता है।
एक पल में एक पीआर बदल रहा है कि भेज देंगे।

FYI करें - जब मैं एक प्रतिबद्ध के खिलाफ दौड़ा, जो कि 3.2d4 परिवर्तन से पहले है, लेकिन पॉड-स्टेटस API परिवर्तन के बाद, पुट-स्थिति स्थिति विलंबता पूरी तरह से ठीक लगती है (यानी 99% ile = 39ms)।

इसलिए मैंने यह सत्यापित किया कि यह वास्तव में 3.2.14 से एन्सड बम्प के कारण है। यहां बताया गया है कि पॉड-स्टेट लेटेंसी कैसे दिखती है:

उस पीआर के खिलाफ:

{
      "data": {
        "Perc50": 1.479,
        "Perc90": 10.959,
        "Perc99": 163.095
      },
      "unit": "ms",
      "labels": {
        "Count": "344494",
        "Resource": "pods",
        "Scope": "namespace",
        "Subresource": "status",
        "Verb": "PUT"
      }
    },

~ HEAD के खिलाफ (मार्च 5 से) उस PR के साथ उल्टा (परीक्षण अभी भी चल रहा है, लेकिन जल्द ही समाप्त होने वाला है):

apiserver_request_latencies_summary{resource="pods",scope="namespace",subresource="status",verb="PUT",quantile="0.5"} 1669
apiserver_request_latencies_summary{resource="pods",scope="namespace",subresource="status",verb="PUT",quantile="0.9"} 9597
apiserver_request_latencies_summary{resource="pods",scope="namespace",subresource="status",verb="PUT",quantile="0.99"} 63392

63ms पहले जैसा था उससे काफी मिलता-जुलता लगता है।

हमें संस्करण को वापस करना चाहिए और समझने की कोशिश करनी चाहिए:

• हम इस वृद्धि को 3.2.14 में क्यों देख रहे हैं?
• क्यूबमार्क में हमने इसे क्यों नहीं पकड़ा?

cc @jpbetz @ kubernetes / sig-api-मशीनरी-बग

एक परिकल्पना (हम क्यूबमार्क में इसे क्यों नहीं पकड़ पाए - हालांकि यह अभी भी एक अनुमान है) यह है कि हमने वहां sth wrt को प्रमाणपत्र में बदल दिया है।
जब मैं kub एन्क्रिप्शन और वास्तविक क्लस्टर से etcd लॉग की तुलना कर रहा हूं, केवल बाद में मैं निम्नलिखित पंक्ति देख रहा हूं:

2018-03-05 08:06:56.389648 I | embed: peerTLS: cert = /etc/srv/kubernetes/etcd-peer.crt, key = /etc/srv/kubernetes/etcd-peer.key, ca = , trusted-ca = /etc/srv/kubernetes/etcd-ca.crt, client-cert-auth = true

पीआर में ही मुझे अपने आस-पास कोई बदलाव नहीं दिखता है, लेकिन मुझे यह भी नहीं पता कि हमें उस लाइन को केवल वास्तविक समूहों में क्यों देखना चाहिए ...
@jpbetz विचारों के लिए

एसीके। चालू
ETA: 9/3/2018
जोखिम: मुद्दा मूल कारण (ज्यादातर)

Re peTTLS - ऐसा लगता है कि पहले भी (3.1.11 के साथ) ऐसा था, इसलिए मुझे लगता है कि यह एक लाल हेरिंग है

cc @gyuho @wenjiaswe

63ms काफी हद तक समान लगता है

हमें वे नंबर कहां से मिले? क्या apiserver_request_latencies_summary वास्तव में वगैरह की विलंबताएं लिखता है? इसके अलावा, etcd से मैट्रिक्स मदद मिलेगी।

एम्बेड करें: peerTLS: cert ...

यह प्रिंट करता है, अगर सहकर्मी टीएलएस कॉन्फ़िगर किया गया है (3.1 में समान)।

हमें वे नंबर कहां से मिले? क्या apiserver_request_latencies_summary वास्तव में वगैरह के विलंब को मापता है? इसके अलावा, etcd से मैट्रिक्स मदद मिलेगी।

यह उदासी के विलंब को मापता है जो (कम से कम लिखने के मामले में) आदि की विलंबता शामिल है।
हम अभी भी वास्तव में यह नहीं समझ पा रहे हैं कि क्या हो रहा है, लेकिन पिछले etcd संस्करण (3.1) में वापस आने से प्रतिगमन ठीक हो जाता है। तो स्पष्ट रूप से समस्या कहीं न कहीं आदि में है।

@shyamjvs

कुबार्क और कुबेरनेट संस्करण क्या चल रहे हैं? हमने वगैरह 3.2 बनाम 3.3 (500-नोड वर्कलोड) के खिलाफ कुबार्क 1.10 का परीक्षण किया, और इसका निरीक्षण नहीं किया। इसे पुन: उत्पन्न करने के लिए कितने नोड्स की आवश्यकता होती है?

कुबार्क और कुबेरनेट संस्करण क्या चल रहे हैं? हमने वगैरह 3.2 बनाम 3.3 (500-नोड वर्कलोड) के खिलाफ कुबार्क 1.10 का परीक्षण किया, और इसका निरीक्षण नहीं किया। इसे पुन: उत्पन्न करने के लिए कितने नोड्स की आवश्यकता होती है?

हम इसे 5k- नोड एक के साथ भी kubmark के साथ पुन: उत्पन्न नहीं कर सकते हैं - https://github.com/kubernetes/kubernetes/issues/60589#issuecomment -371171837 के नीचे देखें

यह केवल वास्तविक समूहों में एक समस्या प्रतीत होती है।
यह एक खुला सवाल है कि ऐसा क्यों है।

जब से हम वापस 3.1 करने के लिए लुढ़का हुआ है 3.1। kubernetes के लिए। हम भी जारी किया etcd 3.1.12 Kubernetes के लिए केवल बकाया महत्वपूर्ण फिक्स के साथ: MVCC "समन्वयन नहीं होगा" द्रष्टा पुनर्स्थापना कार्यवाही की । एक बार जब हमने पाया है और इस मामले में पाए गए प्रदर्शन प्रतिगमन का मूल कारण तय किया है तो हम kubernetes द्वारा उपयोग किए जाने वाले etcd सर्वर को 3.2 तक वापस अपग्रेड करने की योजना को स्केच कर सकते हैं।

ऐसा लगता है कि https://k8s-testgrid.appspot.com/sig-release-master-blocking#gci -gce-100 आज सुबह से लगातार असफल होने लगा

अंतर से , एकमात्र परिवर्तन https://github.com/kubernetes/kubernetes/pull/60421 है जो डिफ़ॉल्ट रूप से हमारे प्रदर्शन परीक्षणों में कोटा सक्षम कर रहा है। त्रुटि हम देख रहे हैं:

Container kube-controller-manager-e2e-big-master/kube-controller-manager is using 0.531144723/0.5 CPU
not to have occurred

@gmarek - सक्रिय करने के लिए कोटा की तरह लगता है हमारे scalability प्रभावित कर रहा है :) आप इस बारे में और अधिक कर सकते हैं - हो सकता है sth गंभीर?
मुझे इस पर नज़र रखने के लिए एक और मुद्दा दर्ज करें।

@ Wojtek-टी @jpbetz @gyuho @timothysc मैं वास्तव में कुछ etcd संस्करण परिवर्तन के साथ दिलचस्प पाया, etcd 3.1.11 से 3.2.16 में जाने की महत्वपूर्ण प्रभाव का सुझाव दे।

हमारे 100-नोड क्लस्टर (आदि में ~ 2x की वृद्धि हुई है) में जब आप नौकरी के लिए k8s रिलीज 1.9 से 1.10 पर चले गए, तो आदि मेमोरी मेमोरी के निम्न ग्राफ को देखें:

और अगली बार देखें कि हमारी 100-नोड वाली नौकरी (HEAD के खिलाफ चल रही है) याद है कि याददाश्त के उपयोग में गिरावट आई है।

तो etc 3.2 सर्वर संस्करण CLEARLY प्रभावित प्रदर्शन दिखा रहा है (अन्य सभी समान चर के साथ) :)

3.2.16 से मेरा रिवर्ट -> 3.2.11:

क्या हमारा मतलब 3.1.11 था?

यह सही है .. क्षमा करें। मेरी टिप्पणी का संपादन किया।

@shyamjvs को कैसे कॉन्फ़िगर किया जाता है? हमने v3.2 में डिफ़ॉल्ट मूल्य --snapshot-count 10000 100000 --snapshot-count बढ़ा दिया है। इसलिए यदि स्नैपशॉट की गिनती अलग है, तो बड़े स्नैपशॉट के साथ वाला अधिक समय तक रफ प्रविष्टियां रखता है, इसलिए पुराने लॉग्स को छोड़ने से पहले अधिक निवासी मेमोरी की आवश्यकता होती है।

आह! यह वास्तव में एक संदिग्ध परिवर्तन की तरह लगता है। राइट फ्लैग, मुझे नहीं लगता कि k8s की तरफ से उन में कोई बदलाव आया है। क्योंकि, जैसा कि आप ऊपर दिए गए मेरे दूसरे ग्राफ में देख सकते हैं, अंतर b / w 11450 चलता है और 11451 मुख्य रूप से सिर्फ मेरा वेंडर रिवर्ट चेंज है (जो किसी भी झंडे को छूने के लिए प्रतीत नहीं होता है)।

हमने डिफ़ॉल्ट मान - ssapshot-काउंट को 10000 से बढ़ाकर 100000 कर दिया है

क्या आप इस बात की पुष्टि कर सकते हैं कि इस बढ़ते हुए उपयोग के मूल कारण क्या हैं? यदि हां, तो हम चाहते हैं:

• पैच वैल्यू वापस मूल मूल्य के साथ, या
• k8s में इसे 10000 पर सेट करें

3.2 पर वापस जाने से पहले

आह! यह वास्तव में एक संदिग्ध परिवर्तन की तरह लगता है।

हाँ, इस परिवर्तन को etcd साइड से हाइलाइट किया जाना चाहिए (हमारे परिवर्तन लॉग और उन्नयन गाइड को बेहतर बनाएगा)।

क्या आप इस बात की पुष्टि कर सकते हैं कि इस बढ़ते हुए उपयोग के मूल कारण क्या हैं?

मुझे यकीन नहीं है कि अगर इसका मूल कारण होगा। लोअर स्नैपशॉट-गिनती निश्चित रूप से स्पाइकी मेमोरी उपयोग को कम करने में मदद करेगी। यदि दोनों etcd संस्करण समान स्नैपशॉट गणना का उपयोग करते हैं, लेकिन एक etcd अभी भी बहुत अधिक मेमोरी उपयोग दिखाता है, तो कुछ और होना चाहिए।

अद्यतन: मैंने सत्यापित किया है कि etcd मेम उपयोग में वृद्धि वास्तव में उच्च -snapshot-count डिफ़ॉल्ट मान के कारण होती है। अधिक विवरण यहाँ - https://github.com/kubernetes/kubernetes/pull/61037#issuecomment -372457843

जब हम बढ़ा हुआ मेम उपयोग नहीं करना चाहते हैं, तो हमें इसे 10,000 पर सेट करने पर विचार करना चाहिए, जब हम 3.2.16 से टकरा रहे हैं।

cc @gyuho @ xiang90 @jpbetz

अद्यतन: में ठीक तय के साथ, फली स्टार्टअप विलंबता 99% अभी भी 5 एस एसएलओ का उल्लंघन करने के करीब लगती है। कम से कम एक अन्य प्रतिगमन है और मैंने सबूत इकट्ठा किया है कि यह हमारे 5k-नोड प्रदर्शन के काम के 111/112 रन की सबसे अधिक संभावना है / b और b / b को उन ग्राफ़ में चलाता है जिन्हें मैंने https में पेस्ट किया था: / /github.com/kubernetes/kubernetes/issues/60589#issuecomment-370568929)। वर्तमान में मैं अंतर (जिसमें लगभग 50 कमिट्स हैं) को बाइसेक्ट कर रहा हूं और परीक्षण प्रति पुनरावृत्ति में ~ 4-5 घंटे लगते हैं।

जो सबूत मैं ऊपर बता रहा था वह निम्नलिखित है:

111 पर देखो विलंब थे:

Feb 14 21:36:05.531: INFO: perc50: 1.070980786s, perc90: 1.743347483s, perc99: 2.629721166s

और 111 पर समग्र पॉड-स्टार्टअप अक्षांश थे:

Feb 14 21:36:05.671: INFO: perc50: 2.416307575s, perc90: 3.24553118s, perc99: 4.092430858s

जबकि 112 पर समान थे:

Feb 16 10:07:43.222: INFO: perc50: 1.131108849s, perc90: 2.18487651s, perc99: 3.570548412s

तथा

Feb 16 10:07:43.353: INFO: perc50: 2.56160248s, perc90: 3.754024568s, perc99: 4.967573867s

इस बीच, अगर किसी ने सट्टेबाजी के खेल के लिए - आप ऊपर बताए गए कमिटमेंट पर एक नज़र डाल सकते हैं और दोषपूर्ण अनुमान लगा सकते हैं :)

एसीके। चालू
ETA: 13/03/2018
जोखिम: यदि इससे पहले डिबग नहीं किया गया है तो रिलीज की तारीख को धक्का दे सकता है

@shyamjvs भी कई जगह दांव लगाता है :)

@dims मुझे लगता है कि अधिक मज़ा जोड़ देगा;)

अपडेट: इसलिए मैंने द्विभाजन के कुछ पुनरावृत्तियों को चलाया और यहां बताया गया है कि संबंधित मेट्रिक्स कमिट (क्रोनोलॉजिस्ट का आदेश दिया गया) के पार कैसे दिखता है। ध्यान दें कि जिन लोगों के लिए मैं स्वयं भागा था, मैंने उन्हें पूर्ववर्ती प्रतिगमन (यानी 3.2। -> 3.1.11) के साथ भाग दिया।

| कमिट | 99% घड़ी विलंबता | 99% फली-स्टार्टअप विलंबता | शुभ अशुभ? |
| ------------- | ------------- | ----- | ------- |
| a042ecde36 (रन -१११ से) | 2.629721166s | 4.092430858s | अच्छा (मैन्युअल रूप से फिर से पुष्टि करना) |
| 5f7b530d87 (मैनुअल) | 3.150616856s | 4.683392706s | बुरा (संभावना) |
| a8060ab0a1 (मैनुअल) | 3.11319985s | 4.710277511s | बुरा (संभावना) |
| 430c1a68c8 (रन-112 से) | 3.570548412s | 4.967573867 | बुरा |
| 430c1a68c8 (मैनुअल) | 3.63505091s | 4.96697776s | बुरा |

ऊपर से, ऐसा लगता है कि यहां 2 प्रतिगमन हो सकते हैं (जैसा कि 2.6s -> 3.6s से सीधे कूदना नहीं है) - एक बी / डब्ल्यू "a042ecde36 - 5f7b530d87" और अन्य बी "डब्ल्यू "8060ab0a1 - 430c1a68c8"। आह!

लिंक की तुलना करने के लिए श्रेणियों के रूप में व्यक्त करना:
a042ecde36 ... 5f7b530
a8060ab0a1 ... 430c1a6

बस a042ecde36 के खिलाफ मैनुअल रन के लिए परिणाम प्राप्त किया है और यह केवल जीवन कठिन बनाता है:

3.269330734s (watch), 4.939237532s (pod-startup)

जैसा कि संभवतः इसका मतलब है कि यह एक परतदार प्रतिगमन हो सकता है।

मैं वर्तमान में a042ecde36 के खिलाफ परीक्षण चला रहा हूं, एक बार फिर संभावना को सत्यापित करने के लिए कि इससे पहले भी प्रतिगमन आया था।

तो यहाँ फिर से a042ecd के खिलाफ चलने का परिणाम है:

2.645592996s (watch), 5.026010032s (pod-startup)

संभवतः इसका मतलब रन -१११ से पहले दर्ज किया गया प्रतिगमन (अच्छी खबर है कि हमारे पास अभी बाइसेशन के लिए एक सही अंत है)।
अब मैं एक बाएं छोर के लिए आगे बढ़ने की कोशिश करूंगा। रन -108 (कमिट 11104d75f) एक संभावित उम्मीदवार है, जिसके निम्नलिखित परिणाम थे जब मैंने पहले इसे चलाया था (आदि 3.1.1 के साथ):

2.593628224s (watch), 4.321942836s (pod-startup)

11104d7 के खिलाफ मेरा फिर से दौड़ना यह कहना अच्छा लगता है:

2.663456162s (watch), 4.288927203s (pod-startup)

मैं यहाँ 11104d7 ... a042ecd में बाइसेक्टिंग पर एक स्टैब लूंगा

अद्यतन: मुझे विश्वास हासिल करने के लिए प्रतिबद्ध 097efb71a315 तीन बार परीक्षण करने की आवश्यकता थी। यह काफी कुछ विचरण दिखाता है, लेकिन लगता है कि एक अच्छी प्रतिबद्धता है:

2.578970061s (watch), 4.129003596s (pod-startup)
2.315561531s (watch), 4.70792639s (pod-startup)
2.303510957s (watch), 3.88150234s (pod-startup)

मैं आगे भी बिस्किटिंग जारी रखूंगा।
यह कहा गया है, कुछ दिन पहले ही पॉड-स्टार्टअप लेटेंसी में एक और स्पाइक (~ 1 एस) हुआ है। और यह एक 99% को लगभग 6s पर धकेल रहा है:

से मेरे मुख्य संदिग्ध प्रतिबद्ध diff 3.1.11 से etcd परिवर्तन है -> 3.1.12 (https://github.com/kubernetes/kubernetes/pull/60998)। मैं इसकी पुष्टि के लिए अगले रन (वर्तमान में प्रगति पर) की प्रतीक्षा करूंगा, लेकिन यह वास्तव में इसे समझने की आवश्यकता नहीं है।

cc @jpbetz @gyuho

चूंकि मैं इस सप्ताह थू-फ्रू पर हूं, इसलिए मैं 5k-नोड क्लस्टर के खिलाफ घनत्व परीक्षण चलाने के निर्देश दे रहा हूं (इसलिए परियोजना तक पहुंच रखने वाला कोई व्यक्ति बिसनेस जारी रख सकता है):

# Start with a clean shell.
# Checkout to the right commit.
make quick-release

# Set the project:
gcloud config set project k8s-scale-testing

# Set some configs for creating/testing 5k-node cluster:
export CLOUDSDK_CORE_PRINT_UNHANDLED_TRACEBACKS=1
export KUBE_GCE_ZONE=us-east1-a
export NUM_NODES=5000
export NODE_SIZE=n1-standard-1
export NODE_DISK_SIZE=50GB
export MASTER_MIN_CPU_ARCHITECTURE=Intel\ Broadwell
export ENABLE_BIG_CLUSTER_SUBNETS=true
export LOGROTATE_MAX_SIZE=5G
export KUBE_ENABLE_CLUSTER_MONITORING=none
export ALLOWED_NOTREADY_NODES=50
export KUBE_GCE_ENABLE_IP_ALIASES=true
export TEST_CLUSTER_LOG_LEVEL=--v=1
export SCHEDULER_TEST_ARGS=--kube-api-qps=100
export CONTROLLER_MANAGER_TEST_ARGS=--kube-api-qps=100\ --kube-api-burst=100
export APISERVER_TEST_ARGS=--max-requests-inflight=3000\ --max-mutating-requests-inflight=1000
export TEST_CLUSTER_RESYNC_PERIOD=--min-resync-period=12h
export TEST_CLUSTER_DELETE_COLLECTION_WORKERS=--delete-collection-workers=16
export PREPULL_E2E_IMAGES=false
export ENABLE_APISERVER_ADVANCED_AUDIT=false

# Bring up the cluster (this brings down pre-existing one if present, so you don't have to explicitly '--down' the previous one) and run density test:
go run hack/e2e.go \
--up \
--test \
--test_args='--ginkgo.focus=\[sig\-scalability\]\sDensity\s\[Feature\:Performance\]\sshould\sallow\sstarting\s30\spods\sper\snode\susing\s\{\sReplicationController\}\swith\s0\ssecrets\,\s0\sconfigmaps\sand\s0\sdaemons$ --allowed-not-ready-nodes=30 --node-schedulable-timeout=30m --minStartupPods=8 --gather-resource-usage=master --gather-metrics-at-teardown=master' \
> somepath/build-log.txt 2>&1 

# To re-run the test on same cluster (without re-creating) just omit '--up' in the above.

महत्वपूर्ण लेख:

• वर्तमान प्रतिबद्ध सीमा संदिग्ध है ff7918d ... a042ecde3 (इसे हम अद्यतन करते रहें जैसा कि हम बताते हैं)
• हमें 3.2.14 के बजाय etcd-3.1.11 का उपयोग करने की आवश्यकता है (पहले के प्रतिगमन को शामिल करने से बचने के लिए)। निम्न फ़ाइलों में संस्करण को न्यूनतम हासिल करने के लिए बदलें:
  
  
  
  • क्लस्टर / GCE / प्रकट होता है / etcd.manifest
  
  
  • क्लस्टर / images / etcd / Makefile
  
  
  • हैक / lib / etcd.sh
  
  

cc: @ wojtek-t

वॉर्ड v3.1.12 फ़िक्सेस वॉच ईवेंट मिस को पुनर्स्थापित करता है। और यह एकमात्र परिवर्तन है जो हमने v3.1.11 से किया है। क्या प्रदर्शन परीक्षण में पुनः आरंभ या बहु-नोड के साथ कुछ भी शामिल है जो नेता से स्नैपशॉट ट्रिगर कर सकता है?

क्या प्रदर्शन परीक्षण में पुनः आरंभ के साथ कुछ भी शामिल है

आदि लॉग से , ऐसा लगता नहीं है कि कोई पुनः आरंभ हुआ था।

बहु नोड

हम अपने सेटअप में केवल एक नोड नोड का उपयोग कर रहे हैं (यह मानते हुए कि आपने क्या पूछा है)।

समझा। फिर, v3.1.11 और v3.1.12 अलग नहीं होना चाहिए: 0
एक और रूप लेगा अगर दूसरा रन भी उच्च अक्षांशों को दर्शाता है।

cc: @jpbetz

@Gyuho से सहमत हैं कि हमें इस पर एक मजबूत संकेत प्राप्त करने की कोशिश करनी चाहिए, क्योंकि दिए गए कोड में केवल कोड परिवर्तन को पुनः आरंभ / पुनर्प्राप्त करने के लिए पृथक किया गया है।

केवल अन्य परिवर्तन go1.8.5 से go1.8.7 तक etcd का अपग्रेड है, लेकिन मुझे संदेह है कि हम इसके साथ एक महत्वपूर्ण प्रदर्शन प्रतिगमन देखेंगे।

तो निरंतरता के साथ, ff7918d1f अच्छा लगता है:

2.246719086s (watch), 3.916350274s (pod-startup)

मैं तदनुसार https://github.com/kubernetes/kubernetes/issues/60589#issuecomment -373051051 में प्रतिबद्ध सीमा को अपडेट करूंगा।

अगला, कमिटमेंट a19a1726 एक अच्छा लगता है, हालाँकि मैं एक बार फिर से पुष्टि करने का सुझाव दूंगा:

2.715156606s (watch), 4.382527095s (pod-startup)

इस बिंदु पर मैं द्विभाजन को विराम देने और अपनी छुट्टी शुरू करने जा रहा हूँ :)
मैंने अगले रन के लिए जगह बनाने के लिए अपने क्लस्टर को नीचे कर दिया है।

धन्यवाद श्याम मैं ए १ ९ ए १a२६ ९ ३ ९ 60४६०६०५ ए ० बी ० ९ 35 ९९ ५३५२६7c डी २५ ९ d३ aa से पुनः प्रयास कर रहा हूं।

कमिटमेंट के लिए aa19a172693a4ad60d5a08e9b93557267d259c37 मुझे निम्नलिखित परिणाम मिले:

2.47655243s (watch), 4.174016696s (pod-startup)

तो यह अच्छा लग रहा है। लगातार बिसनेस।

वर्तमान कमिटेड रेंज संदिग्ध: aa19a172693a4ad60d5a08e9b93557267d259c37 ... a042ecde362000e51f1e7bdbda5bf5d81116f84

@ isylkowski-क्या आप 5PM UTC / 1PM पूर्वी / 10AM प्रशांत में हमारी रिलीज़ मीटिंग में भाग ले सकते हैं? यह एक ज़ूम मीटिंग है: https://zoom.us/j/2018742972

मैं भाग लूँगा।

प्रतिबद्ध cca7ccbff161255292f72c2d18459cdface62122 निम्नलिखित परिणामों के साथ स्पष्ट नहीं दिखता है:

2.984185673s (watch), 4.568914929s (pod-startup)

मैं विश्वास पाने के लिए इसे एक बार और चलाऊंगा, मैं द्वंद्व के गलत आधे हिस्से में प्रवेश नहीं करता।

ठीक है, इसलिए मुझे अब पूरा विश्वास है कि cca7ccbff161255292f72c2d18459cdface62122 खराब है:

3.285168535s (watch), 4.783986141s (pod-startup)

सीमा को नीचे ले जाकर aa19a172693a4ad60d5a08e9b93557267d259c37 ... cca7ccbff161255292f72c2d18459cdfacex122 पर और 92e4d3da0076f923a45d54d54c84c84e91c91/61 पर आज़मा कर देखें।

प्रतिबद्ध 92e4d3da0076f923a45d54d69c84e91ac6a61a55 अच्छा लग रहा है:

2.522438984s (watch), 4.21739985s (pod-startup)

नई संदिग्ध कमिट रेंज 92e4d3da0076f923a45d54d69c84e91ac6a61a55 ... cca7ccbff161255292f72c2d18459cdface62122, 603ebe466d335a373915151517171717181811b1111 पर आजमाएँ।

@wasylkowski कृपया ध्यान दें कि प्रतिबद्ध में से एक अर्थात् https://github.com/kubernetes/kubernetes/commit/4c289014a05669c376994868d8d91f7565a204b5 में वापस लाया गया https://github.com/kubernetes/kubernetes/commit/493f33583053bb4ce9f7d348c5bac39975883cb8

@Dims को अधिक स्पष्ट रूप से टिप्पणी करते हुए, हम यहाँ एक संकेत भूत का पीछा करते हुए हो सकते हैं। यदि 4c28901 समस्या है, और यह 493f335 पर पहले से ही प्रतीत होता है असंबंधित कारणों से वापस आ गया है, तो क्या 1.10 ब्रांच हेड के खिलाफ स्केलेबिलिटी टेस्ट ग्रीन सिग्नल दिखाता है?

क्या हम 1.10 शाखा प्रमुख के खिलाफ एक बार फिर से परीक्षण करने को प्राथमिकता दे सकते हैं, बजाए निरंतरता के?

@wasylkowski / @ wasylkowski-a ^ ^ ^ ^ ^

@ wojtek-t PTAL ASAP

धन्यवाद @dims और @tpepper। 1.10 शाखा प्रमुख के खिलाफ मेरी कोशिश करते हैं और देखते हैं कि क्या होता है।

धन्यवाद @wasylkowski सबसे खराब स्थिति में हम पहले जो करते थे, हम उससे पीछे हट जाते हैं। सही?

1.10 सिर में एक प्रतिगमन होता है:

3.522924087s (watch), 4.946431238s (pod-startup)

यह वगैरह 3.1.12 पर है, वगैरह 3.1.11 नहीं, लेकिन अगर मैं इसे सही तरीके से समझूं तो इससे बहुत फर्क नहीं पड़ना चाहिए।

इसके अलावा, 603ebe466d335a37392315d491782ed18d1bae11 अच्छा लग रहा है:

2.744654024s (watch), 4.284582476s (pod-startup)
2.76287483s (watch), 4.326409841s (pod-startup)
2.560703844s (watch), 4.213785531s (pod-startup)

यह हमें 603ebe466d335a37392315d491782ed18d1bae11 ... cca7ccbff161255292f72c2d18459cdface62122 पर छोड़ता है और वहाँ केवल 3 कमिट है। मुझे देखने दो कि मुझे क्या पता है।

यह भी संभव है कि वास्तव में 4c289014a05669c376994868d8d91f7565a204b5 अपराधी है, लेकिन फिर इसका मतलब है कि हमारे पास एक और प्रतिगमन है जो सिर पर ही प्रकट होता है।

ठीक है, तो जाहिर है कि 6590ea6d5d50700d34255b1e037b2702ad26b7fc प्रतिबद्ध है:

2.553170576s (watch), 4.22516704s (pod-startup)

जबकि प्रतिबद्ध 7b678dc4035c61a1991b5e1442edb13f40deae72

3.498855918s (watch), 4.886599251s (pod-startup)

ख़राब कमेटी @dims द्वारा बताई गई

मुझे 3.1.12 के बजाय वगैरह 3.1.11 पर फिर से पढ़ने की कोशिश करें और देखें कि क्या होता है।

@ isylkowski-एक आह क्लासिक अच्छी खबर बुरी खबर :) यह रखने के लिए धन्यवाद।

@ wojtek-t कोई अन्य सुझाव?

वगैर 3.1.11 पर हेड भी खराब है; मेरी अगली कोशिश उल्टा होने के बाद सीधे प्रयास करने की होगी (इसलिए, प्रतिबद्ध cdecea545553eff09e280d389a3aef69e2f32bf1), लेकिन 3.2.14 के बजाय 3.1.11 के साथ।

अच्छा आंद्रेज लगता है

- मंद

17 मार्च, 2018 को दोपहर 1:19 बजे, आंद्रेजेज वासिलकोव्स्की नोटिफिकेशन @github.com ने लिखा:

वगैर 3.1.11 पर हेड भी खराब है; मेरी अगली कोशिश उल्टा होने के बाद सीधे प्रयास करने की होगी (इसलिए, कम से कम cdecea5 पर), लेकिन 3.2.14 के बजाय 3.1.11 आदि के साथ।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

प्रतिबद्ध cdecea545553eff09e280d389a3aef69e2f32bf1 अच्छा है, इसलिए हमारे पास बाद का प्रतिगमन है:

2.66454307s (watch), 4.308091589s (pod-startup)

प्रतिबद्ध 2a373ace6eda6a9cf050ce70a6cf99183c5e5b37 स्पष्ट रूप से बुरा है:

3.656979569s (watch), 6.746987916s (pod-startup)

@ wasylkowski-a तो हम मूल रूप से https://github.com/kubernetes/kubernetes/compare/cdecea5...2a373ac की रेंज में कमिट देख रहे हैं कि तब क्या गलत है? (इन दोनों के बीच रन बिज़)?

हाँ। यह एक बड़ी रेंज है, दुर्भाग्य से। मैं अभी aded0d922592fdff0137c70443caf2a9502c7580 की जांच कर रहा हूँ।

धन्यवाद @wasylkowski वर्तमान सीमा क्या है? (इसलिए मैं पीआर पर देख सकते हैं)।

प्रतिबद्ध aded0d922592fdff0137c70443caf2a9502c7580 खराब है:

3.626257043s (watch), 5.00754503s (pod-startup)

प्रतिबद्ध f8298702ffe644a4f021e23a616ad6a8790a5537 यह भी है:

3.747051371s (watch), 6.126914967s (pod-startup)

तो 20a6749c3f86c7cb9e98442046532380fb5f6e36 प्रतिबद्ध है:

3.641172882s (watch), 5.100922237s (pod-startup)

और ऐसा ही 0e81651e77e0be7e75179e5986ef2c76601f4dd6 है:

3.687028394s (watch), 5.208157763s (pod-startup)

वर्तमान सीमा cdecea545553eff09e280d389a3aef69e2f32bf1 है ... 0e81651e77e0be7e75179e5986ef2c7b0101f4bd6। हम (मुझे, @ wojtek-t, @shyamjvs) को संदेह होने लगा है कि cdecea545553eff09e280d389a3aef69e2f32bf1 वास्तव में एक परतदार पास है, इसलिए हमें एक अलग बाएं छोर की आवश्यकता है।

/ मुझे https://github.com/kubernetes/kubernetes/commit/b259543985b10875f4a010ed0285ac43e335c8e0 पर अपराधी के रूप में दांव लगाएं

cc @ isylkowski-a

0e81651e77e0be7e75179e5986ef2c76601f4bd6, पता चला है, बुरा है, तो b259543985b10875f4a010ed0285ac43e335c8e0 (244549f02afabc5be23fc56e86a60e5b36838828 के रूप में विलय कर दिया, 0e81651e77e0be7e75179e5986ef2c76601f4bd6 के बाद) जल्द से जल्द अपराधी नहीं हो सकता है (हालांकि यह असंभव नहीं है कि यह अभी तक एक और प्रतिगमन हम पालन करेंगे शुरू की है एक बार हम इस एक बाहर हिला)

प्रति @ wojtek-t और @shyamjvs मैं rerunning cdecea545553eff09e280d389a3aef69e2f32bf1 है, क्योंकि हमें संदेह है कि यह "भड़कीला" हो सकता है

मैं मान लूंगा कि cdecea545553eff09e280d389a3aef69e2f32bf1 मेरे द्वारा देखे गए निम्न परिणामों के आधार पर वास्तव में अच्छा है:

2.66454307s (watch), 4.308091589s (pod-startup)
2.695629257s (watch), 4.194027608s (pod-startup)
2.660956347s (watch), 3m36.62259323s (pod-startup) <-- looks like an outlier
2.865445137s (watch), 4.594671099s (pod-startup)
2.412093606s (watch), 4.070130529s (pod-startup)

वर्तमान में संदिग्ध सीमा: cdecea545553eff09e280d389a3aef69e2f32bf1 ... 0e81651e77e0be7e75179e5986ef2b76601f4bd6

वर्तमान में परीक्षण 99c87cf679e9cbd9647786bf7e81f0a2d771084f

इस कार्य को जारी रखने के लिए @wasylkowski को धन्यवाद।

प्रति चर्चा आज: धाराप्रवाह-स्केलर में अभी भी मुद्दे हैं: https://github.com/kubernetes/kubernetes/issues/61190 , जो पीआरएस द्वारा तय नहीं किए गए हैं। क्या यह संभव है कि यह प्रतिगमन धाराप्रवाह के कारण होता है?

धाराप्रवाह से संबंधित पीआरएस में से एक https://github.com/kubernetes/kubernetes/commit/a88ddac1e47e0bc4b43bfa1b0df2f19aea4b55f2 नवीनतम श्रेणी में है

आज प्रति चर्चा: धाराप्रवाह-स्केलर में अभी भी मुद्दे हैं: # 61190, जो पीआरएस द्वारा तय नहीं किए गए हैं। क्या यह संभव है कि यह प्रतिगमन धाराप्रवाह के कारण होता है?

टीबीएच, मुझे वास्तव में आश्चर्य होगा अगर यह धाराप्रवाह मुद्दों के कारण होगा। लेकिन मैं इस परिकल्पना को पक्का नहीं कर सकता।
मेरी व्यक्तिगत भावना कुब्लेट में कुछ बदलाव होगी, लेकिन मैंने उस सीमा में पीआरएस पर भी ध्यान दिया और कुछ भी वास्तव में संदिग्ध नहीं लगता ...
उम्मीद है कि रेंज कल 4x छोटी होगी, जिसका मतलब सिर्फ युगल पीआरएस होगा।

ठीक है, तो 99c87cf679e9cbd9647786bf7e81f0a2d771084f अच्छा लग रहा है, लेकिन मुझे यह सुनिश्चित करने के लिए तीन रनों की आवश्यकता थी कि यह एक परत नहीं है:

2.901624657s (watch), 4.418169754s (pod-startup)
2.938653965s (watch), 4.423465198s (pod-startup)
3.047455619s (watch), 4.455485098s (pod-startup)

अगला, a88ddac1e47e0bc4b43bfa1b0df2f19aea4455f2 खराब है:

3.769747695s (watch), 5.338517616s (pod-startup)

वर्तमान सीमा 99c87cf679e9cbd9647786bf7e81f0a2d771084f है ... a88ddac1e47e0bc4b43bfa1b0df2f4aa4455f2। विश्लेषण c105796e4ba7fc9cfafc2e7a3cc4a556d7d9defd

मैंने ऊपर उल्लिखित सीमा पर ध्यान दिया - वहां केवल 9 पीआर हैं।
https://github.com/kubernetes/kubernetes/pull/59944 - 100% नहीं - केवल स्वामियों के फ़ोन बदलते हैं
https://github.com/kubernetes/kubernetes/pull/59953 - संभावित
https://github.com/kubernetes/kubernetes/pull/59809 - केवल कुबेल कोड को छू रहा है, इसलिए इस मामले के लिए कोई बात नहीं होनी चाहिए
https://github.com/kubernetes/kubernetes/pull/59955 - 100% नहीं - केवल असंबंधित e2e परीक्षण को छूना
https://github.com/kubernetes/kubernetes/pull/59808 - संभावित रूप से (यह क्लस्टर सेटअप बदलता है)
https://github.com/kubernetes/kubernetes/pull/59913 - 100% नहीं - केवल असंबंधित e2e परीक्षण को छूना
https://github.com/kubernetes/kubernetes/pull/59917 - यह परीक्षण बदल रहा है, लेकिन परिवर्तनों को स्विच नहीं कर रहा है, इसलिए संभावना नहीं है
https://github.com/kubernetes/kubernetes/pull/59668 - 100% नहीं - केवल AWS कोड
https://github.com/kubernetes/kubernetes/pull/59909 - 100% नहीं - केवल स्वामियों के फ़ोन को छूने से

इसलिए मुझे लगता है कि हमारे यहाँ दो उम्मीदवार हैं: https://github.com/kubernetes/kubernetes/pull/59953 और https://github.com/kubernetes/kubernetes/pull/59808
मैं उन्हें समझने के लिए गहरी खुदाई करने की कोशिश करूंगा।

c105796e4ba7fc9cfafc2e7a3cc4a556d7d9defd बुरा लगता है:

3.428891786s (watch), 4.909251611s (pod-startup)

यह देखते हुए कि यह # 59953 का विलय है, जो वोजटेक के संदिग्धों में से एक है, अब मैं इससे पहले एक कमिट पर चलूंगा, इसलिए f60083549a43f152b3142e01756e25611d9b770।

यह प्रतिबद्ध है, हालांकि, OWNERS_ALIASES परिवर्तन है, और इससे पहले कि सीमा में कुछ भी नहीं बचा है, इसलिए c105796e4ba7fc9cfafc2e7a3cc4a556d7dddefd समस्या होनी चाहिए। मैं वैसे भी सुरक्षा के लिए परीक्षण चलाऊंगा।

ऑफ़लाइन चर्चा की गई - हम इसके बजाय स्थानीय स्तर पर वापस किए गए इस कमिट के साथ परीक्षण चलाएंगे।

वाह! एक लाइनर इतनी परेशानी पैदा कर रहा है। धन्यवाद @wasylkowski @ wojtek-t

@dims वन-लाइनर्स वास्तव में स्केलेबिलिटी के साथ तबाही का कारण बन सकते हैं। अतीत से एक और उदाहरण - https://github.com/kubernetes/kubernetes/pull/53720#issue-145949976
सामान्य तौर पर, आप एक अच्छे पढ़ने के लिए https://github.com/kubernetes/community/blob/master/sig-scalability/blogs/scalability-regressions-case-studies.md देखना चाह सकते हैं :)

फिर से अपडेट करें। सिर पर परीक्षण: पहले स्थानीय रूप से उत्तीर्ण किए गए कमिट के साथ चलाएं। यह एक परत हो सकता है, हालांकि, इसलिए मैं इसे पुन: निर्देशित कर रहा हूं।

Https: //github.com/kubernetes/kubernetes/pull/59953 ... में कमिट देखने पर क्या यह बग ठीक नहीं कर रहा था? ऐसा प्रतीत होता है कि बग को "अनुसूचित" स्थिति को गलत वस्तु में रखने के लिए फिक्सिंग किया गया है। उस पीआर में संदर्भित मुद्दे के आधार पर, ऐसा लग रहा है कि क्यूबलेट उस फॉल के बिना रिपोर्ट करने से चूक सकता है?

@ रैंडम-लियू कौन हमें बेहतर तरीके से समझा सकता है कि उस बदलाव का क्या असर होता है :)

# 59953 में कमिट को देखते हुए ... क्या यह बग को ठीक नहीं कर रहा था? ऐसा प्रतीत होता है कि बग को "अनुसूचित" स्थिति को गलत वस्तु में रखने के लिए फिक्सिंग किया गया है। क्या क्यूबलेट रिपोर्ट कर सकता है कि एक फली को उस फिक्स से पहले भी निर्धारित किया गया था?

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

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

दो रनों के बाद मुझे पूरा विश्वास है कि # 59953 को पुनः प्राप्त करने से समस्या ठीक हो जाती है:

3.052567319s (watch), 4.489142104s (pod-startup)
2.799364978s (watch), 4.385999497s (pod-startup)

हम अधिक पॉड स्टेटस अपडेट भेज रहे हैं, जिसके परिणामस्वरूप 429s या उससे अधिक sth हो सकते हैं। और अंत में एक क्यूबलेट को फली की स्थिति की रिपोर्ट करने में अधिक समय लगता है।

यह बहुत अधिक प्रभाव है जो मैं https://github.com/kubernetes/kubernetes/issues/60589#issuecomment -370573938 में परिकल्पना कर रहा था (हालांकि मेरे द्वारा गलत अनुमान लगाने का कारण गलत था :))
इसके अलावा, हम IIRC ने पुट कॉल के लिए # 429s में # वृद्धि देखी है (मेरी https://github.com/kubernetes/kubernetes/issues/60589#issuecomment-370582634 देखें) लेकिन मुझे लगता है कि पहले की सीमा से था आसपास बदलाव)।

दो रनों के बाद मुझे पूरा विश्वास है कि # 59953 को पुनः प्राप्त करने से समस्या ठीक हो जाती है:

मेरे अंतर्ज्ञान (https://github.com/kubernetes/kubernetes/issues/60589#issuecomment-370874602) के बारे में क्यूबलेट पक्ष पर जारी होने के बारे में काफी प्रारंभिक सूत्र में सभी पर सही था :)

/ सिग नोड
@ कुबेरनेट्स / सिग-नोड-बग्स रिलीज टीम वास्तव में समीक्षा # 59953 पर बनाम वापस लौटने और यहां प्रदर्शन के मुद्दे का उपयोग कर सकती है।

# 59953 में कमिट को देखते हुए ... क्या यह बग को ठीक नहीं कर रहा था? ऐसा प्रतीत होता है कि बग को "अनुसूचित" स्थिति को गलत वस्तु में रखने के लिए फिक्सिंग किया गया है। उस पीआर में संदर्भित मुद्दे के आधार पर, ऐसा लग रहा है कि क्यूबलेट उस फॉल के बिना रिपोर्ट करने से चूक सकता है?

@liggitt मेरे लिए यह समझाने के लिए धन्यवाद। हाँ, वह पीआर बग को ठीक कर रहा है। पहले, क्यूबलेट ने हमेशा PodScheduled सेट नहीं किया था। # 59953 के साथ, क्यूबलेट सही ढंग से करेगा।

@shyamjvs मुझे यकीन नहीं है कि यह अधिक पॉड स्टेटस अपडेट पेश कर सकता है।
अगर मैं सही तरीके से समझूं, तो पहले स्टेटस अपडेट में PodScheduled कंडीशन सेट हो जाएगी और फिर यह हमेशा रहेगी और कभी नहीं बदली जाएगी। मुझे समझ में नहीं आता कि यह अधिक स्थिति अपडेट क्यों उत्पन्न करता है।

यह वास्तव में अधिक स्थिति अद्यतन को लागू करता है, यह एक समस्या 2 साल पहले शुरू की गई है https://github.com/kubernetes/kubernetes/pull/24459 लेकिन एक बग द्वारा कवर, और # 59,953 सिर्फ बग को ठीक ...

@ wasylkowski-a क्या आपके पास https://github.com/kubernetes/kubernetes/issues/60589#issuecomment -374982422 और https://github.com/kubernetes/kubernetes/issues/60589# में 2 टेस्ट रन के लिए लॉग हैं।

@yujuhong और मैंने पाया कि # 59953 ने एक मुद्दे को उजागर किया है कि स्थिर फली की PodScheduled स्थिति अपडेट होती रहेगी।

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

इस मुद्दे को # 24459 में पेश किया गया था, लेकिन इसे एक बग द्वारा कवर किया गया था। # 59953 ने बग को ठीक किया, और मूल मुद्दे को उजागर किया।

इसे जल्दी ठीक करने के लिए 2 विकल्प हैं:

• विकल्प 1: क्यूबलेट को PodScheduled कंडीशन में न जोड़ें, क्यूबलेट को शेड्यूलर द्वारा निर्धारित PodScheduled कंडीशन में संरक्षित करना चाहिए।
  
  
  
  • पेशेवरों: सरल।
  
  
  • विपक्ष: स्टेटिक पॉड और पॉड जो कि शेड्यूलर (सीधे नोड नाम असाइन करें) के पास PodScheduled शर्त नहीं होगी। वास्तव में # 59953 के बिना, हालांकि क्यूबलेट अंततः उन फली के लिए इस स्थिति को निर्धारित करेगा, लेकिन बग के कारण बहुत लंबा समय लग सकता है।
  
  
• विकल्प 2: स्टैबल पॉड के लिए PodScheduled स्थिति उत्पन्न करें जब क्यूबलेट इसे शुरू में देखता है।

विकल्प 2 उपयोगकर्ता के कम बदलाव का सामना कर सकता है।

लेकिन हम पूछना चाहते हैं कि क्या PodScheduled फली का मतलब है जो अनुसूचक द्वारा निर्धारित नहीं हैं? क्या हमें वास्तव में उन फली के लिए इस स्थिति की आवश्यकता है? / cc @ kubernetes / sig- autoscaling- बग क्योंकि PodScheduled का उपयोग अब autoscaling द्वारा किया जाता है।
/ cc @ कुबेरनेट्स / सिग-नोड-बग्स @ कुबेरनेट्स / सिग-शेड्यूलिंग-बग्स

@ रैंडम-लियू very long time for kubelet to eventually set this condition क्या प्रभाव है? एंड-यूज़र नोटिस / फेस (टेस्ट हार्नेस फ्लैसीनेस के बाहर) को क्या समस्या होगी? (विकल्प # 1 से)

@dims उपयोगकर्ता लंबे समय तक PodScheduled स्थिति नहीं देखेगा।

मेरे पास एक फिक्स # 61504 है जो https://github.com/kubernetes/kubernetes/issues/60589#issuecomment -375103979 में 2 विकल्प लागू करता है।

मैं इसे विकल्प 1 में बदल सकता हूं यदि लोग सोचते हैं कि यह एक बेहतर समाधान है। :)

आप बेहतर तरीके से उन लोगों से पूछते हैं जो इसे अंदर से जानते हैं! (रिलीज टीम नहीं!)

ping @dashpole @ dchen1107 @derekwaynecarr

@ रैंडम-लियू IIRC हमारे परीक्षणों में नोड्स पर चलने वाला एकमात्र स्थिर पॉड है, जो क्यूब-प्रॉक्सी है। क्या आप बता सकते हैं कि ये updates लगातार अपडेट ’क्यूबलेट द्वारा कितनी बार किए गए हैं? (बग द्वारा प्रस्तुत अतिरिक्त qps का अनुमान लगाने के लिए पूछना)

@ रैंडम-लियू IIRC हमारे परीक्षणों में नोड्स पर चलने वाला एकमात्र स्थिर पॉड है, जो क्यूब-प्रॉक्सी है। क्या आप बता सकते हैं कि ये updates लगातार अपडेट ’क्यूबलेट द्वारा कितनी बार किए गए हैं? (बग द्वारा प्रस्तुत अतिरिक्त qps का अनुमान लगाने के लिए पूछना)

@shyamjvs हाँ, kube-proxy केवल अब नोड पर है।

मुझे लगता है कि यह पॉड सिंक आवृत्ति पर निर्भर करता है https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/kubeletconfig/v1beta1/defaults.go#L47 , जो 1 मिनट का है। तो क्यूबलेट हर 1 मिनट में एक अतिरिक्त पॉड स्टेटस अपडेट जेनरेट करता है।

धन्यवाद। तो इसका मतलब है कि 5000/60 = ~ 83 qps अतिरिक्त उन पॉड-स्टेटस कॉल के कारण जोड़े गए। बग में पहले से उल्लेखित 429 की वृद्धि को समझाने के लिए लगता है।

@ रैंडम-लियू हमें इस छांटने में मदद करने के लिए बहुत-बहुत धन्यवाद।

@jdumars np ~ @yujuhong ने मेरी बहुत मदद की!

लेकिन हम यह पूछना चाहते हैं कि पॉडस्किल्ड का मतलब उन पॉड्स से क्या है जो शेड्यूलर द्वारा शेड्यूल नहीं किए गए हैं? क्या हमें वास्तव में उन फली के लिए इस स्थिति की आवश्यकता है? / cc @ kubernetes / sig- autoscaling- कीड़े क्योंकि

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

इसके अलावा, स्थिर-राज्य फली अद्यतन दर # 14391 के लिए परीक्षण जोड़ने के लिए वास्तव में पुराने मुद्दे को पुनर्जीवित किया

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

@yujuhong - क्या आप इस बारे में बात कर रहे हैं: # 61504 (या क्या मैं इसे गलत समझ रहा हूं)?

@wasylkowski @shyamjvs - क्या आप उस पीआर के साथ 5000-नोड परीक्षण चला सकते हैं ताकि स्थानीय स्तर पर (हम इसे मर्ज करने से पहले) यह सुनिश्चित कर सकें कि यह वास्तव में मदद करता है?

मैंने 1.10 HEAD + # 61504 के खिलाफ परीक्षण चलाया, और पॉड-स्टार्टअप लेटेंसी ठीक लग रही है:

INFO: perc50: 2.594635536s, perc90: 3.483550118s, perc99: 4.327417676s

पुष्टि के लिए एक बार फिर से चलेंगे।

@shyamjvs - thanks a lot!

दूसरा रन भी अच्छा लगता है:

INFO: perc50: 2.583489146s, perc90: 3.466873901s, perc99: 4.380595534s

बहुत विश्वास है कि अब तय किया चाल है। चलो इसे 1.10 asap में मिलता है।

साभार @shyamjvs

जैसा कि हमने ऑफ़लाइन बात की - मुझे लगता है कि हमारे पास पिछले महीने में एक और प्रतिगमन था, लेकिन यह कि रिलीज को अवरुद्ध नहीं करना चाहिए।

@yujuhong - क्या आप इस बारे में बात कर रहे हैं: # 61504 (या क्या मैं इसे गलत समझ रहा हूं)?

हां। उस पीआर में मौजूदा फिक्स https://github.com/kubernetes/kubernetes/issues/60589#issuecomment -375103979 में शुरू में प्रस्तावित विकल्पों में नहीं है

जब तक हमारे पास एक अच्छा प्रदर्शन परीक्षा परिणाम नहीं होता तब तक फिर से खोलना।

@yujuhong @krzyzacy @shyamjvs @ wojtek-t @ Random-लियू @ wasylkowski-इस पर कोई अपडेट? यह अभी भी 1.10 को रोक रहा है।

तो इस बग का एकमात्र भाग जो रिलीज़ को रोक रहा था वह है 5k-नोड प्रदर्शन कार्य। दुर्भाग्य से, हमने एक अलग कारण (रेफरी: https://github.com/kubernetes/kubernetes/issues/61190#issuecomment-376150569) के कारण आज से अपना रन खो दिया है

उन्होंने कहा, मुझे अपने मैन्युअल रन (https://github.com/kubernetes/kubernetes/issues/60589#issuecomment-375350217 पर चिपकाए गए परिणाम) के आधार पर ठीक काम करने का पूरा भरोसा है। इसलिए आईएमएचओ को हमें इस पर रिलीज को रोकने की जरूरत नहीं है (अगले रन वेड पर होने जा रहा है)।

+1
@jdumars - मुझे लगता है कि हम इसे गैर-अवरोधक के रूप में

क्षमा करें, मैंने अपना पोस्ट ऊपर संपादित किया है। मेरा मतलब था कि हमें इसे "गैर-अवरोधक" के रूप में मानना ​​चाहिए।

ठीक है आपका बहुत बहुत धन्यवाद। यह निष्कर्ष आपके द्वारा निवेश किए गए घंटों की एक जबरदस्त मात्रा का प्रतिनिधित्व करता है, और मैं संभवतः आपके द्वारा किए गए कार्य के लिए सभी को पर्याप्त रूप से धन्यवाद नहीं दे सकता। जबकि हम आपको "समुदाय" और "योगदानकर्ताओं" के बारे में सार में बात करते हैं, और जिन लोगों ने इस मुद्दे पर काम किया है वे इसे ठोस शब्दों में दर्शाते हैं। आप इस परियोजना के बहुत दिल और आत्मा हैं, और मुझे पता है कि मैं इसमें शामिल सभी के लिए बोलता हूं जब मैं कहता हूं कि यह इस तरह के जुनून, प्रतिबद्धता और व्यावसायिकता के साथ काम करने के लिए एक सम्मान है।

[MILESTONENOTIFIER] मील का पत्थर मुद्दा: प्रक्रिया के लिए अप-टू-डेट

@krzyzacy @ msau42 @shyamjvs @ wojtek-t

• sig/api-machinery sig/autoscaling sig/node sig/scalability sig/scheduling sig/storage : जरूरत पड़ने पर इन SIG को जारी किया जाएगा।
• priority/critical-urgent : कभी भी स्वचालित रूप से एक रिलीज के मील के पत्थर से बाहर कदम नहीं होता है; सभी उपलब्ध चैनलों के माध्यम से योगदानकर्ता और एसआईजी के लिए लगातार आगे बढ़ें।
• kind/bug : वर्तमान रिलीज़ के दौरान खोजे गए बग को ठीक करता है।
  
  
  
  

  मदद

• अतिरिक्त निर्देश
• लेबल सेट करने की आज्ञा देता है

1.10 के लिए प्रासंगिक फ़िक्सेस के साथ इस समस्या को हल किया गया था।
1.11 के लिए, हम विफलताओं पर नज़र रख रहे हैं - https://github.com/kubernetes/kubernetes/issues/63030।

/बंद करे