Kubeadm: apiserver शुरू करने में विफल रहता है क्योंकि l लंगूरप्रोब बहुत आक्रामक है

ऐसा लगता है कि हम दोनों InitialDelaySeconds और TimeoutSeconds से 15 वर्तमान में नियंत्रण विमान पॉड्स के लिए सेट करते हैं, जो मेल खाता है kube-up.sh भी। मैं समझता हूं कि आरंभिक लॉन्च धीमा है, क्योंकि सभी छवियों को एक ही बार में खींचा जा रहा है, लेकिन सभी छवियों को खींचे जाने के बाद, लॉन्च होने के बाद /healthz चेक का जवाब देने के लिए आपके एप्साइवर को कितना समय लगता है?

इसमें कोई संदेह नहीं है कि हम शायद लो-पावर मशीनों को समायोजित करने के लिए इन दोनों मूल्यों को मोड़ दें।

एक बार शुरू करने के बाद यह << 15s में स्वास्थ्य जांच का जवाब दे सकता है - यह वास्तव में केवल सभी अतिरिक्त सामान है जो कि एफ़िसर निष्पादन के बीच करता है () और वास्तव में afaics की सेवा के लिए तैयार हो रहा है।

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

मैं वही समस्या चला रहा हूं। धीमी मशीनों के साथ kubeadm हमेशा के लिए बैठता है। V1.7.4 का उपयोग करना

@anguslees और @koalalorenzo , क्या आप इस बात की पुष्टि कर सकते हैं कि यदि आप मैन्युअल रूप से /etc/kubernetes/manifests/ में मैनिफ़ेस्ट फ़ाइल्स को संपादित करके) बदलते हैं तो यह आपकी समस्या को हल करता है? मैंने हाल ही में स्लैक पर एक मामला भी देखा, जहां उपयोगकर्ता के लक्षण समान थे, लेकिन संभवतः स्मृति बाधाओं में चल रहा था, क्योंकि समस्या तब चली गई जब वे अधिक मेमोरी वाले होस्ट प्रकार में चले गए।

मैं सिर्फ यह सुनिश्चित करना चाहता हूं कि यह दृष्टिकोण वास्तव में समस्या को ठीक करेगा इससे पहले कि हम इसे कोडिंग में समय लगाने से पहले। धन्यवाद!

हार्डवेयर-असिस्टेड वर्चुअलाइजेशन के बिना QEMU में kubeadm का उपयोग करने का प्रयास करते समय मैं भी इस मुद्दे का अनुभव कर रहा हूं (जो कि एक बुरा विचार है क्योंकि यह बहुत धीमा है)। InitialDelaySeconds और TimeoutSeconds बढ़ाने से मदद मिलती है; क्लस्टर तो अंततः आ जाएगा।

@ पिप्पजकोब मैं इस बात की पुष्टि कर सकता हूं कि (मेरे केलेपी पर) कुबेदम रन में सही बिंदु पर इसे दूसरे टर्मिनल में चलाने से सब कुछ सफलतापूर्वक हो जाता है:

sed -i 's/initialDelaySeconds: [0-9]\+/initialDelaySeconds: 180/' /etc/kubernetes/manifests/kube-apiserver.yaml

(मैं आमतौर पर मैन्युअल रूप से docker kill पुराना / रिस्टार्ट-लूपिंग एपेस्वर कंटेनर देता हूं, मुझे यकीन नहीं है कि अगर यह स्थिर फली के साथ स्वचालित रूप से साफ हो जाता है)

@anguslees बढ़िया! पुष्टि के लिए धन्यवाद।

मैं इस बात की पुष्टि कर सकता हूं कि मेरे पास बस यह मुद्दा था, मेरे मामले में एक रास्पबेरी पाई 3 पर। 180 में परिवर्तन ने इसे ठीक कर दिया, हालांकि मुझे लगता है कि मुझे भी # 106 मुद्दे का सामना करना पड़ा क्योंकि मेरे मामले में यह बस के साथ मर गया:

1 सितंबर, 10:47:30 रास्पबेरी कुब्लेट [6053]: W0901 10: 47: 30.020409 6053 kubelet.go: 1596] मिरर पॉड को हटाना "kube-apiserver-raspberry__ube-system (7c03df63-8efa-1
1e7-ae86-b827ebdd4b52) "क्योंकि यह पुराना है

मुझे मैन्युअल रूप से क्यूबलेट प्रक्रिया को एचयूपी करना था ताकि इसे वापस जीवन में लाया जा सके।

मैं यह भी पुष्टि कर सकता हूं कि मेरे पास यह था और मेरी पवित्रता को बचाने के लिए धन्यवाद कहना चाहता था। मेरे पास रास्पबेरी पाई 2 बी है और मैं पिछले महीने के लिए इनिट चरण में फंस गया था। उस एक-लाइनर को चलाने के बाद एक बार जब यह नियंत्रण विमान की प्रतीक्षा करने लगा, तो मैंने इसे आगे बढ़ा दिया।

यह समस्या अभी भी kubeadm v1.8.0 में मौजूद है, और यह बदतर है क्योंकि kubeadm ही अब अधिकांश कार्यों पर 1min का समय है। लगता है कि 1 मिनट का समय मनमाने ढंग से चुना गया है, और दुर्भाग्य से a) आपको पर्याप्त समय नहीं देता कि आप इसमें कूद सकें और समस्या को हल कर सकें (उदाहरण के लिए: sed हैक ऊपर), b) प्रारंभ करने वाले के लिए पर्याप्त समय (~) मेरे लिए 90s), तब भी kubeadm afaics नहीं बढ़ाया जा सकता है।

टाइमआउट अन्यथा सही तर्क को तोड़ता है, विशेष रूप से जटिल अंततः-सुसंगत प्रणालियों में - हमें उन्हें कभी भी "सिर्फ इसलिए" नहीं जोड़ना चाहिए :( मेरी समझ यह है कि kubeadm एक बिल्डिंग ब्लॉक होने का मतलब है, जिस पर बड़े परिनियोजन सिस्टम निर्भर कर सकते हैं। नतीजतन, मैं साहसपूर्वक कुबेदाम से सभी टाइमआउट को हटाने का प्रस्ताव करता हूं (विभिन्न चरणों को हमेशा के लिए पुन: प्रयास जारी रखना चाहिए), और उस उच्च स्तर के संदर्भ में / यदि उपयुक्त हो तो एक समग्र टाइमआउट जोड़ने के लिए उच्च स्तर की प्रक्रिया पर भरोसा करें। सरल / प्रत्यक्ष उपयोग के मामले में "उपयोगकर्ता द्वारा त्यागने और ^ c दबाने तक" का अर्थ होगा। क्या ऐसा PR स्वीकार्य होगा?

@anguslees हमने पहले "प्रतीक्षा हमेशा के लिए" व्यवहार किया था; लेकिन यह एक UX PoV से बहुत उप-इष्टतम था, इसलिए अब हमारे पास टाइमआउट है। यदि आप चाहें तो हम उनमें से कुछ समय बढ़ाना चाहते हैं।

समस्या यह है कि कुबेदम का उपयोग दो गुना है। हम दोनों के पास यूज़र्स को kubeadm टाइप करने की सुविधा है जो यह जानना चाहते हैं कि कुछ हो रहा है या नहीं _and_ उच्च-स्तरीय उपभोक्ता।

.. तो हम यहाँ किस दिशा में जाने वाले हैं? वर्तमान में मैं kubeadm एक कांटे का उपयोग करता हूं जिसमें 10x के कई क्रैकआउट हुए हैं, और मुझे विश्वास है कि मैं कुछ समय में मानक kubeadm बायनेरिज़ का उपयोग करके वापस जा सकता हूं।

@anguslees हमने पहले "प्रतीक्षा हमेशा के लिए" व्यवहार किया था; लेकिन यह एक UX PoV से बहुत उप-इष्टतम था, इसलिए अब हमारे पास टाइमआउट है। यदि आप चाहें तो हम उनमें से कुछ समय बढ़ाना चाहते हैं।

कैसे उन्हें विन्यास बनाने के बारे में? क्या यह समझ में आता है कि सभी के पास एक ही विकल्प है?

/ प्राथमिकता महत्वपूर्ण-जल्द

क्या यह समझ में आता है कि सभी के पास एक ही विकल्प है?

शायद, या सभी प्रकार के समय के लिए "वजन" के साथ गुणा करने के लिए ... अन्यथा हम समय के झंडे के 20 विभिन्न प्रकारों के साथ नरक में प्रवेश करेंगे :)

रास्पबेरी पी 2 क्लस्टर पर कुबेदम अपग्रेड का उपयोग करके एक ही मुद्दे में चल रहा है। एग्रेसिव टाइमआउट के कारण अपग्रेड फेल हो जाता है। मैनिफ़ेस्ट में लिनेन जांच सेटिंग्स बदलने से कोई मदद नहीं मिलती है। कोई विचार?

मैं अभी भी एक पैटर्न का प्रस्ताव करता हूं जहां किसी भी kubeadm टाइमआउट को कॉलबेड कोडबेस के निचले स्तरों में मनमाने समय के दौरान छिड़कने के बजाय कॉलिंग संदर्भ (या अधिक परिष्कृत त्रुटि रिकवरी रणनीति का हिस्सा) से विरासत में मिला है।

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

मूल प्रकटन linyProbe टाइमआउट के लिए, यह शाब्दिक रूप से एक-लाइनर पैच है। दुर्भाग्य से, अकेले linyProbe को ठीक करना अब पर्याप्त नहीं है क्योंकि "सामान्य से विचलन == त्रुटि" की विस्मृति पूरे कुबेदम कोडबेस में आगे फैल गई है। सांस्कृतिक जागरूकता को बदलना कठिन है, इसलिए इस बीच मेरे पास यहां कुबेदम है , अगर कोई भी रास्पबेरी पाई पर स्थापित करना चाहता है। ( make cross WHAT=cmd/kubeadm KUBE_BUILD_PLATFORMS=linux/arm साथ बनाएँ)

@anguslees क्या आपके पास अपने पैच किए गए कुबेदम का संकलित 1.9.4 संस्करण है? मुझे आपके पैच किए गए संस्करण को संकलित करने में परेशानी हो रही है।

मुझे आश्चर्य है कि एक ध्वज के पीछे कुबेद का यह व्यवहार नहीं है। शायद एक पीआर क्रम में है?

/ असाइन करें @liztio

इसलिए हमने 1.11 में दो मुद्दे तय किए हैं जो इसे प्रभावित कर सकते हैं।

1. स्टार्टअप से पहले etcd छवि को प्राथमिकता दें।
2. स्टार्टअप पर दौड़-हालत की जांच को ठीक करें।
   ...

यदि यह केवल रसबेरी पाई - गियर पर हो रहा है, तो हमें सबसे कम सामान्य भाजक को अर्हता प्राप्त करने के कुछ तरीके की आवश्यकता है।

न्यूनतम लक्ष्य प्लेटफ़ॉर्म क्या है जिसे हम समर्थन देने की योजना बना रहे हैं?

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

यह देखते हुए कि पाई धीमे I / O से ग्रस्त है, सभी छवियों को पहले से खींचना पहले से ही बहुत मदद करेगा, लेकिन वास्तविक टाइमआउट निर्धारित करने के लिए हमें कुछ वास्तविक दुनिया परीक्षणों की आवश्यकता होगी।

imo rasberry pi2 समर्थन के लिए बहुत पुराना है - http://socialcompare.com/en/comparison/raspberrypi-models-comparison , 2015 में सामने आया।

>= 3 अधिक उचित imo लगता है।

Prepulling चित्र मदद नहीं करेगा। LinyProbe टाइमर तब तक शुरू नहीं होता है जब तक कि छवि को खींचा नहीं जाता है (जैसा कि मैंने ऊपर बताया है)।

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

संपादित करें: और स्पष्ट होने के लिए, यह केवल स्टार्टअप है जो उम्र लेता है - मेरा नियंत्रण क्लस्टर 3xRPi2 पर संचालित होता है बस ठीक है, एक बार जब मैं एप्साइवर intialDelaySeconds समयबाह्य (और अन्य स्थापित-केवल समयबाह के भीतर उपयोग किए गए) को बढ़ाता हूं। मुझे समझ में नहीं आता कि हम अभी भी इस बारे में बात क्यों कर रहे हैं: /

मेरे पास 1.9.3 पर ARM64 क्लस्टर है और सफलतापूर्वक 1.9.7 में अपडेट किया गया है लेकिन 1.9.7 से 1.10.2 तक अपग्रेड करने के लिए टाइमआउट की समस्या है।

मैंने एडिटिंग की कोशिश भी की थी और उसी परिणाम के साथ टाइमआउट को बढ़ाते हुए kubeadm को फिर से शुरू किया था (जैसे ये अंतिम परिणाम https://github.com/anguslees/kubernetes/commits/kubeadm-gusfork)।

$ sudo kubeadm upgrade apply  v1.10.2 --force
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade/version] You have chosen to change the cluster version to "v1.10.2"
[upgrade/versions] Cluster version: v1.9.7
[upgrade/versions] kubeadm version: v1.10.2-dirty
[upgrade/version] Found 1 potential version compatibility errors but skipping since the --force flag is set:

   - Specified version to upgrade to "v1.10.2" is higher than the kubeadm version "v1.10.2-dirty". Upgrade kubeadm first using the tool you used to install kubeadm
[upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler]
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.2"...
Static pod: kube-apiserver-kubemaster1 hash: ed7578d5bf9314188dca798386bcfb0e
Static pod: kube-controller-manager-kubemaster1 hash: e0c3f578f1c547dcf9996e1d3390c10c
Static pod: kube-scheduler-kubemaster1 hash: 52e767858f52ac4aba448b1a113884ee
[upgrade/etcd] Upgrading to TLS for etcd
Static pod: etcd-kubemaster1 hash: 413224efa82e36533ce93e30bd18e3a8
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/etcd.yaml"
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing etcd/server certificate and key.
[certificates] Using the existing etcd/peer certificate and key.
[certificates] Using the existing etcd/healthcheck-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests190581659/etcd.yaml"
[upgrade/staticpods] Not waiting for pod-hash change for component "etcd"
[upgrade/etcd] Waiting for etcd to become available
[util/etcd] Waiting 30s for initial delay
[util/etcd] Attempting to get etcd status 1/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 2/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 3/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 4/10
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148"
[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-apiserver.yaml"
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-scheduler.yaml"
[upgrade/staticpods] The etcd manifest will be restored if component "kube-apiserver" fails to upgrade
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing apiserver-etcd-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests190581659/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/apply] FATAL: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: [timed out waiting for the condition]

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

रास्पबेरीपी 3 अभी भी इस मुद्दे को दर्शाता है, यहां तक ​​कि पूर्व-खींची गई छवियों के साथ भी। API सर्वर को किसी ऐसी जगह पर पहुंचने में 2-3 मिनट लगते हैं जहां वह एक पेज की सेवा कर सकता है ...

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

@carlosp एक अपग्रेड के दौरान मैं क्या कर रहा हूँ क्यूबलेट को नीचे ले जाता है जबकि अपीज़र बूट हो रहा है। यह एक प्रकार का हैकी है, लेकिन यह तब तक स्वास्थ्य-जांच को रोकने से रोकता है जब तक कि माफी न हो जाए।

लेकिन ईमानदारी से kubeadm upgrade और ARM सिर्फ मेरे अनुभव में एक साथ काम नहीं करते हैं ...

@brendandburns यह 1.9 तक पूरी तरह से काम करता था। मैंने अपने 1.8 क्लस्टर को बिना हिचकी के साथ तैनात किया, फिर 1.9 से दो बार अपग्रेड किया। इस समस्या का कारण बनने के लिए 1.10 में क्या बदलाव आया होगा, इस पर कोई विचार नहीं किया गया है।

मैंने देखा कि टाइमआउट 1.11 से 5 मिनट में बदल गया (https://github.com/kubernetes/kubernetes/pull/64988/files#diff-2056df5f0c3a4828b3a9a2510a7533c7L4545)। क्या आपने 1.11 के साथ कोशिश की है?

मैं छुट्टियों से लौटने के बाद गोना इस हैक की कोशिश करता हूं। पारितोषिक के लिए धन्यवाद!

@brendandburns @carlosp
हां, कृपया यह पुष्टि करने के लिए 1.11 प्रयास करें कि टाइमआउट वृद्धि आपके लिए एक फिक्स है।

/ cc @ kubernetes / sig-क्लस्टर-जीवनचक्र-बग

अरे! मैं भी इस मुद्दे का सामना कर रहा हूं।
दिलचस्प बात यह है कि, मैं अपने रास्पबेरी 3 पर खरोंच से एक क्लस्टर मास्टर बनाने का प्रबंधन करता हूं, लेकिन मेरे 3+ पर लगातार विफल रहता है।
वैसे भी, वर्तमान में मैं जिस संस्करण का उपयोग कर रहा हूं (https://blog.hypriot.com/post/setup-kubernetes-raspberry-pi-cluster/ पर चरण-दर-चरण प्रलेखन के अनुसार)
kubeadm version: &version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:14:41Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/arm"}

दूसरों के साथ के रूप में, एपेसेवर कंटेनर अंततः उठता है, लेकिन इससे पहले कि कुबेदम बाहर नहीं निकलता है, मुझे लिंबो में छोड़ रहा है क्योंकि मैं वहां से मैन्युअल रूप से लेने के लिए बहुत अनुभवहीन हूं।

त्वरित अद्यतन: चल रहा है
watch -n 1.0 "sed -i 's/initialDelaySeconds: [0-9]\+/initialDelaySeconds: 180/' /etc/kubernetes/manifests/kube-apiserver.yaml"
एक अलग टर्मिनल में मेरे क्लस्टर को उठने की अनुमति दी।

@DJGummikuh
परीक्षण के लिए धन्यवाद 1.11।

दूसरों के साथ के रूप में, एपेसेवर कंटेनर अंततः उठता है, लेकिन इससे पहले कि कुबेदम बाहर नहीं निकलता है, मुझे लिंबो में छोड़ रहा है क्योंकि मैं वहां से मैन्युअल रूप से लेने के लिए बहुत अनुभवहीन हूं।

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

यह कहना मुश्किल है, मुझे लगता है कि लगभग 1 मिनट होगा, हालांकि मुझे नहीं पता कि इसे कैसे ठीक से मापना है।

इसके अतिरिक्त, अब जब मेरा मास्टर चालू है, तो मैं इसके साथ एक नोड जोड़ने में विफल रहता हूं जो एक और टाइमआउट मुद्दा लगता है।
पूर्व उड़ान चेक चल रहा है
: nf_conntrack_ipv4: {} ip_vs: {}]
आप निम्न तरीकों से इस समस्या को हल कर सकते हैं:

1. लापता कर्नेल मॉड्यूल को लोड करने के लिए 'modprobe -' चलाएं;
   
   
   
   1. अनुपलब्ध बिलिन कर्नेल आईपीवी समर्थन प्रदान करें
   
   

I0708 19: 02: 20.256325 8667 kernel_validator.go: 81] वैध कर्नेल संस्करण
I0708 19: 02: 20.256846 8667 kernel_validator.go: 96] कर्नेल कॉन्फ़िगरेशन को मान्य करना
[चेतावनी प्रणाली सत्यापन]: डॉक संस्करण सबसे हाल ही में मान्य संस्करण से अधिक है। डॉकर संस्करण: 18.03.1-ce। अधिकतम मान्य संस्करण: 17.03
[खोज] एपीआई सर्वर से जुड़ने की कोशिश "192.168.2.2:6443"
[खोज] " https://192.168.2.2 : 6443" से जानकारी के लिए अनुरोध करते हुए क्लस्टर-जानकारी खोज ग्राहक बनाया गया
[खोज] " https://192.168.2.2 : 6443" से पुनः सूचना मांगना पिन किए गए सार्वजनिक कुंजी के खिलाफ टीएलएस को मान्य करने के लिए
[खोज] क्लस्टर जानकारी हस्ताक्षर और सामग्री मान्य हैं और टोंस प्रमाणपत्र मान्य जड़ों के खिलाफ मान्य है, एपीआई सर्वर "192.168.2.2:6443" का उपयोग करेगा
[खोज] एपीआई सर्वर "192.168.2.2:6443" के साथ सफलतापूर्वक स्थापित कनेक्शन
[kubelet] क्यूब-सिस्टम नामस्थान में "kubelet-config-1.11" कॉन्फिगरेशन से क्यूबलेट के लिए कॉन्फ़िगरेशन डाउनलोड करना
[kubelet] "/var/lib/kubelet/config.yaml" फाइल करने के लिए क्यूबलेट कॉन्फ़िगरेशन लिखना
[kubelet] "/var/lib/kubelet/kubeadm-flags.env" फाइल करने के लिए झंडे के साथ क्यूबलेट पर्यावरण फ़ाइल लिखना
[preflight] क्यूबलेट सेवा को सक्रिय करना
[tlsbootstrap] TLS बूटस्ट्रैप प्रदर्शन करने के लिए क्यूबलेट की प्रतीक्षा कर रहा है ...
[क्यूबलेट-जांच] ऐसा लगता है कि क्यूबलेट चल नहीं रहा है या स्वस्थ नहीं है।
[क्यूबलेट-जांच] ऐसा लगता है कि क्यूबलेट चल नहीं रहा है या स्वस्थ नहीं है।
[क्यूबलेट-जांच] ऐसा लगता है कि क्यूबलेट चल नहीं रहा है या स्वस्थ नहीं है।
[क्यूबलेट-जांच] ऐसा लगता है कि क्यूबलेट चल नहीं रहा है या स्वस्थ नहीं है।
[क्यूबलेट-जांच] ऐसा लगता है कि क्यूबलेट चल नहीं रहा है या स्वस्थ नहीं है।
दुर्भाग्य से, एक त्रुटि हुई है:
हालत के इंतजार में समय समाप्त हो गया

इस त्रुटि के कारण संभव है:
- क्यूबलेट नहीं चल रहा है
- किसी तरह नोड के गलत तरीके से संचालन के कारण क्यूबलेट अस्वस्थ है (आवश्यक cgroups अक्षम)

यदि आप एक सिस्टम-संचालित प्रणाली पर हैं, तो आप निम्न कमांड के साथ त्रुटि का निवारण करने का प्रयास कर सकते हैं:
- 'व्यवस्थित स्थिति क्यूबलेट'
- 'जर्नलक्टल -xeu क्यूबलेट'
हालत के इंतजार में समय समाप्त हो गया

इस समय के दौरान, एक भी डॉकटर कंटेनर मेरे नोड पर नहीं दिखा।

[चेतावनी आवश्यक है

ऑफटॉपिक, हम यहां इस बारे में बात कर रहे हैं:
https://github.com/kubernetes/kubeadm/issues/975

इसके अतिरिक्त, अब जब मेरा मास्टर चालू है, तो मैं इसके साथ एक नोड जोड़ने में विफल रहता हूं जो एक और टाइमआउट मुद्दा लगता है।
[kubelet-check] HTTP कॉल 'कर्ल -sSL http: // localhost : 10248 / healthz' के बराबर त्रुटि के साथ विफल रही: http: // localhost : 10248 / healthz: डायल tcp [:: 1]: 10248: कनेक्ट करें : कनेक्शन नहीं हो सका।

क्यूबलेट शुरू नहीं हो सका। क्यूबलेट लॉग में बेहतर देखो।

- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'

जाँच की जाँच को विन्यास योग्य बनाया जाना चाहिए, फिर भी हमें शायद ऐसा करने के सबसे अच्छे तरीके के बारे में बात करनी चाहिए।

मुझे लगता है कि ये उपयोग किए गए मूल्य हैं, इसलिए यदि आप कुबेदम का निर्माण कर रहे हैं तो अपने आप से खेलने की कोशिश करें:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96
लेकिन मन है कि यह सभी नियंत्रण विमान घटकों पर मध्यांतर को बढ़ाएगा।

संपादित करें: मैं जाहिरा तौर पर Github में टिप्पणियों को ठीक से प्रारूपित करने के लिए बहुत बेवकूफ हूं :-(

Here are the log outputs of both systemctl status kubelet and journalctl -xeu kubelet. "No cloud provider specified is the only thing that springs to eye.

`root@djg-clusterpi3:/home/djgummikuh# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since Sun 2018-07-08 19:55:15 CEST; 2min 12s ago
     Docs: http://kubernetes.io/docs/
 Main PID: 9233 (kubelet)
   Memory: 14.4M
      CPU: 17.064s
   CGroup: /system.slice/kubelet.service
           └─9233 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-driver=cgroupfs --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --network-pl

Jul 08 19:55:15 djg-clusterpi3 systemd[1]: Started kubelet: The Kubernetes Node Agent.
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.665304    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.675950    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.676273    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.963686    9233 server.go:408] Version: v1.11.0
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964029    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964378    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.965040    9233 plugins.go:97] No cloud provider specified.






Jul 08 19:55:15 djg-clusterpi3 systemd[1]: Started kubelet: The Kubernetes Node Agent.
-- Subject: Unit kubelet.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit kubelet.service has finished starting up.
-- 
-- The start-up result is done.
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.665304    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.675950    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.676273    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.963686    9233 server.go:408] Version: v1.11.0
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964029    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964378    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.965040    9233 plugins.go:97] No cloud provider specified.`

कृपया, ध्यान रखें कि ये लॉग कोई त्रुटि नहीं दिखाते हैं।

हां, लेकिन मुझे विश्वास है कि इस मुद्दे का हिस्सा है। मुझे शुरू करने के लिए कहीं भी [ERROR] की एक भी निर्णायक रेखा नहीं मिल सकती है। यही कारण है कि मुझे बहुत निराशा होती है :-)

वैसे भी, उस गड़बड़ के प्रारूपण के लिए धन्यवाद :-D

तो एक अच्छा अगला कदम क्या होगा?

तो एक अच्छा अगला कदम क्या होगा?

जैसा कि पहले उल्लेख किया गया है:

जाँच की जाँच को विन्यास योग्य बनाया जाना चाहिए, फिर भी हमें शायद ऐसा करने के सबसे अच्छे तरीके के बारे में बात करनी चाहिए।

मुझे लगता है कि ये उपयोग किए गए मूल्य हैं, इसलिए यदि आप कुबेदम का निर्माण कर रहे हैं तो अपने आप से खेलने की कोशिश करें:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96
लेकिन मन है कि यह सभी नियंत्रण विमान घटकों पर मध्यांतर को बढ़ाएगा।

उफ़, मैं अपने आप से कुबेदाम का निर्माण नहीं करता, मैं इसे apt.kubernetes.io के माध्यम से खींच रहा हूं। मेरे पास ऐसा कुछ भी नहीं है जो दूर से मेरी किसी भी मशीन पर जाने के लिए बिल्ड पाइपलाइन से मिलता जुलता हो (इसके साथ अभी तक कोई छेड़छाड़ नहीं की गई है)। मुझे उम्मीद थी कि एक क्लस्टर में शामिल होने के दौरान संशोधित करने के लिए एक समान फ़ाइल होगी जैसे कि इसे बनाने के लिए थी, हालांकि ऐसा लगता है कि ये मान utils में हार्ड-कोड किए गए हैं: -

आप इस समाधान की कोशिश कर सकते हैं, लेकिन यह मुश्किल है:
https://github.com/kubernetes/kubeadm/issues/413#issuecomment -404016163

समस्या यह है कि इसके लिए कॉन्फ़िगरेशन परिवर्तन की आवश्यकता है और मुझे नहीं लगता कि इसे 1.11.X रिलीज़ में शामिल किया जा सकता है (लेकिन हम कोशिश कर सकते हैं)। इस पर भी पहले चर्चा होनी है।

यही मैंने पहले से ही टिप्पणी में किया था जहां मैंने आपको बताया था कि मास्टर ऊपर है (यह मेरी घड़ी-एन 1.0 कमांड कर रहा था)। अब क्या हो रहा है कि kubeadm जॉइन काम नहीं करता है, और जहाँ तक मैं देख सकता हूँ, kubeadm join मेरे लिए yaml फ़ाइलों को कहीं भी पैच करने के लिए नहीं रखता है: - / /

आप किसी अन्य समस्या का अनुभव कर सकते हैं। बताना कठिन है।

ये उपयोग किए गए मान हैं, इसलिए यदि आप कुबेदम का निर्माण कर रहे हैं तो अपने आप से खेलने की कोशिश करें:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96

इसलिए मैंने नोट किया है कि प्रायरिलडेलसेकंड टाइमआउट यहां एक साल बाद _still_ 15s है, और मुझे समझ में नहीं आता है कि इसे कुछ ऐसे क्यों नहीं बढ़ाया गया है जो वास्तव में वास्तविकता का प्रतिनिधित्व करता है। क्या यह बग रिपोर्ट किसी उद्देश्य की पूर्ति कर रही है? मैंने शुरू में एक पीआर का प्रस्ताव नहीं किया था कि मैं खुद इस नंबर को बदल दूं क्योंकि मुझे लगा कि किसी को पहले से ही kubeadm इनर सर्कल मिल सकता है और कुछ ही मिनटों में विलय हो सकता है, लेकिन मुझे ऐसा करने में खुशी हो रही है अगर "PR की कमी" है एकमात्र कारण हम आगे नहीं बढ़े हैं।

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

इसलिए मैं नोट करता हूं कि प्रिन्टडेलेसेकेंड्स टाइमआउट यहां अभी भी एक साल बाद 15s है, और मुझे समझ में नहीं आता है कि इसे उस चीज़ तक क्यों नहीं बढ़ाया गया है जो वास्तव में वास्तविकता का प्रतिनिधित्व करता है। क्या यह बग रिपोर्ट किसी उद्देश्य की पूर्ति कर रही है? मैंने शुरू में एक पीआर का प्रस्ताव नहीं किया था कि मैं खुद इस नंबर को बदल दूं क्योंकि मुझे लगा कि किसी को पहले से ही kubeadm इनर सर्कल मिल सकता है और कुछ ही मिनटों में विलय हो सकता है, लेकिन मुझे ऐसा करने में खुशी हो रही है अगर "PR की कमी" है एकमात्र कारण हम आगे नहीं बढ़े हैं।

मैं आपके सवालों का जवाब नहीं दे सकता क्योंकि पूरा मुद्दा मेरे लिए नया है, लेकिन हम इस सप्ताह इसके बारे में बात करने की कोशिश कर सकते हैं। कृपया ध्यान दें कि kubeadm के पीछे की टीम बड़े लक्ष्यों वाली एक छोटी टीम है और अक्सर इस तरह के एक निश्चित कार्य पर काम करने वाला कोई नहीं होता है।

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

हां, इस थ्रेड में पहले से ही विकल्पों पर चर्चा की गई है। यह सही विकल्प चुनने और कार्यान्वयन करने की बात है।

मुझे वास्तव में विश्वास है कि यह पूरी प्रक्रिया के लिए एक समय सीमा निर्धारित करने के विकल्प के साथ "नो टाइमआउट" को डिफ़ॉल्ट करने के लिए समझ में आता है (जैसा कि इस मुद्दे में पहले कहीं सुझाव दिया गया था)।

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

एक अंतरिम समाधान के रूप में, हालांकि यह वास्तव में kubeadm के लिए टाइमआउट सेटिंग्स को पढ़ने के लिए एक कॉन्फ़िगरेशन फ़ाइल से जुड़ना होगा, जैसे कि kubeadm init सामान ऐसा करता है कि हमारी हैकिंग इनफ़्लाइट टाइमआउट प्रतिस्थापन कार्यों के साथ होती है। यह एक हैक है, किसी भी अलग से मत सोचो - लेकिन एक भयानक हैक अभी भी बिना किसी समाधान के बेहतर है।

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

@anguslees @DJGummikuh से हाल ही में एसआईजी की बैठक में हमने इस बारे में बात की थी।

यह एक काँटेदार समस्या है, लेकिन यहाँ कुछ बेतरतीब नोट हैं।

टिप्पणियाँ:

• हमारे कुछ लोगों के पास बहुत अधिक अनुभव है और वे कह रहे हैं कि यह एक दौड़ की स्थिति की तरह बदबू आ रही है जो एपसेवर शुरू कर देता है। यह इतना लंबा नहीं होना चाहिए। यह एक ARM बनाम GOLANG चीज हो सकती है।
• मैंने एसआईजी एपीआई मशीनरी से पूछा है, लेकिन सुझाए गए जांच के मूल्यों पर कोई प्रतिक्रिया नहीं मिली है और यदि उन्हें यहां एक अलग प्रकार के मुद्दे पर संदेह है।
• हम सहमत हुए हैं कि एक कॉन्फिगर विकल्प या एनवायरनमेंट वैरिएबल या कमांड लाइन पैरामीटर
• टीम के किसी भी व्यक्ति ने धीमी मशीनों (जैसे धीमे VMs) पर कभी भी ऐसा कोई मुद्दा नहीं देखा है, जिसका अर्थ है कि यह आरपीआई संबंधित हो सकता है और पूरे तर्क कि यह "धीमी" हार्डवेयर के कारण अमान्य है।
• इस पर एक नज़र है: https://github.com/kubernetes/kubernetes/issues/64357 उपयोगकर्ता बिल्कुल भी जांच की जाँच नहीं कर रहा है। किसी भी विचार क्यों है?
• क्या किसी को https://www.scaleway.com/ जैसी किसी समस्या पर कोई समस्या दिखाई दी है, इस थ्रेड में सिद्धांत के अनुसार यह वहां भी होना चाहिए?
• एक निचली पंक्ति के रूप में, हमने चर्चा की है कि हार्डकोडिंग बड़े समयबाह्य / विलंब मान कुबेदम के लिए बहुत अधिक मायने नहीं रखेगा, इसलिए यदि कोई इसके लिए पीआर प्रस्तुत करना चाहता है, तो आगे बढ़ें। ( @anguslees )

इस पर एक नज़र है: kubernetes / kubernetes # 64357 उपयोगकर्ता बिल्कुल भी जांच की समस्या नहीं बता रहा है। किसी भी विचार क्यों है?

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

माफी में ARM64 पर संबंधित मुद्दा:
https://github.com/kubernetes/kubernetes/issues/64649

सप्ताहांत में मेरे (अभी भी असफल :-() पाई क्लस्टर के साथ कुछ और शोध किया।

जब से मुझे संदेह हुआ कि मैंने अपने 2 नोड्स में से एक को फिर से इंस्टॉल किया है, शायद OS को फिर से इंस्टॉल किए बिना एक Pi 2 से लेकर Pi 3+ तक अपडेट करना, उनके मुद्दों का कारण हो सकता है। यह मामला नहीं है, समस्या ब्रांड के नए ओएस के साथ समान है।
इसके अतिरिक्त, मैंने बढ़ते समय के साथ कुबेरनेट्स संकलित करने का प्रयास किया और उसी के साथ परीक्षण किया। साथ ही, इससे वास्तव में कोई परिणाम नहीं मिला।
मैं मास्टर को प्राप्त करने में सक्षम था (विन्यास फाइलों को पैच करने के लिए मेरी घड़ी के साथ) लेकिन दूसरी नोड के साथ क्लस्टर में शामिल होना कभी भी सफल नहीं होता है।

इस समस्या को कम करने के लिए कुछ अतिरिक्त उपयोगी लॉग आउटपुट होना वास्तव में साफ-सुथरा होगा। हालाँकि मुझे यह समझ में नहीं आया कि कुबेरनेट के घटक यह कैसे जानते हैं कि लाइनों को कहाँ जोड़ा जाए।

चुनौती के लिए कोई भी? ^ ^

यह वास्तव में kubeadm के बाहर एक समस्या है ...

एपीआई मशीनरी के लोगों ने इस मुद्दे पर टिप्पणियों के लिए मेरे अनुरोध को नहीं देखा, इसलिए जब तक कि इस टिकट के लिए लॉग इन नहीं किया जाता है, तब तक किसी को पहले से ही kubernetes/kubernetes रेपो में लॉग इन करना चाहिए और /sig api-machinery टैग करना चाहिए।

इस समस्या को कम करने के लिए कुछ अतिरिक्त उपयोगी लॉग आउटपुट होना वास्तव में साफ-सुथरा होगा। हालाँकि मुझे यह समझ में नहीं आया कि कुबेरनेट के घटक यह कैसे जानते हैं कि लाइनों को कहाँ जोड़ा जाए।

एक शुरुआत के रूप में सिस्टमड ड्रॉप-इन फ़ाइल में क्यूबलेट के लिए --v 4 सक्षम हो सकता है, जो उच्च वर्बोसिटी को सक्षम करने के लिए GLOG लकड़हारा को बताएगा।
इस के साथ kubeadm कॉन्फिगर से कंट्रोल प्लेन कंपोनेंट्स के लिए भी वही कर सकते हैं:
https://kubernetes.io/docs/setup/independent/control-plane-flags/

इससे मेरी रास्पबेरी पाई 3 क्लस्टर पर समस्या हल हो गई: https://github.com/kubernetes/kubernetes/pull/66264

@joejulian अच्छा मैं पैच करने में कामयाब रहा और अब मेरा क्लस्टर भी फायरिंग कर रहा है। अंत में, पीड़ा के हफ्तों के बाद! धन्यवाद :-)

@joejulian जाँच के लिए धन्यवाद!
एक संभावित फिक्स https://github.com/kubernetes/kubernetes/pull/66264 में पाया जा सकता है

अगली सूचना तक बंद करना।

/बंद करे

वहाँ kubeadm init फ़ाइल में ऐसी सेटिंग्स को पारित करने का एक तरीका है? शायद apiServerExtraArgs ? यह एक दर्द है कि उन्हें थपथपाने के लिए फाइलें देखनी पड़ती हैं, थोड़े मुश्किल से स्वचालित होते हैं।

वहां नहीं हैं। शायद यह जोड़ने के लिए एक अच्छी सुविधा होगी।

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

इसके अतिरिक्त, नियंत्रक सहित नियंत्रक सेवाओं को अधिक राम लगते हैं, अब, रास्पबेरी पाई की तुलना में नियंत्रण विमान की मेजबानी के लिए नोड्स की संख्या दोगुनी है, मैंने रॉक 64 में अपग्रेड किया है।

सज़ा का बहाना है, लेकिन मेरा नियंत्रण विमान कभी ठोस था।

मैं बस एक रास्पबेरी पाई 3+ पर स्थापित करने की कोशिश कर रहा हूं और यह पुष्टि कर सकता हूं कि स्थापित वास्तव में विफल हो जाता है। ऊपर सूचीबद्ध kube-apiserver.yaml पर 'वॉच' ट्रिक का उपयोग करने पर यह लगातार काम करने लगता है ... लेकिन केवल तभी जब मैं आरंभिकDelaySeconds को 360 में बदलता हूं। 180 का सुझाया गया मूल्य मेरी मशीनों पर मामूली लगता है।

बस जब चीजें बहुत आसान हो रही हैं, तो कुबेदम अब शिकायत कर रहा है कि डॉकर (18.09) का संस्करण असमर्थित है। 18.06 को एक त्वरित वापसी ने इस मुद्दे को तय किया।

kubeadm 1.13 में हम ClusterConfig-> ApiServer के तहत कॉन्फ़िगरेशन फ़्लैग जोड़ रहे हैं जो एपीआई सर्वर टाइमआउट को नियंत्रित कर सकता है।
https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1
timeoutForControlPlane

ClusterConfig-> ApiServer के तहत कॉन्फ़िगरेशन ध्वज जो एपीआई सर्वर टाइमआउट को नियंत्रित कर सकता है।

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

मुझे नहीं लगता कि मैंने इस मुद्दे पर चर्चा में कहीं भी एक प्रतिवाद को उठाया है। क्या एक कारण है कि हम _d't_ सिर्फ linyProbe को आरंभिक बढ़ाते हैं और कुछ अन्य समस्या के लिए आगे बढ़ते हैं?

एक तरफ: जहाँ तक मैं एक त्वरित पढ़ने से देख सकता हूँ, TimeoutForControlPlane भी अन्य गैर-विफलता के कारणों को ध्यान में नहीं रखता है, जो कि वृद्धि के लिए अन्य गैर-विफलता के कारण होता है, जैसे कई चित्र खींचते समय भीड़, या अतिरिक्त टाइमआउट + पीछे हटना लूप पुनरावृत्तियों जबकि सब कुछ प्रारंभिक इंस्टॉल-टाइम में परिवर्तित हो रहा है (टाइमआउट + रिट्री बार-बार k8s डिज़ाइन पैटर्न है ... और यह कभी-कभी एक लोड किए गए सिस्टम पर होता है, जो अपेक्षित है और बस ठीक है)। मुझे व्यक्तिगत रूप से ऐसा लगता है कि 4minutes दोनों ही अधीर इंटरैक्टिव उपयोगकर्ताओं को तेज विफलता की उम्मीद के लिए बहुत लंबा है, और एक लोड / धीमी / स्वचालित प्रणाली पर एक इंस्टॉलेशन प्रक्रिया के लिए बहुत कम है जो अपेक्षित सफलता के लिए लंबे समय तक इंतजार करने के लिए तैयार है। यह कैसे हुआ, क्या हम 5mins पर डिफॉल्ट कर सकते हैं? क्या हम SIGINT तक रिट्रीट कर सकते हैं? हम कॉलिंग वातावरण से विरासत में मिलने के बजाय आंतरिक रूप से एक कृत्रिम दीवार-घड़ी की समय सीमा क्यों लगा रहे हैं?

Afaics TimeoutForControlPlane केवल एक अनियंत्रित घातक आंतरिक समय सीमा को एक पैरामीटर के रूप में उजागर कर रहा है, जहां केवल इरादा UX पैरामीटर को बढ़ाने के लिए है जब तक कि समय सीमा कभी नहीं पहुंचती है। वैकल्पिक रूप से, हम सिर्फ _not_ उस मनमाने ढंग से घातक आंतरिक समय सीमा को लागू कर सकते हैं ...

यह एक उत्कृष्ट बिंदु है और मैं तहे दिल से सहमत हूं।

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

हां, कुबेदम से लेनन जांच को संशोधित करने की कोई योजना नहीं है, फिर भी।

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

अर्थात इस मूल्य को बढ़ाने वाला एक समझौता था:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L97
यह एक अच्छा फिक्स नहीं है और यह किसी अन्य बग के लिए वर्कअराउंड की तरह लगता है।

यह कैसे हुआ, क्या हम 5mins पर डिफॉल्ट कर सकते हैं?

टाइमआउट 4 मिनट होने से 30 मिनट पहले था, क्योंकि यह छवियों को 1.11 से पहले विचार में खींच लेता था।
यदि आपके पास 4 बनाम 5 मिनट पर एक राय है, तो विषय पर मजबूत बिंदुओं के साथ एक अच्छी तरह से रेखांकित पीआर 1.14 में बना सकता है।

इस rpi समस्या को "कुछ ऐसा नहीं होना चाहिए", जैसे "क्यूबलेट में एक दौड़ की स्थिति जैसा प्रतीत होता है", "क्यों यह केवल आरपीआई पर होता है और अन्य धीमे उपकरणों पर नहीं" के रूप में एक सिग-क्लस्टर-लाइफ़स्टाइल मीटिंग में योग्य था।

उन सभी कारणों के लिए एक और बग के रूप में कहीं और की तलाश जारी है, लेकिन उन कारणों में से कोई भी कारण नहीं हैं _ शुरुआती_दिल्ली के बादलों को बढ़ाने के लिए। क्या वास्तव में शुरुआती डिडेलसेकंड बढ़ने के लिए एक नकारात्मक पहलू है?

इसे किसी अन्य दिशा से प्राप्त करने के लिए, यदि हम जानते हैं कि हमारे पास kubernetes में कहीं और एक मुद्दा है जिसे kubeadm में इस्तेमाल किया जा सकता है - तो क्या यह kubeadm की भूमिका "शुद्धता पर" लाइन रखने और ज्ञात-टूटे परिणाम का उत्पादन करने के लिए है? यह लक्ष्य के साथ संघर्ष करने के लिए एक उपकरण है कि हम लोगों को वास्तव में वास्तविक तैनाती के लिए उपयोग करने की उम्मीद है लगता है। अब तक मैं टाइमआउट बढ़ाने के लिए (एक साल पहले, पैच के साथ, इसकी रिपोर्ट करने के बावजूद) पैच के बिना अपने क्लस्टर पर कुबेदम का उपयोग करने में असमर्थ रहा हूं, जो मुझे दुखी करता है।

(इस मुद्दे के इर्द-गिर्द अपनी कुंठा को अपने स्वर में लीक करने के लिए क्षमायाचना)

यदि आपकी राय 4 बनाम 5 मिनट पर है

आह। मैं kubeadm में _no_ टाइमआउट के लिए मामला बनाने की कोशिश कर रहा था, लेकिन मुझे अभी तक उस वाक्यांश का एक तरीका ढूंढना है जो उस प्रस्ताव को आश्वस्त करता है (इसे देखें और इस मुद्दे में अन्य असफल प्रयास, उदाहरण के लिए) :(

उन सभी कारणों के लिए एक और बग के रूप में अच्छी तरह से तलाश जारी है, लेकिन उन कारणों में से कोई भी शुरुआती डीलेसेकंड को बढ़ाने के लिए नहीं है। क्या वास्तव में शुरुआती डिडेलसेकंड बढ़ने के लिए एक नकारात्मक पहलू है?

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

इसे किसी अन्य दिशा से प्राप्त करने के लिए, यदि हम जानते हैं कि हमारे पास kubernetes में कहीं और एक मुद्दा है जिसे kubeadm में इस्तेमाल किया जा सकता है - तो क्या यह kubeadm की भूमिका "शुद्धता पर" लाइन रखने और ज्ञात-टूटे परिणाम का उत्पादन करने के लिए है? यह लक्ष्य के साथ संघर्ष करने के लिए एक उपकरण है कि हम लोगों को वास्तव में वास्तविक तैनाती के लिए उपयोग करने की उम्मीद है लगता है।

अंतिम उपयोगकर्ता का सामना करना kubeadm के लिए एक लक्ष्य है, यह सच है।
लेकिन फिर से यह केवल रपीस के लिए एक रिपोर्ट है और वास्तविक बग को सिग-एपी-मशीनरी (एपीआई सर्वर) और सिग-नोड (क्यूबलेट) में बढ़ाया जाना चाहिए और संभवतः कुबेदम के बाहर पुन: पेश किया जाना चाहिए।

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

आपको कुबेदम को पैच करने की ज़रूरत नहीं है, आप इसके बजाय प्रकट फ़ाइलों को पैच कर सकते हैं।
kubeadm 1.13 स्नातक इनिट चरणों के शीर्ष स्तर के आदेशों के लिए - जैसे kubeadm init phase [phase-name]
चरण ज्यादातर इसलिए होते हैं क्योंकि उपयोगकर्ता कस्टम नियंत्रण चाहते हैं कि नियंत्रण विमान नोड कैसे बनाया जाता है ..

यदि आप kubeadm init --help यह आपको दिखाएगा कि चरणों को किस क्रम में निष्पादित किया गया है।

इसलिए आप अपने kubeadm init कमांड को उचित चरणों में तोड़ सकते हैं, आप नियंत्रण विमान घटकों के लिए कस्टम मैनिफ़ेस्ट का उपयोग करते हैं और control-plane चरण को छोड़ते हैं। अब --skip-phases है।

आप पहले से ही 1.11 और 1.12 में कर सकते हैं, लेकिन यह सीधे आगे कम है।

क्योंकि यह उन प्रणालियों पर भी लागू होगा जो समस्या का समाधान नहीं करते हैं।

तो .. इसमें गलत क्या है? हम हर समय बग को ठीक करते हैं जो केवल कुछ सिस्टम पर ट्रिगर होते हैं। कहीं भी हमारे पास टाइमआउट्स हैं, हमें अपनी सबसे धीमी प्रणाली के लिए उन्हें ट्यून करने की आवश्यकता है, न कि हमारे वातावरण के कुछ सबसेट, नहीं?

इस पर एक और कोण यह है कि एक ऑप्स लड़के के रूप में, मैं ओवरलोड स्थितियों में कैस्केडिंग विफलताओं से घबराया हुआ हूं, विशेष रूप से स्वयं के साथ। Afaics, linyprobe समयबाह्य को केवल तभी ट्रिगर करना चाहिए जब चीजें स्पष्ट रूप से विफल हो गईं, न कि केवल तब जब यह किसी के "सामान्य" के विचार से विचलित हो। Afaics we _should_ में हमारे सबसे तेज हार्डवेयर पर भी एक बहुत ही आराम से लिनेप्रोबी कॉन्फ़िगर किया गया है। मेरी छोटी rpi अभी इस अधिभार विफलता को अधिक आसानी से प्रदर्शित कर रही है - लेकिन यह बड़े अधिभार / DoS परिदृश्‍य के अंतर्गत बड़े सर्वरों पर भी लागू होता है। एक छोटे से प्रारंभिकDelaySeconds होने के लिए कोई उल्टा नहीं है । kubeadm का डिफ़ॉल्ट linyprobe सभी प्लेटफार्मों पर अनावश्यक रूप से आक्रामक है।

मुझे खेद है कि मैं समान बिंदुओं को दोहराता रहता हूं, लेकिन शुरुआती शुरुआती के विस्तार के लिए व्यावहारिक और सैद्धांतिक कारण मजबूत हैं, और मैं इसे छोटा रखने के लिए विरोधी तर्क को नहीं समझ रहा हूं :(

इसके लिए एक kubeadm कॉन्फ़िगरेशन विकल्प जोड़ना इस बिंदु पर संभावना नहीं है।

मैं यह समझाने की कोशिश कर रहा हूं कि यह 1.13 में 3 कमांड के साथ पहले से ही संभव है:

sudo kubeadm reset -f
sudo kubeadm init phase control-plane all --config=testkubeadm.yaml
sudo sed -i 's/initialDelaySeconds: 15/initialDelaySeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml
sudo kubeadm init --skip-phases=control-plane --ignore-preflight-errors=all --config=testkubeadm.yaml

मुझे एक विकल्प नहीं चाहिए, मैं यह कहना चाहता हूं कि वर्तमान निश्चित मूल्य (15) को एक अलग निश्चित मूल्य में बदल दिया जाना चाहिए (360 को ऊपर सुझाव दिया गया था)।

.. लेकिन मैं इसे आगे नहीं खींचना चाहता। यह स्पष्ट है कि निर्णय वर्तमान मूल्य के साथ रहना है, इसलिए मैं पराजित वापस ले लूंगा। आपके धैर्य के लिए धन्यवाद :)

@ neolit123 कि संयोजन बहुत अच्छा लग रहा है - जितना मैंने प्रलेखित किया है उससे कहीं अधिक आसान है - नियंत्रण विमान सेट की प्रतीक्षा करना और फिर दूसरे टर्मिनल में जल्दी से दौड़ना। https://github.com/alexellis/k8s-on-raspbian/blob/master/GUIDE.md

मैं निर्देशों का परीक्षण करूंगा और गाइड को अपडेट करने के लिए देखूंगा।

@ neolit123 यह वही है जो मुझे RPi3 B + के ऊपर के कॉन्फिगर का उपयोग करके मिला है

[certs] apiserver serving cert is signed for DNS names [rnode-1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.0.110 192.168.0.26 192.168.0.26]
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xaa7204]

goroutine 1 [running]:
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.validateKubeConfig(0xfa93f2, 0xf, 0xfb3d32, 0x17, 0x4032210, 0x68f, 0x7bc)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:236 +0x120
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.createKubeConfigFileIfNotExists(0xfa93f2, 0xf, 0xfb3d32, 0x17, 0x4032210, 0x0, 0xf7978)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:257 +0x90
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.createKubeConfigFiles(0xfa93f2, 0xf, 0x3ec65a0, 0x3f71c60, 0x1, 0x1, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:120 +0xf4
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.CreateKubeConfigFile(0xfb3d32, 0x17, 0xfa93f2, 0xf, 0x3ec65a0, 0x1f7a701, 0xb9772c)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:93 +0xe8
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases.runKubeConfigFile.func1(0xf66a80, 0x4208280, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/kubeconfig.go:155 +0x168
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).Run.func1(0x3cc2d80, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:235 +0x160
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).visitAll(0x3ec9270, 0x3f71d68, 0x4208280, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:416 +0x5c
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).Run(0x3ec9270, 0x24, 0x416bdb4)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:208 +0xc8
k8s.io/kubernetes/cmd/kubeadm/app/cmd.NewCmdInit.func1(0x3e97b80, 0x3e900e0, 0x0, 0x3)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/init.go:141 +0xfc
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).execute(0x3e97b80, 0x3e3ff80, 0x3, 0x4, 0x3e97b80, 0x3e3ff80)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:760 +0x20c
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x3e96140, 0x3e97b80, 0x3e96780, 0x3d82100)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:846 +0x210
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).Execute(0x3e96140, 0x3c8c0c8, 0x116d958)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:794 +0x1c
k8s.io/kubernetes/cmd/kubeadm/app.Run(0x3c9c030, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/kubeadm.go:48 +0x1b0
main.main()
    _output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/kubeadm.go:29 +0x20

kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:36:44Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/arm"}

Kubeadm-config.yaml में - 192.168.0.26 एक LB है जो 192.168.0.110 की ओर इशारा करता है

apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: stable
apiServer:
  certSANs:
  - "192.168.0.26"
controlPlaneEndpoint: "192.168.0.26:6443"

मुझे बाहरी कॉन्फ़िगर / lb IP के बिना भी समान मिलता है।

एलेक्स

मैं लोगों को कुछ समय के लिए कुबेदम का उपयोग करने के लिए प्रेरित कर रहा हूं, यहां तक ​​कि स्कूल भी इसे अपने पीआई समूहों पर चलाना चाहते हैं। हालांकि मैं समझता हूं कि कोड आधार को जटिल नहीं करना है, मुझे लगता है कि इन छोटे उपकरणों पर चलने के लिए आपके उपयोगकर्ता आधार के लिए यह संभवतः एक अच्छी बात है। यह युवा लोगों को कुबेरनेट के टायर को चीप हार्डवेयर पर किक करने की अनुमति देता है जो अन्यथा नहीं हो सकता है। ऊपर का वर्कअराउंड, मान्य होने पर, इस उपयोग के मामले के लिए बहुत कठिन है।

एक समझौते के बारे में क्या? इसे कॉन्फ़िगर करने योग्य बनाने के बजाय, एक साधारण हेयुरिस्टिक जोड़ें जो कहता है, यदि x86_64 नहीं है, तो डिफ़ॉल्ट टाइमआउट उच्चतर सेट करें?

[kubeconfig] लेखन "admin.conf" kubeconfig फ़ाइल
[kubeconfig] "kublet.conf" kubeconfig फ़ाइल लिखना
घबराहट: रनटाइम त्रुटि: अमान्य मेमोरी एड्रेस या एनएल पॉइंटर डेरेफेरेंस
[संकेत SIGSEGV: विभाजन उल्लंघन कोड = 0x1 योजक = 0x8 पीसी = 0xaa7204]

विषम, admin.conf मशीन उत्पन्न होती है और इसमें एक Config current-context = current-context = current-context = current-context =

इस लाइन से घबराहट होती है:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go#L236

मैं ठीक उसी त्रुटि को देख रहा हूं जैसे: point_up: ऊपर के साथ:

modify_kube_apiserver_config(){
  sed -i 's/failureThreshold: [0-9]/failureThreshold: 15/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 120/g' /etc/kubernetes/manifests/kube-apiserver.yaml
}
kubeadm init phase control-plane all --config=$${KUBEADM_CONFIG_FILE} && \
modify_kube_apiserver_config && \
kubeadm init \
--skip-phases=control-plane \
--ignore-preflight-errors=all \
--config=$${KUBEADM_CONFIG_FILE} \
--v 4

निम्न स्क्रिप्ट kubeadm संस्करण 1.12, 1.13 ( अधिकांश समय) का उपयोग करके मेरे लिए समस्या का समाधान करती है

modify_kube_apiserver_config(){
  while [[ ! -e /etc/kubernetes/manifests/kube-apiserver.yaml ]]; do
    sleep 0.5s;
  done && \
  sed -i 's/failureThreshold: [0-9]/failureThreshold: 18/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 240/g' /etc/kubernetes/manifests/kube-apiserver.yaml
}

# ref https://github.com/kubernetes/kubeadm/issues/413 (initialDelaySeconds is too eager)
if [[ ${var.arch} == "arm" ]]; then modify_kube_apiserver_config & fi

kubeadm init \
  --config=$${KUBEADM_CONFIG_FILE} \
  --v ${var.kubeadm_verbosity}

मैं उसी स्थिति में था, @ neolit123 द्वारा सुझाए गए दृष्टिकोण के साथ एक ही त्रुटि हो रही
मैं @stephenmoloney द्वारा स्क्रिप्ट को चलाने में सक्षम नहीं था, मैं वास्तव में बैश स्क्रिप्टिंग से परिचित नहीं हूं, शायद मेरी गलती है।

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

import os
import time
import threading

filepath = '/etc/kubernetes/manifests/kube-apiserver.yaml'

def replace_defaults():
    print('Thread start looking for the file')
    while not os.path.isfile(filepath):
        time.sleep(1) #wait one second
    print('\033[94m -----------> FILE FOUND: replacing defaults \033[0m')
    os.system("""sed -i 's/failureThreshold: [0-9]/failureThreshold: 18/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")
    os.system("""sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")
    os.system("""sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 240/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")

t = threading.Thread(target=replace_defaults)
t.start()
os.system("kubeadm init")

इसे चलाने के लिए: sudo python however_you_name_the_file.py
मुझे समाधान, @stephenmoloney करने और @ neolit123 ओर इशारा करते हुए के लिए धन्यवाद!

नमस्ते! इस मुद्दे से बहुत मदद मिली

मुझे इस तरह से हल करने के लिए एक शानदार तरीका मिला

mkdir /tmp/kustom

cat > /tmp/kustom/kustomization.yaml <<EOF
patchesJson6902:
- target:
    version: v1
    kind: Pod
    name: kube-apiserver
    namespace: kube-system
  path: patch.yaml
EOF

cat > /tmp/kustom/patch.yaml <<EOF
- op: replace
  path: /spec/containers/0/livenessProbe/initialDelaySeconds
  value: 30
- op: replace
  path: /spec/containers/0/livenessProbe/timeoutSeconds
  value: 30
EOF

sudo kubeadm init --config config.yaml -k /tmp/kustom