/ cc @lukemarsden @luxas @mikedanese

अगर हम #43474 को पूरी तरह से वापस कर देते हैं, तो हम फिर से ऐसी स्थिति में आ जाते हैं जहां हम 0.2.0 सीएनआई प्लगइन्स को तोड़ देते हैं (देखें https://github.com/kubernetes/kubernetes/issues/43014)

क्या हमें https://github.com/kubernetes/kubernetes/pull/43284 जैसा कुछ करने पर विचार करना चाहिए

साथ ही /cc @thockin

/ cc @ Kubernetes / sig-network-bugs

संदर्भ: https://github.com/kubernetes/kubernetes/issues/43397#issuecomment -289978351

@jbeda क्या मुझे --loglevel=5 के साथ कुछ क्यूबलेट लॉग मिल सकते हैं?

@yujuhong - आप उल्लेख करते हैं कि आपको लगता है कि यह इरादे से काम कर रहा है। बावजूद इसके कुबेदम इसी व्यवहार पर निर्भर था। हमने #४३४७४ के साथ एक महत्वपूर्ण बदलाव पेश किया। हम 1.7 के लिए इसे ठीक करने के सही तरीके के बारे में बात कर सकते हैं, लेकिन अभी के लिए, हमें कुबेदम को फिर से काम करने की आवश्यकता है।

सुस्त चर्चा अभी चल रही है - https://kubernetes.slack.com/archives/C09QYUH5W/p1490803144368246

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

वर्तमान योजना जिसका हम परीक्षण करने जा रहे हैं वह है kubeadm अब मास्टर नोड के तैयार होने की प्रतीक्षा नहीं करना है बल्कि इसके बजाय इसे पंजीकृत करना है। यह काफी अच्छा होना चाहिए ताकि CNI डेमॉनसेट को CNI स्थापित करने के लिए शेड्यूल किया जा सके।

@kensimon इसका परीक्षण कर रहा है।

@jbeda हाँ, ऐसा लगता है कि डेमनसेट नियंत्रक अभी भी उन्हें मुख्य रूप से संलग्न करेगा क्योंकि यह पूरी तरह से नेटवर्क-इननेस से अनजान है। हमें वास्तव में इसे और अधिक सामान्य रूप से ठीक करना चाहिए। क्या क्यूब में तत्काल करने के लिए कुछ है या अभी के लिए यह सब कुबेदम में है?

मैं Ubuntu 16.04 पर Kubeadm के साथ Kubernetes स्थापित करने का प्रयास कर रहा हूं। क्या इसके लिए कोई त्वरित समाधान है?

@jbeda अगर आपके पास एक पैच संस्करण है तो इसका परीक्षण करने में खुशी होगी ..

मेरे पास kubeadm नोड की NotReady स्थिति से आगे निकल रहा है, लेकिन यह जो डमी परिनियोजन बनाता है वह काम नहीं कर रहा है क्योंकि node.alpha.kubernetes.io/notReady कलंक इसे चलने से रोकता है। सहिष्णुता जोड़ना मदद नहीं करता है, मुझे बिल्कुल यकीन नहीं है कि इस बिंदु पर कैसे आगे बढ़ना है। क्या कोई इस बात पर प्रकाश डाल सकता है कि notReady कलंक को सहन करने वाले पॉड को कैसे तैनात किया जाए?

मैं कुछ अन्य विकल्पों की खोज कर रहा हूं जैसे नोड को तैयार नहीं के रूप में चिह्नित नहीं करना, लेकिन यह स्पष्ट नहीं है कि हम यही करना चाहते हैं।

हमने क्यूबलेट कमांड लाइन से KUBELET_NETWORK_ARGS को हटाकर इसके आसपास काम किया। उसके बाद kubeadm init ने ठीक काम किया और हम canal cni प्लगइन स्थापित करने में सक्षम थे।

@sbezverk क्या आप कृपया वर्णन करेंगे कि यह कैसे करें?

@sbezverk (अच्छी खोज :)) के निष्कर्षों की पुष्टि कर सकते हैं, /etc/systemd/system/10-kubeadm.conf को समायोजित करने और KUBELET_NETWORK_ARGS को हटाने से यह सेंटोस पर चलेगा। बुनाई के साथ परीक्षण किया।

@overip आपको /etc/systemd/system/kubelet.service.d/10-kubeadm.conf संपादित करने की आवश्यकता है

ExecStart = / usr / bin / kubelet $ KUBELET_KUBECONFIG_ARGS $ KUBELET_SYSTEM_PODS_ARGS $ KUBELET_NETWORK_ARGS $ KUBELET_DNS_ARGS $ KUBELET_AUTHZ_ARGS $ KUBELET_EXTRA_ARGS

$ KUBELET_NETWORK_ARGS को हटा दें

और उसके बाद क्यूबलेट को पुनरारंभ करें उसके बाद bebeadm init काम करना चाहिए।

यह जो मैंने किया है

कुबेदम रीसेट

यहां से ENV प्रविष्टियां हटाएं:

/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

सिस्टम डी और क्यूब सेवाओं को पुनः लोड करें

systemctl डेमॉन-रीलोड
systemctl पुनरारंभ करें kubelet.service

फिर से चलाएँ init

कुबेदम इनिटो

सब ठीक है, और जब तक हम इस पर हैं

यदि आप इसे देखते हैं:
क्यूबलेट: त्रुटि: क्यूबलेट चलाने में विफल: क्यूबलेट बनाने में विफल: गलत कॉन्फ़िगरेशन: क्यूबलेट cgroup ड्राइवर: "cgroupfs" docker cgroup ड्राइवर से अलग है: "systemd"

आपको अपना /etc/systemd/system/kubelet.service.d/10-kubeadm.conf संपादित करना होगा और ध्वज --cgroup-driver="systemd" जोड़ना होगा

और ऊपर के रूप में करो

क्यूबैडम रीसेट
systemctl डेमॉन-रीलोड
systemctl पुनरारंभ करें kubelet.service
कुबेदम init.

मैं क्यूबलेट सीएलआई झंडे से --network-plugin=cni को हटाने में सावधानी बरतता हूं, इससे क्यूबलेट डिफ़ॉल्ट रूप से no_op प्लगइन का उपयोग करता है ... मुझे आश्चर्य होगा अगर इस मामले में कैलिको/वीव जैसे सामान्य प्लगइन भी काम करेंगे (लेकिन फिर फिर से मेरी समझ यह है कि ये प्लगइन्स नीचे कैसे काम करते हैं, यह थोड़ा सीमित है।)

@kensimon एचएम, मेरे सेटअप पर कोई समस्या नहीं देखी है, मैंने नहर सीएनआई प्लगइन तैनात किया है और यह ठीक काम करता है ..

@sbezverk क्या क्रॉस होस्ट नेटवर्किंग भी अच्छी तरह से काम कर रही है?

@resouer पुष्टि नहीं कर सकता, मेरे पास केवल ऑल-इन-वन के रूप में 1.6.0 है।

@resouer @sbezverk मैं सफलतापूर्वक एक मशीन से जुड़ गया।

 [root@deploy-01 x86_64]# kubectl get nodes
 NAME        STATUS    AGE       VERSION
 deploy-01   Ready     51m       v1.6.0
 master-01   Ready     4m        v1.6.0

``` [ रूट@ डिप्लॉय
नाम तैयार स्थिति फिर से शुरू होती है आयु
etcd-तैनाती-01 1/1 रनिंग 0 50मी
क्यूब-एपिसर्वर-तैनाती-01 1/1 रनिंग 0 51मी
क्यूब-नियंत्रक-प्रबंधक-तैनाती-01 1/1 रनिंग 0 50मी
क्यूब-डीएनएस-3913472980-6plgh 3/3 रनिंग 0 51मी
क्यूब-प्रॉक्सी-एमबीवीडीएच 1/1 रनिंग 0 4मी
क्यूब-प्रॉक्सी-आरएमपी36 1/1 रनिंग 0 51मी
क्यूब-शेड्यूलर-तैनाती-01 1/1 रनिंग 0 50मी
Kubernetes-डैशबोर्ड-2396447444-fm8cz 1/1 रनिंग 0 24m
वेट-नेट-3t487 2/2 रनिंग 0 44m
वेट-नेट-एचएचसीक्यूपी 2/2 रनिंग 0 4मी

```

वर्कअराउंड काम करता है लेकिन फलालैन नहीं जा सकता ...

@stevenbower सबसे खराब स्थिति, आप इस सेटिंग को वापस रख सकते हैं और क्यूबलेट को फिर से शुरू कर सकते हैं जब आप कुबेदम व्यवसाय के साथ कर रहे हैं ..

मुझे weave काम करने के साथ तीन नोड क्लस्टर मिला है। सुनिश्चित नहीं है कि यह इस हैक के साथ कितना स्थिर हो सकता है, लेकिन वैसे भी धन्यवाद! :स्माइली:

एक साइड नोड पर, मास्टर पास पर init के बाद, आप $KUBELET_NETWORK_ARGS को वापस रख सकते हैं। मैंने वास्तव में इसे उस मशीन पर नहीं हटाया, जिसमें मैं शामिल हुआ था, केवल cgroup-driver, अन्यथा kubelet और docker एक साथ काम नहीं करेंगे।

लेकिन आपको kubeadm रीसेट करने की आवश्यकता नहीं है, बस /etc/systemd/system/kubelet.service.d/10-kubeadm.conf बदलें और systemctl नृत्य करें:

systemctl डेमॉन-रीलोड
systemctl पुनरारंभ करें kubelet.service

आप में से उन लोगों के लिए जो KUBELET_NETWORK_ARGS को छोड़ रहे हैं और इसकी रिपोर्ट कर रहे हैं, यह आपके लिए कारगर है:

मेरे लिए, मेरे पास 2 क्लस्टर हैं: एक जहां मैंने https://github.com/kubernetes/kubernetes/pull/43824 से पैच लागू किया और कुबेदम को सामान्य रूप से प्रारंभ करने पर आगे बढ़ने दिया, और एक KUBELET_NETWORK_ARGS हटा दिया गया। KUBELET_NETWORK_ARGS हटाए गए क्लस्टर पर, पॉड्स के बीच कोई भी ट्रैफ़िक विफल हो जाता है।

KUBELET_NETWORK_ARGS निकाले गए क्लस्टर पर:

$ kubectl run nginx --image=nginx
deployment "nginx" created
$ kubectl expose deployment nginx --port 80
service "nginx" exposed
$ kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
If you don't see a command prompt, try pressing enter.
/ # wget nginx.default.svc.cluster.local
wget: bad address 'nginx.default.svc.cluster.local'

सामान्य KUBELET_NETWORK_ARGS वाले क्लस्टर पर लेकिन पैच किए गए क्यूबेडम के साथ:

$ kubectl run nginx --image=nginx          
deployment "nginx" created
$ kubectl expose deployment nginx --port 80
service "nginx" exposed
$ kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
If you don't see a command prompt, try pressing enter.
/ # wget nginx.default.svc.cluster.local
Connecting to nginx.default.svc.cluster.local (10.109.159.41:80)
index.html           100% |********************************************************************************************|   612   0:00:00 ETA

यदि आप उन लोगों में से हैं जिन्होंने KUBELET_NETWORK_ARGS को अक्षम कर दिया है, तो जांच लें कि उपरोक्त आपके लिए काम करता है या नहीं।

मेरा सुझाव है कि हम नोड तैयार और डमी परिनियोजन जांच दोनों को छोड़ दें
1.6 के लिए पूरी तरह से और उन्हें 1.7 के लिए सत्यापन चरण में ले जाएं।

29 मार्च, 2017 को सुबह 10:13 बजे, "डैन विलियम्स" नोटिफिकेशन @github.com ने लिखा:

@jbeda https://github.com/jbeda हाँ, डेमनसेट जैसा दिखता है
नियंत्रक अभी भी उन्हें मुख्य रूप से संलग्न करेगा क्योंकि यह पूरी तरह से अज्ञानी है
नेटवर्क-इननेस का। हमें वास्तव में इसे और अधिक सामान्य रूप से ठीक करना चाहिए। है
क्यूब में तुरंत कुछ करना है या अभी के लिए सब कुछ कुबेदम में है?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290158416 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABtFIUw8GIJVfHrecB3qpTLT8Q4AyLVjks5rqpFKgaJpZM4MtMRe
.

कोई और Ubuntu 16.04 चला रहा है? मैंने KUBELET_NETWORK_ARGS को systemd सेवा से हटा दिया है और systemd डेमॉन को पुनः लोड कर दिया है। मैं एक मास्टर नोड को चालू कर सकता हूं लेकिन एक नोड में शामिल नहीं हो सकता। यह त्रुटि के साथ विफल रहता है The requested resource is unavailable

KUBELET_NETWORK_ARGS हटा दिया गया है, पॉड्स के बीच कोई भी ट्रैफ़िक विफल हो जाता है।

मुझे आश्चर्य नहीं होगा क्योंकि KUBELET_NETWORK_ARGS क्यूबलेट को बताता है कि किस प्लगइन का उपयोग करना है, कॉन्फ़िगरेशन और बायनेरिज़ को कहाँ देखना है। आपको उनकी जरूरत है।

मैं 1.6 के लिए किए गए फिक्स के रूप में # 43835 (और 1.6 चेरी पिक # 43837) की अनुशंसा करता हूं। मैंने दोनों का परीक्षण किया और वे काम करते हैं। मैंने @jbeda और @luxas को उनके जागने पर समीक्षा करने के लिए सौंपा है।

वे दोनों पीआर उचित लगते हैं। लेकिन मुझे लगता है कि हमें इसके बजाय https://github.com/kubernetes/kubernetes/pull/43824 के साथ जाना चाहिए। हालांकि यह थोड़ा अधिक जटिल है, यह उस कोड पथ को संरक्षित करता है ताकि उपयोगकर्ता जो डेमोनसेट का उपयोग करने के बाहर सीएनआई को पूर्व-कॉन्फ़िगर करते हैं (मैं इसे https://github.com/jbeda/kubeadm-gce-tf में करता हूं हालांकि मैंने नहीं किया है इसे 1.6 में अपडेट किया गया) अभी भी नोड्स के तैयार होने की प्रतीक्षा करें।

बोनस के रूप में, यह कुबेरनेट्स के लिए @kensimon का पहला पीआर है और उन्होंने इस सामान का परीक्षण करने के लिए स्टॉप निकाला है। लेकिन, ईमानदार होने के लिए, वे दोनों काम करने योग्य हैं और मैं वास्तव में इसे ठीक होते देखना चाहता हूं। :)

क्षमा करें, मैं https://github.com/kubernetes/kubernetes/pull/43824 चूक गया

मैं भी खुश हूँ अगर वे दोनों भी काम करते हैं

@kensimon यह मेरे लिए काम करता है, जब मैं केवल अक्षम KUBELET_NETWORK_ARGS के दौरान kubadm init । आपके निर्देशों के लिए धन्यवाद, मैं इसे सत्यापित कर सका।

यह काम करने के लिए @webwurst की पुष्टि की है जब आप केवल अक्षम KUBELET_NETWORK_ARGS के दौरान kubadm init । हालांकि इसे लेने के लिए मुझे क्यूब-डीएनएस को पुनरारंभ करना पड़ा। @kensimon से चेक काम करता है, dns हल करता है।

हालांकि मैं मानता हूं कि यह एक भयानक हैक है, और ज्यादातर लोगों के लिए बहुत भयानक है, सुस्त चैनलों को देखते हुए।

@kensimon या @mikedanese के पैच द्वारा एक बेहतर समाधान प्रस्तुत किया गया है।

@coeki आपने क्यूब-डीएनएस को वास्तव में कैसे पुनः आरंभ किया। मैंने kubectl delete pod kube-dns-3913472980-l771x --namespace=kube-system की कोशिश की और अब क्यूब-डीएनएस लंबित kube-system kube-dns-3913472980-7jrwm 0/3 Pending 0 4m पर रहता है
यह बिल्कुल के रूप में वर्णित किया: हटाने KUBELET_NETWORK_ARGS , sudo systemctl daemon-reload && sudo systemctl restart kubelet.service , kubeadm init , जोड़ने KUBELET_NETWORK_ARGS , फिर sudo systemctl daemon-reload && sudo systemctl restart kubelet.service
लेकिन तब मेरा मालिक NotReady में रहता है। describe मुझे मिलता है

Conditions:
  Type          Status  LastHeartbeatTime           LastTransitionTime          Reason              Message
  ----          ------  -----------------           ------------------          ------              -------
...
KubeletNotReady         runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

जैसा कि ऊपर वर्णित है, मैंने क्यूब-डीएनएस पुनरारंभ करने का प्रयास किया, लेकिन कोई सफलता नहीं मिली। कोई विचार? मैं इस पर मर रहा हूं, असफल 1.6.0 इस मॉर्गिंग को अपग्रेड करने के बाद हमारे क्लस्टर को फिर से चलाने की कोशिश कर रहा हूं :(

@patte तो मैं सिर्फ delete pods kube-dns-3913472980-3ljfx -n kube-system और फिर क्यूब-डीएनएस फिर से आता हूं।

क्या आपने kubeadm init के बाद, KUBELET_NETWORK_ARGS , फिर से sudo systemctl daemon-reload && sudo systemctl restart kubelet.service बुनाई या कैलिको जैसे पॉड नेटवर्क स्थापित करें? इसे पहले जोड़ें, आपको इसे काम करने में सक्षम होना चाहिए।

मैंने सेंटोस 7 पर कोशिश की और परीक्षण किया और बस इसे उबंटू/ज़ेनियल पर किया, इसलिए काम करना चाहिए।

मैंने जो किया उसे संक्षिप्त करने के लिए:

KUBELET_NETWORK_ARGS निकालें
sudo systemctl daemon-reload && sudo systemctl restart kubelet.service

kubeadm init --token=$TOKEN --apiserver-advertise-address=$(your apiserver ip address)

KUBELET_NETWORK_ARGS फिर से जोड़ें
sudo systemctl daemon-reload && sudo systemctl restart kubelet.service

kubectl apply -f https://git.io/weave-kube-1.6

एक मशीन में शामिल हो गए, आमतौर पर 10.96.0.0 (क्लस्टर आईपी) में एक स्थिर मार्ग जोड़ना पड़ता है क्योंकि मैं योनि पर हूं।
$TOKEN के साथ प्रयोग करें, लेकिन यह चरण अतिरिक्त है।

फिर:

delete pods kube-dns-3913472980-3ljfx -n kube-system

इसके लिए प्रतीक्षा कीजिए

kubectl run nginx --image=nginx
kubectl expose deployment nginx --port 80
kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
/ # wget nginx.default.svc.cluster.local Connecting to nginx.default.svc.cluster.local (10.101.169.36:80) index.html 100% |***********************************************************************| 612 0:00:00 ETA

मेरे लिए काम करता है, हालांकि यह एक भयानक हैक है;)

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

सभी को प्रणाम,

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

गुरु, 30 मार्च, 2017 को सुबह 8:13 बजे, सर्गुई बेजवेर्खी < सूचनाएं @github.com

लिखा था:

मुझे वास्तव में आश्चर्य है कि कुबेरनेट्स विकास समुदाय ने नहीं किया है
आधिकारिक फिक्स के लिए कोई ईटीए प्रदान किया। मेरा मतलब है कि यह एक भयानक बग है जो
कोड परीक्षण के दौरान आसानी से पकड़ा जाना चाहिए। चूंकि यह नहीं है, अत
बहुत कम से कम, 1.6.1 को फिक्स के साथ धक्का दिया जाना चाहिए ताकि लोग करेंगे
उनके समूहों को हैक करना बंद करें और उत्पादक चीजें करना शुरू करें;)। क्या मैं
यहाँ गलत है?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290442315 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AFVgVEoKuUf28VazmUApsnyfGhuAhZIqks5rq8aLgaJpZM4MtMRe
.

क्यूबलेट (# 43474) में बदलाव के कारण क्यूबलेट सही ढंग से रिपोर्टिंग नेटवर्क शुरू कर देता है जो सीएनआई प्लगइन शुरू होने से पहले तैयार नहीं होता है। इसने कुछ ऑर्डर को तोड़ दिया, जिस पर हम निर्भर थे और कुबेदम मास्टर इनिशियलाइज़ेशन में गतिरोध का कारण बना। हम इसे पकड़ नहीं पाए क्योंकि kubeadm e2e परीक्षण कुछ दिनों के लिए टूट गए थे जिससे यह परिवर्तन हुआ।

वर्तमान प्रस्तावित सुधार #43824 और #43835 हैं।

ठीक है, मैं यही समझ गया था। नेटवर्क प्लगइन के बीच इंटरलॉक
आ रहा है और नोड की तैयारी अभी थोड़ी भयानक है।

गुरु, 30 मार्च, 2017 को सुबह 8:28 बजे, माइक डैनी नोटिफिकेशन @github.com
लिखा था:

क्यूबलेट में बदलाव (#43474
https://github.com/kubernetes/kubernetes/pull/43474 ) क्यूबलेट को
सही ढंग से रिपोर्टिंग नेटवर्क शुरू करें cni प्लगइन के पहले तैयार नहीं था
आरंभ किया गया। इसने कुछ आदेश को तोड़ दिया जिस पर हम निर्भर थे और कारण थे
कुबेदम मास्टर इनिशियलाइज़ेशन में गतिरोध। हमने इसे नहीं पकड़ा क्योंकि
kubeadm e2e परीक्षण इस परिवर्तन के कारण कुछ दिनों के लिए टूट गए थे।

वर्तमान प्रस्तावित सुधार हैं #43824
https://github.com/kubernetes/kubernetes/pull/43824 और #43835
https://github.com/kubernetes/kubernetes/pull/43835 ।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290447309 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AFVgVLzQLxeV6qp1Rw1fNALDDaf-Sktyks5rq8o2gaJpZM4MtMRe
.

मुझे अब भी #43835 पसंद है। यह एक आसान बदलाव है, मुझे नहीं लगता कि ई2ई जांच वहीं की जानी चाहिए जहां वे हैं, और #43824 के अभी भी काम नहीं करने की खबरें हैं। मैं आज इसे हल करने के लिए जोर देने जा रहा हूं।

+1 आज इसे हल करने के लिए क्योंकि वर्कअराउंड से संपार्श्विक से निपटने के लिए बहुत सारे प्रयास बर्बाद हो गए हैं।

मुझे विश्वास नहीं हो रहा है कि 1.6.0 रिलीज़ होने से पहले किसी ने वास्तव में kubeadm 1.6.0 की कोशिश नहीं की थी ....

और, क्यूबलेट १.५.६ + कुबेदम १.५.६ भी टूट गए हैं, /etc/systemd/system/kubelet.service.d/10-kubeadm.conf संदर्भ /etc/kubernetes/pki/ca.crt लेकिन kubeadm उत्पन्न नहीं करता है ca.crt, हालांकि ca.pem है।

वर्तमान में 1.6.0 और 1.5.6 k8s उपयुक्त रिपॉजिटरी में केवल बाएँ रिलीज़ हैं...

"बॉक्स से बाहर टूट गया", शब्द आज सीखा।

मुझे अब भी #43835 पसंद है। यह एक आसान बदलाव है, मुझे नहीं लगता कि ई2ई जांच वहीं की जानी चाहिए जहां वे हैं, और #43824 के अभी भी काम नहीं करने की खबरें हैं। मैं आज इसे हल करने के लिए जोर देने जा रहा हूं।

इस पर माइक से सहमत हैं। #43835 सरल परिवर्तन है, और सत्यापन (यदि आवश्यक हो) एक अलग चरण में किया जा सकता है।

@thockin हमें वास्तव में नेटवर्किंग के लिए बेहतर परिस्थितियों और स्थिति की आवश्यकता है, खासकर हो stNetwork: true के साथ। कुछ पॉड्स के लिए नोड्स तैयार हो सकते हैं, लेकिन अन्य के लिए नहीं।

हम नोडनेटवर्क अनुपलब्ध का उपयोग नहीं कर सकते, क्योंकि यह क्लाउड प्रदाताओं के लिए विशिष्ट है। हमें शायद एक और तरीका चाहिए, या अनुसूचक के लिए ho stNetwork:true pods को नोड्स पर Net workReady:false के साथ अनुमति देने के लिए, या

इस बात से सहमत। मैं समस्या में देरी कर रहा हूं क्योंकि मेरे पास कोई अच्छा जवाब नहीं था,
लेकिन हमें इसे 1.7 . में प्राप्त करने की आवश्यकता है

गुरु, 30 मार्च, 2017 को सुबह 10:02 बजे, डैन विलियम्स नोटिफिकेशन @github.com
लिखा था:

@thockin https://github.com/thockin हमें वास्तव में बारीक-बारीक की जरूरत है
नेटवर्किंग के लिए स्थितियां और स्थिति, विशेष रूप से हो stNetwork:true के साथ।
कुछ पॉड्स के लिए नोड्स तैयार हो सकते हैं, लेकिन अन्य के लिए नहीं।

हम नोडनेटवर्क अनुपलब्ध का उपयोग नहीं कर सकते, क्योंकि यह क्लाउड के लिए विशिष्ट है
प्रदाता। हमें शायद एक और, या अनुसूचक के लिए एक तरीका चाहिए
अनुमति दें stNetwork:true pods on node with Net
टेंट पहले से ही नोड्स के लिए काम करते हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290475480 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AFVgVAaO9c76_R8me9PDo96AQ1ZrplMxks5rq-A1gaJpZM4MtMRe
.

@thockin कोई पसंदीदा समाधान? हम या तो नोड की तैयारी को अवरुद्ध कर सकते हैं और पता लगा सकते हैं कि कौन IsNodeReady() का उपयोग करता है जैसे हम पहले ही कर चुके हैं, या हम एक और नोड स्थिति जोड़ सकते हैं और फिर इसके लिए कहीं और कोडबेस के कौन-कौन-से-कितने बिट्स को ठीक कर सकते हैं। या शायद कोई और विकल्प है।

हम नोडनेटवर्क अनुपलब्ध का उपयोग नहीं कर सकते, क्योंकि यह क्लाउड प्रदाताओं के लिए विशिष्ट है। हमें शायद एक और तरीका चाहिए, या अनुसूचक के लिए ho stNetwork:true pods को नोड्स पर Net workReady:false के साथ अनुमति देने के लिए, या

मुझे लगता है कि सभी पहले से ही नोड्स को पूरी तरह से खारिज करने के बजाय, शेड्यूलर को दाग और सहनशीलता का सम्मान करने के लिए तय किया जा सकता है।
किसी को हो stNetwork:true पॉड्स पर सहिष्णुता लागू करनी होगी। मैं नहीं जानता कि कौन है लेकिन यह शेड्यूलर नहीं होना चाहिए क्योंकि पॉड स्पेक को समझने के लिए शेड्यूलर को पढ़ाना बहुत ज्यादा लगता है।

/सीसी @davidopp @dchen1107

इसके अलावा, कोई भी जिसने मेरे या माइकल के पैच की कोशिश की है और आने वाले नियंत्रण विमान पर लटका हुआ है, ऐसा प्रतीत होता है कि master से कुबेदम बनाना काम नहीं करता है जब यह v1.6.0 क्लस्टर का प्रबंधन करता है , kubeadm अमान्य args के साथ kube-apiserver लॉन्च करने का प्रयास कर रहा है:

unknown flag: --proxy-client-cert-file

यदि आप एक v1.6.0 क्लस्टर के विरुद्ध मेरा या माइकल के परिवर्तनों का परीक्षण करना चाहते हैं, तो अभी के लिए मास्टर के शीर्ष पर निर्माण करने के बजाय उन्हें v1.6.0 के विरुद्ध चुनें।

@yujuhong अनुसूचक पहले से ही फली के लिए सहिष्णुता को स्वतः लागू करता है (देखें https://github.com/kubernetes/kubernetes/pull/41414), यह एक समान पर्याप्त उपयोग के मामले की तरह लगता है

मेरे पास सभी दागों और तत्परता की स्पष्ट तस्वीर नहीं है wrt
इस बिंदु पर नेटवर्क। डैन, क्या आपके पास लिखने के लिए आधा घंटा है
वर्तमान स्थिति, तो हम इसे अलग करना शुरू कर सकते हैं? मुझे लगता है कि आप इसे जानते हैं
श्रेष्ठ। मुझे ऐसा लगता है कि हमारे पास कई बारीक मुद्दे हैं जो हमारे पास हैं
अब तक कंबल से ढका हुआ।

गुरु, 30 मार्च, 2017 को सुबह 10:22 बजे, केन साइमन नोटिफिकेशन @github.com
लिखा था:

@yujuhong https://github.com/yujuhong पहले से ही अनुसूचक
पॉड्स पर सहनशीलता को स्वतः लागू करता है (देखें #41414
https://github.com/kubernetes/kubernetes/pull/41414 ), ऐसा लगता है a
समान पर्याप्त उपयोग मामला

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290481017 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AFVgVMas2IP5X5YA0V5626UlGbaS98jtks5rq-TCgaJpZM4MtMRe
.

@thockin मैं वह कर सकता हूं, मुझे इसे कहां रखना चाहिए?

कुछ संबंधित मुद्दे हैं, क्या हम उनमें से किसी एक को फिर से शीर्षक दे सकते हैं, पोस्ट a
वर्तमान स्थिति का सारांश और वहां से जाएं?

गुरु, 30 मार्च, 2017 को सुबह 10:50 बजे, डैन विलियम्स सूचनाएं @github.com
लिखा था:

@thockin https://github.com/thockin मैं वह कर सकता हूं, मुझे कहां रखना चाहिए
यह?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290489157 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AFVgVCXJYk9J0QmjTqQA6PPVuhzMHlLZks5rq-t-gaJpZM4MtMRe
.

क्या हमारे पास कभी भी लाइन है कि यह तय कब CentOS रिपॉजिटरी में पोर्ट किया जाएगा?

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

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

1.6 में आप एक अल्फा फीचर को सक्षम कर सकते हैं जो कोर कुबेरनेट्स (नोडकंट्रोलर) को NodeReady == "False" या NodeReady == "अज्ञात" होने पर NoExecute टेंट जोड़ने का कारण बनता है। यह नोड पर चल रहे पॉड्स को बेदखल कर देगा (यदि वे दाग को बर्दाश्त नहीं करते हैं) और नए पॉड्स को नोड पर शेड्यूल करने से रोकें (यदि वे दाग को बर्दाश्त नहीं करते हैं)।

दीर्घावधि योजना सभी "कैसे कोर कुबेरनेट्स नोड स्थितियों पर प्रतिक्रिया करती है, शेड्यूलिंग और बेदखली के संबंध में" तर्क को कलंक और सहनशीलता (जैसे # 42001) का उपयोग करने के लिए स्थानांतरित करना है। लेकिन हम अभी वहां नहीं हैं और कुछ समय के लिए नहीं रहेंगे। तो निकट अवधि के लिए पॉड के लिए नेटवर्क अनुपलब्ध या किसी अन्य नोड स्थिति को "सहन" करने का कोई तरीका नहीं है जिसे आप जोड़ने का निर्णय ले सकते हैं।

अगर मैं समझता हूं कि @davidopp ने सही कहा है, तो फ़ंक्शन NodeReady है, जो अब सही या गलत या अज्ञात लौटाता है, जो आवश्यक है उसके साथ एक सूची पर टिक करता है। यदि यह उन मूल्यों की सूची वापस कर सकता है जो मिले नहीं हैं, तो आप इसके खिलाफ परीक्षण कर सकते हैं।

कुबेदम के मामले में, यदि तब नेटवर्क अनुपलब्ध है, केवल एक ही है। कुबेदम सच लौट सकता है। यह उस स्थिति में है जब हम kubeadm init समय पर नेटवर्किंग/cni प्लगइन पास नहीं करना चाहते हैं।

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

यदि मैं गलत हूं तो मुझे सही करों ;)

इस धागे पर कूदना क्योंकि मैंने इस मुद्दे को मारा और यह परेशान है:

नेटवर्क की तत्परता एक कलंक क्यों नहीं बन सकती है जिसे क्यूबलेट नोड पर नेटवर्क की स्थिति के आधार पर जोड़ता और हटाता है?
इस तरह नोड उन सभी पॉड्स के लिए "रेडी" हो सकता है जो नेटवर्क रेडीनेस टेंट (पॉड नेटवर्क ऐप्स) को सहन करते हैं।

होस्ट नेटवर्क पॉड्स के लिए, एक प्रवेश नियंत्रक पॉड नेटवर्क रेडीनेस टेंट के लिए सहिष्णुता को इंजेक्ट कर सकता है।

मुझे लगता है कि डेविडॉप की टिप्पणी में दीर्घकालिक योजना के साथ संरेखित है।

मुझे लगता है कि डेविडॉप की टिप्पणी में दीर्घकालिक योजना के साथ संरेखित है।

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

एके। क्या v1.6 पैच रिलीज़ में दाग़ों पर स्विच न करने का कोई कारण है?

नोड स्थितियों के आधार पर स्वचालित रूप से कलंक जोड़ने के लिए कोड 1.6 में अल्फा में चला गया। यह भरोसे के लिए तैयार नहीं है। (और यह केवल वर्तमान में नोड तैयार स्थिति को संभालता है, नेटवर्क नहीं)।

इसलिए, अगर मैं सही ढंग से समझूं, तो अभी के लिए, चूंकि https://github.com/kubernetes/features/issues/166 नेटवर्क की उपलब्धता को सही ढंग से खराब करने में सक्षम होने में कुछ अधिक समय ले रहा है, हमें एक काम के साथ जाना होगा। अगर हम https://github.com/kubernetes/features/issues/166 के साथ इसे ठीक करने के लिए एक टिप्पणी के साथ #43835 जैसे कुबेदम के लिए एक फिक्स ASAP को आगे बढ़ा सकते हैं, तो बहुत सारे पीपीएल खुश होने वाले हैं।

@davidopp मुझे लगता है कि आप " इस पर भरोसा नहीं करना " कहना चाहते

हाँ धन्यवाद, वह एक टाइपो था, जिसे अभी ठीक किया गया है

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

एके। इस मामले में, एक एकल नोड स्थिति में इसके साथ जुड़े कई गुण होते हैं जिन्हें नोड नियंत्रक समझने में सक्षम नहीं हो सकता है।
@mikedanese मुझे लगता है कि kubeadm init के मौजूदा व्यवहार के परिणामस्वरूप एक कार्यशील नोड आकर्षक है। मुझे आशा है कि validation चरण जोड़ने की आवश्यकता मुख्य रूप से इस मुद्दे पर आधारित नहीं है।
@dcbw @thockin @yujuhong क्यूबलेट में नोड कॉन्फ़िगरेशन समस्याओं का प्रतिनिधित्व करने के लिए

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

क्या 1.5.6 स्थापित करने का कोई तरीका है जो उबंटू पर काम करना चाहिए? अगर वहाँ है तो कृपया बताएं कि यह कैसे करना है? धन्यवाद!

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

@davidopp हमें NetworkUnavailable बनाम NodeReady के बारे में सावधान रहने की आवश्यकता है। दो अलग-अलग स्थितियां हैं जिन्हें वास्तव में साफ किया जाना चाहिए:

नोडनेटवर्क अनुपलब्ध - यह क्लाउड मार्गों के लिए विशिष्ट है, और केवल क्लाउड रूट नियंत्रक ही इस स्थिति को साफ़ करते हैं जब नोड्स के बीच क्लाउड मार्ग स्थापित किए गए हैं। नेटवर्क प्लग इन जो ओवरले बनाते हैं या जो नोड्स के बीच L3 रूटिंग नहीं करते हैं वे इस स्थिति का उपयोग नहीं करना चाहते हैं या नहीं करते हैं। यह शर्त किसी नेटवर्क प्लग इन द्वारा नहीं जोड़ी गई है; इसे क्यूबलेट द्वारा विशेष रूप से तब जोड़ा जाता है जब GCE या AWS को क्लाउड प्रदाता के रूप में चुना जाता है। NodeReady को प्रभावित नहीं करता क्योंकि यह एक अलग शर्त है।

NodeReady - सीधे नेटवर्क प्लगइन्स (जैसे, CNI या kubenet या दूरस्थ रनटाइम जैसे dockerhim/CRI-O) से प्रभावित होता है।

विचार करने के लिए तीन अलग-अलग मुद्दे हैं:

1. क्लाउड रूट - यदि क्लाउड इंफ्रास्ट्रक्चर और नेटवर्क प्लगइन को क्लाउड रूट्स की आवश्यकता होती है, तो क्लाउड रूट्स की कमी (जैसे, NodeNetworkUnavailable=true) को शेड्यूलिंग होस्टनेटवर्क = फॉल्स पॉड्स को ब्लॉक करने की आवश्यकता होती है
2. नेटवर्क प्लगइन्स - यदि प्लगइन अभी तक तैयार नहीं है, तो उसे hostNetwork=false पॉड्स के शेड्यूलिंग को ब्लॉक करने की आवश्यकता है। यह नोडनेटवर्क अनुपलब्ध से अलग है क्योंकि प्लगइन का रूट नियंत्रक के साथ कोई सीधा संपर्क नहीं हो सकता है क्योंकि यह क्लाउड मार्गों पर निर्भर नहीं करता है। उदाहरण के लिए, यदि आपके पास कुछ और (क्लाउड रूट, फलालैन, आदि) नोड रूट सेट अप है, तो नोड पर स्थानीय रूप से क्यूबनेट का उपयोग किया जा सकता है।
3. hostNetwork=true पॉड्स को इन सभी शर्तों को अनदेखा करना चाहिए और शेड्यूल किया जाना चाहिए, लेकिन किसी भी अन्य लागू शर्तों (डिस्क स्थान, आदि) के अधीन होना चाहिए।

NodeReady हथौड़े से बहुत बड़ा है। मैं सोच रहा हूं कि हम शायद नेटवर्क प्लगइन तत्परता के लिए एक अतिरिक्त NetworkPluginReady शर्त चाहते हैं (क्लाउड रूट्स की तत्परता से अलग!)

मुझे एक और कामकाज मिला।

जबकि kubeadm प्रिंट करता रहता है '[apclient] पहला नोड पंजीकृत हो गया है, लेकिन अभी तक तैयार नहीं है', मैंने 'kube-flannel.yml' को तैनात किया है जो फ़्लैनेल्ड स्थापित करता है। और इसने कॉन्फ़िगरेशन फ़ाइलों को बदले बिना काम किया।

१) कुबेदम init --pod-network-cidr=10.244.0.0/16 &
2) cp /etc/kubernetes/admin.conf ~/.kube/config
3) kubectl apply -f kube-flannel-rbac.yml (kubeadm 1.6 में आवश्यक)
4) Kubectl लागू -f kube-flannel.yaml
https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml में kube-flannel.yaml का उपयोग

मैं मास्टर नोड को 'रेडी' बना सकता था। लेकिन, क्यूब-डीएनएस संदेश के साथ विफल रहा,

Error syncing pod, skipping: failed to "CreatePodSandbox" for "kube-dns-2759646324-nppx6_kube-system(bd585951-15cb-11e7-95c3-1c98ec12245c)" with CreatePodSandboxError: "CreatePodSandbox for pod \"kube-dns-2759646324-nppx6_kube-system(bd585951-15cb-11e7-95c3-1c98ec12245c)\" failed: rpc error: code = 2 desc = NetworkPlugin cni failed to set up pod \"kube-dns-2759646324-nppx6_kube-system\" network: \"cni0\" already has an IP address different from 10.244.0.1/24"

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

@dcbw मुझे इस मुद्दे में चर्चा की गई विशिष्ट समस्या के बारे में पर्याप्त जानकारी नहीं है कि आपको वास्तव में क्या करना है। मैं सिर्फ दागियों की वर्तमान स्थिति और वे यहां कैसे लागू हो सकते हैं, यह बताना चाहता था।

कृपया पैच किए गए डीबीएस का परीक्षण करें

kubernetes-xenial-unstable अब एक पैच बिल्ड 1.6.1-beta.0.5+d8a384c1c5e35d-00 जिसे @pipejakob और मैं आज परीक्षण कर रहे हैं। पॉड नेटवर्क बनने तक नोड तैयार नहीं रहते हैं (उदाहरण के लिए बुनाई/फलालैन कॉन्फ़िगरेशन लागू करके)। अनुरूपता परीक्षा उत्तीर्ण। पीटीएएल।

# cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial-unstable main
EOF

cc @luxas @jbeda

क्या सामान्य दिशा है कि दाग बहुत कुछ सब कुछ व्यक्त कर सकते हैं
स्थितियाँ हो सकती हैं, और इसलिए हर तरह से बेहतर हैं?

मैं सहमत हूं कि हमें अधिक बारीक संकेत की जरूरत है। हमें अभी भी सुलझाना है
क्यूबलेट, नेट ड्राइवर, क्लाउड कंट्रोलर और क्लाउड प्रदाता के बीच परस्पर क्रिया
hostNetwork=false पॉड अनलॉक करने के लिए, लेकिन hostNetwork=true नहीं होना चाहिए
अवरुद्ध।

गुरु, 30 मार्च, 2017 को शाम 7:24 बजे, डैन विलियम्स नोटिफिकेशन @github.com
लिखा था:

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

@davidopp https://github.com/davidopp हमें सावधान रहने की जरूरत है
नेटवर्क अनुपलब्ध बनाम नोडरेडी। दो अलग-अलग शर्तें हैं:
वास्तव में साफ किया जाना चाहिए:

नोडनेटवर्क अनुपलब्ध - यह क्लाउड मार्गों के लिए विशिष्ट है, और केवल क्लाउड
रूट कंट्रोलर इस स्थिति को तब साफ़ करते हैं जब नोड्स के बीच क्लाउड रूट होते हैं
स्थापित किया गया। नेटवर्क प्लग इन जो ओवरले बनाते हैं या जो L3 नहीं करते हैं
नोड्स के बीच रूटिंग इस स्थिति को नहीं चाहता या उपयोग नहीं करता है। यह स्थिति है
किसी भी नेटवर्क प्लगइन द्वारा नहीं जोड़ा गया; यह क्यूबलेट द्वारा विशेष रूप से तब जोड़ा जाता है जब
GCE या AWS को क्लाउड प्रदाता के रूप में चुना जाता है। NodeReady को प्रभावित नहीं करता है
यह एक अलग शर्त है।

NodeReady - सीधे नेटवर्क प्लग इन से प्रभावित होता है (जैसे, CNI या kubenet
या रिमोट रनटाइम जैसे डॉकशिम/सीआरआई-ओ)।

विचार करने के लिए तीन अलग-अलग मुद्दे हैं:

1. क्लाउड रूट - यदि क्लाउड इन्फ्रास्ट्रक्चर और नेटवर्क प्लगइन
   बादल मार्गों की आवश्यकता है, फिर बादल मार्गों की कमी (जैसे,
   NodeNetworkUnavailable=true) को शेड्यूलिंग को ब्लॉक करने की आवश्यकता है hostNetwork=false
   फली
2. नेटवर्क प्लगइन्स - यदि प्लगइन अभी तक तैयार नहीं है, तो इसकी आवश्यकता है
   होस्टनेटवर्क का ब्लॉक शेड्यूलिंग = झूठी पॉड्स
3. hostNetwork=true पॉड्स को इन सभी स्थितियों को अनदेखा करना चाहिए और होना चाहिए
   अनुसूचित, लेकिन किसी भी अन्य लागू शर्तों के अधीन (डिस्क स्थान, आदि)

NodeReady हथौड़े से बहुत बड़ा है। मैं सोच रहा हूँ कि हम शायद एक चाहते हैं
अतिरिक्त NetworkPluginनेटवर्क प्लगइन तत्परता के लिए तैयार शर्त
(बादल मार्गों की तत्परता से अलग!) और फिर हमें उसे गिराना होगा
देखभाल करने वाले स्थानों के माध्यम से :(

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290597988 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AFVgVGIn0CpVkcHd2SVaoRsp2RJNEgXFks5rrGPqgaJpZM4MtMRe
.

क्यूबलेट KUBELET_NETWORK_ARGS कॉन्फिगरेशन लाइन को हटाकर अस्थायी सुधार की कोशिश करने वाले किसी भी व्यक्ति के लिए, @ jc1arke ने एक आसान वर्कअराउंड पाया - नए मास्टर के लिए दो सत्र हैं और पहले नोड के तैयार होने की प्रतीक्षा करते हुए, दूसरे में नोड-नेटवर्क कॉन्फिगरेशन लागू करें। सत्र:
Kubeadmin init चलाने के बाद पहला सत्र:

...
[apiclient] Created API client, waiting for the control plane to become ready
[apiclient] All control plane components are healthy after 24.820861 seconds
[apiclient] Waiting for at least one node to register and become ready
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
...

दूसरा सत्र (कैलिको का उपयोग करके। आपकी पसंद निश्चित रूप से भिन्न हो सकती है):

root@kube-test-master-tantk:~# kubectl apply -f http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/kubeadm/calico.yaml
configmap "calico-config" created
daemonset "calico-etcd" created
service "calico-etcd" created
daemonset "calico-node" created
deployment "calico-policy-controller" created
job "configure-calico" created
root@kube-test-master-tantk:~#

पहले सत्र में वापस:

...
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node is ready after 118.912515 seconds
[apiclient] Test deployment succeeded
[token] Using token: <to.ken>
[apiconfig] Created RBAC rules
...

क्या सामान्य दिशा है कि दाग बहुत कुछ सब कुछ व्यक्त कर सकते हैं
स्थितियाँ हो सकती हैं, और इसलिए हर तरह से बेहतर हैं?

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

बस @mikedanese और @pipejakob से debs का परीक्षण किया, ये ठीक काम कर रहे हैं।

उबंटू/ज़ेनियल पर परीक्षण किया गया:

root<strong i="9">@kube1</strong>:/home/ubuntu# kubeadm version
kubeadm version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean", BuildDate:"2017-03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

बस @mikedanese और @pipejakob से डेब्स का परीक्षण किया, यह अभी भी स्थिर है
[apiclient] Created API client, waiting for the control plane to become ready

मैंने करीब पांच मिनट इंतजार किया, लेकिन कुछ भी नहीं बदला।
और कल दोहराता रहा
[apiclient] First node has registered, but is not ready yet

टीटीआई को लगता है कि समस्या अभी भी कोई समाधान नहीं है?

उबंटू 16.04 पर परीक्षण किया गया:
kubeadm संस्करण: version.Info {मेजर: "1", माइनर: "6+", GitVersion: "v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit: "d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"2017 BuildDate:"Clean", -03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

@ myqq0000 क्या आप अपने द्वारा उपयोग

kubeadm version

@coeki ओह, मैं इसे भूल गया। मैंने अभी संपादित किया है और अपनी पिछली टिप्पणी में संस्करण पोस्ट किया है। :)

@mikedanese क्या आपके पास

बस 1.6.1-beta.0.5+d8a384c1c5e35d-00 की कोशिश की ( 1.6.1-beta.0.5+48c6a53cf4ff7d-00 https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290616036 में उल्लिखित एक मौजूद नहीं है)।

यह काम तो ठीक करता है।
असंबंधित: ध्यान दें कि यदि आप बुनाई का उपयोग कर रहे हैं तो आपको https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml 'डिफ़ॉल्ट' https:/ के बजाय लागू करना होगा।

@mausch क्या आप मुझे बता सकते हैं कि इन

@srinat999 https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290616036

@ मिकेडनीज पैचेड डेब्स मेरे लिए काम करते हैं। इस पर काम करने वाले सभी के लिए धन्यवाद! :मुस्कुराओ:

root@kube-test0:~# kubeadm version
kubeadm version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean", BuildDate:"2017-03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

@mausch धन्यवाद। वे मेरे लिए भी बुनाई नेटवर्क प्रदाता के साथ काम करते हैं।

सेंटोस के लिए भी वही फिक्स बनाने का कोई मौका? हमारा गेटिंग सिस्टम ज्यादातर कुबेरनेट्स क्लस्टर बेस के लिए सेंटो का उपयोग करता है। अगर मेरे पास सेंटोस संस्करण है तो मैं लगभग गारंटी दे सकता हूं। परीक्षण के रूप में एक दिन में कुबेदम के 100 रन।

@ मिकेडनीज पैचेड डेब्स मेरे लिए आंशिक रूप से काम कर रहे हैं। kubeadm सूचित कर रहा है कि क्लस्टर तैयार है, लेकिन नोड स्वयं नहीं है।

पॉड नेटवर्क लागू होने पर @squall0gd नोड्स तैयार हो जाने चाहिए, जैसे kubectl apply -f https://git.io/weave-kube-1.6

मेरे परीक्षण-वातावरण में (आवारा में, सेंटोस/7 मशीनों पर आधारित), कुबेदम बस लटका हुआ है। स्ट्रेस का उपयोग करके मैं इसे मास्टर पर क्यूबलेट सर्वर से कनेक्ट करने का प्रयास कर रहा हूं, और FUTEX_WAIT, epoll_wait रीट्री लूप कर रहा हूं। लेकिन इसमें से एक भी लाइन का आउटपुट नहीं आ रहा है।

क्यूबलेट प्रारंभ करने में विफल रहता है, जो कारण प्रतीत होता है।
(लेकिन मैं कुबलेट के शुरू होने में विफल होने के कारण नहीं देख सकता ..)

क्या यह इस मुद्दे की समस्या है?

मुझे http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 रेपो से बायनेरिज़ मिलते हैं।
मैं https://storage.googleapis.com/kubernetes-release/release/v1.6.0/bin/linux/amd64/ से बायनेरिज़ को अपडेट करने का भी प्रयास करता हूं।

==> मुझे परीक्षण के लिए कुबेदम का पैच संस्करण कहां मिल सकता है? <==

नोट: मुझे इस अंक में https://github.com/kensimon/aws-quickstart/commit/9ae07f8d9de29c6cbca4624a61e78ab4fe69ebc4 पर संदर्भित kubeadm का एक (दावा किया गया) पैच संस्करण मिला (पैच किया गया संस्करण यह है: https://heptio-aws-quickstart- test.s3.amazonaws.com/heptio/kubernetes/ken-test/kubeadm), लेकिन यह मेरे लिए काम नहीं करता है। व्यवहार अभी भी वही है (कोई आउटपुट नहीं) ...

@squall0gd क्या आप हमें वही संदेश दिखा सकते हैं जो आप देख रहे हैं? आप जो वर्णन करते हैं उसके आधार पर, मुझे आश्चर्य है कि क्या आपने वास्तव में नया .debs उठाया था या पुराने कैश्ड संस्करणों का उपयोग कर रहे थे।

@thockin @davidopp टिम के सुझाव के अनुसार, मैं एक मौजूदा मुद्दे की कमान https://github में कॉपी

यहां मेरे लिए unstable रेपो के साथ काम कर रहा है (केवल मास्टर का परीक्षण किया गया है):

"sudo apt-get update && sudo apt-get install -y apt-transport-https",
"echo 'deb http://apt.kubernetes.io/ kubernetes-xenial-unstable main' | sudo tee /etc/apt/sources.list.d/kubernetes.list",
"curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -",
"sudo apt-get update",
"sudo apt-get install -y docker.io",
"sudo apt-get install -y kubelet kubeadm kubectl kubernetes-cni",
"sudo service kubelet stop",
"sudo service kubelet start",
"sudo kubeadm init",
"sudo cp /etc/kubernetes/admin.conf $HOME/",
"sudo chown $(id -u):$(id -g) $HOME/admin.conf",
"export KUBECONFIG=$HOME/admin.conf",
"kubectl taint nodes --all dedicated-",
"kubectl apply -f https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml",

यह एक बिंदु पर error: taint "dedicated:" not found थूकता है, लेकिन ऐसा लगता है कि यह परवाह किए बिना जारी है।

क्या हम इन परीक्षणों को 1.6 शाखा पर नहीं चलाते हैं?

@davidopp नोड स्थितियों का उद्देश्य मनुष्यों के लिए अतिरिक्त जानकारी प्रदान करना है, यह समझने के लिए कि क्या हो रहा है, जैसे कारण, संदेश और संक्रमण समय।

kubeadm ऐसा नहीं लगता है कि यह रिलीज शाखा पर परीक्षण किया गया है:
https://k8s-testgrid.appspot.com/release-1.6-all

@ bgrant0607 जाहिरा तौर पर kubeadm e2e परीक्षण लगभग एक सप्ताह के लिए अक्षम/गैर-कार्यात्मक थे, जो 1.6 रिलीज, IIRC तक था।

नोड स्थितियों का उद्देश्य मनुष्यों के लिए अतिरिक्त जानकारी प्रदान करना है, यह समझने के लिए कि क्या हो रहा है, जैसे कारण, संदेश और संक्रमण समय।

@ bgrant0607 क्या वे मुख्य रूप से मानव जानकारी के लिए अभिप्रेत हैं, या यह सिर्फ एक सुखद दुष्प्रभाव है? यदि मुख्य रूप से मनुष्यों के लिए है, तो क्या उनका उपयोग शेड्यूलिंग निर्णयों के लिए किया जाना चाहिए जैसे वे वर्तमान में हैं या क्या हमें इससे दूर जाना चाहिए?

@dcbw टैंट्स का इरादा अनिर्धारितता और व्यवधान का GUT बनना है। अंत में, अनुसूचक को शर्तों को अनदेखा करना चाहिए।

https://github.com/kubernetes/kubernetes/pull/18263#issuecomment -169220144
https://github.com/kubernetes/kubernetes/issues/29178

ध्यान दें कि यदि हम नोड्स में एक कलंक जोड़ने जा रहे हैं, तो हमें विचार करने की आवश्यकता है

ए) पिछड़ा संगतता, मास्टर दाग के साथ: https://github.com/kubernetes/kubernetes/pull/43537

बी) संस्करण तिरछा। क्लस्टर को 1.6 में अपग्रेड करते समय, क्यूबलेट मिश्रित रिलीज़ के होंगे, और कुछ 1.4 जितने पुराने हो सकते हैं।

तो संक्षेप में या जैसा कि मैंने इसे पार्स किया है:

@dcbw . पर आधारित

nodeNetworkUnavailable एक क्लाउड प्रदाता चीज़ है, जो kubeadm atm से बंधी नहीं है, हम इसमें भाग ले सकते हैं।

लेकिन NodeReady, जो लूप का मूल कारण है, को और अधिक बारीक करने की आवश्यकता है। यह वही है जो @davidopp एक कलंक बनना चाहता है, एक सूची के आधार पर, जो जांच / जीवंतता, CNI तैयार और आदि के संबंध में बक्से को बंद कर रहा है।

ठीक है, हालांकि आप बहस कर सकते हैं, लेबल क्यों नहीं?

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

मुझे पता है, मैं वास्तव में समस्या का सामना नहीं कर रहा था, और इसके चारों ओर हैक पोस्ट कर रहा था :)

लेकिन वैसे भी, हमें बुनियादी बातों पर किसी अन्य स्थान पर चर्चा करनी चाहिए, सुनिश्चित करें कि एक ईटीए फिक्स यहां रखा गया है, और आगे बढ़ें।

तेज़ नहीं, लेकिन अच्छी तरह से :)

PS हाँ @ bgrant0607 हमें इसका और परीक्षण करना चाहिए था
PS2 अगर मैं इसे गलत देखता हूं, तो आप मुझे दोष दे सकते हैं;)

@coeki मैं आरपीएम/डेब रेपो में एन -1 संस्करणों को रखने के लिए एक अनुरोध भी

@kfox1111 गेटिंग भी एक समस्या है....हमें उस पर एक बेहतर रणनीति की जरूरत है :)

पुरानी रिलीज़ को बिल्कुल भी क्यों हटाएं? यह आसानी से लोगों के स्वचालन को तोड़ सकता है और बार-बार होने वाले इंस्टॉल को रोक सकता है।

नोड स्थितियों का उद्देश्य मनुष्यों के लिए अतिरिक्त जानकारी प्रदान करना है, यह समझने के लिए कि क्या हो रहा है, जैसे कारण, संदेश और संक्रमण समय।

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

लंबे समय में (जैसे v2 API लॉन्ग-रन) यह कल्पना योग्य है कि हम कलंक में कारण और संदेश जोड़ सकते हैं और फिर नोड स्थितियों से छुटकारा पा सकते हैं, लेकिन मैंने वास्तव में इसके बारे में नहीं सोचा है और निश्चित रूप से औपचारिक रूप से ऐसा करने का प्रस्ताव नहीं कर रहा हूं। (हमारे पास पहले से ही एक दिशा में संक्रमण समय के बराबर है, अर्थात् TimeAdded।)

@coeki नहीं, मैं जिस बारे में बात कर रहा था उसका

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

@ kfox1111 , गेटिंग यही करता है, जो अच्छा लगता है उसके साथ न जाएं, और पुराने अच्छे भरोसेमंद तरीके से फेंक दें, अब क्या हुआ।

@davidopp मैं इस बात से सहमत हूं कि लेबल और

वैसे भी, आप मुझे एक चर्चा में फुसलाते हैं, हम वास्तव में इस मुद्दे में नहीं हैं, यही मेरी बात थी।

मैं फिर से पूछना चाहता हूं: अगर मैं "kubeadm init" को बिना किसी आउटपुट के वहां लटका हुआ देखता हूं (क्यूबलेट सर्वर से कनेक्ट करने का प्रयास कर रहा हूं, जो शुरू करने में विफल रहा है), क्या मैं इस मुद्दे से पीड़ित हूं? और अगर यह मामला है, तो क्या #43835 मेरे लिए ठीक है?

अब मुझे कहां मिल सकता है:

• kubeadm / kubectl / kubelet . के या तो पुराने (पूर्व 1.6.0) संस्करण
• या कुबेदम का एक पैच किया हुआ संस्करण (#43835 या जो भी अन्य फिक्स सहित)?

धन्यवाद!

(नोट: ऊपर उल्लिखित प्रतिबद्धता में संदर्भित कुबेदम का पैच संस्करण मेरे लिए काम नहीं करता है ...)

@obnoxxx रिलीज

$ gsutil ls gs://kubernetes-release-dev/ci/v1.6.1-beta.0.12+018a96913f57f9

https://storage.googleapis.com/kubernetes-release-dev/ci/v1.6.1-beta.0.12+018a96913f57f9/bin/linux/amd64/kubeadm

@ मिकेडनीज धन्यवाद! कोशिश कर रहे हैं...

यदि आप ओएस पैकेज को स्थापित किए बिना कुबेदम चलाते हैं, तो आपको इसकी आवश्यकता होगी

$ cat <<EOF > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true"
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true"
Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin"
Environment="KUBELET_DNS_ARGS=--cluster-dns=10.96.0.10 --cluster-domain=cluster.local"
Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt"
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_EXTRA_ARGS
EOF
$ systemctl daemon-reload
$ systemctl restart kubelet

https://github.com/kubernetes/release/blob/master/debian/xenial/kubeadm/channel/stable/etc/systemd/system/kubelet.service.d/10-kubeadm.conf से

@ मिकेडनीज धन्यवाद। मैं ओएस पैकेज (क्यूब रेपो से) स्थापित कर रहा हूं और फिर आरपीएमएस से बायनेरिज़ पर वेब यूआरएल से बायनेरिज़ स्थापित कर रहा हूं ...

हालांकि 1.6.1-बीटा.0.12 संस्करण ने मेरे लिए काम नहीं किया:
kubeadm init अभी भी बिना किसी आउटपुट के हैंग हो जाता है। (क्यूबलेट से जुड़ने की कोशिश कर रहा है)

सेंटो होने पर भी सिस्टमड ड्राइवर को न भूलें।

सिस्टम ड्राइवर?

https://github.com/kubernetes/release/issues/306

भगवान, धन्यवाद, यह बेहतर है! :-)

@pipejakob मेरे पास अभी इस लॉग तक पहुंच नहीं है, लेकिन मैंने kubeadm संस्करण की जांच की है और यह वही संस्करण था जैसा @webwurst को मिला है। इसके अलावा मैं संभव देख लिया है kubeadm के साथ संस्करणों apt-cache policy kubeadm । और केवल एक प्रविष्टि थी - कुबेरनेट्स-ज़ेनियल-अस्थिर से।
@mikedanese मैंने पोस्ट करने से पहले फलालैन के साथ प्रयास किया है;)
संपादित करें: मैंने पूरे मंच का पुनर्निर्माण किया है और kubadm ठीक काम कर रहा है: +1:

दोस्तों फिक्स के लिए यथास्थिति क्या है? क्या यह जल्द ही किसी भी समय स्थिर भंडार में जाने वाला है?

@mikedanese पैच किए गए debs वही कर रहे हैं "नेटवर्क प्लगइन तैयार नहीं है" चीज।

क्या कोई मुझे बता सकता है कि आरएचईएल (आरपीएम) के लिए कुबेदम का पैच संस्करण कैसे बनाया जाए?

@mikedanese पैच किए गए debs के साथ init सफलता की रिपोर्ट करता है, लेकिन "नेटवर्क प्लगइन तैयार नहीं है: cni config uninitialized" संदेश बना रहता है।

मास्टर नोड NotReady ।

weave-net (weaveworks/weave-kube:1.9.4 - https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml) 1/2 CrashLoopBackOff :

FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "weave"

kube-dns पॉड 0/3 Pending ।

@ChipmunkV आपको उपयोगकर्ता स्थान में चलाने के लिए शायद क्यूब-प्रॉक्सी को कॉन्फ़िगर करने की आवश्यकता है। यह 1.5 में भी एक मुद्दा रहा है।

command:
  - /usr/local/bin/kube-proxy
  - --kubeconfig=/var/lib/kube-proxy/kubeconfig.conf
  # add this line:
  - --proxy-mode=userspace

इसके लायक क्या है, kubernetes-xenial-unstable मेरे लिए अच्छा काम कर रहा है।

@pstadler , चैट में @errordeveloper को धन्यवाद, जिन्होंने बताया कि मेरे पास ओवरलैपिंग नेटवर्क हैं, मैंने बुनाई में IPALLOC_RANGE को फिर से कॉन्फ़िगर किया है।

धन्यवाद @thenayr। मैं कुबेरनेट्स मास्टर को ला सकता था, लेकिन कुबेदम जॉइन का उपयोग करके एक कार्यकर्ता को भी इससे जोड़ सकता था। जल्द ही और अपडेट पोस्ट करेंगे

@mikedanese मुझे यह पता लगाने में हमेशा के लिए लग गया कि किस संस्करण का उपयोग करना है, जब तक कि मैं यहां सभी टिप्पणियां नहीं पढ़ता। हमें वास्तव में किसी दिए गए संस्करण के लिए बायनेरिज़ ढूंढना बहुत आसान बनाने की आवश्यकता है। मैंने ci-cross/latest.txt बिंदुओं (अर्थात् v1.7.0-alpha.0.1982+70684584beeb0c ) का उपयोग करने का प्रयास किया है, और यह नया kube-apiserver ध्वज (अर्थात् --proxy-client-key-file d8be13fee85075abfc087632b3dbc586a10897ad में) पेश करने के लिए होता है, जो gcr.io/google_containers/kube-apiserver-amd64 में हाल के किसी भी टैग के साथ काम नहीं करता है ...

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

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

पिछली रिलीज़ 1.5.6 मेरे लिए CentOs 7 पर काम कर रही थी, लेकिन अब मैं वापस रोल भी नहीं कर सकता क्योंकि http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 में kubeadm का एकमात्र संस्करण टूटा हुआ 1.6 है। 0. कुबेदम 1.5.6 आरपीएम कैसे प्राप्त करें इस पर कोई सुझाव?

वाकई, यह अफ़सोस की बात है। ऐसा लगता है कि पुराने संस्करण पूरी तरह से हटा दिए गए हैं। :-(

मेरे परिणाम ये सेंटोस 7 पर हैं:

• मैं Kubectl के बारे में कुछ किए बिना, एक पैच किए गए, नवीनतम kubeadm के साथ भी, मुझे कोई भी परिणाम देने के लिए kubadm init प्राप्त करने में सक्षम नहीं हूं।
• मैं @coeki के निर्देशों के साथ kubectl प्रारंभ करने में सक्षम हूं , और फिर kubeadm भी पास हो गया। लेकिन उसके बाद, मेरे लिए कुछ भी काम नहीं करता है। कुबेक्टल कहते हैं

The connection to the server localhost:8080 was refused - did you specify the right host or port?

कोई संकेत क्या हो रहा है?

@obnoxxx डिफ़ॉल्ट रूप से apiserver 8080 पर नहीं सुनता है, यह सुरक्षित 6443 पोर्ट पर सुनता है, आप netstat -tunlp से जांच सकते हैं।
आपको admin.conf को /etc/kubernetes से $HOME/.kube/config . पर कॉपी करना होगा
सुनिश्चित करें कि आपने अपने $HOME/.kube/ में फ़ाइल पर अनुमतियाँ बदल दी हैं, उसके बाद आपका kubectl एपिसर्वर से ठीक से संपर्क करने में सक्षम होना चाहिए। एचटीएच। सर्गुई

@apsinha क्या आप इस सूत्र से अवगत हैं? कुछ उत्पाद लोगों का अनुसरण करना अच्छा हो सकता है, क्योंकि मुझे लगता है कि भविष्य के लिए कुछ महत्वपूर्ण रास्ते होंगे।

मेरे सर के ऊपर से चला गया:

• 1.6.0 कभी भी स्वचालित परीक्षण से नहीं गुजरा: https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290809481
• पुराने संस्करणों के लिए बायनेरिज़/पैकेज हटा दिए गए थे, ताकि लोग सुरक्षित रूप से वापस नहीं आ सकें; किसी भी इंस्टॉलेशन ऑटोमेशन को तोड़ दिया जो मान रहा था कि वे उपलब्ध रहेंगे: https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290861903
• इस तथ्य की कोई सार्वजनिक घोषणा नहीं (जो मैंने देखी है) कि यह टूटा हुआ है
• फिक्स के बारे में कोई समयरेखा नहीं दी गई है (मैं एक डेवलपर हूं, इसलिए मुझे पता है कि "इसे कब ठीक किया जाएगा?" पूछा जा रहा है, लेकिन फिर भी, लोग यह पूछेंगे, इसलिए कम से कम अनुमानित समय अवधि की पेशकश करना अच्छा है)
• बातचीत में शामिल होने वाले उपयोगकर्ता चीजों की स्थिति, वर्कअराउंड और फिक्स शेड्यूल के बारे में भ्रमित हैं
• योगदानकर्ताओं के बीच बहुत सारी तकनीकी चर्चाएं, जिनमें से कई दीर्घकालिक रणनीति के बारे में हैं, एक ही धागे में संयुक्त हैं क्योंकि उपयोगकर्ता यह पता लगाने की कोशिश कर रहे हैं कि क्या हो रहा है और तत्काल समस्या से कैसे निपटें

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

मैंने कुबेरनेट्स/रिलीज.आरपीएम का उपयोग करके कुबेदम-1.5.6 का निर्माण केवल (मेरी निराशा के लिए) खोजने के लिए किया था

# rpm -Uvh kubectl-1.5.6-0.x86_64.rpm kubeadm-1.5.6-0.x86_64.rpm 
error: Failed dependencies:
        kubectl >= 1.6.0 is needed by kubeadm-1.5.6-0.x86_64
        kubelet >= 1.6.0 is needed by kubeadm-1.5.6-0.x86_64

@bostone आपको यहां .spec को समायोजित करने की आवश्यकता

@sbezverk संकेत के लिए धन्यवाद! अब बेहतर है...

यह उत्सुक है:

• मुझे याद नहीं है कि पिछली रिलीज़ में मेरे लिए admin.conf की प्रतिलिपि बनाना आवश्यक था।
• मैंने पहले kubectl -s localhost:6443 साथ प्रयास किया लेकिन वह पर्याप्त नहीं था।

वैसे भी, अब मैं जारी रख सकता हूँ। एक बार फिर धन्यवाद

v1.6.1 जारी होने की प्रक्रिया में है। ईओडी द्वारा किया जाएगा।

कुछ नोट:

1. पुराने पैकेजों को हटाए जाने की समस्या को यहां ट्रैक किया गया था: https://github.com/kubernetes/release/issues/234। कुबेदम के कुछ निराला संस्करण और इन चीजों को वर्णानुक्रम में कैसे क्रमबद्ध किया जाता है, जाहिर तौर पर कुबेदम के 1.5.x संस्करण को रेपो में रखना संभव नहीं था। ( @bostone आपकी समस्या का भी वहां संदर्भ दिया गया है)
2. kubeadm e2e परीक्षण पीआर पर यहां ट्रैक किया जा रहा है: https://github.com/kubernetes/kubeadm/issues/190
3. जहां तक ​​सार्वजनिक घोषणा का सवाल है - मैंने ट्विटर पर पोस्ट किया लेकिन वह शायद ही आधिकारिक हो। यह स्पष्ट नहीं है कि इस तरह के महत्वपूर्ण मुद्दों के लिए सही चैनल कौन से हैं।

पीएम में लाने के लिए ये सभी अच्छे मुद्दे हैं। @pipejakob ने उस पोस्टमार्टम को एक साथ खींचने के लिए स्वेच्छा से स्वेच्छा से काम किया है।

@obnoxxx admin.conf को कॉपी/

@mikedanese जो बहुत अच्छा लगता है, धन्यवाद!
सिर्फ मैं डमी के लिए - इस मुद्दे के संबंध में इस रिलीज 1.6.1 का क्या असर होगा?
क्या क्यूबलेट /etc/systemd/system/kubelet.service.d/10-kubeadm.conf ( @coeki के वर्कअराउंड) में बदलाव के बिना शुरू होगा या इसमें #43835 (जिसका मेरे लिए कोई प्रभाव नहीं पड़ा) का फिक्स होगा?

@jbeda स्पष्टीकरण के लिए धन्यवाद!

@jbeda मुझे लगता है कि भ्रम आधिकारिक कुबदम इंस्टॉलेशन डॉक सेटिंग YUM रेपो से http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 पर आता है। उस रेपो में केवल kubeadm-1.6.0 . है

और फिर से मेरी निराशा के लिए 1.5.6 आरपीएम का निर्माण और स्थापना एक ही सटीक समस्या के साथ समाप्त हुई। kubeadm init चल रहा है एक ही पंक्ति पर लटक रहा है:

# kubeadm init
Running pre-flight checks
<master/tokens> generated token: "5076be.38581a71134596d0"
<master/pki> generated Certificate Authority key and certificate:
Issuer: CN=kubernetes | Subject: CN=kubernetes | CA: true
Not before: 2017-04-03 21:28:18 +0000 UTC Not After: 2027-04-01 21:28:18 +0000 UTC
Public: /etc/kubernetes/pki/ca-pub.pem
Private: /etc/kubernetes/pki/ca-key.pem
Cert: /etc/kubernetes/pki/ca.pem
<master/pki> generated API Server key and certificate:
Issuer: CN=kubernetes | Subject: CN=kube-apiserver | CA: false
Not before: 2017-04-03 21:28:18 +0000 UTC Not After: 2018-04-03 21:28:18 +0000 UTC
Alternate Names: [10.25.47.21 10.96.0.1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local]
Public: /etc/kubernetes/pki/apiserver-pub.pem
Private: /etc/kubernetes/pki/apiserver-key.pem
Cert: /etc/kubernetes/pki/apiserver.pem
<master/pki> generated Service Account Signing keys:
Public: /etc/kubernetes/pki/sa-pub.pem
Private: /etc/kubernetes/pki/sa-key.pem
<master/pki> created keys and certificates in "/etc/kubernetes/pki"
<util/kubeconfig> created "/etc/kubernetes/kubelet.conf"
<util/kubeconfig> created "/etc/kubernetes/admin.conf"
<master/apiclient> created API client configuration
<master/apiclient> created API client, waiting for the control plane to become ready

मुझे लगता है कि मैं 1.6.1 रिलीज होने का इंतजार करूंगा और उम्मीद करता हूं...

1.6.1 बाहर है।

@mikedanese क्या आपने इस बग को बंद करने से पहले कुबेदम का परीक्षण किया था? अभी मैं 10 मिनट के लिए [apiclient] Created API client, waiting for the control plane to become ready को देख रहा हूं। CentOS 7 पर एकदम नए 1.6.1 इंस्टॉलेशन के साथ

@bostone आप इस मुद्दे को मार रहे होंगे: #43805

/etc/systemd/system/kubelet.service.d/10-kubeadm.conf संपादित करने और --cgroup-driver=systemd जोड़ने का प्रयास करें

systemctl daemon-reload; systemctl restart kubelet चलाना याद रखें

@gtirloni हमारे सुझाव के साथ मैं kubeadm init के अंत तक पहुँच गया, हालाँकि कुबेक्टल को चलाने का कोई भी प्रयास यह त्रुटि उत्पन्न करता है: The connection to the server localhost:8080 was refused - did you specify the right host or port? मुझे यकीन नहीं है कि कहाँ और कैसे परिवर्तन होता है या सही पोर्ट क्या है इस बिंदु?

सुनिश्चित नहीं है कि यह संबंधित है लेकिन systemctl status kubelet चलाते समय मैं यहां देखता हूं:
``` systemctl स्थिति क्यूबलेट -l
kubelet.service - kubelet: Kubernetes Node Agent
लोडेड: लोडेड (/etc/systemd/system/kubelet.service; सक्षम; विक्रेता प्रीसेट: अक्षम)
ड्रॉप-इन: /etc/systemd/system/kubelet.service.d
10-kubeadm.conf
सक्रिय: सोम 2017-04-03 17:31:07 पीडीटी के बाद से सक्रिय (चल रहा है); ११मिनट पहले
दस्तावेज़: http://kubernetes.io/docs/
मुख्य पीआईडी: 10382 (क्यूबलेट)
सीग्रुप: /system.slice/kubelet.service
10382 /usr/bin/kubelet --kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true --pod-manifest-path=/etc/kubernetes/manifests --allow-विशेषाधिकार प्राप्त=सत्य - -network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --cluster-dns=10.96.0.10 --cluster-domain =cluster.local --authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt --cgroup-driver=systemd
10436 जर्नलक्टल-के-एफ

अप्रैल 03 17:41:56 sdl02269 क्यूबलेट [10382]: W0403 17:41: 56.645299 10382 cni.go:157] cni config को अपडेट करने में असमर्थ: /etc/cni/net.d में कोई नेटवर्क नहीं मिला
अप्रैल 03 17:41:56 sdl02269 क्यूबलेट [10382]: E0403 17:41: 56.645407 10382 kubelet.go:2067] कंटेनर रनटाइम नेटवर्क तैयार नहीं है: NetworkReady=गलत कारण: NetworkPluginNotReady संदेश: docker : नेटवर्क प्लगइन तैयार नहीं है: cni config अप्रारंभीकृत```

हाँ हमने परीक्षण किया। e2e परीक्षण जारी शाखा पर गुजर रहे हैं। आप अन्य मुद्दों को मार रहे होंगे।

@bostone शायद आप kubeadm init बाद इन चरणों को याद कर रहे हैं?

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

आपको यहां वर्णित चरण 3 का भी पालन करना होगा। ऐसा लगता है कि आपको प्राप्त होने वाली सीएनआई कॉन्फ़िगरेशन त्रुटि से संबंधित है।

इसके अलावा [एप्लिकेंट] निर्मित एपीआई क्लाइंट को घूरते हुए, पहले से ही उबंटू १६.०४ के साथ १० मिनट के लिए कंट्रोल प्लेन के तैयार होने की प्रतीक्षा कर रहा है और १.६.१ की एक नई स्थापना कर रहा है।

@pingthings मैं स्लैक कुबेरनेट्स और kubeadm चैनल से जुड़ने की सलाह दूंगा। हम आपको वहां डिबग करने में मदद कर सकते हैं।

मैंने अपने कुबेरनेट्स क्लस्टर को सेंटोस-रिलीज़-7-3.1611.el7.centos.x86_64 पर निम्नलिखित चरणों का पालन करके सफलतापूर्वक सेटअप किया है (मुझे लगता है कि डॉकर पहले से ही स्थापित है):

1) (/etc/yum.repo.d/kubernetes.repo से) baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64-unstable
=> नवीनतम कुबेरनेट्स के लिए अस्थिर भंडार का उपयोग करने के लिए 1.6.1
2) यम इंस्टाल-वाई क्यूबलेट कुबेदम कुबेक्टल कुबेरनेट्स-सीएनआई
3) (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) अंतिम पंक्ति के अंत में "--cgroup-driver=systemd" जोड़ें।
=> ऐसा इसलिए है क्योंकि डॉकर cgroup-driver के लिए systemd का उपयोग करता है जबकि kubelet cgroup-driver के लिए cgroupfs का उपयोग करता है।
4) systemctl क्यूबलेट सक्षम करें && systemctl स्टार्ट क्यूबलेट
5) कुबेदम इनिट --पॉड-नेटवर्क-सीडीआर 10.244.0.0/16
=> यदि आप --api-advertise-addresses जोड़ते थे, तो आपको इसके बजाय --apiserver-advertise-address का उपयोग करना होगा।
6) cp /etc/kubernetes/admin.conf $HOME/
sudo chown $(id -u):$(id -g) $HOME/admin.conf
निर्यात KUBECONFIG=$HOME/admin.conf
=> इस चरण के बिना, आपको kubectl get के साथ त्रुटि मिल सकती है
=> मैंने इसे 1.5.2 . के साथ नहीं किया
7) Kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml
=> 1.6.0 एक भूमिका-आधारित अभिगम नियंत्रण का परिचय देता है ताकि आपको एक फलालैन डेमोंसेट बनाने से पहले एक ClusterRole और एक ClusterRoleBinding जोड़ना चाहिए
8) Kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
=> एक फलालैन डेमोंसेट बनाएं
9) (प्रत्येक दास नोड पर) कुबेदम शामिल हों --token (आपका टोकन) (आईपी):(पोर्ट)
=> जैसा कि kubeadm init . के परिणाम में दिखाया गया है

उपरोक्त सभी चरण Kubernetes-1.6.0, विशेष रूप से kubeadm के आसपास विभिन्न मुद्दों के सुझावों के संयोजन का परिणाम हैं।

आशा है कि इससे आपका समय बचेगा।

यह हल नहीं हो रहा है (उबंटू एलटीएस, कुबेदम 1.6.1)।

सबसे पहले, मैंने --apiserver-advertise-address ध्वज का उपयोग करते समय "क्रिएटेड एपीआई क्लाइंट, कंट्रोल प्लेन के तैयार होने की प्रतीक्षा में" कुबेदम को लटकाने का भी अनुभव किया। जर्नल लॉग कहते हैं:

let.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Apr 04 12:27:04 xxx kubelet[57592]: E0404 12:27:04.352780   57592 eviction_manager.go:214] eviction manager: unexpected err: failed GetNode: node 'xxx' not found
Apr 04 12:27:05 xxx kubelet[57592]: E0404 12:27:05.326799   57592 kubelet_node_status.go:101] Unable to register node "xxx" with API server: Post https://x.x.x.x:6443/api/v1/nodes: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.745674   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://x.x.x.x:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dxxx&resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.746759   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://x.x.x.x:6443/api/v1/nodes?fieldSelector=metadata.name%3Dxxx&resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.747749   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://x.x.x.x:6443/api/v1/services?resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeou

अगर मैं यह ध्वज प्रदान नहीं करता हूं, तो कुबेदम गुजरता है, लेकिन फिर भी मुझे क्यूबलेट शुरू करने के लिए निम्न त्रुटि मिलती है:

Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

क्यूबलेट ने ठीक से शुरू करने से इनकार कर दिया, और मैं किसी भी तरह से kubectl साथ क्लस्टर से कनेक्ट नहीं हो सकता

ऐसा लगता है कि 1.5.x kubeadm संस्करण न केवल सेंटोस रिपॉजिटरी से, बल्कि उबंटू एलटीएस से भी हटा दिए गए हैं: https://packages.cloud.google.com/apt/dists/kubernetes-xenial/main/binary-amd64/Packages It डाउनग्रेड करना मुश्किल बनाता है, और वास्तव में पश्चगामी संगतता को तोड़ता है

@बोस्टोन

क्या आपने "कंट्रोल प्लेन के तैयार होने की प्रतीक्षा" में हैंग का पता लगाया? 1.6.1 के साथ सभी परिवर्तनों को आजमाने के बाद मुझे वही चीज़ दिखाई देती है।

@gtirloni @srzjulio kubeadm init बाद इन चरणों को जोड़ने से कोई मदद नहीं मिली। इसने क्यूबलेट सेवा को failed से active (running) लेकिन मेरे पास अभी भी The connection to the server localhost:8080 was refused - did you specify the right host or port? संदेश है। और अगर मैं सुनने वाली सेवाओं को देखता हूं तो मुझे कहीं भी 8080 नहीं दिखाई देता। मैं जो देख सकता हूं वह यह है कि क्यूबलेट इन बंदरगाहों पर सुन रहा है:

kubelet    6397  root   12u  IPv6 611842      0t0  TCP *:4194 (LISTEN)
kubelet    6397  root   15u  IPv4 611175      0t0  TCP sdl02269.labs.teradata.com:49597->sdl02269.labs.teradata.com:sun-sr-https (ESTABLISHED)
kubelet    6397  root   16u  IPv4 611890      0t0  TCP localhost:10248 (LISTEN)
kubelet    6397  root   18u  IPv6 611893      0t0  TCP *:10250 (LISTEN)
kubelet    6397  root   19u  IPv6 611895      0t0  TCP *:10255 (LISTEN)

तो कुछ गलत (बदली हुई?) सेटिंग है जो गलत तरीके से 8080 की ओर इशारा करती है?

@bostone यह आपके लिए आवश्यक क्यूबलेट पोर्ट नहीं है, यह क्यूब-एपिसेवर है, इसे 6443 पोर्ट पर सुनना चाहिए।

@sbezverk मैंने बंदरगाहों तक किसी भी चूक को संशोधित नहीं किया (यह किसी भी निर्देश में नहीं है) 8080 से 6443 पर स्विच करने के लिए मुझे क्या करने की आवश्यकता है?

@bostone अगर आपने एपिसर्वर मेनिफेस्ट में कुछ भी संशोधित नहीं किया है तो डिफ़ॉल्ट रूप से यह 6443 पोर्ट पर सुनेगा। आपको बस /etc/kubernetes/admin.conf को $HOME/.kube/config में कॉपी करने की जरूरत है, कॉन्फिग फाइल पर अनुमतियां बदलें और आपको पूरी तरह से तैयार होना चाहिए।

@sbezverk BTW - मैं सभी इंस्टॉलेशन चरणों को रूट के रूप में चला रहा हूं लेकिन kubeadm init आउटपुट से ये 3 निर्देश लाइनें sudo उपयोगकर्ता का उपयोग करने का सुझाव देती हैं। इस पर क्या सिफारिश है? क्या सभी इंस्टॉलेशन चरणों को एक सूडो के रूप में भी चलाना चाहिए?

ठीक है, मैंने सभी चरणों को खरोंच से किया है और यह बेहतर प्रतीत होता है। यहां वे चरण दिए गए हैं जो मेरे लिए अब तक काम कर रहे हैं और मैं CentOS 7 पर रूट के रूप में चल रहा हूं।

# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
        https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
# setenforce 0
# yum install -y docker kubelet kubeadm kubectl kubernetes-cni
# vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

-cgroup-driver=systemd को 10-kubeadm.conf में जोड़ें और सहेजें

# systemctl enable docker && systemctl start docker
# systemctl enable kubelet && systemctl start kubelet
# sysctl -w net.bridge.bridge-nf-call-iptables=1
# systemctl stop firewalld; systemctl disable firewalld
# kubeadm init
# cp /etc/kubernetes/admin.conf $HOME/
# chown $(id -u):$(id -g) $HOME/admin.conf
# export KUBECONFIG=$HOME/admin.conf
# kubectl apply -f https://git.io/weave-kube

इस बिंदु पर मैं kubectl get nodes चला सकता हूं और सूची में अपना मास्टर नोड देख सकता हूं।
kubeadm init को छोड़कर मिनियन के लिए सभी चरणों को दोहराएं और इसके बजाय kubeadm join --token a21234.c7abc2f82e2219fd 12.34.567.89:6443 जैसा कि kubeadm init द्वारा उत्पन्न किया गया है
यह चरण पूरा हो गया है और मैं मास्टर और मिनियन नोड्स देख सकता हूं

और अब - समस्या:

# kubectl get nodes
NAME       STATUS     AGE       VERSION
abc02918   NotReady   42m       v1.6.1
abc04576   NotReady   29m       v1.6.1

# kubectl describe node abc02918
Events:
  FirstSeen LastSeen    Count   From            SubObjectPath   Type        Reason          Message
  --------- --------    -----   ----            -------------   --------    ------          -------
  43m       43m     1   kubelet, sdl02918           Normal      Starting        Starting kubelet.
  43m       43m     1   kubelet, sdl02918           Warning     ImageGCFailed       unable to find data for container /
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasSufficientDisk   Node sdl02918 status is now: NodeHasSufficientDisk
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasSufficientMemory Node sdl02918 status is now: NodeHasSufficientMemory
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasNoDiskPressure   Node sdl02918 status is now: NodeHasNoDiskPressure
  42m       42m     1   kube-proxy, sdl02918            Normal      Starting        Starting kube-proxy.

तो ऐसा लगता है कि नोड्स कभी तैयार नहीं होते हैं। कोई सुझाव?

मुझे लगता है कि आपकी बुनाई ठीक से तैनात नहीं हो रही है क्योंकि आप इसका उपयोग कर रहे हैं
प्री-1.6 yaml फ़ाइल।

कोशिश करें "kubectl apply -f https://git.io/weave-kube-1.6 "

मंगलवार, 4 अप्रैल, 2017 को दोपहर 12:24 बजे, बो स्टोन नोटिफिकेशन @github.com ने लिखा:

ठीक है, मैंने सभी चरणों को खरोंच से किया है और यह बेहतर प्रतीत होता है। यहाँ हैं
मेरे लिए अब तक काम करने वाले कदम और मैं रूट के रूप में चल रहा हूं।

बिल्ली <

[कुबेरनेट्स]
नाम = कुबेरनेट्स
बेसुर्ल = http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
सक्षम = 1
gpgcheck=1
रेपो_जीपीजीचेक=1
gpgkey= https://packages.cloud.google.com/yum/doc/yum-key.gpg http://yum.kubernetes.io/repos/kubernetes-el7-x86_64enabled=1gpgcheck=1repo_gpgcheck=1gpgkey=https:/ /packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
ईओएफ

सेटनफोर्स 0

यम इंस्टाल-वाई डॉकर क्यूबलेट कुबेदम कुबेक्टल कुबेरनेट्स-सीएनआई

vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

-cgroup-driver=systemd को 10-kubeadm.conf में जोड़ें और सहेजें

systemctl docker सक्षम करें && systemctl start docker

systemctl क्यूबलेट सक्षम करें && systemctl स्टार्ट क्यूबलेट

sysctl -w net.bridge.bridge-nf-call-iptables=1

systemctl फ़ायरवॉल बंद करो; systemctl फ़ायरवॉल को अक्षम करें

कुबेदम इनिटो

cp /etc/kubernetes/admin.conf $HOME/

chown $(id -u):$(id -g) $HOME/admin.conf

निर्यात KUBECONFIG=$HOME/admin.conf

Kubectl लागू -f https://git.io/weave-kube

इस बिंदु पर मैं कुबेक्टल नोड्स प्राप्त कर सकता हूं और अपने मास्टर नोड को देख सकता हूं
सूची।
कुबेदम जॉइन चलाने के अलावा मिनियन के लिए सभी चरणों को दोहराएं
--token a21234.c7abc2f82e2219fd 12.34.567.89:6443 जैसा कि kubeadm द्वारा उत्पन्न किया गया है
इस में
यह चरण पूरा हो गया है और मैं मास्टर और मिनियन नोड्स देख सकता हूं

और अब - समस्या:

Kubectl नोड्स प्राप्त करें

नाम स्थिति आयु संस्करण
abc02918 तैयार नहीं 42m v1.6.1
abc04576 तैयार नहीं 29m v1.6.1

Kubectl नोड का वर्णन abc02918

आयोजन:
सबऑब्जेक्टपाथ प्रकार कारण संदेश से पहली बार अंतिम बार देखी गई गणना
------------------------------------------------------------ -------------
43m 43m 1 क्यूबलेट, sdl02918 सामान्य प्रारंभिक क्यूबलेट।
43m 43m 1 क्यूबलेट, sdl02918 चेतावनी ImageGC कंटेनर के लिए डेटा खोजने में विफल /
43m 43m 29 क्यूबलेट, sdl02918 सामान्य NodeHasSufficientDisk Node sdl02918 स्थिति अब है: NodeHasSufficientDisk
43m 43m 29 क्यूबलेट, sdl02918 सामान्य NodeHasSufficientMemory Node sdl02918 स्थिति अब है: NodeHasSufficientMemory
43m 43m 29 क्यूबलेट, sdl02918 सामान्य NodeHasNoDiskPressure नोड sdl02918 स्थिति अब है: NodeHasNoDiskPressure
42m 42m 1 क्यूब-प्रॉक्सी, sdl02918 नॉर्मल स्टार्टिंग क्यूब-प्रॉक्सी।

तो ऐसा लगता है कि नोड्स कभी तैयार नहीं होते हैं। कोई सुझाव?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-291571437 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAeJQ6OFBV3s6OHmfOkUdwqQsJ1sjg23ks5rsnzMgaJpZM4MtMRe
.

CentOS, और kubeadm के 1.6.1-1 संस्करण का उपयोग करना, और उपरोक्त चरणों का पालन करते हुए, मुझे थोड़ा अलग व्यवहार मिलता है: क्लस्टर को तैयार होने की सूचना दी जाती है, लेकिन फिर मैं इस संदेश पर अटक जाता हूं:

[apiclient] Temporarily unable to list nodes (will retry)

लॉग में, हालांकि, हमें अभी भी वही त्रुटि है:

Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: E0404 13:30:30.491150  108575 pod_workers.go:182] Error syncing pod 2193220cb6f65d66c0d8762189232e64 ("kube-apiserver-csc-q-docker-1.colinx.com_kube-system(2193220cb6f65d66c0d8762189232e64)"), skipping: failed to "StartContainer" for "kube-apiserver" with CrashLoopBackOff: "Back-off 20s restarting failed container=kube-apiserver pod=kube-apiserver-csc-q-docker-1.colinx.com_kube-system(2193220cb6f65d66c0d8762189232e64)"
Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: W0404 13:30:30.524051  108575 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: E0404 13:30:30.524243  108575 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

@sjenning बस इतना ही! मुझे अभी भी कुछ छवियों को तैनात करने की आवश्यकता है यह देखने के लिए कि क्या सब कुछ काम करता है लेकिन मैं सभी नोड्स को Ready स्थिति के साथ देख सकता हूं! आप सभी का धन्यवाद दोस्तों (अभी के लिए :)

@bostone मैंने आपके द्वारा उपयोग की जाने वाली उसी रेसिपी का अनुसरण किया, लेकिन अलग-अलग परिणाम मिले - मुझे पिछले कुबेदम इनिट नहीं मिला। आप किस डॉकर संस्करण का उपयोग कर रहे हैं? शायद मेरे मामले में यही अंतर है?

@dcowden यह वही है जो यम मेरे सिस्टम पर चुनता है Docker version 1.12.6, build 96d83a5/1.12.6 । इसके अलावा मुझे अपने पिछले इंस्टाल के शीर्ष पर ठीक करने की कोशिश करने के बजाय उन सभी वीएम को पुन: व्यवस्थित करने में मदद मिली जो मैं उपयोग कर रहा था

@ बोस्टोन धन्यवाद। मैं यह देखने के लिए उस संस्करण में डाउनग्रेड करूँगा कि क्या मुझे एक कार्यशील सेटअप मिल सकता है। मेरे सिस्टम पर नवीनतम एक अजीब 17.03.1.ce संस्करण है (जाहिर है नवीनतम महानतम)

सुनिश्चित नहीं है कि यह आम तौर पर उपयोगी है, लेकिन मेरे पास एक उत्तरदायी प्लेबुक है कि
CentOS 7 के लिए सभी चरण करता है

https://github.com/sjenning/kubeadm-playbook

वाईएमएमवी, लेकिन यह कम से कम प्रक्रिया को दस्तावेज करता है। मैं भी कुछ काम करता हूँ जैसे
जेसन-फाइल लॉगिंग और ओवरले स्टोरेज का उपयोग करने के लिए डॉकर स्विच करें।

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

मंगलवार, 4 अप्रैल, 2017 को दोपहर 12:55 बजे, डेव काउडेन नोटिफिकेशन @github.com
लिखा था:

@bostone https://github.com/bostone धन्यवाद। मैं उस पर डाउनग्रेड करूंगा
संस्करण यह देखने के लिए कि क्या मुझे एक कार्यशील सेटअप मिल सकता है। मेरे सिस्टम पर नवीनतम है a
अजीब 17.03.1.ce संस्करण (जाहिर है नवीनतम महानतम)

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-291580822 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAeJQ7CUA4vxhF3T7nMc9wRu47rbWe-Kks5rsoQmgaJpZM4MtMRe
.

@sjenning धन्यवाद! यह बहुत मददगार है!

ठीक है, यहाँ एक जटिलता है। मास्टर और मिनियन पर kubeadm reset चलाने के बाद और डॉकर और क्यूबलेट सेवाओं को पुनरारंभ करने के बाद kubeadm init Created API client, waiting for the control plane to become ready एक बार फिर
@sjenning क्या आपने शुरू में इसे चलाने के बाद अपनी प्लेबुक को फिर से चलाने की कोशिश की है?

@bostone मेरे मामले में /var/lib/etcd/ था।

@autostatic निर्देशिका खाली थी और इसका नाम बदलने से मदद नहीं मिली। @sjenning आप प्लेबुक हैंग हो जाते हैं, मैंने आपके लिए एक टिकट बनाया है

क्या किसी ने डैशबोर्ड को v1.6.1 पर चलाने का प्रयास किया है? मुझे एक त्रुटि मिल रही है जो निम्नलिखित बताती है:

`निषिद्ध (403)

उपयोगकर्ता " system:serviceaccount :kube- system:default " क्लस्टर क्षेत्र में नामस्थानों को सूचीबद्ध नहीं कर सकता है। (नामस्थान प्राप्त करें)
`

मुझे लगता है कि मुझे अधिक आरबीएसी को कॉन्फ़िगर करने की आवश्यकता है, जैसे आपको फलालैन चलाने के लिए करना है?

@srzjulio क्या आप इसके लिए एक नया मुद्दा

@srzjulio आपको RBAC नियमों को अपडेट करने की आवश्यकता है, हमने इनका उपयोग हमें जाने के लिए किया:

apiVersion: rbac.authorization.k8s.io/v1alpha1
प्रकार: ClusterRoleBinding
मेटाडेटा:
नाम: क्लस्टर-व्यवस्थापक
भूमिका संदर्भ:
apiGroup: rbac.authorization.k8s.io
प्रकार: ClusterRole
नाम: क्लस्टर-व्यवस्थापक
विषय:

• प्रकार: समूह
  नाम: सिस्टम: मास्टर्स
• प्रकार: समूह
  नाम: सिस्टम: प्रमाणित
• प्रकार: समूह
  नाम: सिस्टम: अनधिकृत

सावधान रहें - @sbezverk के पास जो बंधन है वह अनिवार्य रूप से RBAC को बंद कर रहा है। यदि आप ऐसा करते हैं तो आपके पास एक सुपर असुरक्षित क्लस्टर होगा।

kind: Group
name: system:unauthenticated

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

@jbeda यह व्यवहार से मेल खाता है जो हमारे पास बॉक्स के ठीक बाहर 1.5.6 था। यह लोगों को नए सुरक्षा नियमों के साथ कुछ भी करने में असमर्थ होने के बजाय सुरक्षा कॉन्फ़िगरेशन की समीक्षा करने और धीरे-धीरे समायोजित करने का अवसर देता है।

वास्तव में, सिस्टम बनाना अनधिकृत बनाना 1.5.6 . से कहीं अधिक खराब है

यदि आप कोई प्राधिकरण नहीं चाहते हैं, तो हमेशा अनुमति दें प्राधिकरण का उपयोग करें

यदि आप ऑडिट करते समय सभी को अनुमति देना चाहते हैं, तो RBAC के संयोजन का उपयोग करें,AlwaysAllow

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

क्षमा करें, और मैं इसे फिर से दोहराता हूं, इसका मूल मुद्दे से कोई लेना-देना नहीं है। और हालांकि वैध समस्याएं और मुद्दे, हमें बातचीत को कहीं और स्थानांतरित करना चाहिए।

फिर से क्षमा करें, बहुत जल्द एंटर दबाएं, लेकिन जैसे ही चीजें खड़ी हों:

1 - रिलीज 1.6.0 समस्याएं पैदा करता है
2 - सभी निश्चित नहीं हैं
3 - आरबीएसी में जाना (मेरी राय में अच्छा है) लेकिन समस्या है, क्यों? बिंदु 4 देखें
4 - यह बहुत अच्छी तरह से संप्रेषित नहीं था, और बहुत सारे दस्तावेज़/ब्लॉग या इसे समझाने के लिए कुछ भी नहीं है
5 - मैं उन सभी पीपीएल को नमन करता हूं जो बचाने की कोशिश कर रहे हैं, लेकिन हमें ऐसा करने के लिए एक बेहतर तरीके की जरूरत है

https://kubernetes.io/docs/admin/authorization/rbac/#service -account-permissions अनुमतियों को खोलने के लिए आपके पास सबसे कम से कम बारीक विकल्पों के लिए एक अच्छा मार्गदर्शक है।

क्यूबलेट में "

Apr 12 14:23:25 machine01 kubelet[3026]: W0412 14:23:25.542322    3026 docker_service.go:196] No cgroup driver is set in Docker
Apr 12 14:23:25 machine01 kubelet[3026]: W0412 14:23:25.542343    3026 docker_service.go:197] Falling back to use the default driver: "cgroupfs"
Apr 12 14:23:25 machine01 kubelet[3026]: error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"

जबकि हम स्पष्ट रूप से देख सकते हैं कि देशी.cgroupdriver=systemd docker daemon में सेट है:

 ps -ef|grep -i docker
root      4365     1  3 14:30 ?        00:00:33 /usr/bin/docker-current daemon --authorization-plugin=rhel-push-plugin --exec-opt native.cgroupdriver=systemd --selinux-enabled --log-driver=journald --insecure-registry 172.30.0.0/16 --storage-driver devicemapper --storage-opt dm.fs=xfs --storage-opt dm.thinpooldev=/dev/mapper/vg.docker--pool --storage-opt dm.use_deferred_removal=true --storage-opt dm.use_deferred_deletion=true

@ReSearchITEng आप डॉकटर को 1.12.6 पर अपडेट क्यों नहीं करते? इस संस्करण के साथ एक आकर्षण की तरह काम करता है।

@sbezverk : मैंने अभी 1.12.5 पर अपडेट किया है और अब यह काम कर रहा है! बहुत धन्यवाद!

मदद के लिए सभी को धन्यवाद।
अंत में फलालैन के साथ पूरी तरह से k8s 1.6.1 काम कर रहा है। सब कुछ अब ansible playbooks में है।
Centos/RHEL पर परीक्षण किया गया। डेबियन आधारित (जैसे उबंटू) के लिए भी तैयारी शुरू हो गई थी, लेकिन कुछ शोधन की आवश्यकता हो सकती है।

https://github.com/ReSearchITEng/kubeadm-playbook/blob/master/README.md

पीएस: sjenning/kubeadm-playbook पर आधारित काम - बहुत धन्यवाद @sjenning !

@sjenning @ReSearchITEng
नमस्ते, मेरे पास एक योनि + उत्तरदायी प्लेबुक है [0] जो आपने बनाई है, लेकिन मैं अभी भी इसे काम करने में असमर्थ हूं, मेरे लिए यह नेटवर्किंग सेटअप पर विफल हो रहा है। मैंने कैलिको, बुनाई और फलालैन के साथ प्रयास किया है, और तीनों विफल हो गए हैं (हालांकि विभिन्न लक्षणों के साथ)।

मैं इन संस्करणों को चला रहा हूं:
[ आवारा @ मास्टर ~]$ डोकर --संस्करण
डॉकर संस्करण 1.12.6, बिल्ड 3a094bd/1.12.6
[ आवारा @ मास्टर ~]$ क्यूबलेट --संस्करण
कुबेरनेट्स v1.6.1
[ आवारा @ मास्टर ~]$ कुबेदम संस्करण
kubeadm संस्करण: version.Info {मेजर: "1", माइनर: "6", GitVersion: "v1.6.1", GitCommit: "b0b7a323cc5a4a2019b2e9520c21c7830b7f708e", GitTreeState: "क्लीन", बिल्डडेट: "2017-04-03T20:33: 27Z", GoVersion: "go1.7.5", कंपाइलर: "gc", प्लेटफ़ॉर्म: "linux/amd64"}

त्रुटियां:

[vagrant<strong i="19">@master</strong> ~]$ kubectl get all --all-namespaces
NAMESPACE     NAME                                           READY     STATUS             RESTARTS   AGE
kube-system   po/calico-etcd-gvrhd                           1/1       Running            0          47m
kube-system   po/calico-node-7jvs8                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-node-7ljpn                           2/2       Running            0          47m
kube-system   po/calico-node-w15z3                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-node-zq3zx                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-policy-controller-1777954159-13x01   1/1       Running            0          47m
kube-system   po/etcd-master                                 1/1       Running            0          46m
kube-system   po/kube-apiserver-master                       1/1       Running            0          46m
kube-system   po/kube-controller-manager-master              1/1       Running            0          46m
kube-system   po/kube-dns-3913472980-16m01                   3/3       Running            0          47m
kube-system   po/kube-proxy-70bmf                            1/1       Running            0          45m
kube-system   po/kube-proxy-9642h                            1/1       Running            0          45m
kube-system   po/kube-proxy-jhtvm                            1/1       Running            0          45m
kube-system   po/kube-proxy-nb7q5                            1/1       Running            0          47m
kube-system   po/kube-scheduler-master                       1/1       Running            0          46m

NAMESPACE     NAME              CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
default       svc/kubernetes    10.96.0.1       <none>        443/TCP         47m
kube-system   svc/calico-etcd   10.96.232.136   <none>        6666/TCP        47m
kube-system   svc/kube-dns      10.96.0.10      <none>        53/UDP,53/TCP   47m

NAMESPACE     NAME                              DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kube-system   deploy/calico-policy-controller   1         1         1            1           47m
kube-system   deploy/kube-dns                   1         1         1            1           47m

NAMESPACE     NAME                                     DESIRED   CURRENT   READY     AGE
kube-system   rs/calico-policy-controller-1777954159   1         1         1         47m
kube-system   rs/kube-dns-3913472980                   1         1         1         47m

[vagrant<strong i="5">@master</strong> ~]$ kubectl -n kube-system describe po/calico-node-zq3zx
Name:       calico-node-zq3zx
Namespace:  kube-system
Node:       node1/192.168.10.101
Start Time: Wed, 26 Apr 2017 19:37:35 +0000
Labels:     k8s-app=calico-node
        pod-template-generation=1
Annotations:    kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"DaemonSet","namespace":"kube-system","name":"calico-node","uid":"844cd287-2ab7-11e7-b184-5254008815b6","ap...
        scheduler.alpha.kubernetes.io/critical-pod=
Status:     Running
IP:     192.168.10.101
Controllers:    DaemonSet/calico-node
Containers:
  calico-node:
    Container ID:   docker://ca00b0a73a073a2d2e39cb0cc315b8366eaa20e2e479002dd16134b0d1e94f0b
    Image:      quay.io/calico/node:v1.1.3
    Image ID:       docker-pullable://quay.io/calico/node<strong i="6">@sha256</strong>:8e62eee18612a6ac7bcae90afaba0ed95265baba7bf3c0ab632b7b40ddfaf603
    Port:       
    State:      Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Mon, 01 Jan 0001 00:00:00 +0000
      Finished:     Wed, 26 Apr 2017 20:21:09 +0000
    Ready:      False
    Restart Count:  12
    Requests:
      cpu:  250m
    Environment:
      ETCD_ENDPOINTS:               <set to the key 'etcd_endpoints' of config map 'calico-config'> Optional: false
      CALICO_NETWORKING_BACKEND:        <set to the key 'calico_backend' of config map 'calico-config'> Optional: false
      CALICO_DISABLE_FILE_LOGGING:      true
      FELIX_DEFAULTENDPOINTTOHOSTACTION:    ACCEPT
      CALICO_IPV4POOL_CIDR:         192.168.0.0/16
      CALICO_IPV4POOL_IPIP:         always
      FELIX_IPV6SUPPORT:            false
      FELIX_LOGSEVERITYSCREEN:          info
      IP:                   
    Mounts:
      /lib/modules from lib-modules (ro)
      /var/run/calico from var-run-calico (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from calico-cni-plugin-token-5wnmg (ro)
  install-cni:
    Container ID:   docker://442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
    Image:      quay.io/calico/cni:v1.7.0
    Image ID:       docker-pullable://quay.io/calico/cni<strong i="7">@sha256</strong>:3612ffb0bff609d65311b45f4bae57fa80a05d25e1580ceb83ba4162e2ceef9f
    Port:       
    Command:
      /install-cni.sh
    State:      Running
      Started:      Wed, 26 Apr 2017 19:38:29 +0000
    Ready:      True
    Restart Count:  0
    Environment:
      ETCD_ENDPOINTS:       <set to the key 'etcd_endpoints' of config map 'calico-config'>     Optional: false
      CNI_NETWORK_CONFIG:   <set to the key 'cni_network_config' of config map 'calico-config'> Optional: false
    Mounts:
      /host/etc/cni/net.d from cni-net-dir (rw)
      /host/opt/cni/bin from cni-bin-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from calico-cni-plugin-token-5wnmg (ro)
Conditions:
  Type      Status
  Initialized   True 
  Ready     False 
  PodScheduled  True 
Volumes:
  lib-modules:
    Type:   HostPath (bare host directory volume)
    Path:   /lib/modules
  var-run-calico:
    Type:   HostPath (bare host directory volume)
    Path:   /var/run/calico
  cni-bin-dir:
    Type:   HostPath (bare host directory volume)
    Path:   /opt/cni/bin
  cni-net-dir:
    Type:   HostPath (bare host directory volume)
    Path:   /etc/cni/net.d
  calico-cni-plugin-token-5wnmg:
    Type:   Secret (a volume populated by a Secret)
    SecretName: calico-cni-plugin-token-5wnmg
    Optional:   false
QoS Class:  Burstable
Node-Selectors: <none>
Tolerations:    CriticalAddonsOnly=:Exists
        node-role.kubernetes.io/master=:NoSchedule
        node.alpha.kubernetes.io/notReady=:Exists:NoExecute for 300s
        node.alpha.kubernetes.io/unreachable=:Exists:NoExecute for 300s
Events:
  FirstSeen LastSeen    Count   From        SubObjectPath           Type        Reason      Message
  --------- --------    -----   ----        -------------           --------    ------      -------
  46m       46m     1   kubelet, node1  spec.containers{calico-node}    Normal      Pulling     pulling image "quay.io/calico/node:v1.1.3"
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Pulled      Successfully pulled image "quay.io/calico/node:v1.1.3"
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Created     Created container with id e035a82202b2c8490e879cb9647773158ff05def6c60b31a001e23e6d288a977
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Started     Started container with id e035a82202b2c8490e879cb9647773158ff05def6c60b31a001e23e6d288a977
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Pulling     pulling image "quay.io/calico/cni:v1.7.0"
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Pulled      Successfully pulled image "quay.io/calico/cni:v1.7.0"
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Created     Created container with id 442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Started     Started container with id 442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
  44m       44m     1   kubelet, node1  spec.containers{calico-node}    Normal      Created     Created container with id 163a9073070aa52ce7ee98c798ffe130a581e4fdbbc503540ed5d3b79651c549
  44m       44m     1   kubelet, node1  spec.containers{calico-node}    Normal      Started     Started container with id 163a9073070aa52ce7ee98c798ffe130a581e4fdbbc503540ed5d3b79651c549
  44m       44m     1   kubelet, node1                  Warning     FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 10s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  44m   44m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 07453d944dfb9a4ebae57c83158e4b51f8870bcab94b4f706239f6c0b93bb62d
  44m   44m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 07453d944dfb9a4ebae57c83158e4b51f8870bcab94b4f706239f6c0b93bb62d
  43m   43m 2   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 20s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  43m   43m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 00f363848c16ff66743d54b87948133a87a97bfd32fbde2338622904d0990601
  43m   43m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 00f363848c16ff66743d54b87948133a87a97bfd32fbde2338622904d0990601
  42m   42m 3   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 40s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  41m   41m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id a5aad1f1a57a361fafcaa2ee6aba244bf19925f56c5b46771cfd45e5e7fd884e
  41m   41m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id a5aad1f1a57a361fafcaa2ee6aba244bf19925f56c5b46771cfd45e5e7fd884e
  41m   40m 6   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 1m20s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  40m   40m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 520ee97fe986fd726a0347cab6de5b2a8fba91f73df2d601e8b7625531ed2117
  40m   40m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 520ee97fe986fd726a0347cab6de5b2a8fba91f73df2d601e8b7625531ed2117
  39m   36m 12  kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 2m40s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  36m   36m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 90be4da6fd2e8c111c3e2a91256d60656db80316c1497c29c4155b8f009f241f
  36m   36m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 90be4da6fd2e8c111c3e2a91256d60656db80316c1497c29c4155b8f009f241f
  31m   31m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id bf0d93f45d5ffa2d2c42487851f80048757da5c767491f673bfecfa37fe76e48
  31m   31m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id bf0d93f45d5ffa2d2c42487851f80048757da5c767491f673bfecfa37fe76e48
  44m   3m  12  kubelet, node1  spec.containers{calico-node}    Normal  Pulled      Container image "quay.io/calico/node:v1.1.3" already present on machine
  25m   3m  5   kubelet, node1  spec.containers{calico-node}    Normal  Started     (events with common reason combined)
  25m   3m  5   kubelet, node1  spec.containers{calico-node}    Normal  Created     (events with common reason combined)
  36m   15s 149 kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  44m   15s 173 kubelet, node1  spec.containers{calico-node}    Warning BackOff Back-off restarting failed container

यह महत्वपूर्ण जानकारी की तरह दिखता है, लेकिन मुझे यकीन नहीं है कि इसे कैसे ठीक किया जाए:

[vagrant<strong i="6">@master</strong> ~]$ kubectl -n kube-system logs calico-node-zq3zx calico-node
Skipping datastore connection test
time="2017-04-26T20:20:39Z" level=info msg="NODENAME environment not specified - check HOSTNAME" 
time="2017-04-26T20:20:39Z" level=info msg="Loading config from environment" 
ERROR: Unable to access datastore to query node configuration
Terminating
time="2017-04-26T20:21:09Z" level=info msg="Unhandled error: client: etcd cluster is unavailable or misconfigured; error #0: client: endpoint http://10.96.232.136:6666 exceeded header timeout
" 
time="2017-04-26T20:21:09Z" level=info msg="Unable to query node configuration" Name=node1 error="client: etcd cluster is unavailable or misconfigured; error #0: client: endpoint http://10.96.232.136:6666 exceeded header timeout
" 
Calico node failed to start

किसी भी तरह की सहायता का स्वागत किया जाएगा...

[०]- https://github.com/thiagodasilva/kubernetes-swift/tree/master/roles

मैं नहीं पहचान सका कि आपकी ओर से क्या गलत है।
मैं दृढ़ता से सुझाव देता हूं कि आप यहां प्लेबुक का उपयोग करके एक अलग इंस्टॉलेशन बनाने का प्रयास करें: https://github.com/ReSearchITEng/kubeadm-playbook और यह देखने का प्रयास करें कि क्या अंतर है।
पीएस: मेरे आखिरी परीक्षण 1.6.2 के साथ हैं, क्यूब * और छवियों दोनों और ठीक लगता है।

@kelseyhightower

@ReSearchITEng क्षमा करें, मैं वापस रिपोर्ट करना भूल गया, लेकिन मुझे अंततः यह काम करने के लिए मिला, मेरी योनि + ansible फ़ाइलें यहाँ हैं: https://github.com/thiagodasilva/kubernetes-swift

मुझे भी यही समस्या मिली, लेकिन मैं सिर्फ मास्टर नोड पर cni कॉन्फिगर को वर्कर नोड के संबंधित स्थान पर कॉपी करता हूं, फिर यह ठीक हो गया।

systemctl स्थिति kubelet.service -l

kubelet.service - kubelet: Kubernetes Node Agent
लोडेड: लोडेड (/etc/systemd/system/kubelet.service; सक्षम; विक्रेता प्रीसेट: अक्षम)
ड्रॉप-इन: /etc/systemd/system/kubelet.service.d
10-kubeadm.conf
सक्रिय: मंगल 2017-06-06 10:42:00 CST से सक्रिय (चल रहा है); १८मिनट पहले
दस्तावेज़: http://kubernetes.io/docs/
मुख्य पीआईडी: ४४१४ (क्यूबलेट)
मेमोरी: 43.0M
सीग्रुप: /system.slice/kubelet.service
4414 /usr/bin/kubelet --kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true --pod-manifest-path=/etc/kubernetes/manifests --network-plugin=cni - -cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --cluster-dns=10.96.0.10 --cluster-domain=cluster.local --authorizatio -ca-file=/etc/kubernetes/pki/ca.crt --cgroup-driver=cgroupfs
└─4493 जर्नलक्टल-के-एफ

जून 06 10:59:46 contiv1.com क्यूबलेट [4414]: W0606 10:59:46.215827 4414 cni.go:157] cni कॉन्फिग को अपडेट करने में असमर्थ: /etc/cni/net.d में कोई नेटवर्क नहीं मिला
जून 06 10:59:46 contiv1.com क्यूबलेट[4414]: E0606 10:59:46.215972 4414 kubelet.go:2067] कंटेनर रनटाइम नेटवर्क तैयार नहीं: NetworkReady=false तैयार संदेश: docker : नेटवर्क प्लगइन तैयार नहीं है: cni config अप्रारंभीकृत
जून 06 10:59:51 contiv1.com क्यूबलेट [4414]: W0606 10:59:51.216843 4414 cni.go:157] cni कॉन्फिग को अपडेट करने में असमर्थ: /etc/cni/net.d में कोई नेटवर्क नहीं मिला
जून 06 10:59:51 contiv1.com क्यूबलेट [4414]: E0606 10:59:51.216942 4414 kubelet.go:2067] कंटेनर रनटाइम नेटवर्क तैयार नहीं: NetworkReady=false तैयार संदेश: docker : नेटवर्क प्लगइन तैयार नहीं है: cni config अप्रारंभीकृत
जून 06 10:59:56 contiv1.com क्यूबलेट [4414]: W0606 10:59:56.217923 4414 cni.go:157] cni config को अपडेट करने में असमर्थ: /etc/cni/net.d में कोई नेटवर्क नहीं मिला
जून 06 10:59:56 contiv1.com क्यूबलेट [4414]: E0606 10:59:56.218113 4414 kubelet.go:2067] कंटेनर रनटाइम नेटवर्क तैयार नहीं: NetworkReady=false तैयार संदेश: docker : नेटवर्क प्लगइन तैयार नहीं है: cni config अप्रारंभीकृत
जून 06 11:00:01 contiv1.com क्यूबलेट [4414]: W0606 11:00:01.219251 4414 cni.go:157] cni कॉन्फिग को अपडेट करने में असमर्थ: /etc/cni/net.d में कोई नेटवर्क नहीं मिला
जून ०६ ११:००:०१ contiv1.com क्यूबलेट [४४१४]: ई०६०६ ११:००: ०१.२१९३८२ ४४१४ kubelet.go:२०६७] कंटेनर रनटाइम नेटवर्क तैयार नहीं है: NetworkReady=false तैयार संदेश: docker : नेटवर्क प्लगइन तैयार नहीं है: cni config अप्रारंभीकृत
जून 06 11:00:06 contiv1.com क्यूबलेट [4414]: W0606 11:00: 06.220396 4414 cni.go:157] cni कॉन्फिग को अपडेट करने में असमर्थ: /etc/cni/net.d में कोई नेटवर्क नहीं मिला
जून 06 11:00:06 contiv1.com क्यूबलेट [4414]: E0606 11:00:06.220575 4414 kubelet.go:2067] कंटेनर रनटाइम नेटवर्क तैयार नहीं है: NetworkReady=false तैयार संदेश: docker : नेटवर्क प्लगइन तैयार नहीं है: cni config अप्रारंभीकृत

सभी नोड्स की स्थिति:
[ root@ swarm net.d]# Kubectl नोड प्राप्त करें
नाम स्थिति आयु संस्करण
contiv1.com तैयार 1h v1.6.4
contiv2.com तैयार 1h v1.6.4
swarm.com तैयार 1h v1.6.4

इस पर कोई संकल्प? मैं सभी उल्लिखित संकल्पों को आजमाने के बाद भी ऐसा नहीं कर पाया।

Kubernetes को स्थापित करने के लिए नया होने के कारण मैं बहुत भ्रमित हो जाता हूं। मैंने https://medium.com/@SystemMining/setup -kubenetes-cluster-on-ubuntu-16-04-with-kubeadm-336f4061d929 का अनुसरण करने की कोशिश की, जो नेटवर्क के लिए वेव-क्यूब का उपयोग करते हैं, लेकिन मैं भी इसी मुद्दे पर अटका हुआ हूं . इसे हल करने का कोई तरीका?
Ready False Mon, 12 Jun 2017 16:55:16 +0200 Mon, 12 Jun 2017 12:22:45 +0200 KubeletNotReady runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

यह अभी भी एक मुद्दा क्यों है? Ubuntu 16.04/CentOS 7.3 नवीनतम अपडेट के साथ 1.6.4 के साथ आधिकारिक k8s रेपो का उपयोग करके और यहां बताए गए चरणों का पालन करें: https://kubernetes.io/docs/setup/in निर्भर/install-kubeadm
Jun 13 09:57:21 tme-lnx1-centos kubelet: W0613 09:57:21.871413 10321 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Jun 13 09:57:21 tme-lnx1-centos kubelet: E0613 09:57:21.871788 10321 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

@drajen नहीं, इससे _only v1.6.0_ प्रभावित

kubectl apply -f https://git.io/weave-kube-1.6

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

@luxas मैं इसके संदर्भ देखता

@drajen मुझे लगता है कि @luxas 'बिंदु यह है कि सेटअप के बारे में पूछने के लिए यह गलत जगह है।
विभिन्न सेटअप गाइड आपको इस बिंदु से आगे ले जाएंगे - पुराने गाइड में विशिष्ट लापता कदम, जिसका लक्सस मददगार रूप से उल्लेख करता है, इसमें आपको नेटवर्क कॉन्फ़िगरेशन लागू करने की आवश्यकता है इससे पहले कि सब कुछ ठीक से काम करना शुरू कर दे।

हाँ, यह स्पष्ट नहीं हो सकता है और इसके लिए हमें खेद है, लेकिन हमारे पास एक भी प्रदाता का नाम नहीं हो सकता है।

स्लैक पर @drajen के साथ चैट की गई और समस्या cgroup से संबंधित थी, क्यूबलेट अस्वस्थ था और कोई पॉड बनाने में सक्षम नहीं था, इसलिए समस्या।

मेरी विशेष समस्या को जमीन पर लाने के लिए https://github.com/kubernetes/kubeadm/issues/302

अभी भी इसे 1.7 पर आर्क में मार रहा है, क्या कहीं भी कोई त्वरित सुधार है?

संपादित करें:

kubectl apply -f https://git.io/weave-kube-1.6

चाल चली, ऐसा लगता है कि हमें बस सीएनआई चलाने की जरूरत है

कम से कम CentOS/RHEL के लिए, सुनिश्चित करें कि आप /etc/systemd/system/kubelet.service.d/10-kubeadm.conf को अपडेट करें और फ़्लैग जोड़ें --cgroup-driver="systemd"

यदि आप उसी मशीन पर पुनः पुनः स्थापित करते हैं, तो यह एक पूर्ण उचित रीसेट है:
https://github.com/ReSearchITEng/kubeadm-playbook/blob/master/reset.yml
(यह विशेष रूप से आवश्यक है यदि आप फलालैन का उपयोग करते हैं)
यदि आप सभी को एक साथ करना चाहते हैं, तो आप पूरी परियोजना का उपयोग करना चाह सकते हैं: https://github.com/ReSearchITEng/kubeadm-playbook/

मैंने इस मुद्दे को मारा, और मैंने ऊपर पढ़ा कुछ भी काम नहीं किया। इसलिए मैंने बहुत अधिक नियंत्रित सेटअप के साथ फिर से कोशिश की, उबंटू से नवीनतम कोरओएस पर स्विच करना, शुरू करने के लिए k8s के पुराने संस्करण में जाना, और सामान्य तौर पर प्रत्येक वीएम में स्थापित हर आखिरी चीज के बारे में बहुत गुदा होना। मैं kubeadm का उपयोग नहीं कर रहा हूं, बल्कि इसके बजाय आवारा और ansible का संयोजन है।

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

जब मैंने k8s के पुराने (1.4.3) संस्करण के साथ इस सेटअप की कोशिश की, तो यह दृष्टिकोण सुनहरा था। मैंने फिर 1.71 में अपग्रेड करने का प्रयास किया। एक बार फिर, मैं अभी भी कुबेदम का उपयोग न करने के बावजूद भी इसी मुद्दे पर बात कर रहा हूं।

मैंने पुष्टि की है कि मैं मास्टर और तीन संभावित श्रमिकों सहित अपने प्रत्येक नोड में कैलिको चला रहा हूं। मेरे सभी नोड्स नोटरेडी के रूप में रिपोर्ट कर रहे हैं, इसलिए मुझे सच में यकीन नहीं है कि मैं इसे चलाने के लिए बुनाई (या कुछ और) कैसे लागू कर सकता हूं।

यह पूरी बात सिर्फ चिकन/अंडा लगता है ... एक पॉड आवंटित नहीं कर सकता क्योंकि नेटवर्किंग विफल हो रही है, लेकिन पॉड आवंटित करने में सक्षम होने के लिए /etc/cni/net.d पर नेटवर्क बनाने के लिए नेटवर्किंग चलाने की आवश्यकता है। और फिर, यह सब कुछ घंटे पहले k8s 1.4.3 के साथ काम कर रहा था। मैं बहुत निराश हूँ!

मैं किसी भी अंतर्दृष्टि की सराहना करता हूं जो कोई भी दे सकता है।

फुटनोट:

मास्टर पर: journalctl -r -u kubelet मुझे देता है

जुलाई 24 00:48:16 दुष्ट-क्यूब-मास्टर-01 क्यूबलेट-रैपर [7647]: E0724 00:48:16.592274 7647 kubelet.go:2136] कंटेनर रनटाइम नेटवर्क तैयार नहीं है: NetworkReady=false कारण:NetworkPluginNotReady संदेश:docker : नेटवर्क प्लगइन नहीं है
जुलाई 24 00:48:16 दुष्ट-क्यूब-मास्टर-01 क्यूबलेट-रैपर [7647]: W0724 00:48:16.590588 7647 cni.go:189] cni कॉन्फिग को अपडेट करने में असमर्थ: /etc/cni/net में कोई नेटवर्क नहीं मिला ।डी

डोकर पीएस | ग्रेप केलिको

(पठनीयता के लिए छोटा)
सीडीई ... quay.io/calico/ नेता-निर्वाचक @ SHA256 : ... "/run.sh --election = ग" 8 घंटे पहले ऊपर 8 घंटे
f72... calico/ kube-policy-controller@sha256 :... "/dist/controller" 8 घंटे पहले ऊपर 8 घंटे
c47... gcr.io/google_containers/pause-amd64:3.0 "/pause" 8 घंटे पहले ऊपर 8 घंटे

कोई /etc/cni/net.d . नहीं है

मेरे कुबेक्टल बॉक्स से:
Kubectl नोड्स प्राप्त करें
10.0.0.111 तैयार नहीं, शेड्यूलिंग अक्षम 8h v1.7.1+coreos.0
10.0.0.121 तैयार नहीं 8h v1.7.1+coreos.0
10.0.0.122 नहीं तैयार 8h v1.7.1+coreos.0
10.0.0.123 नहीं तैयार 8h v1.7.1+coreos.0

Kubectl लागू -f https://git.io/weave-kube-1.6

कुछ भी ठीक नहीं किया और वास्तव में केवल और अधिक समस्याएं पैदा करने लगता है।

Bill@rogue :~/vagrant_rogue/rogue-cluster$ kubectl apply -f https://git.io/weave-kube-1.6
सेवाखाता "बुनाई-नेट" बनाया गया
क्लस्टररोलबाइंडिंग "वीव-नेट" बनाया गया
डेमोंसेट "वीव-नेट" बनाया गया
सर्वर से त्रुटि (निषिद्ध): क्लस्टररोल्स। ["प्राप्त करें"]} नीति नियम {संसाधन: ["पॉड्स"], एपीआई समूह: [""], क्रिया: ["सूची"]} नीति नियम {संसाधन: ["पॉड्स"], एपीआई समूह: [""], क्रिया: ["घड़ी"]} नीति नियम {संसाधन: ["नामस्थान"], एपीआई समूह: [""], क्रिया: ["प्राप्त करें"]} नीति नियम {संसाधन: ["नामस्थान"], एपीआई समूह: [""], क्रिया: ["सूची"]} नीति नियम {संसाधन: ["नामस्थान"], एपीआई समूह: [""], क्रिया: ["घड़ी"]} नीति नियम {संसाधन: ["नोड्स"], एपीआई समूह: [""], क्रिया: ["प्राप्त करें"]} नीति नियम {संसाधन: ["नोड्स"], एपीआई समूह: [""], क्रिया: ["सूची"]} नीति नियम {संसाधन: ["नोड्स"], एपीआई समूह: [""], क्रिया: ["घड़ी"]} नीति नियम {संसाधन: ["नेटवर्क नीतियां"], एपीआई समूह: ["एक्सटेंशन"], क्रिया: ["प्राप्त करें"]} नीति नियम {संसाधन: ["नेटवर्क नीतियां"], एपीआई समूह: ["एक्सटेंशन"], क्रिया: ["सूची"]} नीति नियम {संसाधन: ["नेटवर्क नीतियां"], एपीआई समूह: ["एक्सटेंशन"], क्रिया: ["घड़ी"]}] उपयोगकर्ता = और {क्यूब-व्यवस्थापक [सिस्टम: ए प्रमाणित] नक्शा []} स्वामी नियम = [] नियम समाधान त्रुटि = []

बिल@दुष्ट :~/vagrant_rogue/rogue-cluster$ kubectl पॉड्स प्राप्त करें --namespace=kube-system
नाम तैयार स्थिति फिर से शुरू होती है आयु
क्यूब-एपिसर्वर-10.0.0.111 1/1 रनिंग 1 8h
क्यूब-कंट्रोलर-मैनेजर-10.0.0.111 1/1 रनिंग 1 8h
क्यूब-डीएनएस-v20-fcl01 0/3 लंबित 0 8h
क्यूब-प्रॉक्सी-10.0.0.111 1/1 रनिंग 1 8h
क्यूब-प्रॉक्सी-10.0.0.121 1/1 रनिंग 1 8h
क्यूब-प्रॉक्सी-10.0.0.122 1/1 रनिंग 1 8h
क्यूब-प्रॉक्सी-10.0.0.123 1/1 रनिंग 1 8h
क्यूब-शेड्यूलर-10.0.0.111 1/1 रनिंग 1 8h
कुबेरनेट्स-डैशबोर्ड-v1.4.1-29zzk 0/1 लंबित 0 8h
बुनाई-नेट-2lplj 1/2 क्रैशलूपबैकऑफ़ 3 3m
बुनाई-नेट-2nbgd 1/2 क्रैशलूपबैकऑफ़ 3 3m
वेट-नेट-fdr1v 2/2 रनिंग 0 3m
बुनाई-नेट-jzv50 1/2 CrashLoopBackOff 3 3m

बुनाई की त्रुटियों की गहन जांच से संकेत मिलता है कि वे या तो (ए) एपिसर्वर से कनेक्ट नहीं हो सकते हैं, या फिर (बी) "रनिंग" चिह्नित एक के मामले में यह शिकायत कर रहा है कि यह खुद से कनेक्ट नहीं हो सकता है।

@billmilligan इसी तरह के मुद्दों के साथ, कंटेनर शुरू होने के कुछ मिनट बाद डीएनएस काम करना बंद कर देता है

@Paxa @billmilligan यदि आप सहायता प्राप्त करना चाहते हैं, तो इस मुद्दे पर टिप्पणी न करें। इसके बजाय, अनुरोध किए गए पर्याप्त विवरण के साथ कुबेदम रेपो में नए खोलें।

@luxas सम्मानपूर्वक, मुझे सवाल करना है कि यह एक नया मुद्दा है या नहीं। चूँकि मुझे कुबेदम के बिना k8s की स्थापना के ठीक वैसा ही परिणाम मिल रहा है जैसा कि बाकी सभी को कुबेदम के

@ बिलमिलिगन सम्मानपूर्वक, चूंकि यह मुद्दा कुबेदम के बारे में है, और आप इसे कुबेदम के बिना पुन: पेश करने में सक्षम हैं, तो इसे दर्ज करने के लिए गलत जगह है? मुझे लगता है कि इस सूत्र ने कुबेदम मुद्दे को हल कर दिया। यह एक नया मुद्दा है। मुझे लगता है कि एक नए मुद्दे के रूप में इस पर अधिक ध्यान दिया जाएगा। जैसा कि इस धागे के लोग सोचते हैं कि यह पहले ही हल हो चुका है और इसे अनदेखा कर रहे हैं।

मैं कुबेदम का उपयोग करता हूं और इस मुद्दे से प्रभावित था, और इसे 1.6.1 से हल किया गया है। मैंने तब से k8s के नुकसान को तैनात किया है, इसलिए मुझे सच में लगता है कि आपके पास एक अलग मुद्दा है।

@ kfox1111 प्रतिक्रिया के लिए धन्यवाद। मैं एक नया मुद्दा दर्ज करूंगा, लेकिन 1.7.x में अभी भी कहीं और इसका सामना करने वाले लोगों की संख्या अभी भी मुझे आश्चर्यचकित करती है।

टीएल; डॉ;

त्रुटि संदेश

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

जरूरी नहीं कि बुरा हो।

वह त्रुटि संदेश आपको बताता है कि आपको किसी तृतीय पक्ष CNI कल्पना कार्यान्वयन प्रदाता में प्लग इन करना होगा।

CNI क्या है और Kubernetes के साथ कैसे एकीकृत होता है?

CNI कंटेनर नेटवर्क इंटरफेस के लिए खड़ा है और एक विनिर्देश को परिभाषित करता है जो क्यूबलेट क्लस्टर के लिए एक नेटवर्क बनाने के लिए उपयोग करता है। अधिक जानकारी के लिए यह पृष्ठ देखें कि कुबेरनेट्स क्लस्टर के लिए नेटवर्क बनाने के लिए CNI युक्ति का उपयोग कैसे करता है।

Kubernetes परवाह नहीं है कि नेटवर्क कैसे बनाया जाता है जब तक कि यह CNI विनिर्देश को संतुष्ट करता है।

kubelet नए पॉड्स को नेटवर्क से
kubelet सीएनआई नेटवर्क के उपयोग के लिए एक कॉन्फ़िगरेशन निर्देशिका (अक्सर /etc/cni/net.d ) पढ़ता है।
जब एक नया पॉड बनाया जाता है, तो क्यूबलेट कॉन्फ़िगरेशन निर्देशिका में फ़ाइलों को पढ़ता है, exec कॉन्फ़िगरेशन फ़ाइल में निर्दिष्ट सीएनआई बाइनरी के लिए बाहर है (बाइनरी अक्सर /opt/cni/bin )। निष्पादित किया जाने वाला बाइनरी किसी तृतीय-पक्ष (जैसे वीव, फलालैन, केलिको, आदि) से संबंधित है और स्थापित किया गया है।

kubeadm कुबेरनेट्स समूहों को स्पिन करने के लिए एक सामान्य उपकरण है और यह नहीं जानता कि आपको कौन सा नेटवर्किंग समाधान चाहिए और यह किसी विशिष्ट व्यक्ति का पक्ष नहीं लेता है। kubeadm init चलने के बाद, ऐसी कोई CNI बाइनरी या कॉन्फ़िगरेशन नहीं है । इसका मतलब है कि kubeadm init पूरी तरह से काम कर रहे क्लस्टर को चलाने और चलाने के लिए पर्याप्त नहीं है ।

इसका मतलब है, कि kubeadm init , क्यूबलेट लॉग कहेगा

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

यह बहुत अपेक्षित है। यदि ऐसा नहीं होता, तो हम एक विशिष्ट नेटवर्क प्रदाता का पक्ष लेते।

तो मैं इस त्रुटि को "ठीक" कैसे करूं?
कुबेदम आरंभ करने की मार्गदर्शिका में अगला चरण "पॉड नेटवर्क स्थापित करना" है।
इसका मतलब है, kubectl apply आपके पसंदीदा CNI नेटवर्क प्रदाता की ओर से एक मेनिफेस्ट।

डेमनसेट /opt/cni/bin लिए आवश्यक CNI बायनेरिज़ और आवश्यक कॉन्फ़िगरेशन को /etc/cni/net.d/ कॉपी करेगा। साथ ही यह वास्तविक डेमॉन चलाएगा जो नोड्स के बीच नेटवर्क सेट करता है (उदाहरण के लिए iptables नियम लिखकर)।

CNI प्रदाता स्थापित होने के बाद, क्यूबलेट नोटिस करेगा कि "ओह, मेरे पास कुछ जानकारी है कि नेटवर्क कैसे स्थापित किया जाए", और तृतीय-पक्ष कॉन्फ़िगरेशन और बायनेरिज़ का उपयोग करेगा।

और जब नेटवर्क को तृतीय-पक्ष प्रदाता द्वारा स्थापित किया जाता है (क्यूबलेट द्वारा इसे लागू करके), तो नोड स्वयं को Ready चिह्नित करेगा।

यह मामला कुबेदम से कैसे संबंधित है?

v1.6 चक्र के अंत में, एक PR का विलय कर दिया गया जिसने क्यूबलेट द्वारा Ready/NotReady स्थिति की रिपोर्ट करने के तरीके को बदल दिया। पहले रिलीज में, kubelet ने हमेशा Ready स्थिति की सूचना दी थी, भले ही सीएनआई नेटवर्क स्थापित किया गया हो या नहीं। यह वास्तव में एक प्रकार का गलत था, और CNI नेटवर्क स्थिति का सम्मान करने के लिए इसे बदल दिया गया। यानी, NotReady जब CNI को शुरू नहीं किया गया था और Ready जब इनिशियलाइज़ किया गया था।

v1.6.0 में kubeadm ने बाकी kubeadm init कार्यों के साथ आगे बढ़ने से पहले मास्टर नोड के Ready स्थिति में होने के लिए गलत तरीके से प्रतीक्षा की। जब क्यूबलेट व्यवहार को NotReady रिपोर्ट करने के लिए बदल दिया गया था, जब सीएनआई को शुरू नहीं किया गया था, तो कुबेदम नोड के लिए Ready प्राप्त करने के लिए हमेशा के लिए इंतजार करेगा।

कुबेदम पक्ष पर प्रतीक्षा करें कि यह समस्या क्या है

हालांकि, हमने जल्दी से v1.6.1 में प्रतिगमन को ठीक कर दिया और इसे v1.6.0 के कुछ दिनों बाद जारी किया।

इसके बारे में अधिक जानकारी के लिए कृपया पूर्वव्यापी पढ़ें, और इस दोष के साथ v1.6.0 क्यों जारी किया जा सकता है।

तो, अगर आपको लगता है कि आप इस मुद्दे को kubeadm v1.6.1+ में देखते हैं, तो आप क्या करते हैं?

ठीक है, मुझे सच में लगता है कि आप नहीं करते हैं। यह समस्या उस समय की है जब kubeadm init गतिरोध में है।
किसी भी उपयोगकर्ता या अनुरक्षक ने इसे v1.6.1+ में नहीं देखा है।

क्या आप हालांकि देखेंगे

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

v1.6 से ऊपर के सभी संस्करणों में प्रत्येक kubeadm init बाद, लेकिन यह बुरा नहीं है

वैसे भी, यदि आप कुबेदमो के साथ कुछ अनपेक्षित देखते हैं तो कृपया एक नया मुद्दा खोलें

कृपया इस मुद्दे पर अधिक टिप्पणी न करें। इसके बजाय एक नया खोलें।

@billmilligan तो मुझे लगता है कि आपके क्लस्टर को चलाने और चलाने के लिए आपको केवल kubectl apply एक सीएनआई प्रदाता का मैनिफेस्ट करना होगा

ऊपर जो कहा गया है, मैं उसका बहुत संक्षेप में वर्णन कर रहा हूं, लेकिन उम्मीद है कि अधिक स्पष्ट और विस्तृत तरीके से।
यदि CNI के काम करने के तरीके के बारे में आपके कोई प्रश्न हैं, तो कृपया StackOverflow, एक समस्या या Slack जैसे सामान्य समर्थन चैनल देखें।

(अंत में, इतने बोल्ड टेक्स्ट के लिए खेद है, लेकिन मुझे लगा कि लोगों का ध्यान आकर्षित करने के लिए इसकी आवश्यकता है।)