Kubernetes: ज़ोन के असंतुलन होने पर कुछ नोड्स को शेड्यूलिंग में नहीं माना जाता है

/ शिग शेड्यूलिंग

क्या आप सर्वर से पुनर्प्राप्त किए गए नोड, डेमोंसेट, एक उदाहरण पॉड और युक्त नेमस्पेस का पूर्ण यामाल प्रदान कर सकते हैं?

नोड:
https://gist.github.com/zetaab/2a7e8d3fe6cb42a617e17abc0fa375f7

daemonset:
https://gist.github.com/zetaab/31bb406c8bd622b3017bf4f468d0154f

उदाहरण फली (काम करना):
https://gist.github.com/zetaab/814871bec6f2879e371f5bbdc6f2e978

उदाहरण पॉड (शेड्यूलिंग नहीं):
https://gist.github.com/zetaab/f3488d65486c745af78dbe2e6173fd42

नाम स्थान:
https://gist.github.com/zetaab/4625b759f4e21b50757c79e5072cd7d9

डेमनसेट पॉड्स शेड्यूल एक नोडएफ़िनिटी चयनकर्ता के साथ है जो केवल एक नोड से मेल खाता है, इसलिए "13 में से 12 मैच नहीं हुआ" संदेश अपेक्षित है।

मुझे ऐसा कोई कारण नहीं दिखाई देता है कि शेड्यूलर पॉड / नोड कॉम्बो से नाखुश हो ... कोई ऐसा पोर्ट नहीं है जो पॉडस्पेक में संघर्ष कर सकता है, नोड अकुशल या दागी नहीं है, और पर्याप्त संसाधन हैं

ठीक है मैंने सभी 3 अनुसूचियों को फिर से शुरू किया (अगर हम वहां कुछ दिलचस्प देख सकते हैं तो 4 के लिए लॉजेल बदल दिया)। हालांकि, इसने इस मुद्दे को ठीक कर दिया

% kubectl get ds --all-namespaces
NAMESPACE     NAME                       DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                     AGE
falco         falco-daemonset            13        13        13      13           13          <none>                            338d
kube-system   audit-webhook-deployment   3         3         3       3            3           node-role.kubernetes.io/master=   175d
kube-system   calico-node                13        13        13      13           13          kubernetes.io/os=linux            36d
kube-system   kops-controller            3         3         3       3            3           node-role.kubernetes.io/master=   194d
kube-system   metricbeat                 6         6         6       6            6           <none>                            36d
kube-system   openstack-cloud-provider   3         3         3       3            3           node-role.kubernetes.io/master=   338d
logging       fluent-bit                 13        13        13      13           13          <none>                            338d
monitoring    node-exporter              13        13        13      13           13          kubernetes.io/os=linux            59d
volume        csi-cinder-nodeplugin      6         6         6       6            6           <none>                            239d
weave         weave-scope-agent          13        13        13      13           13          <none>                            194d
weave         weavescope-iowait-plugin   6         6         6       6            6           <none>                            194d

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

cc @ kubernetes / sig-अनुसूचन-कीड़े @ आह-जी

हम इसी तरह के मुद्दे को v1.18.3 पर देखते हैं, डेमोंसेट पॉड्स के लिए एक नोड निर्धारित नहीं किया जा सकता है।
पुनः आरंभ अनुसूचक मदद करता है।

[root@tesla-cb0434-csfp1-csfp1-control-03 ~]# kubectl get pod -A|grep Pending
kube-system   coredns-vc5ws                                                 0/1     Pending   0          2d16h
kube-system   local-volume-provisioner-mwk88                                0/1     Pending   0          2d16h
kube-system   svcwatcher-ltqb6                                              0/1     Pending   0          2d16h
ncms          bcmt-api-hfzl6                                                0/1     Pending   0          2d16h
ncms          bcmt-yum-repo-589d8bb756-5zbvh                                0/1     Pending   0          2d16h
[root@tesla-cb0434-csfp1-csfp1-control-03 ~]# kubectl get ds -A
NAMESPACE     NAME                       DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                   AGE
kube-system   coredns                    3         3         2       3            2           is_control=true                 2d16h
kube-system   danmep-cleaner             0         0         0       0            0           cbcs.nokia.com/danm_node=true   2d16h
kube-system   kube-proxy                 8         8         8       8            8           <none>                          2d16h
kube-system   local-volume-provisioner   8         8         7       8            7           <none>                          2d16h
kube-system   netwatcher                 0         0         0       0            0           cbcs.nokia.com/danm_node=true   2d16h
kube-system   sriov-device-plugin        0         0         0       0            0           sriov=enabled                   2d16h
kube-system   svcwatcher                 3         3         2       3            2           is_control=true                 2d16h
ncms          bcmt-api                   3         3         0       3            0           is_control=true                 2d16h
[root@tesla-cb0434-csfp1-csfp1-control-03 ~]# kubectl get node
NAME                                  STATUS   ROLES    AGE     VERSION
tesla-cb0434-csfp1-csfp1-control-01   Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-control-02   Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-control-03   Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-edge-01      Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-edge-02      Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-worker-01    Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-worker-02    Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-worker-03    Ready    <none>   2d16h   v1.18.3

डिबग करने का तरीका जाने बिना डिबग करना मुश्किल है। क्या आपके पास शेड्यूल पॉड को विफल करने के लिए किसी भी संयोग से शेड्यूलर लॉग हैं?

ठीक है मैंने सभी 3 अनुसूचियों को फिर से शुरू किया

मुझे लगता है कि उनमें से केवल एक का नाम default-scheduler , सही है?

अगर हम वहाँ कुछ दिलचस्प देख सकते हैं तो बदला हुआ 4

क्या आपने जो देखा, उसे साझा कर सकते हैं?

9 पर सेट करें, लेकिन ऐसा लगता है कि अधिक दिलचस्प कुछ नहीं है, नीचे लॉग लूपिंग हैं।

I0601 01:45:05.039373       1 generic_scheduler.go:290] Preemption will not help schedule pod kube-system/coredns-vc5ws on any node.
I0601 01:45:05.039437       1 factory.go:462] Unable to schedule kube-system/coredns-vc5ws: no fit: 0/8 nodes are available: 7 node(s) didn't match node selector.; waiting
I0601 01:45:05.039494       1 scheduler.go:776] Updating pod condition for kube-system/coredns-vc5ws to (PodScheduled==False, Reason=Unschedulable)

हाँ, मैं एक ही पंक्ति से अधिक कुछ भी नहीं देख सकता था

no fit: 0/8 nodes are available: 7 node(s) didn't match node selector.; waiting

अजीब बात यह है कि लॉग संदेश केवल 7 नोड्स के लिए परिणाम दिखा रहा है, जैसे कि https://github.com/kubernetes/kubernetes/issues/91340 में रिपोर्ट की गई समस्या

/ cc @ कदमी

@ आह-जी यह उसी मुद्दे की तरह दिखता है जो मैंने वहां रिपोर्ट किया था, ऐसा लगता है जैसे हमारे पास या तो एक फिल्टर प्लगइन है जो हमेशा अपनी त्रुटि या किसी अन्य स्थिति की रिपोर्ट नहीं करता है जो मुझे अनुमान लगाने में चुपचाप विफल हो रहा है

ध्यान दें कि मेरे अंक में, अनुसूचक को फिर से शुरू करना भी तय है (जैसा कि इस सूत्र में भी उल्लेख किया गया है https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-636360092)

मेरा भी एक डेमोंसेट के बारे में था, इसलिए मुझे लगता है कि यह एक डुप्लिकेट है। अगर ऐसा है तो हम इसे बंद कर सकते हैं और https://github.com/kubernetes/kubernetes/issues/91340 पर चर्चा जारी रख सकते हैं

वैसे भी शेड्यूलर को अधिक वर्बोज़ लॉगिंग विकल्प की आवश्यकता होती है, यदि इन मुद्दों को डीबग करना असंभव है, अगर यह लॉग के बारे में नहीं है तो यह क्या करता है

@zetaab +1, अनुसूचक अपनी वर्तमान लॉगिंग क्षमताओं में महत्वपूर्ण सुधार का उपयोग कर सकता है। यह एक उन्नयन है जिसका अर्थ है मैं थोड़ी देर के लिए निपटने के लिए और मैंने आखिरकार इसके लिए एक मुद्दा खोला है: https://github.com/kubernetes/kubernetes/issues/91633

/ असाइन

मैं इस पर गौर कर रहा हूं। कुछ सवाल मुझे केस को कम करने में मदद करते हैं। मैं अभी तक पुन: पेश नहीं कर पाया हूं।

• पहले क्या बनाया गया था: डेमोंसेट या नोड?
• क्या आप डिफ़ॉल्ट प्रोफ़ाइल का उपयोग कर रहे हैं?

• क्या आपके पास एक्सटेंडर हैं?

डेमोंसेट से पहले नोड बनाए गए थे।
मान लें कि हमने डिफ़ॉल्ट प्रोफ़ाइल का उपयोग किया है, तो आप किस प्रोफ़ाइल का मतलब और जांचना चाहते हैं?
कोई विस्तार नहीं।

    command:
    - /usr/local/bin/kube-scheduler
    - --address=127.0.0.1
    - --kubeconfig=/etc/kubernetes/kube-scheduler.kubeconfig
    - --profiling=false
    - --v=1

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

हां, वे झंडे शेड्यूलर को डिफ़ॉल्ट प्रोफ़ाइल के साथ चलाएंगे। मैं देखता रहूंगा। मैं अभी भी पुन: पेश नहीं कर सका।

अभी भी कुछ भी नहीं ... कुछ और जो आप उपयोग कर रहे हैं जो आपको लगता है कि प्रभावित हो सकता है? taints, बंदरगाहों, अन्य संसाधन?

इससे जुड़े कुछ प्रयास किए। जब समस्या चालू होती है, तब भी पॉड्स को नोड (परिभाषा के बिना या "नोडनेम" चयनकर्ता के साथ) निर्धारित किया जा सकता है।

यदि Affinity / Antiaffinity का उपयोग करने की कोशिश कर रहे हैं, तो फली नोड के लिए निर्धारित नहीं होती है।

जब समस्या जारी हो तो काम करना:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx
  name: nginx
spec:
  nodeName: master-zone-3-1-1-test-cluster-k8s-local
  containers:
    - image: nginx
      name: nginx
      resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always

एक ही समय में काम नहीं कर रहा है:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx
  name: nginx
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                  - master-zone-3-1-1-test-cluster-k8s-local
  containers:
    - image: nginx
      name: nginx
      resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always

यह भी जब उत्तरार्द्ध की जाँच की तो वे भी काफी दिलचस्प थे:

Warning  FailedScheduling  4m37s (x17 over 26m)  default-scheduler  0/9 nodes are available: 8 node(s) didn't match node selector.
Warning  FailedScheduling  97s (x6 over 3m39s)   default-scheduler  0/8 nodes are available: 8 node(s) didn't match node selector.
Warning  FailedScheduling  53s                   default-scheduler  0/8 nodes are available: 8 node(s) didn't match node selector.
Warning  FailedScheduling  7s (x5 over 32s)      default-scheduler  0/9 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 7 node(s) didn't match node selector.

• पहली घटना तब है जब प्रकट सिर्फ लागू किया गया था (गैर-अनुसूच्य नोड के लिए कुछ भी नहीं किया गया)।
• दूसरा और तीसरा तब था जब नोड को कुब्लेट के साथ हटा दिया गया था और फिर पुनरारंभ किया गया था।
• चौथा आया जब नोड वापस आया। जिस नोड में कोई समस्या थी, वह मास्टर था, इसलिए नोड वहां नहीं जा रहा था (लेकिन यह दिखाता है कि नोड 3 पूर्व की घटनाओं में नहीं पाया गया था)। चौथी घटना के साथ दिलचस्प बात यह है कि अभी भी एक नोड गुम होने की सूचना है। ईवेंट कहता है कि 0/9 नोड्स उपलब्ध हैं, लेकिन विवरण केवल 8 से दिया गया है।

"नोडनेम" एक चयनकर्ता नहीं है। नोडनेम का उपयोग शेड्यूलिंग को बायपास करेगा।

चौथा आया जब नोड वापस आया। जिस नोड में कोई समस्या थी, वह मास्टर था, इसलिए नोड वहां नहीं जा रहा था (लेकिन यह दिखाता है कि नोड 3 पूर्व की घटनाओं में नहीं पाया गया था)। चौथी घटना के साथ दिलचस्प बात यह है कि अभी भी एक नोड गुम होने की सूचना है। ईवेंट कहता है कि 0/9 नोड्स उपलब्ध हैं, लेकिन विवरण केवल 8 से दिया गया है।

आप कह रहे हैं कि जिस कारण से नोड को लापता नोड में शेड्यूल नहीं किया जाना चाहिए था, क्योंकि यह एक मास्टर था?

हम 8 node(s) didn't match node selector 7. को देख रहे हैं। मुझे लगता है कि इस बिंदु पर कोई नोड नहीं हटाया गया था, सही है?

"नोडनेम" एक चयनकर्ता नहीं है। नोडनेम का उपयोग शेड्यूलिंग को बायपास करेगा।

"NodeName" की कोशिश हाईलाइज करने के लिए की गई थी, यह नोड प्रयोग करने योग्य है और अगर चाहिए तो पॉड वहां पहुंच जाता है। तो फली शुरू करने के लिए नोड नोड की असमर्थता नहीं है।

चौथा आया जब नोड वापस आया। जिस नोड में कोई समस्या थी, वह मास्टर था, इसलिए नोड वहां नहीं जा रहा था (लेकिन यह दिखाता है कि नोड 3 पूर्व की घटनाओं में नहीं पाया गया था)। चौथी घटना के साथ दिलचस्प बात यह है कि अभी भी एक नोड गुम होने की सूचना है। ईवेंट कहता है कि 0/9 नोड्स उपलब्ध हैं, लेकिन विवरण केवल 8 से दिया गया है।

आप कह रहे हैं कि जिस कारण से नोड को लापता नोड में शेड्यूल नहीं किया जाना चाहिए था, क्योंकि यह एक मास्टर था?

हम 8 node(s) didn't match node selector 7. को देख रहे हैं। मुझे लगता है कि इस बिंदु पर कोई नोड नहीं हटाया गया था, सही है?

टेस्ट क्लस्टर में 9 नोड हैं; 3 स्वामी और 6 कार्यकर्ता। गैर-काम करने वाले नोड को सफलतापूर्वक शुरू करने से पहले, घटनाओं ने सभी उपलब्ध नोड्स के बारे में जानकारी बताई: 0/8 nodes are available: 8 node(s) didn't match node selector. । लेकिन जब वह नोड जो नोड चयनकर्ता से मेल खाएगा, तो घटना ने 0/9 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 7 node(s) didn't match node selector. व्याख्या को बताया कि 8 हैं जो मेल नहीं खा रहे हैं, लेकिन नौवें के बारे में कुछ भी नहीं बताता है (जो कि पिछली घटना पर स्वीकार किया गया था)।

तो घटना की स्थिति:

• पहली घटना: 9 नोड्स उपलब्ध, त्रुटि डेमोंसेट के साथ देखी गई
• दूसरी और तीसरी घटना: 8 नोड्स उपलब्ध। जो फली प्राप्त नहीं कर रहा था, वह पुनः आरंभ हो रहा था
• 4 वीं घटना: 9 नोड्स उपलब्ध (इसलिए एक को फिर से शुरू किया गया)।

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

"NodeName" की कोशिश हाईलाइज करने के लिए की गई थी, यह नोड प्रयोग करने योग्य है और अगर चाहिए तो पॉड वहां पहुंच जाता है। तो फली शुरू करने के लिए नोड नोड की असमर्थता नहीं है।

ध्यान दें कि एक नोड पर ओवर-कमिंग के खिलाफ कुछ भी नहीं है, लेकिन अनुसूचक। तो यह वास्तव में बहुत कुछ नहीं दिखाता है।

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

मेरा सवाल है: क्या 9 वीं नोड शुरू से ही दागी थी? मैं उस राज्य (या 2) तक पहुँचने के लिए (1) प्रतिलिपि प्रस्तुत करने योग्य चरणों की तलाश में हूँ जहाँ बग हो सकता है।

मेरा सवाल है: क्या 9 वीं नोड शुरू से ही दागी थी? मैं उस राज्य (या 2) तक पहुँचने के लिए (1) प्रतिलिपि प्रस्तुत करने योग्य चरणों की तलाश में हूँ जहाँ बग हो सकता है।

हां, इस मामले में हर समय तनाव था, क्योंकि गैर-प्राप्त नोड मास्टर था। लेकिन हमने स्वामी और श्रमिकों दोनों पर एक ही मुद्दा देखा है।

फिर भी कोई विचार नहीं है कि मुद्दा कहां से आता है, बस नोड के कम से कम मनोरंजन और नोड को पुनरारंभ करने से समस्या ठीक हो रही है। लेकिन उन चीजों को ठीक करने के लिए "कठिन" तरीके हैं।

लंबा शॉट, लेकिन अगर आप इसे फिर से चलाते हैं ... तो क्या आप जांच सकते हैं कि नोड के लिए कोई नामांकित पॉड्स हैं जो नहीं दिखाते हैं?

मैं संभावित परिदृश्यों के बारे में सोचते हुए प्रश्न पोस्ट कर रहा हूं:

• क्या आपके क्लस्टर में अन्य मास्टर नोड्स हैं?
• क्या आपके पास एक्सटेंडर हैं?

* Do you have other master nodes in your cluster?

सभी क्लुसर के 3 स्वामी हैं (इसलिए उन का पुनः आरंभ करना आसान है)

* Do you have extenders?

नहीं।

आज एक दिलचस्प बात देखने को मिली: मेरे पास क्लस्टर था जहां एक मास्टर को डेमोंसेट से पॉड नहीं मिल रहा था। हमारे पास उपयोग में ChaosMonkey है, जिसने कार्यकर्ता नोड्स में से एक को समाप्त कर दिया। यह दिलचस्प है, इसने गुरु को जाने के लिए फली बनाई जो इसे पहले प्राप्त नहीं कर रहा था। तो किसी भी तरह समस्याग्रस्त की तुलना में अन्य नोड को हटाने से उस बिंदु पर समस्या ठीक हो रही थी।

उस "फिक्स" के कारण मुझे नामांकित पॉड्स के बारे में जवाब देने में सक्षम होने के लिए reoccur करने के लिए समस्या का इंतजार करना होगा।

मैं अब उलझन में हूँ ... क्या आपका डेमोंसेट मास्टर नोड्स के लिए तनाव को सहन करता है? दूसरे शब्दों में ... क्या आपके लिए बग केवल शेड्यूलिंग ईवेंट है या यह भी कि फली शेड्यूल होना चाहिए?

मुद्दा यह है, कि नोड शेड्यूलर द्वारा नहीं पाया गया है, यहां तक ​​कि कम से कम एक मिलान आत्मीयता (या एंटीफिनिटी) सेटिंग्स भी हैं।

इसलिए मैंने कहा कि दागी त्रुटि की उम्मीद है, और पहले से ही पहली घटना में होनी चाहिए थी (क्योंकि दागी आत्मीयता मानदंडों का हिस्सा नहीं है)

समझ लिया। मैं यह सुनिश्चित करने के लिए आपके सेटअप की पुष्टि करने की कोशिश कर रहा था कि मुझे कुछ याद नहीं है।

मुझे नहीं लगता कि नोड अनुसूचक द्वारा "अनदेखी" है। यह देखते हुए कि हम 0/9 nodes are available , हम यह निष्कर्ष निकाल सकते हैं कि नोड वास्तव में कैश में है। यह और अधिक पसंद है कि अकारण कारण कहीं खो जाता है, इसलिए हम इसे घटना में शामिल नहीं करते हैं।

सच है, कुल संख्या हमेशा वास्तविक नोड गणना के साथ मेल खाती है। सभी नोड्स पर बस अधिक वर्णनात्मक घटना पाठ नहीं दिया गया है, लेकिन जैसा कि आपने उल्लेख किया है अलग मुद्दा हो सकता है।

क्या आप अपने क्यूब-शेड्यूलर लॉग को देखने में सक्षम हैं? जो कुछ भी प्रासंगिक लगता है?

मुझे लगता है कि @zetaab ने सफलता के बिना देखने की कोशिश की। मैं कोशिश कर सकता हूं जब समस्या फिर से हो (और साथ ही उस नामांकित फली चीज से पहले पूछा जाए)

यदि संभव हो तो, 1.18.5 भी चलाएं, यदि हमने अनजाने में समस्या को ठीक कर दिया है।

अगर आप किसी भी अधिक लॉग की जरूरत है, तो मैं अपने परीक्षण क्लस्टर पर इस मज़बूती से पुन: पेश करने में सक्षम हूं

@dilyevsky कृपया

यह प्रतीत होता है कि डीएस फली के लिए नोड का सिर्फ मेटाडेटा.नाम है ... अजीब। यहाँ फली यम:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    scheduler.alpha.kubernetes.io/critical-pod: ""
  creationTimestamp: "2020-07-09T23:17:53Z"
  generateName: cilium-
  labels:
    controller-revision-hash: 6c94db8bb8
    k8s-app: cilium
    pod-template-generation: "1"
  managedFields:
    # managed fields crap
  name: cilium-d5n4f
  namespace: kube-system
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: DaemonSet
    name: cilium
    uid: 0f00e8af-eb19-4985-a940-a02fa84fcbc5
  resourceVersion: "2840"
  selfLink: /api/v1/namespaces/kube-system/pods/cilium-d5n4f
  uid: e3f7d566-ee5b-4557-8d1b-f0964cde2f22
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchFields:
          - key: metadata.name
            operator: In
            values:
            - us-central1-dilyevsky-master-qmwnl
  containers:
  - args:
    - --config-dir=/tmp/cilium/config-map
    command:
    - cilium-agent
    env:
    - name: K8S_NODE_NAME
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: spec.nodeName
    - name: CILIUM_K8S_NAMESPACE
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.namespace
    - name: CILIUM_FLANNEL_MASTER_DEVICE
      valueFrom:
        configMapKeyRef:
          key: flannel-master-device
          name: cilium-config
          optional: true
    - name: CILIUM_FLANNEL_UNINSTALL_ON_EXIT
      valueFrom:
        configMapKeyRef:
          key: flannel-uninstall-on-exit
          name: cilium-config
          optional: true
    - name: CILIUM_CLUSTERMESH_CONFIG
      value: /var/lib/cilium/clustermesh/
    - name: CILIUM_CNI_CHAINING_MODE
      valueFrom:
        configMapKeyRef:
          key: cni-chaining-mode
          name: cilium-config
          optional: true
    - name: CILIUM_CUSTOM_CNI_CONF
      valueFrom:
        configMapKeyRef:
          key: custom-cni-conf
          name: cilium-config
          optional: true
    image: docker.io/cilium/cilium:v1.7.6
    imagePullPolicy: IfNotPresent
    lifecycle:
      postStart:
        exec:
          command:
          - /cni-install.sh
          - --enable-debug=false
      preStop:
        exec:
          command:
          - /cni-uninstall.sh
    livenessProbe:
      exec:
        command:
        - cilium
        - status
        - --brief
      failureThreshold: 10
      initialDelaySeconds: 120
      periodSeconds: 30
      successThreshold: 1
      timeoutSeconds: 5
    name: cilium-agent
    readinessProbe:
      exec:
        command:
        - cilium
        - status
        - --brief
      failureThreshold: 3
      initialDelaySeconds: 5
      periodSeconds: 30
      successThreshold: 1
      timeoutSeconds: 5
    resources: {}
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
        - SYS_MODULE
      privileged: true
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/cilium
      name: cilium-run
    - mountPath: /host/opt/cni/bin
      name: cni-path
    - mountPath: /host/etc/cni/net.d
      name: etc-cni-netd
    - mountPath: /var/lib/cilium/clustermesh
      name: clustermesh-secrets
      readOnly: true
    - mountPath: /tmp/cilium/config-map
      name: cilium-config-path
      readOnly: true
    - mountPath: /lib/modules
      name: lib-modules
      readOnly: true
    - mountPath: /run/xtables.lock
      name: xtables-lock
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: cilium-token-j74lr
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  hostNetwork: true
  initContainers:
  - command:
    - /init-container.sh
    env:
    - name: CILIUM_ALL_STATE
      valueFrom:
        configMapKeyRef:
          key: clean-cilium-state
          name: cilium-config
          optional: true
    - name: CILIUM_BPF_STATE
      valueFrom:
        configMapKeyRef:
          key: clean-cilium-bpf-state
          name: cilium-config
          optional: true
    - name: CILIUM_WAIT_BPF_MOUNT
      valueFrom:
        configMapKeyRef:
          key: wait-bpf-mount
          name: cilium-config
          optional: true
    image: docker.io/cilium/cilium:v1.7.6
    imagePullPolicy: IfNotPresent
    name: clean-cilium-state
    resources: {}
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
      privileged: true
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/cilium
      name: cilium-run
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: cilium-token-j74lr
      readOnly: true
  priority: 2000001000
  priorityClassName: system-node-critical
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: cilium
  serviceAccountName: cilium
  terminationGracePeriodSeconds: 1
  tolerations:
  - operator: Exists
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/disk-pressure
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/memory-pressure
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/pid-pressure
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/unschedulable
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/network-unavailable
    operator: Exists
  volumes:
  - hostPath:
      path: /var/run/cilium
      type: DirectoryOrCreate
    name: cilium-run
  - hostPath:
      path: /opt/cni/bin
      type: DirectoryOrCreate
    name: cni-path
  - hostPath:
      path: /etc/cni/net.d
      type: DirectoryOrCreate
    name: etc-cni-netd
  - hostPath:
      path: /lib/modules
      type: ""
    name: lib-modules
  - hostPath:
      path: /run/xtables.lock
      type: FileOrCreate
    name: xtables-lock
  - name: clustermesh-secrets
    secret:
      defaultMode: 420
      optional: true
      secretName: cilium-clustermesh
  - configMap:
      defaultMode: 420
      name: cilium-config
    name: cilium-config-path
  - name: cilium-token-j74lr
    secret:
      defaultMode: 420
      secretName: cilium-token-j74lr
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2020-07-09T23:17:53Z"
    message: '0/6 nodes are available: 5 node(s) didn''t match node selector.'
    reason: Unschedulable
    status: "False"
    type: PodScheduled
  phase: Pending
  qosClass: BestEffort

जिस तरह से मैं इसे पुन: पेश करता हूं वह 3 मास्टर्स और 3 वर्कर नोड्स (क्लस्टर एपीआई का उपयोग करके) और सिलियम 1.7.6 के साथ नए क्लस्टर को कताई करके है:

---
# Source: cilium/charts/agent/templates/serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cilium
  namespace: kube-system
---
# Source: cilium/charts/operator/templates/serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cilium-operator
  namespace: kube-system
---
# Source: cilium/charts/config/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: cilium-config
  namespace: kube-system
data:

  # Identity allocation mode selects how identities are shared between cilium
  # nodes by setting how they are stored. The options are "crd" or "kvstore".
  # - "crd" stores identities in kubernetes as CRDs (custom resource definition).
  #   These can be queried with:
  #     kubectl get ciliumid
  # - "kvstore" stores identities in a kvstore, etcd or consul, that is
  #   configured below. Cilium versions before 1.6 supported only the kvstore
  #   backend. Upgrades from these older cilium versions should continue using
  #   the kvstore by commenting out the identity-allocation-mode below, or
  #   setting it to "kvstore".
  identity-allocation-mode: crd

  # If you want to run cilium in debug mode change this value to true
  debug: "false"

  # Enable IPv4 addressing. If enabled, all endpoints are allocated an IPv4
  # address.
  enable-ipv4: "true"

  # Enable IPv6 addressing. If enabled, all endpoints are allocated an IPv6
  # address.
  enable-ipv6: "false"

  # If you want cilium monitor to aggregate tracing for packets, set this level
  # to "low", "medium", or "maximum". The higher the level, the less packets
  # that will be seen in monitor output.
  monitor-aggregation: medium

  # The monitor aggregation interval governs the typical time between monitor
  # notification events for each allowed connection.
  #
  # Only effective when monitor aggregation is set to "medium" or higher.
  monitor-aggregation-interval: 5s

  # The monitor aggregation flags determine which TCP flags which, upon the
  # first observation, cause monitor notifications to be generated.
  #
  # Only effective when monitor aggregation is set to "medium" or higher.
  monitor-aggregation-flags: all

  # ct-global-max-entries-* specifies the maximum number of connections
  # supported across all endpoints, split by protocol: tcp or other. One pair
  # of maps uses these values for IPv4 connections, and another pair of maps
  # use these values for IPv6 connections.
  #
  # If these values are modified, then during the next Cilium startup the
  # tracking of ongoing connections may be disrupted. This may lead to brief
  # policy drops or a change in loadbalancing decisions for a connection.
  #
  # For users upgrading from Cilium 1.2 or earlier, to minimize disruption
  # during the upgrade process, comment out these options.
  bpf-ct-global-tcp-max: "524288"
  bpf-ct-global-any-max: "262144"

  # bpf-policy-map-max specified the maximum number of entries in endpoint
  # policy map (per endpoint)
  bpf-policy-map-max: "16384"

  # Pre-allocation of map entries allows per-packet latency to be reduced, at
  # the expense of up-front memory allocation for the entries in the maps. The
  # default value below will minimize memory usage in the default installation;
  # users who are sensitive to latency may consider setting this to "true".
  #
  # This option was introduced in Cilium 1.4. Cilium 1.3 and earlier ignore
  # this option and behave as though it is set to "true".
  #
  # If this value is modified, then during the next Cilium startup the restore
  # of existing endpoints and tracking of ongoing connections may be disrupted.
  # This may lead to policy drops or a change in loadbalancing decisions for a
  # connection for some time. Endpoints may need to be recreated to restore
  # connectivity.
  #
  # If this option is set to "false" during an upgrade from 1.3 or earlier to
  # 1.4 or later, then it may cause one-time disruptions during the upgrade.
  preallocate-bpf-maps: "false"

  # Regular expression matching compatible Istio sidecar istio-proxy
  # container image names
  sidecar-istio-proxy-image: "cilium/istio_proxy"

  # Encapsulation mode for communication between nodes
  # Possible values:
  #   - disabled
  #   - vxlan (default)
  #   - geneve
  tunnel: vxlan

  # Name of the cluster. Only relevant when building a mesh of clusters.
  cluster-name: default

  # DNS Polling periodically issues a DNS lookup for each `matchName` from
  # cilium-agent. The result is used to regenerate endpoint policy.
  # DNS lookups are repeated with an interval of 5 seconds, and are made for
  # A(IPv4) and AAAA(IPv6) addresses. Should a lookup fail, the most recent IP
  # data is used instead. An IP change will trigger a regeneration of the Cilium
  # policy for each endpoint and increment the per cilium-agent policy
  # repository revision.
  #
  # This option is disabled by default starting from version 1.4.x in favor
  # of a more powerful DNS proxy-based implementation, see [0] for details.
  # Enable this option if you want to use FQDN policies but do not want to use
  # the DNS proxy.
  #
  # To ease upgrade, users may opt to set this option to "true".
  # Otherwise please refer to the Upgrade Guide [1] which explains how to
  # prepare policy rules for upgrade.
  #
  # [0] http://docs.cilium.io/en/stable/policy/language/#dns-based
  # [1] http://docs.cilium.io/en/stable/install/upgrade/#changes-that-may-require-action
  tofqdns-enable-poller: "false"

  # wait-bpf-mount makes init container wait until bpf filesystem is mounted
  wait-bpf-mount: "false"

  masquerade: "true"
  enable-xt-socket-fallback: "true"
  install-iptables-rules: "true"
  auto-direct-node-routes: "false"
  kube-proxy-replacement:  "probe"
  enable-host-reachable-services: "false"
  enable-external-ips: "false"
  enable-node-port: "false"
  node-port-bind-protection: "true"
  enable-auto-protect-node-port-range: "true"
  enable-endpoint-health-checking: "true"
  enable-well-known-identities: "false"
  enable-remote-node-identity: "true"
---
# Source: cilium/charts/agent/templates/clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cilium
rules:
- apiGroups:
  - networking.k8s.io
  resources:
  - networkpolicies
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - discovery.k8s.io
  resources:
  - endpointslices
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - namespaces
  - services
  - nodes
  - endpoints
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch
  - update
- apiGroups:
  - ""
  resources:
  - nodes
  - nodes/status
  verbs:
  - patch
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - create
  - get
  - list
  - watch
  - update
- apiGroups:
  - cilium.io
  resources:
  - ciliumnetworkpolicies
  - ciliumnetworkpolicies/status
  - ciliumclusterwidenetworkpolicies
  - ciliumclusterwidenetworkpolicies/status
  - ciliumendpoints
  - ciliumendpoints/status
  - ciliumnodes
  - ciliumnodes/status
  - ciliumidentities
  - ciliumidentities/status
  verbs:
  - '*'
---
# Source: cilium/charts/operator/templates/clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cilium-operator
rules:
- apiGroups:
  - ""
  resources:
  # to automatically delete [core|kube]dns pods so that are starting to being
  # managed by Cilium
  - pods
  verbs:
  - get
  - list
  - watch
  - delete
- apiGroups:
  - discovery.k8s.io
  resources:
  - endpointslices
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  # to automatically read from k8s and import the node's pod CIDR to cilium's
  # etcd so all nodes know how to reach another pod running in in a different
  # node.
  - nodes
  # to perform the translation of a CNP that contains `ToGroup` to its endpoints
  - services
  - endpoints
  # to check apiserver connectivity
  - namespaces
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - cilium.io
  resources:
  - ciliumnetworkpolicies
  - ciliumnetworkpolicies/status
  - ciliumclusterwidenetworkpolicies
  - ciliumclusterwidenetworkpolicies/status
  - ciliumendpoints
  - ciliumendpoints/status
  - ciliumnodes
  - ciliumnodes/status
  - ciliumidentities
  - ciliumidentities/status
  verbs:
  - '*'
---
# Source: cilium/charts/agent/templates/clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cilium
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cilium
subjects:
- kind: ServiceAccount
  name: cilium
  namespace: kube-system
---
# Source: cilium/charts/operator/templates/clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cilium-operator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cilium-operator
subjects:
- kind: ServiceAccount
  name: cilium-operator
  namespace: kube-system
---
# Source: cilium/charts/agent/templates/daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    k8s-app: cilium
  name: cilium
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: cilium
  template:
    metadata:
      annotations:
        # This annotation plus the CriticalAddonsOnly toleration makes
        # cilium to be a critical pod in the cluster, which ensures cilium
        # gets priority scheduling.
        # https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/
        scheduler.alpha.kubernetes.io/critical-pod: ""
      labels:
        k8s-app: cilium
    spec:
      containers:
      - args:
        - --config-dir=/tmp/cilium/config-map
        command:
        - cilium-agent
        livenessProbe:
          exec:
            command:
            - cilium
            - status
            - --brief
          failureThreshold: 10
          # The initial delay for the liveness probe is intentionally large to
          # avoid an endless kill & restart cycle if in the event that the initial
          # bootstrapping takes longer than expected.
          initialDelaySeconds: 120
          periodSeconds: 30
          successThreshold: 1
          timeoutSeconds: 5
        readinessProbe:
          exec:
            command:
            - cilium
            - status
            - --brief
          failureThreshold: 3
          initialDelaySeconds: 5
          periodSeconds: 30
          successThreshold: 1
          timeoutSeconds: 5
        env:
        - name: K8S_NODE_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: spec.nodeName
        - name: CILIUM_K8S_NAMESPACE
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        - name: CILIUM_FLANNEL_MASTER_DEVICE
          valueFrom:
            configMapKeyRef:
              key: flannel-master-device
              name: cilium-config
              optional: true
        - name: CILIUM_FLANNEL_UNINSTALL_ON_EXIT
          valueFrom:
            configMapKeyRef:
              key: flannel-uninstall-on-exit
              name: cilium-config
              optional: true
        - name: CILIUM_CLUSTERMESH_CONFIG
          value: /var/lib/cilium/clustermesh/
        - name: CILIUM_CNI_CHAINING_MODE
          valueFrom:
            configMapKeyRef:
              key: cni-chaining-mode
              name: cilium-config
              optional: true
        - name: CILIUM_CUSTOM_CNI_CONF
          valueFrom:
            configMapKeyRef:
              key: custom-cni-conf
              name: cilium-config
              optional: true
        image: "docker.io/cilium/cilium:v1.7.6"
        imagePullPolicy: IfNotPresent
        lifecycle:
          postStart:
            exec:
              command:
              - "/cni-install.sh"
              - "--enable-debug=false"
          preStop:
            exec:
              command:
              - /cni-uninstall.sh
        name: cilium-agent
        securityContext:
          capabilities:
            add:
            - NET_ADMIN
            - SYS_MODULE
          privileged: true
        volumeMounts:
        - mountPath: /var/run/cilium
          name: cilium-run
        - mountPath: /host/opt/cni/bin
          name: cni-path
        - mountPath: /host/etc/cni/net.d
          name: etc-cni-netd
        - mountPath: /var/lib/cilium/clustermesh
          name: clustermesh-secrets
          readOnly: true
        - mountPath: /tmp/cilium/config-map
          name: cilium-config-path
          readOnly: true
          # Needed to be able to load kernel modules
        - mountPath: /lib/modules
          name: lib-modules
          readOnly: true
        - mountPath: /run/xtables.lock
          name: xtables-lock
      hostNetwork: true
      initContainers:
      - command:
        - /init-container.sh
        env:
        - name: CILIUM_ALL_STATE
          valueFrom:
            configMapKeyRef:
              key: clean-cilium-state
              name: cilium-config
              optional: true
        - name: CILIUM_BPF_STATE
          valueFrom:
            configMapKeyRef:
              key: clean-cilium-bpf-state
              name: cilium-config
              optional: true
        - name: CILIUM_WAIT_BPF_MOUNT
          valueFrom:
            configMapKeyRef:
              key: wait-bpf-mount
              name: cilium-config
              optional: true
        image: "docker.io/cilium/cilium:v1.7.6"
        imagePullPolicy: IfNotPresent
        name: clean-cilium-state
        securityContext:
          capabilities:
            add:
            - NET_ADMIN
          privileged: true
        volumeMounts:
        - mountPath: /var/run/cilium
          name: cilium-run
      restartPolicy: Always
      priorityClassName: system-node-critical
      serviceAccount: cilium
      serviceAccountName: cilium
      terminationGracePeriodSeconds: 1
      tolerations:
      - operator: Exists
      volumes:
        # To keep state between restarts / upgrades
      - hostPath:
          path: /var/run/cilium
          type: DirectoryOrCreate
        name: cilium-run
      # To install cilium cni plugin in the host
      - hostPath:
          path:  /opt/cni/bin
          type: DirectoryOrCreate
        name: cni-path
        # To install cilium cni configuration in the host
      - hostPath:
          path: /etc/cni/net.d
          type: DirectoryOrCreate
        name: etc-cni-netd
        # To be able to load kernel modules
      - hostPath:
          path: /lib/modules
        name: lib-modules
        # To access iptables concurrently with other processes (e.g. kube-proxy)
      - hostPath:
          path: /run/xtables.lock
          type: FileOrCreate
        name: xtables-lock
        # To read the clustermesh configuration
      - name: clustermesh-secrets
        secret:
          defaultMode: 420
          optional: true
          secretName: cilium-clustermesh
        # To read the configuration from the config map
      - configMap:
          name: cilium-config
        name: cilium-config-path
  updateStrategy:
    rollingUpdate:
      maxUnavailable: 2
    type: RollingUpdate
---
# Source: cilium/charts/operator/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    io.cilium/app: operator
    name: cilium-operator
  name: cilium-operator
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      io.cilium/app: operator
      name: cilium-operator
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      annotations:
      labels:
        io.cilium/app: operator
        name: cilium-operator
    spec:
      containers:
      - args:
        - --debug=$(CILIUM_DEBUG)
        - --identity-allocation-mode=$(CILIUM_IDENTITY_ALLOCATION_MODE)
        - --synchronize-k8s-nodes=true
        command:
        - cilium-operator
        env:
        - name: CILIUM_K8S_NAMESPACE
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        - name: K8S_NODE_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: spec.nodeName
        - name: CILIUM_DEBUG
          valueFrom:
            configMapKeyRef:
              key: debug
              name: cilium-config
              optional: true
        - name: CILIUM_CLUSTER_NAME
          valueFrom:
            configMapKeyRef:
              key: cluster-name
              name: cilium-config
              optional: true
        - name: CILIUM_CLUSTER_ID
          valueFrom:
            configMapKeyRef:
              key: cluster-id
              name: cilium-config
              optional: true
        - name: CILIUM_IPAM
          valueFrom:
            configMapKeyRef:
              key: ipam
              name: cilium-config
              optional: true
        - name: CILIUM_DISABLE_ENDPOINT_CRD
          valueFrom:
            configMapKeyRef:
              key: disable-endpoint-crd
              name: cilium-config
              optional: true
        - name: CILIUM_KVSTORE
          valueFrom:
            configMapKeyRef:
              key: kvstore
              name: cilium-config
              optional: true
        - name: CILIUM_KVSTORE_OPT
          valueFrom:
            configMapKeyRef:
              key: kvstore-opt
              name: cilium-config
              optional: true
        - name: AWS_ACCESS_KEY_ID
          valueFrom:
            secretKeyRef:
              key: AWS_ACCESS_KEY_ID
              name: cilium-aws
              optional: true
        - name: AWS_SECRET_ACCESS_KEY
          valueFrom:
            secretKeyRef:
              key: AWS_SECRET_ACCESS_KEY
              name: cilium-aws
              optional: true
        - name: AWS_DEFAULT_REGION
          valueFrom:
            secretKeyRef:
              key: AWS_DEFAULT_REGION
              name: cilium-aws
              optional: true
        - name: CILIUM_IDENTITY_ALLOCATION_MODE
          valueFrom:
            configMapKeyRef:
              key: identity-allocation-mode
              name: cilium-config
              optional: true
        image: "docker.io/cilium/operator:v1.7.6"
        imagePullPolicy: IfNotPresent
        name: cilium-operator
        livenessProbe:
          httpGet:
            host: '127.0.0.1'
            path: /healthz
            port: 9234
            scheme: HTTP
          initialDelaySeconds: 60
          periodSeconds: 10
          timeoutSeconds: 3
      hostNetwork: true
      restartPolicy: Always
      serviceAccount: cilium-operator
      serviceAccountName: cilium-operator

यहाँ अनुसूचक लॉग है:
I0709 23:08:22.055830 1 registry.go:150] Registering EvenPodsSpread predicate and priority function I0709 23:08:22.056081 1 registry.go:150] Registering EvenPodsSpread predicate and priority function I0709 23:08:23.137451 1 serving.go:313] Generated self-signed cert in-memory W0709 23:08:33.843509 1 authentication.go:297] Error looking up in-cluster authentication configuration: etcdserver: request timed out W0709 23:08:33.843671 1 authentication.go:298] Continuing without authentication configuration. This may treat all requests as anonymous. W0709 23:08:33.843710 1 authentication.go:299] To require authentication configuration lookup to succeed, set --authentication-tolerate-lookup-failure=false I0709 23:08:33.911805 1 registry.go:150] Registering EvenPodsSpread predicate and priority function I0709 23:08:33.911989 1 registry.go:150] Registering EvenPodsSpread predicate and priority function W0709 23:08:33.917999 1 authorization.go:47] Authorization is disabled W0709 23:08:33.918162 1 authentication.go:40] Authentication is disabled I0709 23:08:33.918238 1 deprecated_insecure_serving.go:51] Serving healthz insecurely on [::]:10251 I0709 23:08:33.925860 1 configmap_cafile_content.go:202] Starting client-ca::kube-system::extension-apiserver-authentication::client-ca-file I0709 23:08:33.926013 1 shared_informer.go:223] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::client-ca-file I0709 23:08:33.930685 1 secure_serving.go:178] Serving securely on 127.0.0.1:10259 I0709 23:08:33.936198 1 tlsconfig.go:240] Starting DynamicServingCertificateController I0709 23:08:34.026382 1 shared_informer.go:230] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::client-ca-file I0709 23:08:34.036998 1 leaderelection.go:242] attempting to acquire leader lease kube-system/kube-scheduler... I0709 23:08:50.597201 1 leaderelection.go:252] successfully acquired lease kube-system/kube-scheduler E0709 23:08:50.658551 1 factory.go:503] pod: kube-system/coredns-66bff467f8-9rjvd is already present in the active queue E0709 23:12:27.673854 1 factory.go:503] pod kube-system/cilium-vv466 is already present in the backoff queue E0709 23:12:58.099432 1 leaderelection.go:320] error retrieving resource lock kube-system/kube-scheduler: etcdserver: leader changed

शेड्यूलर पॉड्स को पुनरारंभ करने के बाद, लंबित पॉड तुरंत शेड्यूल करता है।

आपको कौन-से पॉड इवेंट मिलते हैं? क्या आप जानते हैं कि अगर नोड में टैंट हैं
यह कहाँ निर्धारित नहीं है? क्या यह केवल मास्टर नोड्स या किसी भी के लिए विफल रहता है
नोड्स? क्या नोड में पर्याप्त जगह है?

थू पर, जुलाई, 9, 2020, 7:49 बजे dilyevsky, सूचनाएं @github.com
लिखा था:

ऐसा प्रतीत होता है कि डीएस पॉड के लिए नोड का सिर्फ मेटाडेटा। नाम ...
अजीब। यहाँ फली यम:

एपीवर्सन: वाइकाइंड: पोडमेटडाटा:
एनोटेशन:
अनुसूचक। जालपा।कुबेरनेत्स।इयो-क्रिटिकल -पोड: ""
रचनाचित्र: "2020-07-09T23: 17: 53Z"
उत्पन्ननाम: सिलियम-
लेबल:
नियंत्रक-संशोधन-हैश: 6c94db8bb8
k8s- ऐप: सिलियम
पॉड-टेम्प्लेट-पीढ़ी: "1"
managedFields:
# प्रबंधित फ़ील्ड बकवास
नाम: cilium-d5n4f
namespace: kube-system
ownerReferences:

• एपीवर्सन: ऐप्स / v1
  blockOwnerDeletion: सच है
  नियंत्रक: सच है
  दयालु: DaemonSet
  नाम: सिलियम
  uid: 0f00e8af-eb19-4985-a940-a02fa84fcbc5
  संसाधन विचलन: "2840"
  सेल्फलिंक: / एपीआई / v1 / नेमस्पेस / क्यूब-सिस्टम / पॉड्स / सिलियम-डी ५ एन ४ एफ
  uid: e3f7d566-ee5b-4557-8d1b-f0964cde2f22spec:
  आत्मीयता:
  nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
  nodeSelectorTerms:
  - मैचफ़ील्ड:
  - कुंजी: मेटाडेटा
  ऑपरेटर: में
  मान:
  - us-central1-dilyevsky-master-qmwnl
  कंटेनर:
• आर्ग:
  
  
  
  • --config-dir = / tmp / पपनी / config-नक्शा
    
    आदेश:
  
  
  • पपनी-एजेंट
    
    env:
  
  
  • नाम: K8S_NODE_NAME
    
    valueFrom:
    
    fieldRef:
    
    एपीवर्सन: v1
    
    fieldPath: spec.nodeName
  
  
  • नाम: CILIUM_K8S_NAMESPACE
    
    valueFrom:
    
    fieldRef:
    
    एपीवर्सन: v1
    
    फ़ील्डपाथ: मेटाडेटा.नामस्पेस
  
  
  • नाम: CILIUM_FLANNEL_MASTER_DEVICE
    
    valueFrom:
    
    configMapKeyRef:
    
    कुंजी: फलालैन-मास्टर-डिवाइस
    
    नाम: cilium-config
    
    वैकल्पिक: सच
  
  
  • नाम: CILIUM_FLANNEL_UNINSTALL_ON_EXIT
    
    valueFrom:
    
    configMapKeyRef:
    
    कुंजी: फलालैन-स्थापना-पर-बाहर
    
    नाम: cilium-config
    
    वैकल्पिक: सच
  
  
  • नाम: CILIUM_CLUSTERMESH_CONFIG
    
    मान: / var / lib / cilium / clustermesh /
  
  
  • नाम: CILIUM_CNI_CHAINING_MODE
    
    valueFrom:
    
    configMapKeyRef:
    
    कुंजी: cni- चेनिंग-मोड
    
    नाम: cilium-config
    
    वैकल्पिक: सच
  
  
  • नाम: CILIUM_CUSTOM_CNI_CONF
    
    valueFrom:
    
    configMapKeyRef:
    
    कुंजी: कस्टम- cni-conf
    
    नाम: cilium-config
    
    वैकल्पिक: सच
    
    छवि: docker.io/cilium/ सिलियम : v1.7.6
    
    ImagePullPolicy: ifNotPresent
    
    जीवन चक्र:
    
    postStart:
    
    कार्यकारी:
    
    आदेश:
    
    
    
    
    
    • /cni-install.sh
    
    
    
    • --enable-डिबग = false
      
      
      preStop:
      
      
      कार्यकारी:
      
      
      आदेश:
    
    
    
    • /cni-uninstall.sh
      
      
      livenessProbe:
      
      
      कार्यकारी:
      
      
      आदेश:
      
      
      
      
      
      
      
      • पपनी
      
      
      
      
      • स्थिति
      
      
      
      
      • --संक्षिप्त करें
        
        
        
        असफलता
        
        
        
        आरंभिक दिनों: १२०
        
        
        
        समयावधि: 30
        
        
        
        successThreshold: 1
        
        
        
        टाइमआउट सेकंड्स: 5
        
        
        
        नाम: cilium- एजेंट
        
        
        
        readinessProbe:
        
        
        
        कार्यकारी:
        
        
        
        आदेश:
      
      
      
      
      • पपनी
      
      
      
      
      • स्थिति
      
      
      
      
      • --संक्षिप्त करें
        
        
        
        असफलता
        
        
        
        आरंभिक दिनों: 5
        
        
        
        समयावधि: 30
        
        
        
        successThreshold: 1
        
        
        
        टाइमआउट सेकंड्स: 5
        
        
        
        संसाधन: {}
        
        
        
        securityContext:
        
        
        
        क्षमताओं:
        
        
        
        जोड़ें:
      
      
      
      
      • NET_ADMIN
      
      
      
      
      • SYS_MODULE
        
        
        
        विशेषाधिकार प्राप्त: सत्य
        
        
        
        terminationMessagePath: / dev / समाप्ति-लॉग
        
        
        
        टर्मिनेशनमेजपॉलिश: फाइल
        
        
        
        volumeMounts:
      
      
      
      
    
    
    
  
  
  • माउंटपाथ: / var / run / cilium
    
    नाम: सिलियम-रन
  
  
  • माउंटपाथ: / मेजबान / ऑप्ट / cni / बिन
    
    नाम: cni-path
  
  
  • MountPath: /host/etc/cni/net.d
    
    नाम: etc-cni-netd
  
  
  • माउंटपाथ: / var / lib / cilium / clustermesh
    
    नाम: क्लस्टरमेश-रहस्य
    
    सच में: सच
  
  
  • MountPath: / tmp / cilium / config-map
    
    नाम: cilium-config-path
    
    सच में: सच
  
  
  • MountPath: / lib / मॉड्यूल
    
    नाम: lib- मॉड्यूल
    
    सच में: सच
  
  
  • MountPath: /run/xtables.lock
    
    नाम: xtables- ताला
  
  
  • माउन्टपाथ: /वर / रुन / सेकर्स / क्यूबर्नेटेस.आईओ / सरवाइसीकाउंट
    
    नाम: cilium-token-j74lr
    
    सच में: सच
    
    dnsPolicy: क्लस्टरस्टर
    
    enableServiceLinks: सच
    
    hostNetwork: सच है
    
    initContainers:
  
  
• आदेश:
  
  
  
  • /init-container.sh
    
    env:
  
  
  • नाम: CILIUM_ALL_STATE
    
    valueFrom:
    
    configMapKeyRef:
    
    कुंजी: साफ-सिलियम-राज्य
    
    नाम: cilium-config
    
    वैकल्पिक: सच
  
  
  • नाम: CILIUM_BPF_STATE
    
    valueFrom:
    
    configMapKeyRef:
    
    कुंजी: साफ-सिलियम-बीपीएफ-राज्य
    
    नाम: cilium-config
    
    वैकल्पिक: सच
  
  
  • नाम: CILIUM_WAIT_BPF_MOUNT
    
    valueFrom:
    
    configMapKeyRef:
    
    कुंजी: प्रतीक्षा-बीपीएफ-माउंट
    
    नाम: cilium-config
    
    वैकल्पिक: सच
    
    छवि: docker.io/cilium/ सिलियम : v1.7.6
    
    ImagePullPolicy: ifNotPresent
    
    नाम: स्वच्छ-सिलियम-राज्य
    
    संसाधन: {}
    
    securityContext:
    
    क्षमताओं:
    
    जोड़ें:
    
    
    
    
    
    • NET_ADMIN
      
      
      विशेषाधिकार प्राप्त: सत्य
      
      
      terminationMessagePath: / dev / समाप्ति-लॉग
      
      
      टर्मिनेशनमेजपॉलिश: फाइल
      
      
      volumeMounts:
    
    
    
  
  
  • माउंटपाथ: / var / run / cilium
    
    नाम: सिलियम-रन
  
  
  • माउन्टपाथ: /वर / रुन / सेकर्स / क्यूबर्नेटेस.आईओ / सरवाइसीकाउंट
    
    नाम: cilium-token-j74lr
    
    सच में: सच
    
    प्राथमिकता: 2000001000
    
    प्राथमिकताClassName: सिस्टम-नोड-क्रिटिकल
    
    पुनः आरंभ करें: हमेशा
    
    अनुसूचकनाम: डिफ़ॉल्ट-अनुसूचक
    
    सुरक्षासुविधा: {}
    
    serviceAccount: सिलियम
    
    serviceAccountName: सिलियम
    
    टर्मिनेशनग्रेसप्रोडसकंड्स: 1
    
    tolerations:
  
  
• ऑपरेटर: मौजूद है
• प्रभाव: NoExecute
  कुंजी: node.kubernetes.io/not-ready
  ऑपरेटर: मौजूद है
• प्रभाव: NoExecute
  कुंजी: node.kubernetes.io/unreachable
  ऑपरेटर: मौजूद है
• प्रभाव: NoSchedule
  कुंजी: node.kubernetes.io/disk-pressure
  ऑपरेटर: मौजूद है
• प्रभाव: NoSchedule
  कुंजी: node.kubernetes.io/memory-pressure
  ऑपरेटर: मौजूद है
• प्रभाव: NoSchedule
  कुंजी: node.kubernetes.io/pid-pressure
  ऑपरेटर: मौजूद है
• प्रभाव: NoSchedule
  कुंजी: node.kubernetes.io/unschedulable
  ऑपरेटर: मौजूद है
• प्रभाव: NoSchedule
  कुंजी: node.kubernetes.io/network-unavailable
  ऑपरेटर: मौजूद है
  मात्रा:
• hostPath:
  पथ: / var / रन / सिलियम
  प्रकार: DirectoryOrCreate
  नाम: सिलियम-रन
• hostPath:
  पथ: / ऑप्ट / cni / बिन
  प्रकार: DirectoryOrCreate
  नाम: cni-path
• hostPath:
  पथ: /etc/cni/net.d
  प्रकार: DirectoryOrCreate
  नाम: etc-cni-netd
• hostPath:
  पथ: / lib / मॉड्यूल
  प्रकार: ""
  नाम: lib- मॉड्यूल
• hostPath:
  पथ: /run/xtables.lock
  प्रकार: FileOrCreate
  नाम: xtables- ताला
• नाम: क्लस्टरमेश-रहस्य
  गुप्त:
  defaultMode: 420
  वैकल्पिक: सच
  secretName: सिलियम-क्लस्टरमेश
• configMap:
  defaultMode: 420
  नाम: cilium-config
  नाम: cilium-config-path
• नाम: cilium-token-j74lr
  गुप्त:
  defaultMode: 420
  गुप्तनाम: सिलियम-टोकन-जे st४ र्लास्ततुस:
  शर्तेँ:
• lastProbeTime: null
  lastTransitionTime: "2020-07-09T23: 17: 53Z"
  संदेश: '0/6 नोड उपलब्ध हैं: 5 नोड (एस) नोड चयनकर्ता से मेल नहीं खाते।'
  कारण: असंदिग्ध
  स्थिति: "गलत"
  प्रकार: PodScheduled
  चरण: लंबित
  qosClass: BestEffort

जिस तरह से मैं इसे दोहराता हूं वह 2 मास्टर्स के साथ नए क्लस्टर को कताई करके और है
3 कार्यकर्ता नोड्स (क्लस्टर एपीआई का उपयोग करके) और सीलियम 1.7.6 को लागू करना:

--- # स्रोत: cilium / चार्ट / एजेंट / टेम्पलेट्स / serviceaccount.yamlapiVersion: v1kind: ServiceAccountmetadata:
नाम: सिलियम
namespace: kube-system
--- # स्रोत: cilium / चार्ट / ऑपरेटर / टेम्प्लेट / serviceaccount.yamlapiVersion: v1kind: ServiceAccountmetadata:
नाम: सिलियम-ऑपरेटर
namespace: kube-system
--- # स्रोत: cilium / चार्ट / कॉन्फ़िगरेशन / टेम्प्लेट / configmap.yamlapiVersion: v1kind: कॉन्फिगरेशन कार्ड
नाम: cilium-config
नेमस्पेस: क्यूब-सिस्टमडाटा:

# आइडेंटिटी आवंटन मोड चयन करता है कि कैसे पहचान को सीलियम के बीच साझा किया जाता है
# नोड्स सेट करके कि वे कैसे संग्रहित हैं। विकल्प "crd" या "kvstore" हैं।
# - "crd" पहचान को कुबेरनेट्स में CRDs (कस्टम संसाधन परिभाषा) के रूप में संग्रहीत करता है।
# इनसे पूछताछ की जा सकती है:
# कुबेटील को सिलियमिड मिलता है
# - "kvstore" एक kvstore, etcd या consul में पहचानों को संग्रहीत करता है
# नीचे कॉन्फ़िगर किया गया। 1.6 से पहले के सिलियम संस्करण केवल kvstore का समर्थन करते थे
# बैकएंड। इन पुराने सिलियम संस्करणों से उन्नयन का उपयोग जारी रखना चाहिए
# नीचे, पहचान-आवंटन-मोड पर टिप्पणी करके kvstore, या
# इसे "kvstore" पर सेट करना।
पहचान-आवंटन-मोड: crd

# यदि आप डिबग मोड में साइलियम चलाना चाहते हैं, तो इस मान को सही में बदलें
डिबग: "गलत"

# IPv4 एड्रेसिंग सक्षम करें। सक्षम होने पर, सभी समापन बिंदुओं को एक IPv4 आवंटित किया जाता है
# पता।
सक्षम- ipv4: "true"

# IPv6 एड्रेसिंग सक्षम करें। सक्षम होने पर, सभी समापन बिंदुओं को एक IPv6 आवंटित किया जाता है
# पता।
सक्षम- ipv6: "false"

# यदि आप पैकेट के लिए ट्रेसिंग के लिए सिलिअम मॉनिटर चाहते हैं, तो इस स्तर को सेट करें
# "कम", "मध्यम", या "अधिकतम"। उच्च स्तर, कम पैकेट
# जिसे मॉनिटर आउटपुट में देखा जाएगा।
मॉनिटर-एकत्रीकरण: मध्यम

# मॉनिटर एकत्रीकरण अंतराल मॉनिटर के बीच विशिष्ट समय को नियंत्रित करता है
# प्रत्येक स्वीकृत कनेक्शन के लिए अधिसूचना घटनाएं।
#
# केवल तब प्रभावी होता है जब मॉनिटर एकत्रीकरण "मध्यम" या उच्चतर पर सेट होता है।
मॉनिटर-एकत्रीकरण-अंतराल: 5 एस

# मॉनिटर एकत्रीकरण झंडे जो निर्धारित करते हैं कि कौन से टीसीपी झंडे हैं
# पहला अवलोकन, कारण सूचनाओं के उत्पन्न होने का कारण।
#
# केवल तब प्रभावी होता है जब मॉनिटर एकत्रीकरण "मध्यम" या उच्चतर पर सेट होता है।
मॉनिटर-एकत्रीकरण-झंडे: सभी

# ct-global-max-प्रविष्टियाँ- * कनेक्शन की अधिकतम संख्या निर्दिष्ट करता है
# सभी समापन बिंदुओं पर समर्थित, प्रोटोकॉल द्वारा विभाजित: टीसीपी या अन्य। एक जोड़ा
# मैप्स IPv4 कनेक्शन के लिए इन मूल्यों का उपयोग करता है, और मैप्स की एक और जोड़ी
# IPv6 कनेक्शन के लिए इन मूल्यों का उपयोग करें।
#
# यदि इन मूल्यों को संशोधित किया जाता है, तो अगले सिलियम स्टार्टअप के दौरान
# चल रहे कनेक्शनों की ट्रैकिंग बाधित हो सकती है। यह संक्षिप्त हो सकता है
# पॉलिसी ड्रॉप या कनेक्शन के लिए लोडबेलिंग के फैसलों में बदलाव।
#
# व्यवधान को कम करने के लिए Cilium 1.2 या उससे पहले के उपयोगकर्ताओं को अपग्रेड करना
# अपग्रेड प्रक्रिया के दौरान, इन विकल्पों पर टिप्पणी करें।
bpf-ct-global-tcp-max: "524288"
bpf-ct-global-any-max: "262144"

# bpf-policy-map-max ने समापन बिंदु में प्रविष्टियों की अधिकतम संख्या निर्दिष्ट की
# पॉलिसी मैप (प्रति समापन बिंदु)
बीपीएफ-नीति-मानचित्र-अधिकतम: "16384"

# मानचित्र प्रविष्टियों का पूर्व-आवंटन प्रति-पैकेट विलंबता को कम करने की अनुमति देता है, पर
# नक्शों में प्रविष्टियों के लिए अप-फ्रंट मेमोरी आवंटन का खर्च।
# नीचे डिफ़ॉल्ट मान स्थापना में स्मृति उपयोग को कम करेगा;
# जो उपयोगकर्ता विलंबता के प्रति संवेदनशील हैं, वे इसे "सत्य" पर सेट करने पर विचार कर सकते हैं।
#
# यह विकल्प सिलियम 1.4 में पेश किया गया था। सिलियम 1.3 और पहले अनदेखा करें
# यह विकल्प और ऐसा व्यवहार करता है जैसे यह "सत्य" पर सेट है।
#
# यदि इस मान को संशोधित किया जाता है, तो अगले सिलियम स्टार्टअप के दौरान पुनर्स्थापना
# मौजूदा समापन बिंदुओं और चल रहे कनेक्शनों की ट्रैकिंग बाधित हो सकती है।
# इसके कारण पॉलिसी में गिरावट हो सकती है या लोडिंग के फैसले में बदलाव हो सकता है
# कुछ समय के लिए कनेक्शन। समापन के लिए समापन बिंदुओं को फिर से बनाने की आवश्यकता हो सकती है
# कनेक्टिविटी।
#
# यदि यह विकल्प 1.3 या उससे पहले के उन्नयन के दौरान "झूठा" पर सेट है
# 1.4 या बाद में, फिर यह अपग्रेड के दौरान एक बार के व्यवधान का कारण बन सकता है।
उपदेश-bpf- मानचित्र: "गलत"

# संगत इस्तियो सिदेकार इस्तियो-प्रॉक्सी से मेल खाते हुए नियमित अभिव्यक्ति
# कंटेनर छवि नाम
sidecar-istio -xy-image: "सिलियम / istio_proxy"

# नोड्स के बीच संचार के लिए एनकैप्सुलेशन मोड
# संभावित मान:
# - अक्षम
# - vxlan (डिफ़ॉल्ट)
# - जीनव
सुरंग: vxlan

# क्लस्टर का नाम। केवल प्रासंगिक जब समूहों का एक जाल का निर्माण।
क्लस्टर-नाम: डिफ़ॉल्ट

# DNS पोलिंग समय-समय पर प्रत्येक matchName लिए DNS लुकअप जारी करता है
# सिलियम-एजेंट। परिणाम का उपयोग समापन बिंदु नीति को पुन: उत्पन्न करने के लिए किया जाता है।
# DNS लुकअप को 5 सेकंड के अंतराल के साथ दोहराया जाता है, और इसके लिए बनाया जाता है
# A (IPv4) और AAAA (IPv6) पते। एक लुकअप विफल होना चाहिए, सबसे हाल का आईपी
इसके बजाय # डेटा का उपयोग किया जाता है। एक आईपी परिवर्तन Cilium के एक उत्थान को गति देगा
# प्रत्येक समापन बिंदु के लिए नीति और प्रति cilium- एजेंट नीति में वृद्धि
# रिपॉजिटरी रिवीजन।
#
# यह विकल्प डिफ़ॉल्ट रूप से संस्करण 1.4.x से शुरू होकर पक्ष में अक्षम है
# अधिक शक्तिशाली DNS प्रॉक्सी-आधारित कार्यान्वयन, विवरण के लिए [0] देखें।
# इस विकल्प को सक्षम करें यदि आप FQDN नीतियों का उपयोग करना चाहते हैं लेकिन उपयोग नहीं करना चाहते हैं
# डीएनएस प्रॉक्सी।
#
# अपग्रेड को आसान बनाने के लिए, उपयोगकर्ता इस विकल्प को "सही" पर सेट कर सकते हैं।
# अन्यथा कृपया अपग्रेड गाइड [1] को देखें, जिसमें बताया गया है कि कैसे
# उन्नयन के लिए नीति नियम तैयार करें।
#
# [0] http://docs.cilium.io/en/stable/policy/language/#dns -based
# [1] http://docs.cilium.io/en/stable/install/upgrad/#changes -that-may-requirement-action
tofqdns-enable-poller: "false"

# प्रतीक्षा-बीपीएफ-माउंट इनइट कंटेनर प्रतीक्षा करता है जब तक कि बीपीएफ फाइलसिस्टम माउंट नहीं किया जाता है
प्रतीक्षा-बीपीएफ-माउंट: "गलत"

बहाना: "सच"
सक्षम- xt-सॉकेट-फ़ॉलबैक: "सत्य"
स्थापित- iptables-rules: "true"
ऑटो-डायरेक्ट-नोड-रूट: "गलत"
क्यूब-प्रॉक्सी-रिप्लेसमेंट: "जांच"
सक्षम-होस्ट-पहुंच-योग्य सेवाएं: "गलत"
सक्षम-बाहरी- ips: "झूठा"
सक्षम-नोड-पोर्ट: "गलत"
नोड-पोर्ट-बाइंड-सुरक्षा: "सच"
सक्षम-ऑटो-सुरक्षा-नोड-पोर्ट-रेंज: "सच"
सक्षम-समापन बिंदु-स्वास्थ्य-जाँच: "सत्य"
सक्षम-ज्ञात-पहचान: "असत्य"
सक्षम-दूरस्थ-नोड-पहचान: "सत्य"
--- # स्रोत: cilium / चार्ट / एजेंट / टेम्पलेट्स / क्लस्टरो.लिम्पीविज़न: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:
नाम: ciliumrules:

• apiGroups:
  
  
  
  • networking.k8s.io
    
    संसाधन:
  
  
  • networkpolicies
    
    क्रियाएं:
  
  
  • प्राप्त
  
  
  • सूची
  
  
  • घड़ी
  
  
• apiGroups:
  
  
  
  • discovery.k8s.io
    
    संसाधन:
  
  
  • endpointslices
    
    क्रियाएं:
  
  
  • प्राप्त
  
  
  • सूची
  
  
  • घड़ी
  
  
• apiGroups:
  
  
  
  • ""
    
    संसाधन:
  
  
  • नामस्थान
  
  
  • सेवाएं
  
  
  • नोड्स
  
  
  • अंतिमबिंदुओं
    
    क्रियाएं:
  
  
  • प्राप्त
  
  
  • सूची
  
  
  • घड़ी
  
  
• apiGroups:
  
  
  
  • ""
    
    संसाधन:
  
  
  • फली
  
  
  • नोड्स
    
    क्रियाएं:
  
  
  • प्राप्त
  
  
  • सूची
  
  
  • घड़ी
  
  
  • अपडेट करें
  
  
• apiGroups:
  
  
  
  • ""
    
    संसाधन:
  
  
  • नोड्स
  
  
  • नोड्स / स्थिति
    
    क्रियाएं:
  
  
  • पैच
  
  
• apiGroups:
  
  
  
  • apiextensions.k8s.io
    
    संसाधन:
  
  
  • customresourcedefinitions
    
    क्रियाएं:
  
  
  • सृजन करना
  
  
  • प्राप्त
  
  
  • सूची
  
  
  • घड़ी
  
  
  • अपडेट करें
  
  
• apiGroups:
  
  
  
  • cilium.io
    
    संसाधन:
  
  
  • ciliumnetworkpolicies
  
  
  • ciliumnetworkpolicies / स्थिति
  
  
  • ciliumclusterwidenetworkpolicies
  
  
  • ciliumclusterwidenetworkpolicies / स्थिति
  
  
  • ciliumendpoints
  
  
  • ciliumendpoints / स्थिति
  
  
  • ciliumnodes
  
  
  • ciliumnodes / स्थिति
  
  
  • ciliumidentities
  
  
  • ciliumidentities / स्थिति
    
    क्रियाएं:
  
  
  • '*'
    
    --- # स्रोत: cilium / चार्ट / ऑपरेटर / टेम्प्लेट / क्लस्टरऑल.वीवर्जन: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:
    
    नाम: सिलियम-ऑपरेटर्स:
  
  
• apiGroups:
  
  
  
  • ""
    
    संसाधन:
    
    # स्वचालित रूप से हटाने के लिए [कोर | kube] dns फली ताकि शुरू हो रहे हैं
    
    # सिलियम द्वारा प्रबंधित
  
  
  • फली
    
    क्रियाएं:
  
  
  • प्राप्त
  
  
  • सूची
  
  
  • घड़ी
  
  
  • हटाना
  
  
• apiGroups:
  
  
  
  • discovery.k8s.io
    
    संसाधन:
  
  
  • endpointslices
    
    क्रियाएं:
  
  
  • प्राप्त
  
  
  • सूची
  
  
  • घड़ी
  
  
• apiGroups:
  
  
  
  • ""
    
    संसाधन:
    
    # k8s से स्वचालित रूप से पढ़ने के लिए और नोड के पॉड CIDR को सिलियम के लिए आयात करें
    
    # वगैरह तो सभी नोड्स जानते हैं कि एक दूसरे पॉड में कैसे पहुंचा जाए
    
    # नोड।
  
  
  • नोड्स
    
    # CNP का अनुवाद करने के लिए जिसमें इसके समापन बिंदुओं के लिए ToGroup
  
  
  • सेवाएं
  
  
  • अंतिमबिंदुओं
    
    # एपिवर कनेक्टिविटी को चेक करने के लिए
  
  
  • नामस्थान
    
    क्रियाएं:
  
  
  • प्राप्त
  
  
  • सूची
  
  
  • घड़ी
  
  
• apiGroups:
  
  
  
  • cilium.io
    
    संसाधन:
  
  
  • ciliumnetworkpolicies
  
  
  • ciliumnetworkpolicies / स्थिति
  
  
  • ciliumclusterwidenetworkpolicies
  
  
  • ciliumclusterwidenetworkpolicies / स्थिति
  
  
  • ciliumendpoints
  
  
  • ciliumendpoints / स्थिति
  
  
  • ciliumnodes
  
  
  • ciliumnodes / स्थिति
  
  
  • ciliumidentities
  
  
  • ciliumidentities / स्थिति
    
    क्रियाएं:
  
  
  • '*'
    
    --- # स्रोत: cilium / चार्ट / एजेंट / टेम्पलेट्स / क्लस्टरोकलिंडिंग ।yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:
    
    नाम: ciliumroleRef:
    
    एपीग्रुप: rbac.authorization.k8s.io
    
    तरह: क्लस्टर
    
    नाम: ciliumsubjects:
  
  
• तरह: ServiceAccount
  नाम: सिलियम
  namespace: kube-system
  --- # स्रोत: cilium / चार्ट / ऑपरेटर / टेम्प्लेट / क्लस्टरऑलिंडिंग ।yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:
  नाम: cilium-operroleRef:
  एपीग्रुप: rbac.authorization.k8s.io
  तरह: क्लस्टर
  नाम: सिलियम-ऑपरेटरों
• तरह: ServiceAccount
  नाम: सिलियम-ऑपरेटर
  namespace: kube-system
  --- # स्रोत: cilium / चार्ट / एजेंट / टेम्पलेट्स / daemonset.yamlapiVersion: ऐप्स / v1kind: DaemonSetmetadata:
  लेबल:
  k8s- ऐप: सिलियम
  नाम: सिलियम
  नेमस्पेस: क्यूब-सिस्टमस्पेक:
  चयनकर्ता:
  matchLabels:
  k8s- ऐप: सिलियम
  टेम्पलेट:
  मेटाडाटा:
  एनोटेशन:
  # यह एनोटेशन प्लस क्रिटिकलएडोंसनलली टोलरेंस बनाता है
  # साइलियम क्लस्टर में एक महत्वपूर्ण फली है, जो सिलियम सुनिश्चित करता है
  # प्राथमिकता शेड्यूलिंग मिलती है।
  # https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/
  अनुसूचक। जालपा।कुबेरनेत्स।इयो-क्रिटिकल -पोड: ""
  लेबल:
  k8s- ऐप: सिलियम
  कल्पना:
  कंटेनर:
  
  
  
  • आर्ग:
    
    
    
    
    
    • --config-dir = / tmp / पपनी / config-नक्शा
      
      
      आदेश:
    
    
    
    • पपनी-एजेंट
      
      
      livenessProbe:
      
      
      कार्यकारी:
      
      
      आदेश:
      
      
      
      
      
      
      
      • पपनी
      
      
      
      
      • स्थिति
      
      
      
      
      • --संक्षिप्त करें
        
        
        
        असफलता
        
        
        
        # लीवर की जांच के लिए शुरुआती देरी जानबूझकर बड़ी है
        
        
        
        # यदि प्रारंभिक घटना में एक अंतहीन मार और पुनरारंभ चक्र से बचें
        
        
        
        # बूटस्ट्रैपिंग में अपेक्षा से अधिक समय लगता है।
        
        
        
        आरंभिक दिनों: १२०
        
        
        
        समयावधि: 30
        
        
        
        successThreshold: 1
        
        
        
        टाइमआउट सेकंड्स: 5
        
        
        
        readinessProbe:
        
        
        
        कार्यकारी:
        
        
        
        आदेश:
      
      
      
      
      • पपनी
      
      
      
      
      • स्थिति
      
      
      
      
      • --संक्षिप्त करें
        
        
        
        असफलता
        
        
        
        आरंभिक दिनों: 5
        
        
        
        समयावधि: 30
        
        
        
        successThreshold: 1
        
        
        
        टाइमआउट सेकंड्स: 5
        
        
        
        env:
      
      
      
      
    
    
    
    • नाम: K8S_NODE_NAME
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      एपीवर्सन: v1
      
      
      fieldPath: spec.nodeName
    
    
    
    • नाम: CILIUM_K8S_NAMESPACE
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      एपीवर्सन: v1
      
      
      फ़ील्डपाथ: मेटाडेटा.नामस्पेस
    
    
    
    • नाम: CILIUM_FLANNEL_MASTER_DEVICE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      कुंजी: फलालैन-मास्टर-डिवाइस
      
      
      नाम: cilium-config
      
      
      वैकल्पिक: सच
    
    
    
    • नाम: CILIUM_FLANNEL_UNINSTALL_ON_EXIT
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      कुंजी: फलालैन-स्थापना-पर-बाहर
      
      
      नाम: cilium-config
      
      
      वैकल्पिक: सच
    
    
    
    • नाम: CILIUM_CLUSTERMESH_CONFIG
      
      
      मान: / var / lib / cilium / clustermesh /
    
    
    
    • नाम: CILIUM_CNI_CHAINING_MODE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      कुंजी: cni- चेनिंग-मोड
      
      
      नाम: cilium-config
      
      
      वैकल्पिक: सच
    
    
    
    • नाम: CILIUM_CUSTOM_CNI_CONF
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      कुंजी: कस्टम- cni-conf
      
      
      नाम: cilium-config
      
      
      वैकल्पिक: सच
      
      
      चित्र: "docker.io/cilium/ cilium: v1.7.6 "
      
      
      ImagePullPolicy: IfNotPresent
      
      
      जीवन चक्र:
      
      
      postStart:
      
      
      कार्यकारी:
      
      
      आदेश:
      
      
      
      
      
      
      
      • "/Cni-install.sh"
      
      
      
      
      • "--Enable-डिबग = false"
        
        
        
        preStop:
        
        
        
        कार्यकारी:
        
        
        
        आदेश:
      
      
      
      
      • /cni-uninstall.sh
        
        
        
        नाम: सिलियम-एजेंट
        
        
        
        securityContext:
        
        
        
        क्षमताओं:
        
        
        
        जोड़ें:
        
        
        
        
        
        
        
        
        
        • NET_ADMIN
        
        
        
        
        
        • SYS_MODULE
          
          
          
          
          विशेषाधिकार प्राप्त: सत्य
          
          
          
          
          volumeMounts:
        
        
        
        
        
      
      
      
      
    
    
    
    • माउंटपाथ: / var / run / cilium
      
      
      नाम: सिलियम-रन
    
    
    
    • माउंटपाथ: / मेजबान / ऑप्ट / cni / बिन
      
      
      नाम: cni-path
    
    
    
    • MountPath: /host/etc/cni/net.d
      
      
      नाम: etc-cni-netd
    
    
    
    • माउंटपाथ: / var / lib / cilium / clustermesh
      
      
      नाम: क्लस्टरमेश-रहस्य
      
      
      सच में: सच
    
    
    
    • MountPath: / tmp / cilium / config-map
      
      
      नाम: cilium-config-path
      
      
      सच में: सच
      
      
      # कर्नेल मॉड्यूल लोड करने में सक्षम होने की आवश्यकता है
    
    
    
    • MountPath: / lib / मॉड्यूल
      
      
      नाम: lib- मॉड्यूल
      
      
      सच में: सच
    
    
    
    • MountPath: /run/xtables.lock
      
      
      नाम: xtables- ताला
      
      
      hostNetwork: सच है
      
      
      initContainers:
    
    
    
  
  
  • आदेश:
    
    
    
    
    
    • /init-container.sh
      
      
      env:
    
    
    
    • नाम: CILIUM_ALL_STATE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      कुंजी: साफ-सिलियम-राज्य
      
      
      नाम: cilium-config
      
      
      वैकल्पिक: सच
    
    
    
    • नाम: CILIUM_BPF_STATE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      कुंजी: साफ-सिलियम-बीपीएफ-राज्य
      
      
      नाम: cilium-config
      
      
      वैकल्पिक: सच
    
    
    
    • नाम: CILIUM_WAIT_BPF_MOUNT
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      कुंजी: प्रतीक्षा-बीपीएफ-माउंट
      
      
      नाम: cilium-config
      
      
      वैकल्पिक: सच
      
      
      चित्र: "docker.io/cilium/ cilium: v1.7.6 "
      
      
      ImagePullPolicy: IfNotPresent
      
      
      नाम: स्वच्छ-सिलियम-राज्य
      
      
      securityContext:
      
      
      क्षमताओं:
      
      
      जोड़ें:
      
      
      
      
      
      
      
      • NET_ADMIN
        
        
        
        विशेषाधिकार प्राप्त: सत्य
        
        
        
        volumeMounts:
      
      
      
      
    
    
    
    • माउंटपाथ: / var / रन / cilium
      
      
      नाम: सिलियम-रन
      
      
      पुनः आरंभ करें: हमेशा
      
      
      प्राथमिकताClassName: सिस्टम-नोड-क्रिटिकल
      
      
      serviceAccount: सिलियम
      
      
      serviceAccountName: सिलियम
      
      
      टर्मिनेशनग्रेसप्रोडसकंड्स: 1
      
      
      tolerations:
    
    
    
  
  
  • ऑपरेटर: मौजूद है
    
    मात्रा:
    
    # पुनरारंभ / उन्नयन के बीच स्थिति रखने के लिए
  
  
  • hostPath:
    
    पथ: / var / रन / cilium
    
    प्रकार: DirectoryOrCreate
    
    नाम: सिलियम-रन
    
    # होस्ट में cilium cni plugin इंस्टॉल करने के लिए
  
  
  • hostPath:
    
    पथ: / ऑप्ट / cni / बिन
    
    प्रकार: DirectoryOrCreate
    
    नाम: cni-path
    
    # मेजबान में cilium cni विन्यास स्थापित करने के लिए
  
  
  • hostPath:
    
    पथ: /etc/cni/net.d
    
    प्रकार: DirectoryOrCreate
    
    नाम: etc-cni-netd
    
    # कर्नेल मॉड्यूल लोड करने में सक्षम होने के लिए
  
  
  • hostPath:
    
    पथ: / lib / मॉड्यूल
    
    नाम: lib- मॉड्यूल
    
    # अन्य प्रक्रियाओं (जैसे क्यूब-प्रॉक्सी) के साथ समवर्ती रूप से iptables का उपयोग करने के लिए
  
  
  • hostPath:
    
    पथ: /run/xtables.lock
    
    प्रकार: FileOrCreate
    
    नाम: xtables- ताला
    
    # क्लस्टरमेश कॉन्फ़िगरेशन को पढ़ने के लिए
  
  
  • नाम: क्लस्टरमेश-रहस्य
    
    गुप्त:
    
    defaultMode: 420
    
    वैकल्पिक: सच
    
    secretName: सिलियम-क्लस्टरमेश
    
    # कॉन्फिगर मैप से कॉन्फिगरेशन पढ़ने के लिए
  
  
  • configMap:
    
    नाम: cilium-config
    
    नाम: cilium-config-path
    
    updateStrategy:
    
    rollingUpdate:
    
    अधिकतमउपयोग: २
    
    प्रकार: RollingUpdate
    
    --- # स्रोत: cilium / चार्ट / ऑपरेटर / टेम्प्लेट / परिनियोजन ।yamlapiVersion: ऐप्स / v1kind: परिनियोजनमेटाटा:
    
    लेबल:
    
    io.cilium / ऐप: ऑपरेटर
    
    नाम: सिलियम-ऑपरेटर
    
    नाम: सिलियम-ऑपरेटर
    
    नेमस्पेस: क्यूब-सिस्टमस्पेक:
    
    प्रतिकृतियां: १
    
    चयनकर्ता:
    
    matchLabels:
    
    io.cilium / ऐप: ऑपरेटर
    
    नाम: सिलियम-ऑपरेटर
    
    रणनीति:
    
    rollingUpdate:
    
    अधिकतम: १
    
    अधिकतमउपलब्ध: १
    
    प्रकार: RollingUpdate
    
    टेम्पलेट:
    
    मेटाडाटा:
    
    एनोटेशन:
    
    लेबल:
    
    io.cilium / ऐप: ऑपरेटर
    
    नाम: सिलियम-ऑपरेटर
    
    कल्पना:
    
    कंटेनर:
  
  
  • आर्ग:
    
    
    
    
    
    • --debug = $ (CILIUM_DEBUG)
    
    
    
    • --identity-आवंटन मोड = $ (CILIUM_IDENTITY_ALLOCATION_MODE)
    
    
    
    • --synchronize-k8s-नोड्स = true
      
      
      आदेश:
    
    
    
    • पपनी-ऑपरेटर
      
      
      env:
    
    
    
    • नाम: CILIUM_K8S_NAMESPACE
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      एपीवर्सन: v1
      
      
      फ़ील्डपाथ: मेटाडेटा.नामस्पेस
    
    
    
    • नाम: K8S_NODE_NAME
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      एपीवर्सन: v1
      
      
      fieldPath: spec.nodeName
    
    
    
    • नाम: CILIUM_DEBUG
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      कुंजी: डिबग
      
      
      नाम: cilium-config
      
      
      वैकल्पिक: सच
    
    
    
    • नाम: CILIUM_CLUSTER_NAME
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      कुंजी: क्लस्टर-नाम
      
      
      नाम: cilium-config
      
      
      वैकल्पिक: सच
    
    
    
    • नाम: CILIUM_CLUSTER_ID
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      कुंजी: क्लस्टर-आईडी
      
      
      नाम: cilium-config
      
      
      वैकल्पिक: सच
    
    
    
    • नाम: CILIUM_IPAM
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      कुंजी: आईपीम
      
      
      नाम: cilium-config
      
      
      वैकल्पिक: सच
    
    
    
    • नाम: CILIUM_DISABLE_ENDPOINT_CRD
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      कुंजी: अक्षम-समापन बिंदु-crd
      
      
      नाम: cilium-config
      
      
      वैकल्पिक: सच
    
    
    
    • नाम: CILIUM_KVSTORE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      कुंजी: kvstore
      
      
      नाम: cilium-config
      
      
      वैकल्पिक: सच
    
    
    
    • नाम: CILIUM_KVSTORE_OPT
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      कुंजी: kvstore- ऑप्ट
      
      
      नाम: cilium-config
      
      
      वैकल्पिक: सच
    
    
    
    • नाम: AWS_ACCESS_KEY_ID
      
      
      valueFrom:
      
      
      secretKeyRef:
      
      
      कुंजी: AWS_ACCESS_KEY_ID
      
      
      नाम: cilium-aws
      
      
      वैकल्पिक: सच
    
    
    
    • नाम: AWS_SECRET_ACCESS_KEY
      
      
      valueFrom:
      
      
      secretKeyRef:
      
      
      कुंजी: AWS_SECRET_ACCESS_KEY
      
      
      नाम: cilium-aws
      
      
      वैकल्पिक: सच
    
    
    
    • नाम: AWS_DEFAULT_REGION
      
      
      valueFrom:
      
      
      secretKeyRef:
      
      
      कुंजी: AWS_DEFAULT_REGION
      
      
      नाम: cilium-aws
      
      
      वैकल्पिक: सच
    
    
    
    • नाम: CILIUM_IDENTITY_ALLOCATION_MODE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      कुंजी: पहचान-आवंटन-मोड
      
      
      नाम: cilium-config
      
      
      वैकल्पिक: सच
      
      
      चित्र: "docker.io/cilium/ ऑपरेटर: v1.7.6 "
      
      
      ImagePullPolicy: IfNotPresent
      
      
      नाम: सिलियम-ऑपरेटर
      
      
      livenessProbe:
      
      
      httpGet:
      
      
      मेजबान: '127.0.0.1'
      
      
      पथ: / healthz
      
      
      पोर्ट: 9234
      
      
      योजना: HTTP
      
      
      आरंभिक दिनों: 60
      
      
      समयावधि: १०
      
      
      टाइमआउट सेकंड्स: 3
      
      
      hostNetwork: सच है
      
      
      पुनः आरंभ करें: हमेशा
      
      
      serviceAccount: सिलियम-ऑपरेटर
      
      
      serviceAccountName: सिलियम-ऑपरेटर
    
    
    
  
  

-
आपको यह इसलिए मिल रहा है क्योंकि आपको सौंपा गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-656404841 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAJ5E6BMTNCADT5K7D4PMF3R2ZJRVANCNFSM4NOTPEDA
।

क्या आप नोड के लिए फ़िल्टर करने के लिए logvel को बढ़ाने और grep का उपयोग करने का प्रयास कर सकते हैं
या फली?

थू पर, जुलाई, 9, 2020, 7:55 बजे dilyevsky, सूचनाएं @github.com
लिखा था:

यहाँ अनुसूचक लॉग है:

I0709 23: 08: 22.056081 1 रजिस्ट्री। एगो: 150] शाम को पंजीकृत करना
I0709 23: 08: 23.137451 1 सेवारत। आम: 313] स्मृति में स्व-हस्ताक्षरित प्रमाण पत्र बनाया गया
W0709 23: 08: 33.843509 1 प्रमाणीकरण.go: 297] इन-क्लस्टर प्रमाणीकरण कॉन्फ़िगरेशन देखने में त्रुटि: वेंडर: अनुरोध समय समाप्त
W0709 23: 08: 33.843671 1 प्रमाणीकरण.go: 298] प्रमाणन कॉन्फ़िगरेशन के बिना जारी। यह सभी अनुरोधों को गुमनाम माना जा सकता है।
W0709 23: 08: 33.843710 1 प्रमाणीकरण.go: 299] प्रमाणीकरण कॉन्फ़िगरेशन लुकअप को सफल करने के लिए, सेट करने के लिए - सहायता-सहिष्णुता-लुकअप-विफलता = गलत
I0709 23: 08: 33.911805 1 रजिस्ट्री। एगो: 150] यहां तक ​​कि पंजीकरण भी पूर्व निर्धारित और प्राथमिकता समारोह
I0709 23: 08: 33.911989 1 रजिस्ट्री। एगो: 150] यहां तक ​​कि पंजीकृत करें
W0709 23: 08: 33.917999 1 प्राधिकरण।एगो: 47] प्राधिकरण अक्षम है
W0709 23: 08: 33.918162 1 प्रमाणीकरण.go: 40] प्रमाणीकरण अक्षम है
I0709 23: 08: 33.918238 1 deprecated_insecure_serves.go: 51] Healthz की असुरक्षित रूप से सेवा करना [::]: 10251
I0709 23: 08: 33.925860 1 configmap_cafile_content.go: 202] क्लाइंट-शुरू करना :: kube-system :: extension-apiserver-प्रमाणीकरण :: क्लाइंट-सीए-फ़ाइल
I0709 23: 08: 33.926013 1 साझा_इनफॉर्मर .go: 223] क्लाइंट के लिए सिंक करने के लिए कैश की प्रतीक्षा कर रहा है :: क्यूब-सिस्टम :: एक्सटेंशन-एपाइज़र-प्रमाणीकरण :: क्लाइंट-सीए-फ़ाइल
I0709 23: 08: 33.930685 1 safe_serves.go: 178] 127.0.0.1:10259 पर सुरक्षित रूप से सेवा करना
I0709 23: 08: 33.936198 1 tlsconfig.go: 240] डायनामिकसेवा करना शुरू करना
I0709 23: 08: 34.026382 1 साझा_informer.go: 230] ग्राहक-सीए के लिए कैश सिंक किए गए हैं :: क्यूब-सिस्टम :: एक्सटेंशन-एपेसेवर-प्रमाणीकरण :: क्लाइंट-सीए-फाइल
I0709 23: 08: 34.036998 1 leaderelection.go: 242] लीडर लीज़ क्यूब-सिस्टम / क्यूब-शेड्यूलर का अधिग्रहण करने का प्रयास कर रहा है ...
I0709 23: 08: 50.597201 1 लीडरलेक्शन। अहंकार: 252] सफलतापूर्वक पट्टे पर लिया गया क्यूब-सिस्टम / क्यूब-अनुसूचक
E0709 23: 08: 50.658551 1 factory.go: 503] फली: क्यूब-प्रणाली / coredns-66bff467f8-9rjvd पहले से ही सक्रिय कतार में मौजूद है
E0709 23: 12: 27.673854 1 factory.go: 503] पॉड क्यूब-सिस्टम / सिलियम-वीवी 466 पहले से ही बैकऑफ़ कतार में मौजूद है
E0709 23: 12: 58.099432 1 leaderelection.go: 320] संसाधन लॉक क्यूब-सिस्टम / क्यूब-अनुसूचक को पुनर्प्राप्त करने में त्रुटि: आदि: नेता बदल गया

शेड्यूलर पॉड्स को पुनरारंभ करने के बाद, लंबित पॉड तुरंत शेड्यूल करता है।

-
आपको यह इसलिए मिल रहा है क्योंकि आपको सौंपा गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-656406215 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAJ5E6E4QPGNNBFUYSZEJC3R2ZKHDANCNFSM4NOTPEDA
।

ये हैं घटनाएँ:
`` `घटनाक्रम:
संदेश से कारण आयु लिखें
---- ------ ---- ---- -------
चेतावनी विफल रहीडिफ़ॉल्ट-अनुसूचक 0/6 नोड्स उपलब्ध हैं: 5 नोड (एस) नोड चयनकर्ता से मेल नहीं खाते।
चेतावनी विफल रहीडिफ़ॉल्ट-अनुसूचक 0/6 नोड्स उपलब्ध हैं: 5 नोड (एस) नोड चयनकर्ता से मेल नहीं खाते।

The node only has two taints but the pod tolerates all existing taints and yeah it seems to only happen on masters:

टेंट: नोड-role.kubernetes.io/ मास्टर: NoSchedule
node.kubernetes.io/network-un उपलब्ध: NoSchedule

There is enough space and pod is best effort with no reservation anyway:
```  Resource                   Requests    Limits
  --------                   --------    ------
  cpu                        650m (32%)  0 (0%)
  memory                     70Mi (0%)   170Mi (2%)
  ephemeral-storage          0 (0%)      0 (0%)
  hugepages-1Gi              0 (0%)      0 (0%)
  hugepages-2Mi              0 (0%)      0 (0%)
  attachable-volumes-gce-pd  0           0

मैं शेड्यूलर लॉग स्तर बढ़ाने की कोशिश करूँगा ...

आपके पॉड याम्ल में वास्तव में node-role.kubernetes.io/master टोलरेशन नहीं है। तो यह मास्टर में निर्धारित नहीं किया जाना चाहिए था।

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

हमने नंगे न्यूनतम पर असफल तैनाती को छीन लिया (हमने असफल होने पर गुरु को हटा दिया है):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
      restartPolicy: Always
      schedulerName: default-scheduler
      nodeSelector:
        kubernetes.io/hostname: master-2

हम एक ही मुद्दा चल रहा था जब मास्टर एक टेंट था, और तैनाती टेंट के लिए एक झुकाव। तो यह विशेष रूप से डेमोंसेट्स, सहनशीलता या आत्मीयता / विरोधी-संबंध से संबंधित नहीं लगता है। जब विफलता होने लगती है, तो विशिष्ट नोड को लक्षित करने वाला कुछ भी निर्धारित नहीं किया जा सकता है। हम 1.18.2 में 1.18.5 तक का मुद्दा देखते हैं (1.18.0 या .1 के साथ प्रयास नहीं किया है)

बस एक नोड चयनकर्ता के साथ एक फली का निर्माण करना जो कि असफल नोड के होस्टनाम से मेल खाने के लिए है, शेड्यूलिंग को विफल करने के लिए पर्याप्त था

क्या आप स्पष्ट कर सकते हैं कि अगर आपने ऐसी फली बनाई या उससे पहले यह असफल होने लगी? मुझे लगता है कि इस नोड में एक तनाव नहीं था जो फली को सहन नहीं करता था।

@ नोदो प्रजनन के लिए मदद करने जा रहा है। क्या आप कोड को NodeSelector के लिए देख सकते हैं? परीक्षण करते समय आपको अतिरिक्त लॉग लाइनें जोड़ने की आवश्यकता हो सकती है। आप कैशे भी प्रिंट कर सकते हैं।

• क्यूब-शेड्यूलर की पीआईडी ​​प्राप्त करें: $ pidof kube-scheduler
• ट्रिगर कतार डंप: $ sudo kill -SIGUSR2 <pid> । ध्यान दें कि यह शेड्यूलर प्रक्रिया को नहीं मारेगा।
• फिर शेड्यूलर लॉग में, स्ट्रिंग्स "डंप ऑफ कैश्ड नोडइन्फो", "डंप ऑफ शेड्यूलिंग क्यू" और "कैश कंपेरर स्टार्ट" की खोज करें।

/ प्राथमिकता महत्वपूर्ण-अत्यावश्यक

/ सौंपना रद्द

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

कृपया ऐसा करो। मैंने अतीत में सफलता के बिना इसे पुन: पेश करने की कोशिश की है। मुझे असफलता के पहले उदाहरण में अधिक दिलचस्पी है। यह अभी भी taints से संबंधित हो सकता है।

हमने मुद्दे को फिर से तैयार किया है। मैंने आपसे जो आदेश माँगा था, वह यहाँ है:

I0716 14:47:52.768362       1 factory.go:462] Unable to schedule default/test-deployment-558f47bbbb-4rt5t: no fit: 0/6 nodes are available: 5 node(s) didn't match node selector.; waiting
I0716 14:47:52.768683       1 scheduler.go:776] Updating pod condition for default/test-deployment-558f47bbbb-4rt5t to (PodScheduled==False, Reason=Unschedulable)
I0716 14:47:53.018781       1 httplog.go:90] verb="GET" URI="/healthz" latency=299.172µs resp=200 UserAgent="kube-probe/1.18" srcIP="127.0.0.1:57258": 
I0716 14:47:59.469828       1 comparer.go:42] cache comparer started
I0716 14:47:59.470936       1 comparer.go:67] cache comparer finished
I0716 14:47:59.471038       1 dumper.go:47] Dump of cached NodeInfo
I0716 14:47:59.471484       1 dumper.go:49] 
Node name: master-0-bug
Requested Resources: {MilliCPU:1100 Memory:52428800 EphemeralStorage:0 AllowedPodNumber:0 ScalarResources:map[]}
Allocatable Resources:{MilliCPU:2000 Memory:3033427968 EphemeralStorage:19290208634 AllowedPodNumber:110 ScalarResources:map[hugepages-1Gi:0 hugepages-2Mi:0]}
Scheduled Pods(number: 9):
...
I0716 14:47:59.472623       1 dumper.go:60] Dump of scheduling queue:
name: coredns-cd64c8d7c-29zjq, namespace: kube-system, uid: 938e8827-5d17-4db9-ac04-d229baf4534a, phase: Pending, nominated node: 
name: test-deployment-558f47bbbb-4rt5t, namespace: default, uid: fa19fda9-c8d6-4ffe-b248-8ddd24ed5310, phase: Pending, nominated node: 

दुर्भाग्य से मदद करने के लिए प्रतीत नहीं होता है

कैश डंप करना डीबगिंग के लिए है, यह कुछ भी नहीं बदलेगा। क्या आप डंप को शामिल कर सकते हैं?

इसके अलावा, यह मानते हुए कि यह पहली त्रुटि थी, क्या आप पॉड याम और नोड शामिल कर सकते हैं?

यह बहुत ज्यादा सब कुछ है कि डंप किया गया था, मैं सिर्फ अन्य नोड्स को हटा दिया। यह पहली त्रुटि नहीं थी, लेकिन आप डंप में coredns फली देख सकते हैं, यह पहले वाला था। मुझे यकीन नहीं है कि आप डंप में और क्या पूछ रहे हैं।
मैं यामलों को लाऊंगा

धन्यवाद, मुझे महसूस नहीं हुआ कि आपने संबंधित नोड और पॉड को ट्रिम कर दिया है।

क्या आप उस नोड के लिए निर्धारित पॉड्स को शामिल कर सकते हैं हालांकि? बस के मामले में संसाधन उपयोग गणना में एक बग है।

Requested Resources: {MilliCPU:1100 Memory:52428800 EphemeralStorage:0 AllowedPodNumber:0 ScalarResources:map[]}

वह AllowedPodNumber: 0 अजीब लगता है।

यहाँ उस नोड पर अन्य पॉड्स हैं:
` name: kube-controller-manager-master-0-bug, namespace: kube-system, uid: 095eebb0-4752-419b-aac7-245e5bc436b8, phase: Running, nominated node: name: kube-proxy-xwf6h, namespace: kube-system, uid: 16552eaf-9eb8-4584-ba3c-7dff6ce92592, phase: Running, nominated node: name: kube-apiserver-master-0-bug, namespace: kube-system, uid: 1d338e26-b0bc-4cef-9bad-86b7dd2b2385, phase: Running, nominated node: name: kube-multus-ds-amd64-tpkm8, namespace: kube-system, uid: d50c0c7f-599c-41d5-a029-b43352a4f5b8, phase: Running, nominated node: name: openstack-cloud-controller-manager-wrb8n, namespace: kube-system, uid: 17aeb589-84a1-4416-a701-db6d8ef60591, phase: Running, nominated node: name: kube-scheduler-master-0-bug, namespace: kube-system, uid: 52469084-3122-4e99-92f6-453e512b640f, phase: Running, nominated node: name: subport-controller-28j9v, namespace: kube-system, uid: a5a07ac8-763a-4ff2-bdae-91c6e9e95698, phase: Running, nominated node: name: csi-cinder-controllerplugin-0, namespace: kube-system, uid: 8b16d6c8-a871-454e-98a3-0aa545f9c9d0, phase: Running, nominated node: name: calico-node-d899t, namespace: kube-system, uid: e3672030-53b1-4356-a5df-0f4afd6b9237, phase: Running, nominated node:

सभी नोड्स ने डंप में अनुरोधित संसाधनों में 0 पर सेट किया गया है, लेकिन अन्य नोड्स शेड्यूल किए जा सकते हैं

नोड याम्ल:

apiVersion: v1
kind: Node
metadata:
  annotations:
    kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
    node.alpha.kubernetes.io/ttl: "0"
    volumes.kubernetes.io/controller-managed-attach-detach: "true"
  creationTimestamp: "2020-07-16T09:59:48Z"
  labels:
    beta.kubernetes.io/arch: amd64
    beta.kubernetes.io/instance-type: 54019dbc-10d7-409c-8338-5556f61a9371
    beta.kubernetes.io/os: linux
    failure-domain.beta.kubernetes.io/region: regionOne
    failure-domain.beta.kubernetes.io/zone: nova
    kubernetes.io/arch: amd64
    kubernetes.io/hostname: master-0-bug
    kubernetes.io/os: linux
    node-role.kubernetes.io/master: ""
    node.kubernetes.io/instance-type: 54019dbc-10d7-409c-8338-5556f61a9371
    node.uuid: 00324054-405e-4fae-a3bf-d8509d511ded
    node.uuid_source: cloud-init
    topology.kubernetes.io/region: regionOne
    topology.kubernetes.io/zone: nova
  name: master-0-bug
  resourceVersion: "85697"
  selfLink: /api/v1/nodes/master-0-bug
  uid: 629b6ef3-3c76-455b-8b6b-196c4754fb0e
spec:
  podCIDR: 192.168.0.0/24
  podCIDRs:
  - 192.168.0.0/24
  providerID: openstack:///00324054-405e-4fae-a3bf-d8509d511ded
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
status:
  addresses:
  - address: 10.0.10.14
    type: InternalIP
  - address: master-0-bug
    type: Hostname
  allocatable:
    cpu: "2"
    ephemeral-storage: "19290208634"
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 2962332Ki
    pods: "110"
  capacity:
    cpu: "2"
    ephemeral-storage: 20931216Ki
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 3064732Ki
    pods: "110"
  conditions:
  - lastHeartbeatTime: "2020-07-16T10:02:20Z"
    lastTransitionTime: "2020-07-16T10:02:20Z"
    message: Calico is running on this node
    reason: CalicoIsUp
    status: "False"
    type: NetworkUnavailable
  - lastHeartbeatTime: "2020-07-16T15:46:11Z"
    lastTransitionTime: "2020-07-16T09:59:43Z"
    message: kubelet has sufficient memory available
    reason: KubeletHasSufficientMemory
    status: "False"
    type: MemoryPressure
  - lastHeartbeatTime: "2020-07-16T15:46:11Z"
    lastTransitionTime: "2020-07-16T09:59:43Z"
    message: kubelet has no disk pressure
    reason: KubeletHasNoDiskPressure
    status: "False"
    type: DiskPressure
  - lastHeartbeatTime: "2020-07-16T15:46:11Z"
    lastTransitionTime: "2020-07-16T09:59:43Z"
    message: kubelet has sufficient PID available
    reason: KubeletHasSufficientPID
    status: "False"
    type: PIDPressure
  - lastHeartbeatTime: "2020-07-16T15:46:11Z"
    lastTransitionTime: "2020-07-16T10:19:44Z"
    message: kubelet is posting ready status. AppArmor enabled
    reason: KubeletReady
    status: "True"
    type: Ready
  daemonEndpoints:
    kubeletEndpoint:
      Port: 10250
  nodeInfo:
    architecture: amd64
    bootID: fe410ed3-2825-4f94-a9f9-08dc5e6a955e
    containerRuntimeVersion: docker://19.3.11
    kernelVersion: 4.12.14-197.45-default
    kubeProxyVersion: v1.18.5
    kubeletVersion: v1.18.5
    machineID: 00324054405e4faea3bfd8509d511ded
    operatingSystem: linux
    systemUUID: 00324054-405e-4fae-a3bf-d8509d511ded

और फली:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2020-07-16T10:13:35Z"
  generateName: pm-node-exporter-
  labels:
    controller-revision-hash: 6466d9c7b
    pod-template-generation: "1"
  name: pm-node-exporter-mn9vj
  namespace: monitoring
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: DaemonSet
    name: pm-node-exporter
    uid: 5855a26f-a57e-4b0e-93f2-461c19c477e1
  resourceVersion: "5239"
  selfLink: /api/v1/namespaces/monitoring/pods/pm-node-exporter-mn9vj
  uid: 0db09c9c-1618-4454-94fa-138e55e5ebd7
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchFields:
          - key: metadata.name
            operator: In
            values:
            - master-0-bug
  containers:
  - args:
    - --path.procfs=/host/proc
    - --path.sysfs=/host/sys
    image: ***
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 3
      httpGet:
        path: /
        port: 9100
        scheme: HTTP
      initialDelaySeconds: 5
      periodSeconds: 5
      successThreshold: 1
      timeoutSeconds: 1
    name: pm-node-exporter
    ports:
    - containerPort: 9100
      hostPort: 9100
      name: metrics
      protocol: TCP
    resources:
      limits:
        cpu: 200m
        memory: 150Mi
      requests:
        cpu: 100m
        memory: 100Mi
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /host/proc
      name: proc
      readOnly: true
    - mountPath: /host/sys
      name: sys
      readOnly: true
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: pm-node-exporter-token-csllf
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  hostNetwork: true
  hostPID: true
  nodeSelector:
    node-role.kubernetes.io/master: ""
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: pm-node-exporter
  serviceAccountName: pm-node-exporter
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/disk-pressure
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/memory-pressure
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/pid-pressure
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/unschedulable
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/network-unavailable
    operator: Exists
  volumes:
  - hostPath:
      path: /proc
      type: ""
    name: proc
  - hostPath:
      path: /sys
      type: ""
    name: sys
  - name: pm-node-exporter-token-csllf
    secret:
      defaultMode: 420
      secretName: pm-node-exporter-token-csllf
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2020-07-16T10:13:35Z"
    message: '0/6 nodes are available: 2 node(s) didn''t have free ports for the requested
      pod ports, 3 node(s) didn''t match node selector.'
    reason: Unschedulable
    status: "False"
    type: PodScheduled
  phase: Pending
  qosClass: Burstable

सभी जानकारी के लिए बहुत बहुत धन्यवाद। @nodo आप इसे ले जा सकते हैं?

हम भी अधिक जानकारी प्राप्त करने के लिए https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc के साथ प्रयास कर रहे हैं

/मदद

यदि आप बग ढूंढते हैं तो @maelk इसे लेने के लिए स्वतंत्र है और एक पीआर सबमिट करें। आपके द्वारा जोड़ी गई लॉग लाइनें मददगार होने की संभावना है। अन्यथा, मैं योगदानकर्ताओं के लिए खोल रहा हूं।

@alculquicondor :
इस अनुरोध को एक योगदानकर्ता की मदद के रूप में चिह्नित किया गया है।

कृपया सुनिश्चित करें कि अनुरोध यहां सूचीबद्ध आवश्यकताओं को पूरा करता

यदि यह अनुरोध अब इन आवश्यकताओं को पूरा नहीं करता है, तो लेबल को हटाया जा सकता है
/remove-help कमांड के साथ टिप्पणी करके।

/ असाइन

@maelk क्या यह समय पहली बार होने पर समय के लिए कुछ विशिष्ट है? उदाहरण के लिए, क्या यह नोड शुरू होने के ठीक बाद होता है?

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

प्राथमिकता कम करने तक हमारे पास एक प्रतिलिपि प्रस्तुत करने योग्य मामला है।

हम बग को एक अनुसूचक के साथ पुन: उत्पन्न करने में सक्षम थे जिसमें अतिरिक्त लॉग प्रविष्टियां थीं। जो हम देखते हैं कि एक स्वामी पूरी तरह से नोड्स की सूची से गायब हो जाता है जो इसके माध्यम से पुनरावृत्त होते हैं। हम देख सकते हैं कि प्रक्रिया 6 नोड्स (स्नैपशॉट से) से शुरू होती है:

I0720 13:58:28.246507       1 generic_scheduler.go:441] Looking for a node for kube-system/coredns-cd64c8d7c-tcxbq, going through []*nodeinfo.NodeInfo{(*nodeinfo.NodeInfo)(0xc000326a90), (*nodeinfo.NodeInfo)(0xc000952000), (*nodeinfo.NodeInfo)(0xc0007d08f0), (*nodeinfo.NodeInfo)(0xc0004f35f0), (*nodeinfo.NodeInfo)(0xc000607040), (*nodeinfo.NodeInfo)(0xc000952000)}

लेकिन इसके बाद, हम देख सकते हैं कि यह केवल 5 से अधिक नोड्स पर प्रसारित होता है, और फिर हमें मिलता है:

I0720 13:58:28.247420       1 generic_scheduler.go:505] pod kube-system/coredns-cd64c8d7c-tcxbq : processed 5 nodes, 0 fit

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

लॉग लाइन द्वारा कोड संदर्भ:

1. https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdde4cb201118ca380732d7f361R441R441
2. https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdde4cb201118ca380732d7f361R505R5

@maelk
क्या आपने %v/%v on node %v, too many nodes fit लिए कोई रेखाएँ

अन्यथा, @pancernik आप workqueue.ParallelizeUntil(ctx, 16, len(allNodes), checkNode) पर बगों की जांच कर सकते हैं?

नहीं, वह लॉग दिखाई नहीं दिया। मुझे यह भी लगता है कि यह हो सकता है कि या तो हमारे पास समानांतरकरण के साथ कोई मुद्दा है या पहले नोड को फ़िल्टर किया गया है। यदि यह यहाँ एक त्रुटि के साथ विफल हो रहा था: https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c59c6cafc2ad9bdd=d237cdd9e4cb201118ca3807x7/7366366366366 कार्य और समानांतरकरण।

मुझे बस एहसास हुआ कि एक नोड दो बार फ़िल्टरिंग से गुजर रहा है!

लॉग हैं:

I0720 13:58:28.246507       1 generic_scheduler.go:441] Looking for a node for kube-system/coredns-cd64c8d7c-tcxbq, going through []*nodeinfo.NodeInfo{(*nodeinfo.NodeInfo)(0xc000326a90), (*nodeinfo.NodeInfo)(0xc000952000), (*nodeinfo.NodeInfo)(0xc0007d08f0), (*nodeinfo.NodeInfo)(0xc0004f35f0), (*nodeinfo.NodeInfo)(0xc000607040), (*nodeinfo.NodeInfo)(0xc000952000)}
I0720 13:58:28.246793       1 generic_scheduler.go:469] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-60846k0y-scheduler, fits: false, status: &v1alpha1.Status{code:3, reasons:[]string{"node(s) didn't match node selector"}}
I0720 13:58:28.246970       1 generic_scheduler.go:483] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-60846k0y-scheduler : status is not success
I0720 13:58:28.246819       1 taint_toleration.go:71] Checking taints for pod kube-system/coredns-cd64c8d7c-tcxbq for node master-0-scheduler : taints : []v1.Taint{v1.Taint{Key:"node-role.kubernetes.io/master", Value:"", Effect:"NoSchedule", TimeAdded:(*v1.Time)(nil)}} and tolerations: []v1.Toleration{v1.Toleration{Key:"node-role.kubernetes.io/master", Operator:"Exists", Value:"", Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"CriticalAddonsOnly", Operator:"Exists", Value:"", Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"node-role.kubernetes.io/master", Operator:"Exists", Value:"", Effect:"NoExecute", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"node-role.kubernetes.io/not-ready", Operator:"Exists", Value:"", Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"node.kubernetes.io/not-ready", Operator:"Exists", Value:"", Effect:"NoExecute", TolerationSeconds:(*int64)(0xc000d40d90)}, v1.Toleration{Key:"node.kubernetes.io/unreachable", Operator:"Exists", Value:"", Effect:"NoExecute", TolerationSeconds:(*int64)(0xc000d40db0)}}
I0720 13:58:28.247019       1 taint_toleration.go:71] Checking taints for pod kube-system/coredns-cd64c8d7c-tcxbq for node master-2-scheduler : taints : []v1.Taint{v1.Taint{Key:"node-role.kubernetes.io/master", Value:"", Effect:"NoSchedule", TimeAdded:(*v1.Time)(nil)}} and tolerations: []v1.Toleration{v1.Toleration{Key:"node-role.kubernetes.io/master", Operator:"Exists", Value:"", Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"CriticalAddonsOnly", Operator:"Exists", Value:"", Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"node-role.kubernetes.io/master", Operator:"Exists", Value:"", Effect:"NoExecute", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"node-role.kubernetes.io/not-ready", Operator:"Exists", Value:"", Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"node.kubernetes.io/not-ready", Operator:"Exists", Value:"", Effect:"NoExecute", TolerationSeconds:(*int64)(0xc000d40d90)}, v1.Toleration{Key:"node.kubernetes.io/unreachable", Operator:"Exists", Value:"", Effect:"NoExecute", TolerationSeconds:(*int64)(0xc000d40db0)}}
I0720 13:58:28.247144       1 generic_scheduler.go:469] pod kube-system/coredns-cd64c8d7c-tcxbq on node master-2-scheduler, fits: false, status: &v1alpha1.Status{code:2, reasons:[]string{"node(s) didn't match pod affinity/anti-affinity", "node(s) didn't satisfy existing pods anti-affinity rules"}}
I0720 13:58:28.247172       1 generic_scheduler.go:483] pod kube-system/coredns-cd64c8d7c-tcxbq on node master-2-scheduler : status is not success
I0720 13:58:28.247210       1 generic_scheduler.go:469] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-7dt1xd4k-scheduler, fits: false, status: &v1alpha1.Status{code:3, reasons:[]string{"node(s) didn't match node selector"}}
I0720 13:58:28.247231       1 generic_scheduler.go:483] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-7dt1xd4k-scheduler : status is not success
I0720 13:58:28.247206       1 generic_scheduler.go:469] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-60846k0y-scheduler, fits: false, status: &v1alpha1.Status{code:3, reasons:[]string{"node(s) didn't match node selector"}}
I0720 13:58:28.247297       1 generic_scheduler.go:483] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-60846k0y-scheduler : status is not success
I0720 13:58:28.247246       1 generic_scheduler.go:469] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-hyk0hg7r-scheduler, fits: false, status: &v1alpha1.Status{code:3, reasons:[]string{"node(s) didn't match node selector"}}
I0720 13:58:28.247340       1 generic_scheduler.go:483] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-hyk0hg7r-scheduler : status is not success
I0720 13:58:28.247147       1 generic_scheduler.go:469] pod kube-system/coredns-cd64c8d7c-tcxbq on node master-0-scheduler, fits: false, status: &v1alpha1.Status{code:2, reasons:[]string{"node(s) didn't match pod affinity/anti-affinity", "node(s) didn't satisfy existing pods anti-affinity rules"}}
I0720 13:58:28.247375       1 generic_scheduler.go:483] pod kube-system/coredns-cd64c8d7c-tcxbq on node master-0-scheduler : status is not success
I0720 13:58:28.247420       1 generic_scheduler.go:505] pod kube-system/coredns-cd64c8d7c-tcxbq : processed 5 nodes, 0 fit
I0720 13:58:28.247461       1 generic_scheduler.go:430] pod kube-system/coredns-cd64c8d7c-tcxbq After scheduling, filtered: []*v1.Node{}, filtered nodes: v1alpha1.NodeToStatusMap{"master-0-scheduler":(*v1alpha1.Status)(0xc000d824a0), "master-2-scheduler":(*v1alpha1.Status)(0xc000b736c0), "worker-pool1-60846k0y-scheduler":(*v1alpha1.Status)(0xc000d825a0), "worker-pool1-7dt1xd4k-scheduler":(*v1alpha1.Status)(0xc000b737e0), "worker-pool1-hyk0hg7r-scheduler":(*v1alpha1.Status)(0xc000b738c0)}
I0720 13:58:28.247527       1 generic_scheduler.go:185] Pod kube-system/coredns-cd64c8d7c-tcxbq failed scheduling:
  nodes snapshot: &cache.Snapshot{nodeInfoMap:map[string]*nodeinfo.NodeInfo{"master-0-scheduler":(*nodeinfo.NodeInfo)(0xc000607040), "master-1-scheduler":(*nodeinfo.NodeInfo)(0xc0001071e0), "master-2-scheduler":(*nodeinfo.NodeInfo)(0xc000326a90), "worker-pool1-60846k0y-scheduler":(*nodeinfo.NodeInfo)(0xc000952000), "worker-pool1-7dt1xd4k-scheduler":(*nodeinfo.NodeInfo)(0xc0007d08f0), "worker-pool1-hyk0hg7r-scheduler":(*nodeinfo.NodeInfo)(0xc0004f35f0)}, nodeInfoList:[]*nodeinfo.NodeInfo{(*nodeinfo.NodeInfo)(0xc000326a90), (*nodeinfo.NodeInfo)(0xc000952000), (*nodeinfo.NodeInfo)(0xc0007d08f0), (*nodeinfo.NodeInfo)(0xc0004f35f0), (*nodeinfo.NodeInfo)(0xc000607040), (*nodeinfo.NodeInfo)(0xc000952000)}, havePodsWithAffinityNodeInfoList:[]*nodeinfo.NodeInfo{(*nodeinfo.NodeInfo)(0xc000326a90), (*nodeinfo.NodeInfo)(0xc000607040)}, generation:857} 
  statuses: v1alpha1.NodeToStatusMap{"master-0-scheduler":(*v1alpha1.Status)(0xc000d824a0), "master-2-scheduler":(*v1alpha1.Status)(0xc000b736c0), "worker-pool1-60846k0y-scheduler":(*v1alpha1.Status)(0xc000d825a0), "worker-pool1-7dt1xd4k-scheduler":(*v1alpha1.Status)(0xc000b737e0), "worker-pool1-hyk0hg7r-scheduler":(*v1alpha1.Status)(0xc000b738c0)} 

जैसा कि आप देख सकते हैं नोड कार्यकर्ता-पूल 1-60846k0y-अनुसूचक फ़िल्टरिंग के माध्यम से दो बार जाता है

नहीं, वह लॉग दिखाई नहीं दिया। मुझे यह भी लगता है कि यह हो सकता है कि या तो हमारे पास समानांतरकरण के साथ कोई मुद्दा है या पहले नोड को फ़िल्टर किया गया है। यदि यह यहां एक त्रुटि के साथ विफल हो रहा था: नॉर्डिक्स @ 5c00cdf # diff -c237cdd9e4cb201118ca380732d7f361R464 यह लॉग्स afaik में दिखाई देगा, इसलिए मैं विशेष रूप से फ़ंक्शन और समानांतरकरण के चारों ओर अधिक डिबग प्रविष्टियां जोड़ने का प्रयास करूंगा।

हाँ, पॉड ईवेंट में कोई त्रुटि एक शेड्यूलिंग त्रुटि के रूप में प्रकट होगी।

मुझे बस एहसास हुआ कि एक नोड दो बार फ़िल्टरिंग से गुजर रहा है!

मैं ईमानदारी से यह नहीं सोचूंगा कि समानांतरण में कीड़े हैं (अभी भी जांच के लायक हैं), लेकिन यह एक संकेत हो सकता है कि हम कैश से स्नैपशॉट बनाने में विफल रहे (जैसा कि हमने कैश डंप से देखा, कैश सही है), एक को जोड़कर दो बार नोड। चूंकि स्थितियां एक नक्शा है, तो यह समझ में आता है कि हम केवल अंतिम लॉग लाइन पर "5" नोड्स देखते हैं।

यह कोड (1.18 का टिप) https://github.com/kubernetes/kubernetes/blob/ec73e191f47b7992c2f40fadf1389446d6661d6d/pkg/scheduler/internal/cache/cache.go#L203 है।

cc @ आहग-जी

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

कैश! = स्नैपशॉट

कैश वह जीवित चीज है जो घटनाओं से अपडेट हो जाती है। स्नैपशॉट अद्यतन किया गया है (कैश से) प्रत्येक शेड्यूलिंग चक्र से पहले राज्य को "लॉक" करें। हमने इस अंतिम प्रक्रिया को यथासंभव तेज़ बनाने के लिए अनुकूलन जोड़े हैं। यह संभव है कि बग वहाँ है।

धन्यवाद @maelk! यह बहुत उपयोगी है। आपका लॉग संकेत मिलता है कि (*nodeinfo.NodeInfo)(0xc000952000) पर पहले से ही सूची में दोहराया गया है https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff किसी भी समानांतर कोड का निष्पादित से पहले -c237cdd9e4cb201118ca380732d7f361R441। इसका मतलब यह होगा कि स्नैपशॉट अपडेट होने से पहले इसका डुप्लिकेट है।

वास्तव में, यह स्नैपशॉट से आता है, जो इस लॉग संदेश से पहले होता है: https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb2018-2018

ये सही है। मेरा मतलब था कि यह स्नैपशॉट के अपडेट के पहले ही डुप्लिकेट हो चुका है।

ये सही है। मेरा मतलब था कि यह स्नैपशॉट के अपडेट के पहले ही डुप्लिकेट हो चुका है।

नहीं, शेड्यूलिंग चक्र के प्रारंभ में स्नैपशॉट अपडेट किया गया है। बग या तो स्नैपशॉट अद्यतन के दौरान या उससे पहले है। लेकिन कैश सही है, https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -659465008 में डंप के अनुसार

संपादित करें: मैंने इसे गलत पढ़ा है, मैंने "फिनिश" शब्द नहीं देखा है :)

PR ऑप्टिमाइज़िंग अपडेट स्नैपशॉट 1.18 में किया गया था: https://github.com/kubernetes/kubernetes/pull/85738 और https://github.com/kubernetes/kubernetes/pull-86919

मुझे आश्चर्य है कि अगर नोड ट्री में भी डुप्लिकेट रिकॉर्ड हैं

मुझे आश्चर्य है कि अगर नोड ट्री में भी डुप्लिकेट रिकॉर्ड हैं

@maelk क्या आप कैश में नोड्स की पूरी सूची का डंप दिखा सकते हैं?

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

केवल स्पष्ट करने हेतु:
1) क्लस्टर में 6 नोड हैं (स्वामी सहित)
2) फली को होस्ट करने वाला नोड बिल्कुल भी जांच नहीं किया गया था (कोई लॉग लाइन जो यह संकेत नहीं दे रही है), जिसका मतलब यह हो सकता है कि यह NodeInfoList में बिल्कुल भी नहीं है।
3) NodeInfoList में 6 नोड हैं, लेकिन उनमें से एक डुप्लिकेट है

मुझे आश्चर्य है कि अगर नोड ट्री में भी डुप्लिकेट रिकॉर्ड हैं

@maelk क्या आप कैश में नोड्स की पूरी सूची का डंप दिखा सकते हैं?

प्रत्येक नोड ट्री, सूची और मानचित्र का एक डंप महान होगा।

मैं उन पर काम करूँगा। इस बीच, एक छोटा सा अद्यतन। हम लॉग में देख सकते हैं:

I0720 13:37:30.530980       1 node_tree.go:100] Removed node "worker-pool1-60846k0y-scheduler" in group "" from NodeTree
I0720 13:37:30.531136       1 node_tree.go:86] Added node "worker-pool1-60846k0y-scheduler" in group "regionOne:\x00:nova" to NodeTree

और वह सटीक बिंदु है जब लापता नोड गायब हो जाता है। लॉग में अंतिम घटना 13:37:24 पर है। अगले शेड्यूलिंग में, अनुपलब्ध नोड चला गया है। इसलिए ऐसा लगता है कि बग नोड_ट्री के अपडेट के बाद / में है। सभी नोड्स उस अपडेट से गुजरते हैं, यह सिर्फ इतना है कि यह कार्यकर्ता 608 इसके माध्यम से जाने वाला अंतिम है।

कैश डंप करते समय (SIGUSR2 के साथ) सभी छह नोड्स वहां सूचीबद्ध होते हैं, नोड्स पर चलने वाले डुप्लिकेट या गुम नोड्स के बिना।

हम इसे स्नैपशॉट कार्यक्षमता के आसपास जोड़े गए डिबग के साथ एक नया प्रयास देंगे: https://github.com/Nordix/kubernetes/commit/53279fb06536558f9a91836c771b182741153791

नोड नोड्री से "कार्यकर्ता-पूल 1-60846k0y-अनुसूचक" समूह में हटा दिया गया

दिलचस्प है, मुझे लगता है कि हटाने / जोड़ने के लिए एक अद्यतन द्वारा कॉल ट्रिगर किया जाता है। ज़ोन कुंजी हटाने पर गायब है, लेकिन ऐड पर मौजूद है, इसलिए अद्यतन मूल रूप से ज़ोन और क्षेत्र लेबल जोड़ रहा था?

क्या आपके पास इस नोड से संबंधित अन्य अनुसूचक लॉग हैं?

हम जोड़े गए लॉगिंग के साथ बग को पुन: उत्पन्न करने का प्रयास कर रहे हैं। अधिक जानकारी होने पर मैं वापस आऊंगा

मैं उन पर काम करूँगा। इस बीच, एक छोटा सा अद्यतन। हम लॉग में देख सकते हैं:

I0720 13:37:30.530980       1 node_tree.go:100] Removed node "worker-pool1-60846k0y-scheduler" in group "" from NodeTree
I0720 13:37:30.531136       1 node_tree.go:86] Added node "worker-pool1-60846k0y-scheduler" in group "regionOne:\x00:nova" to NodeTree

मैं बताता हूं कि ऐसा नोड बार-बार आने वाला नोड है। @maelk , क्या आपने अन्य नोड्स के लिए समान संदेश देखे या नहीं? @ आह-जी के रूप में, यह उम्मीद की जानी चाहिए कि जब कोई नोड प्राप्त करता है तो यह पहली बार टोपोलॉजी लेबल है।

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

क्या आपको लापता नोड के लिए अपडेट लॉग मिले?

क्या आपको लापता नोड के लिए अपडेट लॉग मिले?

योग्य, बस यह सवाल टाइप कर रहा था।

शायद बग यह है कि सभी नोड्स को हटाने से पहले पूरे क्षेत्र को पेड़ से हटा दिया जाता है।

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

क्या आपको लापता नोड के लिए अपडेट लॉग मिले?

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

सच कहूं तो, बग के कारण के बारे में मेरे पास अभी भी कोई सुराग नहीं है, लेकिन अगर हम इसे खोजने के करीब पहुंच सकते हैं, तो मैं एक पीआर या यूनिट परीक्षण प्रस्तुत करूंगा।

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

यदि ऐसा है, तो मुझे लगता है कि यह "सटीक बिंदु है जब लापता नोड गायब हो जाता है।" सहसंबद्ध नहीं हो सकता है। नए लॉग का इंतजार करें। यह बहुत अच्छा होगा यदि आप सभी अनुसूचक लॉग को एक फ़ाइल में साझा कर सकते हैं।

जब हम नए लॉगिंग के साथ पुन: पेश करेंगे तो मैं करूँगा। मौजूदा लोगों से, हम वास्तव में देख सकते हैं कि उस अपडेट के तुरंत बाद पॉड शेड्यूलिंग विफल होने वाला पहला है। लेकिन यह जानने के लिए पर्याप्त जानकारी नहीं देता है कि बीच में क्या हुआ था, इसलिए बने रहें ...

@maelk क्या आपने शेड्यूलर लॉग में snapshot state is not consistent से शुरू होने वाला संदेश देखा है?

क्या आपके लिए पूर्ण अनुसूचक लॉग प्रदान करना संभव होगा?

नहीं, वह संदेश मौजूद नहीं है। मैं एक धारीदार लॉग फ़ाइल (पुनरावृत्ति से बचने के लिए) दे सकता था, लेकिन पहले तब तक प्रतीक्षा करें जब तक हमारे पास आउटपुट न हो जाए

मैंने बग ढूंढ लिया है। समस्या नोडट्री अगले () फ़ंक्शन के साथ है, जो कुछ मामलों में सभी नोड्स की सूची वापस नहीं करता है। https://github.com/kubernetes/kubernetes/blob/release-1.18/pkg/scheduler/internal/cache/node_tree.go#L147

यदि आप यहां निम्नलिखित जोड़ते हैं तो यह दिखाई देता है: https://github.com/kubernetes/kubernetes/blob/release-1.18/pkg/scheduler/internal/cache/node_tree_nest.go#L443

{
    name:           "add nodes to a new and to an exhausted zone",
    nodesToAdd:     append(allNodes[5:9], allNodes[3]),
    nodesToRemove:  nil,
    operations:     []string{"add", "add", "next", "next", "add", "add", "add", "next", "next", "next", "next"},
    expectedOutput: []string{"node-6", "node-7", "node-3", "node-8", "node-6", "node-7"},
},

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

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

मैंने पुनरावृत्ति के साथ भी यही समस्या देखी। लेकिन मैं स्नैपशॉट में एक डुप्लिकेट से लिंक करने में विफल रहा। क्या आप एक परिदृश्य बनाने में कामयाब रहे हैं, जहां @maelk होगा?

हां, आप मेरे द्वारा लगाए गए छोटे कोड को जोड़कर इकाई परीक्षणों में इसे चला सकते हैं

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

समस्या को पुन: प्रस्तुत करने और अपने सेटअप में परीक्षण चलाने में मदद के लिए @igraecao तक बड़े अंगूठे

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

NodeInfoList की शुरुआत के साथ next फ़ंक्शन का उद्देश्य बदल गया, और इसलिए हम निश्चित रूप से इसे सरल बना सकते हैं और शायद इसे toList , एक फ़ंक्शन जो पेड़ से एक सूची बनाता है और बस शुरू होता है। हर बार शुरुआत से।

मैं अब इस मुद्दे को समझता हूं: ज़ोन समाप्त हो गया है या नहीं इसकी गणना गलत है क्योंकि यह नहीं मानता है कि प्रत्येक ज़ोन में हमने यह "UpdateSnapshot" प्रक्रिया कहाँ शुरू की है। और हाँ, यह केवल असमान क्षेत्रों के साथ दिखाई देगा।

महान नौकरी इस @maelk खोलना!

मुझे लगता है कि पुराने संस्करणों में हमारे पास एक ही मुद्दा होगा। हालांकि, यह इस तथ्य से छिपा है कि हम हर बार एक पेड़ पास करते हैं। जबकि 1.18 में हम परिणाम को स्नैपशॉट करते हैं जब तक कि पेड़ में परिवर्तन न हों।

अब जब राउंड-रॉबिन रणनीति को जेनेरिक_स्क्राइडर.ओगो में लागू किया गया है, तो हम अपडेट कर सकते हैं कि अपडेट करने वाले स्नैपशॉट से पहले सभी काउंटरों को रीसेट कर दें, जैसा कि आपका पीआर कर रहा है।

https://github.com/kubernetes/kubernetes/blob/02cf58102a61b6d1e021e256381ff750573ce55d/pkg/scheduler/core/generic_scheduler.go#L357

बस चेक करने के लिए @ आह-जी, यह ठीक होना चाहिए यहां तक ​​कि एक क्लस्टर में नए नोड्स को हर समय जोड़ा / हटा दिया गया है, है ना?

मूल कारण बताने के लिए धन्यवाद

अगले फ़ंक्शन का उद्देश्य NodeInfoList की शुरुआत के साथ बदल गया, और इसलिए हम निश्चित रूप से इसे सरल बना सकते हैं और शायद इसे toList में बदल सकते हैं, एक फ़ंक्शन जो पेड़ से एक सूची बनाता है और बस हर बार शुरुआत से शुरू होता है।

यह देखते हुए कि cache.nodeTree.next() केवल स्नैपशॉट नोडइनफॉइलिस्ट के निर्माण में कहा जाता है, मुझे लगता है कि इंडेक्स (ज़ोनइंडेक्स और नोडइंडेक्स) को नोडट्री संरचना से निकालना भी सुरक्षित है। इसके बजाय, एक सरल nodeIterator() फ़ंक्शन के साथ अपने ज़ोन / नोड के माध्यम से एक राउंड-रॉबिन तरीके से पुनरावृति करना।

BTW: https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -662663090 में एक टाइपो है, मामला होना चाहिए:

{
    name:           "add nodes to a new and to an exhausted zone",
    nodesToAdd:     append(allNodes[6:9], allNodes[3]),
    nodesToRemove:  nil,
    operations:     []string{"add", "add", "next", "next", "add", "add", "next", "next", "next", "next"},
    expectedOutput: []string{"node-6", "node-7", "node-3", "node-8", "node-6", "node-7"},
    // with codecase on master and 1.18, its output is [node-6 node-7 node-3 node-8 node-6 node-3]
},

बस चेक करने के लिए @ आह-जी, यह ठीक होना चाहिए यहां तक ​​कि एक क्लस्टर में नए नोड्स को हर समय जोड़ा / हटा दिया गया है, है ना?

मैं मान रहा हूं कि आप जेनेरिक_स्क्राइडर.ओगो में तर्क के बारे में बात कर रहे हैं, यदि हां, तो यह बहुत ज्यादा मायने नहीं रखता है यदि नोड्स जोड़े या हटाए गए हैं, तो मुख्य बात जो हमें बचने की जरूरत है वह एक ही समय में नोड्स से अधिक परेशान है। हम एक पॉड को शेड्यूल करते हैं, हमें बस फली के पार नोड्स पर पुनरावृत्ति करने की एक अच्छी आवश्यकता है।

यह देखते हुए कि cache.nodeTree.next () को केवल स्नैपशॉट नोडइन्फो के निर्माण में कहा जाता है, मुझे लगता है कि इंडेक्स (ज़ोनइंडेक्स और नोडइंडेक्स) को नोडट्री संरचना से निकालना भी सुरक्षित है। इसके बजाए, एक सरल नोड -िएटर () फ़ंक्शन के साथ एक राउंड-रॉबिन तरीके से अपने ज़ोन / नोड के माध्यम से पुनरावृति करने के लिए आते हैं।

हां, हमें हर बार एक ही क्रम में सभी क्षेत्रों / नोड्स पर पुनरावृति करने की आवश्यकता है।

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

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

मैं वास्तव में आप यहाँ क्या मतलब नहीं मिलता है। क्या ऐसा है कि नोड्स का क्रम मायने रखता है और हमें अभी भी ज़ोन के बीच राउंड-रॉबिन जाना चाहिए या क्या हम एक के बाद एक ज़ोन, एक ज़ोन के सभी नोड्स को सूचीबद्ध कर सकते हैं? मान लीजिए कि आपके पास दो-दो नोड्स हैं, प्रत्येक क्रम में आप उनसे क्या उम्मीद करते हैं, या क्या यह बिल्कुल भी मायने रखता है?

आदेश मायने रखता है, हमें सूची बनाते समय ज़ोन के बीच वैकल्पिक करने की आवश्यकता है। यदि आपके पास प्रत्येक z1: {n11, n12} और z2: {n21, n22} दो क्षेत्र हैं, तो सूची {n11, n21, n12, n22} होनी चाहिए

ठीक है, धन्यवाद, मैं इसे एक विचार दूँगा। क्या हम इस बीच जल्दी ठीक कर सकते हैं? btw, कुछ परीक्षण इस पर विफल हो रहे हैं, लेकिन मुझे यकीन नहीं है कि यह मेरे पीआर से कैसे संबंधित है

वे गुच्छे हैं। कृपया 1.18 को एक पैच भेजें।

ठीक। कर दूँगा। धन्यवाद

{
  name:           "add nodes to a new and to an exhausted zone",
  nodesToAdd:     append(allNodes[5:9], allNodes[3]),
  nodesToRemove:  nil,
  operations:     []string{"add", "add", "next", "next", "add", "add", "add", "next", "next", "next", "next"},
  expectedOutput: []string{"node-6", "node-7", "node-3", "node-8", "node-6", "node-7"},
},

@maelk , क्या आपका मतलब है कि यह परीक्षण 'नोड -5' को नजरअंदाज करता है?

मैंने https://github.com/kubernetes/kubernetes/pull/93516 में परिशिष्ट तय करने के बाद पाया, परीक्षा परिणाम सभी नोड्स पुनरावृत्त हो सकते हैं:

{
            name:           "add nodes to a new and to an exhausted zone",
            nodesToAdd:     append(append(make([]*v1.Node, 0), allNodes[5:9]...), allNodes[3]),
            nodesToRemove:  nil,
            operations:     []string{"add", "add", "next", "next", "add", "add", "add", "next", "next", "next", "next"},
            expectedOutput: []string{"node-5", "node-6", "node-3", "node-7", "node-8", "node-5"},
},

नोड -5, 6, 7, 8, 3 को पुनरावृत्त किया जा सकता है।

मुझे माफ कर दो अगर यहाँ कुछ गलत समझे।

हां, यह उद्देश्य पर था, जो वहां था, उसके आधार पर, लेकिन मैं देख सकता हूं कि यह कैसे गूढ़ हो सकता है, इसलिए इसे बेहतर बनाएं ताकि ऐप स्पष्ट तरीके से व्यवहार कर रहा हो। पैच के लिए धन्यवाद।

कितनी दूर आपको लगता है कि यह बग मौजूद था? 1.17? 1.16? मैंने अभी ठीक 1.17 में AWS पर एक ही समस्या देखी है और अनिर्धारित नोड को पुनः आरंभ करने से समस्या ठीक हो गई है।

@judgeaxl क्या आप अधिक जानकारी प्रदान कर सकते हैं? लॉग लाइनें, कैश डंप आदि, इसलिए हम यह निर्धारित कर सकते हैं कि क्या समस्या समान है।

जैसा कि मैंने https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -662746695 में उल्लेख किया है, मेरा मानना ​​है कि यह बग पुराने संस्करणों में मौजूद था, लेकिन मेरी सोच यह क्षणिक थी।

@maelk क्या आप जांच कर पाएंगे?

कृपया क्षेत्र में नोड्स के वितरण को भी साझा करें।

@alculquicondor दुर्भाग्य से मैं इस बिंदु पर नहीं हो सकता। माफ़ करना।

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

ज़ोन असंतुलन होने पर कुछ नोड्यूल को शेड्यूलिंग में नहीं माना जाता है