/ سم مكعبlukemarsdenluxasmikedanese

إذا عدنا إلى رقم 43474 تمامًا ، فإننا في موقف مرة أخرى حيث نكسر 0.2.0 مكونات CNI الإضافية (انظر https://github.com/kubernetes/kubernetes/issues/43014)

هل يجب أن نفكر في القيام بشيء مثل https://github.com/kubernetes/kubernetes/pull/43284؟

أيضا / ccthockin

/ cc @ kubernetes / sig-network-bugs

المرجع: https://github.com/kubernetes/kubernetes/issues/43397#issuecomment -289978351

jbeda هل يمكنني الحصول على بعض سجلات kubelet مع --loglevel = 5؟

yujuhong - لقد ذكرت أنك تعتقد أن هذا يعمل على النحو المنشود. بغض النظر ، كان kubeadm يعتمد على هذا السلوك. قدمنا ​​تغيير كسر مع # 43474. يمكننا التحدث عن الطريقة الصحيحة لإصلاح هذا لـ 1.7 ولكن ، في الوقت الحالي ، نحتاج إلى تشغيل kubeadm مرة أخرى.

مناقشة Slack جارية الآن - https://kubernetes.slack.com/archives/C09QYUH5W/p1490803144368246

يبدو أن DaemonSets سيستمر في الجدولة حتى إذا لم تكن العقدة جاهزة. هذا حقًا ، في هذه الحالة ، kubeadm هو بجنون العظمة إلى حد ما.

الخطة الحالية التي سنختبرها هي عدم انتظار kubeadm حتى تصبح العقدة الرئيسية جاهزة ولكن بدلاً من ذلك يتم تسجيلها فقط. يجب أن يكون هذا جيدًا بما يكفي للسماح بجدولة CNI DaemonSet لإعداد CNI.

@ kensimon يختبر هذا.

jbeda نعم ، يبدو أن وحدة التحكم DaemonSet ستظل قائمة في قوائمها بشكل أساسي لأنها تجهل تمامًا عدم وجود الشبكة. يجب أن نصلح هذا الأمر بشكل عام. هل هناك أي شيء يمكن القيام به في kube أو هل كل شيء موجود في kubeadm في الوقت الحالي؟

أحاول تثبيت kubernetes مع kubeadm على Ubuntu 16.04. هل هناك حل سريع لهذا؟

jbeda إذا كان لديك نسخة مصححة سعيدة باختبارها ..

لقد تجاوزت kubeadm حالة العقدة NotReady ، لكن النشر الوهمي الذي تنشئه لا يعمل بسبب تلطيخ node.alpha.kubernetes.io/notReady يمنعه من العمل. لا يبدو أن إضافة التسامح يساعد ، لست متأكدًا تمامًا من كيفية المضي قدمًا في هذه المرحلة. هل يمكن لأي شخص إلقاء بعض الضوء على كيفية نشر حجرة تتسامح مع تلوث notReady ؟

أنا أستكشف بعض الخيارات الأخرى مثل عدم وضع علامة على العقدة على أنها ليست جاهزة ، ولكن ليس من الواضح أن هذا ما نريد القيام به.

لقد عملنا على حلها عن طريق إزالة KUBELET_NETWORK_ARGS من سطر أوامر kubelet. بعد أن عملت kubeadm init بشكل جيد وتمكنا من تثبيت المكون الإضافي canal cni.

sbezverk هل يمكنك وصف كيفية القيام بذلك؟

يمكن تأكيد نتائجsbezverk (البحث الجيد :)) ، وضبط /etc/systemd/system/10-kubeadm.conf وإزالة KUBELET_NETWORK_ARGS سيجعلها تعمل على centos. تم اختباره مع النسج.

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_EX

إزالة $ KUBELET_NETWORK_ARGS

ثم أعد تشغيل kubelet بعد أن يعمل bebeadm init.

وهذا هو ما فعلته

إعادة تعيين kubeadm

إزالة مدخلات ENV من:

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

إعادة تحميل خدمات systemd و kube

إعادة تحميل البرنامج الخفي systemctl
إعادة تشغيل systemctl kubelet.service

إعادة تشغيل الحرف الأول

الحرف الأول kubeadm

كل شيء على ما يرام ، وبينما نحن فيه

إذا رأيت هذا:
kubelet: خطأ: فشل في تشغيل Kubelet: فشل في إنشاء kubelet: خطأ التكوين: kubelet cgroup driver: "cgroupfs" يختلف عن docker cgroup driver: "systemd"

يجب عليك تحرير /etc/systemd/system/kubelet.service.d/10-kubeadm.conf وإضافة العلامة --cgroup-driver = "systemd"

وتفعل ما ورد أعلاه

إعادة تعيين kuebadm
إعادة تحميل البرنامج الخفي systemctl
إعادة تشغيل systemctl kubelet.service
الحرف الأول kubeadm.

سأكون حريصًا على إزالة --network-plugin=cni من علامات kubelet CLI ، وهذا يتسبب في استخدام kubelet للمكوِّن الإضافي no_op افتراضيًا ... سأكون متفاجئًا إذا كانت المكونات الإضافية الشائعة مثل calico / weave ستعمل في هذه الحالة (ولكن ثم مرة أخرى ، فإن فهمي لكيفية عمل هذه المكونات الإضافية محدود بعض الشيء.)

@ kensimon hm ، لم أر أي مشكلات في الإعداد الخاص بي ، لقد قمت بنشر المكون الإضافي canal cni وكان يعمل بشكل جيد ..

sbezverk هل تعمل الشبكات عبر المضيف بشكل جيد أيضًا؟

resouer لا يمكن التأكيد ، لدي 1.6.0 فقط باعتباره الجهاز متعدد الإمكانات.

resouersbezverk انضممت بنجاح آلة.

 [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

"" [ root @ publish
إعادة تعيين الوضع الجاهز للاسم العمر
etcd -loy-01 1/1 الجري 0 50 م
kube-apiserver -loy-01 1/1 الجري 0 51 م
kube-controller-manager -loy-01 1/1 الجري 0 50 م
kube-dns-3913472980-6plgh 3/3 الجري 0 51 م
kube-proxy-mbvdh 1/1 الجري 0 4 م
kube-proxy-rmp36 1/1 الجري 0 51 م
kube-جدولة-النشر 01 1/1 الجري 0 50 م
kubernetes-dashboard-2396447444-fm8cz 1/1 ركض 0 24 م
weave-net-3t487 2/2 الجري 0 44 م
نسج صافي hhcqp 2/2 الجري 0 4 م

""

الحل يعمل ولكن لا يمكن الحصول على الفانيلا ...

stevenbower أسوأ سيناريو ، يمكنك إعادة هذا الإعداد وإعادة تشغيل kubelet عند الانتهاء من أعمال kubeadm ..

حصلت على مجموعة من ثلاث عقد مع عمل weave . لست متأكدًا من مدى استقرار هذا مع هذا الاختراق ، ولكن شكرًا على أي حال! : مبتسم:

على العقدة الجانبية ، يمكنك إعادة $ KUBELET_NETWORK_ARGS ، بعد تمرير البادئ في المفتاح الرئيسي. في الواقع لم أقم بإزالته على الجهاز الذي انضممت إليه ، فقط سائق المجموعة ، وإلا فلن يعمل kubelet و docker معًا.

لكن ليس عليك إعادة تعيين kubeadm ، فقط قم بتغيير /etc/systemd/system/kubelet.service.d/10-kubeadm.conf وقم برقصة systemctl:

إعادة تحميل البرنامج الخفي systemctl
إعادة تشغيل systemctl kubelet.service

لأولئك منكم الذين يسقطون KUBELET_NETWORK_ARGS ويبلغون أنه يعمل من أجلك:

بالنسبة لي ، لدي مجموعتان: واحدة حيث قمت بتطبيق التصحيح من https://github.com/kubernetes/kubernetes/pull/43824 والسماح لـ kubeadm بالمتابعة بشكل طبيعي عند التهيئة ، وواحدة مع 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 عادي ولكن مع kubeadm مصحح:

$ 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 صباحًا ، كتب "Dan Williams" [email protected] :

jbeda https://github.com/jbeda نعم ، يبدو مثل DaemonSet
ستظل وحدة التحكم قائمة عليها بشكل أساسي لأنها جاهلة تمامًا
من الشبكة iness. يجب أن نصلح هذا الأمر بشكل عام. هل هناك
أي شيء فوري للقيام به في kube أم أنه كل شيء في kubeadm في الوقت الحالي؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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 يخبر kubelet عن المكون الإضافي الذي يجب استخدامه ، ومكان البحث عن التكوين والثنائيات. كنت في حاجة إليها.

أوصي بـ # 43835 (واختيار 1.6 cherry # 43837) كإصلاح نصنعه لـ 1.6. اختبرت كلاهما وهما يعملان. لقد قمت بتعيين jbeda و luxas للمراجعة عند الاستيقاظ.

كلاهما يبدو معقولاً. لكن أعتقد أننا يجب أن ننظر إلى استخدام https://github.com/kubernetes/kubernetes/pull/43824 بدلاً من ذلك. على الرغم من أن الأمر أكثر تعقيدًا بعض الشيء ، إلا أنه يحافظ على مسار الكود هذا بحيث يتمكن المستخدمون من تكوين CNI مسبقًا خارج استخدام Daemonset (أفعل ذلك في https://github.com/jbeda/kubeadm-gce-tf على الرغم من أنني لم أقم بذلك تحديثه إلى 1.6) لا يزال ينتظر حتى تصبح العقد جاهزة.

على سبيل المكافأة، وهذا هوkensimon الصورة الأولى PR إلى Kubernetes وكان قد انسحب توقف لاختبار هذه الاشياء. لكن لكي أكون صادقًا ، كلاهما عملي وأريد حقًا أن أراه ثابتًا. :)

آسف فاتني https://github.com/kubernetes/kubernetes/pull/43824. أنا سعيد أيضًا بأي منهما إذا كان كلاهما يعمل.

أنا سعيد أيضًا بأي منهما إذا كان كلاهما يعمل أيضًا

kensimon إنه يعمل بالنسبة لي ، عندما أقوم فقط بتعطيل KUBELET_NETWORK_ARGS خلال kubadm init . بفضل تعليماتك يمكنني التحقق من ذلك.

تم تأكيد webwurst لأنه يعمل عند تعطيل KUBELET_NETWORK_ARGS خلال kubadm init . اضطررت إلى إعادة تشغيل kube-dns حتى تتمكن من استلامها. الشيك من @ kensimon يعمل ، يحل نظام أسماء النطاقات.

على الرغم من أنني أوافق على أن هذا اختراق رهيب ، ومروع للغاية بالنسبة لمعظم الناس لمتابعة ، بالنظر إلى قنوات Slack.

يتم تقديم حل أفضل من خلال التصحيحات من @ kensimon أوmikedanese.

coeki كيف بالضبط قمت kubectl delete pod kube-dns-3913472980-l771x --namespace=kube-system والآن يبقى kube-dns معلقًا 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

لقد جربت إعادة تشغيل kube-dns كما هو موضح أعلاه ، ولكن لم تنجح. اي فكرة؟ أنا أموت على هذا ، أحاول تشغيل مجموعتنا مرة أخرى بعد فشل ترقية 1.6.0 هذا التحذير :(

patte لذا أنا فقط delete pods kube-dns-3913472980-3ljfx -n kube-system وبعد ذلك يأتي kube-dns مرة أخرى.

هل قمت بعد kubeadm init بإضافة KUBELET_NETWORK_ARGS ، مرة أخرى sudo systemctl daemon-reload && sudo systemctl restart kubelet.service تثبيت شبكة pod ، مثل weave أو calico؟ أضف ذلك أولاً ، يجب أن تكون قادرًا على تشغيله.

لقد جربت واختبرت على centos7 وفعلتها للتو على ubuntu / xenial ، لذا يجب أن تعمل.

لتلخيص ما فعلته:

إزالة 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 (مجموعة IP) لأنني في حالة متشرد.
استخدم مع رمز $ 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

يعمل معي ، على الرغم من أنه اختراق مروع ؛)

أنا مندهش حقًا من أن مجتمع تطوير kubernetes لم يقدم أي ETA لإصلاح رسمي. أعني أن هذا خطأ مروع يجب اكتشافه بسهولة أثناء اختبار الكود. نظرًا لأنه لم يتم ، على الأقل ، دفع 1.6.1 في أسرع وقت ممكن مع الإصلاح حتى يتوقف الناس عن اختراق مجموعاتهم والبدء في القيام بأشياء منتجة ؛). هل أنا مخطئ هنا؟

مرحبا جميعا،

لقد كنت مشتتًا قليلاً هذا الأسبوع ، وهذا خيط طويل مليء
kubeadm الأشياء أنا لا أعرف ذلك جيدًا. هل يمكن لأحد أن يلخص لي؟ أنا
أعتقد أنني فهمت جوهر الخطأ ، ولكن ما هي الحلول المقترحة و
ما الذي يجعلهم فظيعين؟

يوم الخميس ، 30 آذار (مارس) 2017 الساعة 8:13 صباحًا ، سيرجي بيزفيرخي < [email protected]

كتب:

أنا مندهش حقًا من أن مجتمع تطوير kubernetes لم يفعل ذلك
قدم أي ETA لإصلاح رسمي. أعني أن هذا خطأ فظيع
يجب أن يتم اكتشافه بسهولة أثناء اختبار الكود. منذ ذلك الحين لم يحدث ذلك ، في
على أقل تقدير ، يجب دفع 1.6.1 في أسرع وقت ممكن مع الإصلاح حتى يفعل الناس ذلك
توقف عن اختراق مجموعاتهم وابدأ في القيام بأشياء منتجة ؛). هل انا
خطأ هنا؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290442315 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AFVgVEoKuUf28VazmUApsnyfGhuAhZIqks5rq8aLgaJpZM4MtMRe
.

أدى التغيير في kubelet (# 43474) إلى بدء kubelet بشكل صحيح في الإبلاغ عن الشبكة غير جاهزة قبل تهيئة المكون الإضافي cni. أدى هذا إلى كسر بعض الأوامر التي كنا نعتمد عليها وتسبب في حدوث مأزق في تهيئة kubeadm master. لم نلاحظ ذلك لأن اختبارات kubeadm e2e قد تعطلت لبضعة أيام قبل هذا التغيير.

الإصلاحات المقترحة الحالية هي # 43824 و # 43835.

حسنًا ، هذا ما فهمته. التعشيق بين البرنامج المساعد للشبكة
الخروج واستعداد العقدة أمر مروع بعض الشيء في الوقت الحالي.

يوم الخميس ، 30 آذار (مارس) 2017 الساعة 8:28 صباحًا ، Mike Danese [email protected]
كتب:

تغيير في kubelet (# 43474
https://github.com/kubernetes/kubernetes/pull/43474 ) تسبب في kubelet إلى
ابدأ بشكل صحيح في الإبلاغ عن الشبكة غير جاهزة قبل أن يصبح البرنامج المساعد cni
مهيأ. هذا كسر بعض الأوامر التي كنا نعتمد عليها وتسببنا فيها
طريق مسدود في التهيئة الرئيسية kubeadm. لم نحصل عليه بسبب
تم كسر اختبارات 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. إنه تغيير أبسط ، لا أعتقد أنه يجب إجراء فحوصات e2e في مكانها ، وهناك تقارير تفيد بأن # 43824 لا تعمل حتى الآن. سأبذل قصارى جهدي لحل هذه المشكلة اليوم.

+1 لحلها اليوم حيث يتم إهدار الكثير من الجهود في التعامل مع الضمانات من الحل البديل.

لا أصدق أن أحداً لم يحاول فعلاً kubeadm 1.6.0 قبل إصدار 1.6.0 ....

و kubelet 1.5.6 + kubeadm 1.5.6 معطلة أيضًا ، /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 apt ...

تعلمت الكلمات اليوم "كسر خارج الصندوق".

ما زلت أفضل # 43835. إنه تغيير أبسط ، لا أعتقد أنه يجب إجراء فحوصات e2e في مكانها ، وهناك تقارير تفيد بأن # 43824 لا تعمل حتى الآن. سأبذل قصارى جهدي لحل هذه المشكلة اليوم.

أتفق مع مايك في هذا. # 43835 هو التغيير الأبسط ، ويمكن إجراء التحقق (إذا لزم الأمر) في مرحلة منفصلة.

thockin نحن بحاجة حقًا إلى شروط وحالة أكثر دقة للتواصل ، خاصة مع ho stNetwork: صحيح. يمكن أن تكون العقد جاهزة لبعض البودات ، ولكن ليس البعض الآخر.

لا يمكننا استخدام nodeNetworkUnavailable لأن ذلك خاص بموفري الخدمات السحابية. ربما نحتاج إلى طريقة أخرى ، أو طريقة تسمح للمجدول بالسماح لـ ho الحقيقية على العقد مع Net workReady: false ، أو جعل العيوب تعمل مع العقد غير الجاهزة. وعمل اختبارات kubeadm e2e :(

يوافق على. لقد تم تأخير المشكلة لأنه لم يكن لدي إجابات رائعة ،
لكننا نحتاج إلى الحصول على هذا في 1.7

يوم الخميس ، 30 آذار (مارس) 2017 الساعة 10:02 صباحًا ، إرسال Dan Williams [email protected]
كتب:

thockin https://github.com/thockin نحتاج حقًا إلى دقة أفضل
شروط وحالة الشبكات ، خاصة مع ho stNetwork: true.
يمكن أن تكون العقد جاهزة لبعض البودات ، ولكن ليس البعض الآخر.

لا يمكننا استخدام nodeNetworkUnavailable لأن ذلك خاص بالسحابة
مقدمي. ربما نحتاج إلى طريقة أخرى ، أو طريقة للمجدول
allow ho stNetwork: القرون workReady: false ، أو جعل
تعمل العيوب على العقد غير الجاهزة.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290475480 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AFVgVAaO9c76_R8me9PDo96AQ1ZrplMxks5rq-A1gaJpZM4MtMRe
.

thockin أي حل مفضل؟ يمكننا إما حظر استعداد العقدة ومعرفة من يستخدم IsNodeReady () كما فعلنا بالفعل ، أو يمكننا إضافة شرط عقدة آخر ثم إصلاح من يعرف كيف عدد بتات قاعدة الكود في مكان آخر لها. أو ربما هناك خيار آخر.

لا يمكننا استخدام nodeNetworkUnavailable لأن ذلك خاص بموفري الخدمات السحابية. ربما نحتاج إلى طريقة أخرى ، أو طريقة تسمح للمجدول بالسماح لـ ho الحقيقية على العقد مع Net workReady: false ، أو جعل العيوب تعمل مع العقد غير الجاهزة.

أعتقد أنه يمكن إصلاح المجدول لاحترام العيوب والتسامح ، بدلاً من استبعاد جميع العقد غير الجاهزة تمامًا.
سيتعين على شخص ما تطبيق التسامح على ho stNetwork: الكبسولات الحقيقية . لا أعرف من ولكن لا ينبغي أن يكون المجدول لأن جدول التدريس لفهم مواصفات البود يبدو كثيرًا جدًا.

/ سم مكعبdavidopp @ dchen1107

أيضًا ، بالنسبة لأي شخص جرب تصحيحاتي أو تصحيحات مايكل ويتم تعليقه على طائرة التحكم القادمة ، يبدو كما لو أن بناء kubeadm من master لا يعمل عند جعله يدير مجموعة v1.6.0 ، بسبب محاولة kubeadm تشغيل kube-apiserver باستخدام أرغس غير صالحة:

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

إذا كنت ترغب في اختبار تغييراتي أو تغييرات مايكل مقابل مجموعة v1.6.0 ، فاخترها مقابل v1.6.0 بدلاً من البناء فوق Master في الوقت الحالي.

yujuhong يقوم المجدول بالفعل بتطبيق التسامح تلقائيًا على

ليس لدي صورة واضحة لكل العيوب والجاهزية المكتوبة
الشبكة ، في هذه المرحلة. دان ، هل لديك نصف ساعة لكتابة ملف
الحالة الحالية ، حتى نتمكن من البدء في تفريقها؟ أعتقد أنك تعرف ذلك
أفضل. أشعر أن لدينا عددًا من المشكلات الدقيقة التي نواجهها للتو
مغطاة بطانية حتى الآن.

يوم الخميس ، 30 مارس 2017 الساعة 10:22 صباحًا ، كين سيمون إخطارات @
كتب:

yujuhong https://github.com/yujuhong المجدول بالفعل
يطبق التسامح تلقائيًا على البودات (انظر # 41414
https://github.com/kubernetes/kubernetes/pull/41414 ) ، يبدو هذا مثل ملف
حالة استخدام مماثلة بما فيه الكفاية

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290481017 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AFVgVMas2IP5X5YA0V5626UlGbaS98jtks5rq-TCgaJpZM4MtMRe
.

thockin يمكنني أن أفعل ذلك ، أين

هناك مشكلتان مرتبطتان ، هل يمكننا إعادة تسمية أحدهما ، ونشر
ملخص للوضع الحالي والذهاب من هناك؟

يوم الخميس ، 30 مارس 2017 الساعة 10:50 صباحًا ، Dan Williams [email protected]
كتب:

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 افتراضيًا ، لا يقوم Kubernetes بتطبيق أي تلطيخ تلقائيًا على العقد. لا يحترم المجدول الألوان التي تمت إضافتها بواسطة أنظمة النشر مثل kubeadm و kops وما إلى ذلك أو التي تمت إضافتها يدويًا بواسطة المستخدمين (وتحترم التفاوتات المقابلة التي تمت إضافتها إلى البودات).

في الإصدار 1.6 افتراضيًا ، يستبعد برنامج جدولة Kubernetes العقد من الاعتبار إذا كانت تُبلغ عن حالات عقدة معينة ، بما في ذلك عدم توفر الشبكة. رمز ذلك هنا . لا علاقة له بالتلوث - إنه مجرد النظر إلى حالة العقدة.

في 1.6 يمكنك تمكين ميزة ألفا التي تجعل Kubernetes الأساسية (NodeController) تضيف علامة NoExecute عندما يكون هناك NodeReady == "False" أو NodeReady == "غير معروف". سيؤدي هذا إلى طرد القرون التي تعمل على العقدة (إذا لم تتسامح مع التلوث) ومنع القرون الجديدة من الجدولة على العقدة (إذا لم تتسامح مع التلوث).

تتمثل الخطة طويلة المدى في نقل جميع منطق "كيفية تفاعل Kubernetes الأساسية مع ظروف العقدة ، فيما يتعلق بالجدولة والإخلاء" لاستخدام الملوثات والتفاوتات (على سبيل المثال # 42001). لكننا لم نصل إلى هناك بعد ولن نكون هناك لفترة من الوقت. لذلك ، على المدى القريب ، لا توجد طريقة لـ pod "للتسامح" مع NetworkUnavailable أو أي شرط آخر للعقدة قد تقرر إضافته.

إذا فهمت ما قاله davidopp بشكل صحيح ، فإن الوظيفة هي NodeReady ، والتي تُرجع الآن صواب أو خطأ أو غير معروف ، وتضع علامة على قائمة بما هو مطلوب. إذا كان بإمكانه إرجاع قائمة بالقيم التي لم تتحقق ، فيمكنك اختبارها مقابل ذلك.

في حالة kubeadm ، إذا كانت NetworkUnavailable هي الوحيدة. يمكن أن يعود kubeadm صحيحًا. هذا في الحالة التي لا نريد فيها تمرير المكون الإضافي Network / cni في kubeadm init time.

لأنني إذا فهمت جيدًا ، يتم تعيين التلوث والتسامح بناءً على هذه الوظيفة ، على الأقل بالنسبة لـ kubeadm.

صححني إذا كنت مخطئا ؛)

القفز إلى هذا الموضوع لأنني واجهت هذه المشكلة وهي مزعجة:

لماذا لا يصبح جاهزية الشبكة عيبًا يضيفه kubelet ويزيله بناءً على حالة الشبكة على العقدة؟
وبهذه الطريقة ، يمكن أن تكون العقدة "جاهزة" لجميع البودات التي تتسامح مع تلوث جاهزية الشبكة (تطبيقات شبكة البودات).

بالنسبة إلى كبسولات الشبكة المضيفة ، يمكن لوحدة التحكم في الدخول ضخ التسامح لتشويه استعداد شبكة الجراب.

أعتقد أن هذا يتوافق مع الخطة طويلة المدى في تعليق دافيدوب.

أعتقد أن هذا يتوافق مع الخطة طويلة المدى في تعليق دافيدوب.

نعم بالضبط. تتمثل الخطة طويلة المدى في وجود تلوث لكل حالة عقدة والتوقف عن وجود أي شيء داخلي في Kubernetes مع الانتباه إلى ظروف العقدة. بدأنا هذا العمل بميزة 1.6 ألفا التي ذكرتها.

أك. هل هناك سبب لعدم التبديل إلى التلطيخ في إصدار التصحيح v1.6؟

الكود الخاص بإضافة الصبغات تلقائيًا استنادًا إلى شروط العقدة ذهب للتو إلى alpha في 1.6. إنه ليس جاهزًا للاعتماد عليه. (وهو يتعامل فقط مع حالة استعداد العقدة حاليًا ، وليس الشبكة).

لذلك ، إذا فهمت بشكل صحيح ، في الوقت الحالي ، نظرًا لأن https://github.com/kubernetes/features/issues/166 يستغرق وقتًا أطول حتى نتمكن من تشويه توفر الشبكة بشكل صحيح ، يتعين علينا حل المشكلة. إذا تمكنا من دفع إصلاح في أسرع وقت ممكن لـ kubeadm ، مثل # 43835 ، مع تعليق لإصلاح ذلك باستخدام https://github.com/kubernetes/features/issues/166 ، فسيكون الكثير من الأشخاص سعداء.

davidopp أفترض أنك قصدت أن تقول " لا يعتمد عليها ". ما زلت أفتقد العلاقة بين الشرط التلقائي لتشويه المنطق الذي ذكرته مع تلوث kubelet لنشر kubelet مباشرة لمشاكل الشبكة.

نعم شكرا ، كان ذلك خطأ مطبعي ، تم إصلاحه الآن

نعم ، يمكن أن تجعل Kubelet تضيف الصبغة. قد لا يكون من المثالي أن يضيف Kubelet الصبغات لبعض شروط العقدة ويقوم NodeController بإضافتها لظروف العقدة الأخرى (هذا الأخير ضروري لأن السيد وحده يمكنه اكتشاف العقدة التي لا يمكن الوصول إليها) ، ولكن هذه مجرد حجة هندسة برمجيات ، وليس أي شيء أساسي. كانت خطتي تتمثل في أن تقوم NodeController بإضافة الملوثات لجميع حالات العقدة ولكن لا توجد متطلبات قوية للقيام بذلك بهذه الطريقة.

أك. في هذه الحالة ، تحتوي حالة العقدة الواحدة على العديد من السمات المرتبطة بها والتي قد لا تتمكن وحدة التحكم في العقدة من تمييزها.
mikedanese أشعر أن السلوك الحالي لـ kubeadm init مما أدى إلى وجود عقدة عاملة أمر جذاب. آمل ألا تكون متطلبات إضافة مرحلة validation مدفوعة بشكل أساسي بناءً على هذه المشكلة.
dcbwthockinyujuhong هل من أفكار حول استخدام التلويث لتمثيل مشكلات تكوين العقدة في kubelet؟

لاحظ أنه إذا كنت تريد أن يحل ملوثك الجديد محل التصفية التلقائية الحالية للعقد مع NetworkUnavailable ، فستحتاج إلى تعديل الوظيفة التي ذكرتها سابقًا (أي إزالتها من مجموعة الشروط التي تقوم بتصفية العقدة). لا أعرف ما هي الآثار الجانبية الأخرى التي ستكون لها ، حيث يمكن استخدام هذه الوظيفة في قوائم عقدة بخلاف المجدول.

هل هناك طريقة لتثبيت 1.5.6 والتي يجب أن تعمل على Ubuntu؟ إذا كان هناك ، هل يمكنك شرح كيفية القيام بذلك؟ شكرا!

لاحظ أنه إذا كنت تريد أن يحل ملوثك الجديد محل التصفية التلقائية الحالية للعقد مع NetworkUnavailable ، فستحتاج إلى تعديل الوظيفة التي ذكرتها سابقًا (أي إزالتها من مجموعة الشروط التي تقوم بتصفية العقدة). لا أعرف ما هي الآثار الجانبية الأخرى التي ستكون لها ، حيث يمكن استخدام هذه الوظيفة في قوائم عقدة بخلاف المجدول.

davidopp ، يجب أن نكون حذرين بشأن NetworkUnavailable مقابل NodeReady. هناك شرطان منفصلان يجب تنظيفهما حقًا:

nodeNetworkUnavailable - هذا خاص بالمسارات السحابية ، ووحدات التحكم في المسار السحابي هي الوحيدة التي تمسح هذا الشرط عند إعداد المسارات السحابية بين العقد. لا تريد مكونات الشبكة الإضافية التي تنشئ تراكبات أو التي لا تقوم بتوجيه L3 بين العقد أو تستخدم هذا الشرط. لا يتم إضافة هذا الشرط بواسطة أي مكون إضافي للشبكة ؛ تمت إضافته بواسطة kubelet على وجه التحديد عند تحديد GCE أو AWS كموفري خدمة السحابة. لا يؤثر على NodeReady لأنه حالة منفصلة.

NodeReady - يتأثر مباشرة بالمكونات الإضافية للشبكة (على سبيل المثال ، CNI أو kubenet أو أوقات التشغيل البعيدة مثل dockershim / CRI-O).

هناك ثلاث قضايا منفصلة يجب مراعاتها:

1. مسارات السحابة - إذا كانت البنية التحتية السحابية والمكوِّن الإضافي للشبكة تتطلب مسارات سحابية ، فإن نقص المسارات السحابية (على سبيل المثال ، NodeNetworkUnavailable = true) يحتاج إلى حظر مضيف جدولة الشبكة = بودات خاطئة
2. المكونات الإضافية للشبكة - إذا لم يكن البرنامج المساعد جاهزًا بعد ، فهذا يحتاج إلى حظر جدولة hostNetwork = pods false. هذا منفصل عن NodeNetworkUnavailable لأن المكون الإضافي قد لا يكون له تفاعل مباشر مع وحدة التحكم في التوجيهات لأنه لا يعتمد على المسارات السحابية. على سبيل المثال ، يمكن استخدام kubenet محليًا على العقدة إذا كان لديك شيء آخر (المسارات السحابية ، الفانيلا ، إلخ) لإعداد مسارات العقد.
3. hostNetwork = يجب أن تتجاهل البودات الحقيقية كل هذه الشروط وأن يتم جدولتها ، ولكنها تخضع لأي شروط أخرى قابلة للتطبيق (مساحة القرص ، إلخ)

NodeReady هو مجرد مطرقة كبيرة جدًا. أعتقد أننا ربما نريد شرطًا إضافيًا NetworkPluginReady لاستعداد البرنامج المساعد للشبكة (منفصل عن جاهزية المسارات السحابية!) ومن ثم علينا أن ننتقل إلى الأماكن التي تهتم:

وجدت عمل آخر حولها.

أثناء استمرار kubeadm في طباعة "[apiclient] تم تسجيل العقدة الأولى ، ولكنها ليست جاهزة بعد" ، قمت بنشر "kube-flannel.yml" الذي يقوم بتثبيت flanneld. وعمل دون تغيير ملفات التكوين.

1) kubeadm init --pod-network-cidr = 10.244.0.0 / 16 &
2) cp /etc/kubernetes/admin.conf ~ / .kube / config
3) kubectl application -f kube-flannel-rbac.yml (ضروري في kubeadm 1.6)
4) تطبيق kubectl -f kube-flannel.yaml
استخدم kube-flannel.yaml في https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml

يمكنني جعل العقدة الرئيسية "جاهزة". ولكن ، فشل kube-dns مع الرسالة ،

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"

بعد أن قمت بتغيير المكون الإضافي للشبكة إلى weave-net ، نجح الأمر.

dcbw لا أعرف ما يكفي عن المشكلة المحددة التي تمت مناقشتها في هذه المسألة لأخبرك بالضبط بما يجب القيام به. أردت فقط أن أشرح الوضع الحالي للعيوب وكيف يمكن تطبيقها هنا.

يرجى اختبار DEBS المصححة

يحتوي kubernetes-xenial-unstable الآن على إصدار مصحح 1.6.1-beta.0.5+d8a384c1c5e35d-00 والذي قمنا أنا و

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

تضمين التغريدة

هو الاتجاه العام الذي يمكن أن يعبر فيه التلوث عن كل شيء تقريبًا
يمكن ، وبالتالي هي أفضل من كل شيء؟

أوافق على أننا بحاجة إلى المزيد من الإشارات الدقيقة. ما زلنا بحاجة لفرز
التفاعل بين kubelet و net driver ووحدة التحكم السحابية وموفر السحابة
لفتح hostNetwork = pods false ، لكن hostNetwork = true يجب ألا يكون
منعت.

يوم الخميس ، 30 مارس 2017 الساعة 7:24 مساءً ، Dan Williams [email protected]
كتب:

لاحظ أنه إذا كنت تريد أن يحل لونك الجديد محل التلقائي الحالي
تصفية العقد مع NetworkUnavailable ، ستحتاج إلى تعديل ملف
الوظيفة التي ذكرتها سابقًا (أي إزالتها من مجموعة الشروط
التي تقوم بتصفية العقدة). أنا لا أعرف ما هي الآثار الجانبية الأخرى التي سوف
لأن هذه الوظيفة يمكن استخدامها في قوائم عقدة بخلاف ملفات
المجدول.

davidopp https://github.com/davidopp نحن بحاجة إلى توخي الحذر
NetworkUnavailable مقابل NodeReady. هناك شرطان منفصلان
يجب تنظيفها حقًا:

nodeNetworkUnavailable - هذا خاص بالمسارات السحابية ، والسحابة فقط
تمسح أجهزة التحكم في المسار هذا الشرط عندما يكون للطرق السحابية بين العقد
تم إنشاؤها. المكونات الإضافية للشبكة التي تنشئ تراكبات أو التي لا تفعل L3
التوجيه بين العقد لا تريد أو تستخدم هذا الشرط. هذا الشرط
لم تتم إضافته بواسطة أي مكون إضافي للشبكة ؛ تمت إضافته بواسطة kubelet على وجه التحديد عندما
يتم تحديد GCE أو AWS كموفري السحابة. لا يؤثر على NodeReady منذ ذلك الحين
إنها حالة منفصلة.

NodeReady - يتأثر مباشرة بالمكونات الإضافية للشبكة (على سبيل المثال ، CNI أو kubenet
أو أوقات التشغيل البعيدة مثل dockershim / CRI-O).

هناك ثلاث قضايا منفصلة يجب مراعاتها:

1. مسارات السحابة - إذا كانت البنية التحتية السحابية والمكوِّن الإضافي للشبكة
   تتطلب مسارات سحابية ، ثم نقص المسارات السحابية (على سبيل المثال ،
   NodeNetworkUnavailable = true) يحتاج إلى حظر جدولة hostNetwork = false
   القرون
2. المكونات الإضافية للشبكة - إذا لم يكن المكون الإضافي جاهزًا بعد ، فهذا يحتاج إلى
   جدولة كتلة hostNetwork = كبسولات زائفة
3. hostNetwork = يجب أن تتجاهل القرون الحقيقية كل هذه الشروط وتكون كذلك
   مجدول ، ولكن مع مراعاة أي شروط أخرى قابلة للتطبيق (مساحة القرص ، إلخ)

NodeReady هو مجرد مطرقة كبيرة جدًا. أنا أفكر أننا ربما نريد
شرط إضافي NetworkPluginReady لاستعداد البرنامج المساعد للشبكة
(منفصل عن جاهزية المسارات السحابية!) ومن ثم علينا أن نضع ذلك في الاعتبار
من خلال إلى الأماكن التي تهتم:

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290597988 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AFVgVGIn0CpVkcHd2SVaoRsp2RJNEgXFks5rrGPqgaJpZM4MtMRe
.

لأي شخص لا يزال يحاول الإصلاح المؤقت عن طريق إزالة خط تكوين kubelet 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
...

الجلسة الثانية (باستخدام Calico. قد يختلف اختيارك بالطبع):

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
...

هو الاتجاه العام الذي يمكن أن يعبر فيه التلوث عن كل شيء تقريبًا
يمكن ، وبالتالي هي أفضل من كل شيء؟

علم. ربما لا يمكننا التخلص من أي من شروط العقدة بسبب مخاوف التوافق مع الإصدارات السابقة ، ولكن يمكننا التخلص من كل المنطق في البرنامج الرئيسي الذي يتخذ الإجراءات بناءً عليها (مثل حظر الجدولة أو طرد البودات). إلى جانب جعل السلوك أكثر وضوحًا (لا حاجة إلى حفظ الشروط التي تمنع الجدولة ، والتي تسبب الإخلاء ، ومدة انتظار الإخلاء ، وما إلى ذلك) ، يمكن تكوين رد الفعل على الظروف على أساس كل حجرة.

اختبرت للتو debs من mikedanese و pipejakob ، هذه تعمل بشكل جيد.

تم اختباره على ubuntu / xenial:

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"}

اختبرت للتو debs من mikedanese و pipejakob ، ما زالت
[apiclient] Created API client, waiting for the control plane to become ready

لقد انتظرت حوالي خمس دقائق ، لكن لم يتغير شيء.
وبالأمس استمر في التكرار
[apiclient] First node has registered, but is not ready yet

TTI أعتقد أن المشكلة لا تزال بلا حل؟

تم الاختبار على Ubuntu 16.04:
إصدار kubeadm: version.Info {Major: "1"، Minor: "6+"، GitVersion: "v1.6.1-beta.0.5 + d8a384c1c5e35d"، GitCommit: "d8a384c1c5e35d5118f79808deb7bab41f3f7964" -03-31T04: 20: 36Z "، إصدار GoVersion:" go1.7.5 "، المترجم:" gc "، النظام الأساسي:" linux / amd64 "}

@ myqq0000 هل يمكنك نشر النسخة التي تستخدمها؟

kubeadm version

coeki أوه ، لقد نسيت ذلك. لقد قمت بالتحرير الآن ونشرت النسخة في تعليقي السابق. :)

mikedanese هل لديك أي خطة لتحديث centos yum repo؟ أم أنه تم نشره بالفعل في yum repo؟

لقد جربت للتو 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

mikedanese debs مصححة تعمل بالنسبة لي. شكرا لجميع العمل على هذا! :ابتسامة:

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 شكرا. إنهم يعملون من أجلي أيضًا مع مزود شبكة نسج.

هل هناك أي فرصة لبناء نفس الإصلاح لـ Centos أيضًا؟ يستخدم نظام البوابات الخاص بنا في الغالب السنتوس لقاعدة كتلة kubernetes. إذا كان لدي إصدار centos ، يمكنني أن أضمن تقريبًا. 100 جولة من kubeadm init كاختبار في اليوم.

mikedanese debs kubeadm أن المجموعة جاهزة ، لكن العقدة نفسها ليست كذلك.

يجب أن تصبح عقد @ squall0gd جاهزة عند تطبيق شبكة pod ، على سبيل المثال kubectl apply -f https://git.io/weave-kube-1.6

في بيئة الاختبار الخاصة بي (في المتشرد ، بناءً على آلات centos / 7) ، يتوقف kubeadm فقط. باستخدام الدعامة ، يمكنني رؤيتها وهي تحاول الاتصال بخادم kubelet على الخادم الرئيسي ، والقيام بحلقات إعادة المحاولة FUTEX_WAIT ، epoll_wait. لكن لا يوجد خط واحد ناتج من ouf منه.

فشل kubelet في البدء ، والذي يبدو أنه السبب.
(لكن لا يمكنني رؤية أسباب فشل kublet في البدء ..)

هل هذه هي مشكلة هذه القضية؟

أحصل على ثنائيات من http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 repo.
أحاول أيضًا تحديث الثنائيات من https://storage.googleapis.com/kubernetes-release/release/v1.6.0/bin/linux/amd64/ .

==> أين يمكنني الحصول على نسخة مصححة من kubeadm للاختبار؟ <==

ملاحظة: لقد عثرت على نسخة مصححة (مُطالب بها) من kubeadm المشار إليها في هذه المشكلة على https://github.com/kensimon/aws-quickstart/commit/9ae07f8d9de29c6cbca4624a61e78ab4fe69ebc4 (النسخة المصححة هي: https: // heptio-aws-quickstart- test.s3.amazonaws.com/heptio/kubernetes/ken-test/kubeadm) ، لكن هذا لا يعمل بالنسبة لي. لا يزال السلوك كما هو (لا يوجد ناتج على الإطلاق) ...

@ squall0gd هل يمكنك أن

thockindavidopp ، لذلك وفقًا لاقتراح تيم ، سأتولى أمر مشكلة حالية أو https: // github. com / kubernetes / kubernetes / issues / 43815 # issuecomment -290597988 بداخله.

إليك ما يبدو أنه يعمل بالنسبة لي باستخدام الريبو 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؟

تهدف شروط

لا يبدو kubeadm أنه تم اختباره في فرع التحرير:
https://k8s-testgrid.appspot.com/release-1.6-all

@ bgrant0607 يبدو أن اختبارات kubeadm e2e معطلة / غير وظيفية لمدة أسبوع تقريبًا حتى الإصدار 1.6 ، IIRC

تهدف شروط العقدة إلى توفير معلومات إضافية للبشر ، لفهم ما يجري ، مثل السبب والرسالة ووقت الانتقال.

@ bgrant0607 هل هي مخصصة بشكل أساسي للمعلومات البشرية ، أم أن هذا مجرد أثر جانبي سعيد؟ إذا كانت في المقام الأول للبشر ، فهل يجب استخدامها لجدولة القرارات كما هي حاليًا أم يجب أن نبتعد عن ذلك؟

تهدفdcbw Taints إلى أن تصبح 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 أن يكون

حسنًا ، على الرغم من أنك قد تجادل ، فلماذا لا تسميها؟

لكن dcbw @ هل وجدت موضوعًا أكثر ملاءمة لهذه المناقشة؟ لأن هذا يصبح مستودعًا لمشاكل النشر وليس حقًا جذر الأشياء.

أعلم ، لقد كنت جزءًا من عدم الوصول إلى المشكلة حقًا ، ونشر الاختراقات حولها :)

ولكن على أي حال ، يجب أن نناقش الأساسيات في مكان آخر ، والتأكد من وضع ETA عند الإصلاح هنا ، والمضي قدمًا.

لا تكون لاذع ، ولكن بشكل جيد :)

PS نعم @ bgrant0607 كان يجب علينا اختبار هذا أكثر
PS2 إذا رأيت هذا خطأ ، يمكنك إلقاء اللوم علي ؛)

coeki أود أيضًا إضافة طلب لإصدارات N-1 للاحتفاظ بها في rpm / deb repos. تنتهي جميع الإصدارات الرئيسية في النهاية بمشكلة أو مشكلتين. تجنب المشغلون منذ فترة طويلة إصدارات N.0 للإنتاج لهذا السبب بالذات. إنه يعمل بشكل جيد إذا تم ترك الإصدارات السابقة لفترة من الوقت. ولكن هذه المرة تمت إزالة 1.5.x تمامًا قبل أن يصبح 1.6 مستقرًا. هذا يضع المشغلين الذين لم يكونوا مستعدين جيدًا (النسخ المتطابق المحلي ، وما إلى ذلك) من إحراز تقدم أثناء حل المشكلة. غالبًا ما يمكن التعامل مع ألم إطلاق N + 1 الوعر عن طريق الاحتفاظ بـ N لفترة من الوقت.

@ kfox1111 البوابة مشكلة أيضًا .... نحن بحاجة إلى استراتيجية أفضل لذلك :)

لماذا حتى حذف الإصدارات القديمة على الإطلاق؟ يمكن أن يؤدي ذلك بسهولة إلى كسر أتمتة الأشخاص ومنع عمليات التثبيت القابلة للتكرار.

تهدف شروط العقدة إلى توفير معلومات إضافية للبشر ، لفهم ما يجري ، مثل السبب والرسالة ووقت الانتقال.

متفق. تعد تجربة المستخدم بالتأكيد سببًا رئيسيًا لعدم قدرتنا على التخلص من حالات العقد. ومع ذلك ، أعتقد أنه يمكننا التخلص من جميع استخدامات شروط العقدة كمحفز للإجراءات الرئيسية (مثل الإخلاء وحظر الجدولة) ، واستخدام التلويث لذلك بدلاً من ذلك.

على المدى الطويل (مثل v2 API طويل المدى) ، من الممكن أن نضيف سببًا ورسالة إلى التلوث ثم نتخلص من شروط العقدة ، لكنني لم أفكر في الأمر حقًا ، وبالتأكيد لا أقترح رسميًا القيام بذلك. (لدينا بالفعل ما يعادل وقت الانتقال في اتجاه واحد ، وهو الوقت المضاف.)

coeki لا ، ما كنت أتحدث عنه لا علاقة له بالبوابة. لا يمكن للبوابة العثور على جميع المشاكل إلا إذا كان لديك بوابة تختبر كل ما يمكن القيام به. يحب المشغلون القيام بأشياء غريبة في بيئاتهم. :) مكلفة للغاية لاختبار كل الأشياء الممكنة.

أطلب عدم حذف الإصدار القديم قبل أن يصل الإصدار الجديد إلى الإصدار الأول على الأقل. في هذا المثال ، 1.6.1. على الأقل. يعد الاحتفاظ بالمزيد من الإصدارات القديمة أفضل. هذه هي أفضل ممارسة للسماح للمشغلين بمواصلة إحراز تقدم أثناء معالجة الأخطاء في الإصدار الجديد.

@ kfox1111 ، هذا ما يفعله يتماشى مع شيء يبدو جيدًا ،

davidopp أوافق على أن الملصقات والتلوث قد يكون لها تمييز مختلف عن طريقة api للنظر إليها ، UX والآلات ، لكنها منتشرة الآن. أنا أيضًا ، هذا هو :)

على أي حال ، لقد استدرجتني إلى مناقشة ، لم يكن لدينا حقًا في هذه المسألة ، كانت هذه وجهة نظري.

أود أن أسأل مرة أخرى: إذا رأيت "kubeadm init" معلقة هناك بدون إخراج (محاولة الاتصال بخادم kubelet ، الذي فشل في البدء) ، هل أعاني من هذه المشكلة؟ وإذا كانت هذه حالة ، فهل يعد # 43835 حلًا لي؟

الآن أين يمكنني الحصول على:

• إما الإصدارات الأقدم (ما قبل 1.6.0) من kubeadm / kubectl / kubelet
• أو نسخة مصححة من kubeadm (بما في ذلك # 43835 أو أي إصلاح آخر)؟

شكرا!

(ملاحظة: نسخة مصححة من kubeadm المشار إليها في ذكر تلتزم أعلاه لا يعمل بالنسبة لي ...)

obnoxxx جرب غيض من فرع الإصدار 1.6.

$ 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

mikedanese شكرا! محاولة...

إذا قمت بتشغيل 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

mikedanese شكرا. أقوم بتثبيت حزمة نظام التشغيل (من kube repo) ثم أقوم بتثبيت الثنائيات من عنوان url للويب على الثنائيات من rpms ...

لم النسخة 1.6.1-beta.0.12 لا تعمل بالنسبة لي على الرغم من:
لا يزال kubeadm init معلقًا بدون أي إخراج. (محاولة الاتصال بـ kubelet)

لا تنس برنامج تشغيل systemd أيضًا إذا كان centos.

سائق النظام؟

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

يا إلهي ، هذا أفضل! :-)

pipejakob لا يمكنني الوصول إلى هذه السجلات في الوقت الحالي ، لكنني تحققت من إصدار kubeadm وكان نفس الإصدار الذي حصلت عليه webwurst . علاوة على ذلك ، لقد تحققت من الإصدارات الممكنة kubeadm مع apt-cache policy kubeadm . وكان هناك إدخال واحد فقط - من kubernetes-xenial-unstable.
mikedanese لقد حاولت مع الفانيلا قبل النشر ؛)
تحرير: لقد أعدت بناء النظام الأساسي بالكامل و kubadm يعمل بشكل جيد: +1:

يا رفاق ما هو الوضع الراهن للإصلاح؟ هل سينتقل إلى المستودع الثابت في أي وقت قريبًا؟

mikedanese مصححة debs تقوم بنفس الشيء "المكون الإضافي للشبكة غير جاهز".

هل يمكن لأي شخص إخباري بكيفية إنشاء نسخة مصححة من kubeadm لـ rhel (rpm)؟

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 ربما تحتاج إلى تكوين kube-proxy للتشغيل في مساحة المستخدمين. كانت هذه مشكلة في 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. يمكنني إحضار برنامج Kubernetes الرئيسي ولكن يمكنني أيضًا توصيل عامل واحد به باستخدام kubeadm Join. سننشر المزيد من التحديثات قريبا

mikedanese استغرق الأمر مني إلى الأبد لمعرفة الإصدار الذي يجب استخدامه ، حتى قرأت جميع التعليقات هنا. نحتاج حقًا إلى تسهيل العثور على الثنائيات لإصدار معين. لقد حاولت استخدام ما هو ci-cross/latest.txt نقطة (أي v1.7.0-alpha.0.1982+70684584beeb0c ) ، وحدث ذلك لإدخال علم جديد kube-apiserver (أي --proxy-client-key-file في d8be13fee85075abfc087632b3dbc586a10897ad) ، والذي لا يعمل مع أي من علامات recents في gcr.io/google_containers/kube-apiserver-amd64 ...

كيف يمكننا تسهيل معرفة المراجعات التي تحتوي على ثنائيات في المجموعة؟ سيكون من الجيد أن تكون قادرًا على سرد الدلائل ، أو أن يكون لديك ملف خريطة بسيط أو أي شيء لا يتطلب معرفته أو الاضطرار إلى التخمين.

errordeveloper ، نحاول إصدار إصدار حتى نتمكن من دفع الإصلاح إلى الفرع المستقر ، ويجب أن يتم ذلك في O (أيام) على ما آمل. هناك ارتباط في وصف هذه المشكلة إلى debs المصححة في حالة غير مستقرة.

كان الإصدار السابق 1.5.6 يعمل معي على CentOs 7 ولكن الآن لا يمكنني التراجع لأن الإصدار الوحيد من kubeadm في http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 هو الإصدار 1.6 المكسور. 0. أي اقتراحات حول كيفية الحصول على kubeadm 1.5.6 RPM؟

في الواقع ، إنه أمر مؤسف. يبدو أن الإصدارات القديمة قد أزيلت بالكامل. :-(

نتائجي هي هذه على centos 7:

• لم أتمكن من الحصول على kubadm init لإعطائي أي نتيجة على الإطلاق ، حتى مع أحدث kubeadm مصحح ، دون القيام بشيء بخصوص kubectl.
• لقد تمكنت من بدء kubectl بتعليمات coeki ، ثم مرت kubeadm. لكن بعد ذلك ، لا شيء يعمل معي. يقول kubectl

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 الخاص بك قادرًا على الاتصال بـ apiserver بشكل صحيح. HTH. سيرجي

apsinha هل أنت على علم بهذا الموضوع؟ قد يكون من الجيد أن يكون لديك بعض الأشخاص الذين يتبعون المنتج ، حيث أعتقد أنه سيكون هناك بعض الوجبات السريعة المهمة في المستقبل.

من فوق رأسي:

• 1.6.0 لم يخضع للاختبار الآلي مطلقًا: https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290809481
• تمت إزالة الثنائيات / الحزم للإصدارات الأقدم ، لذلك لا يمكن للأشخاص التراجع بأمان ؛ كسر أي أتمتة للتثبيت كانت تفترض استمرار توفرها: https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290861903
• لا يوجد إعلان عام (رأيته) عن حقيقة أن هذا مكسور
• لم يتم تقديم مخطط زمني للإصلاح (أنا مطور ، لذا فأنا أعرف مدى البغيضة التي يُسأل عنها "متى سيتم إصلاحه؟" ، ولكن مع ذلك ، سيسأل الناس هذا ، لذلك من الجيد على الأقل تقديم فترة زمنية مقدرة)
• استمر المستخدمون في الانضمام إلى المحادثة في حيرة من أمرهم بشأن حالة الأشياء والحلول البديلة وجدول الإصلاح
• الكثير من المناقشات الفنية بين المساهمين ، الكثير منها حول الإستراتيجية طويلة المدى ، مجتمعة في نفس سلسلة المحادثات حيث يحاول المستخدمون معرفة ما يحدث وكيفية التعامل مع المشكلة الفورية

لا قصد من عدم الاحترام جميع الأشخاص العظماء الذين يجعلون Kubernetes على ما هو عليه. أنا فقط آمل أن تكون هناك بعض "اللحظات القابلة للتعليم" هنا للمضي قدمًا ، حيث يبدو هذا سيئًا من حيث التصور العام عن Kubernetes كونها موثوقة / مستقرة. (kubeadm الممنوح هو alpha / beta ، لكنه لا يزال يتمتع بالكثير من الرؤية.)

لقد قمت ببناء kubeadm-1.5.6 باستخدام kubernetes / release.rpm فقط لأجد (يثير دهشتي) ذلك

# 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. نظرًا لبعض الإصدارات الغريبة من kubeadm وكيفية فرز هذه الأشياء أبجديًا ، يبدو أنه لم يكن من الممكن الاحتفاظ بالإصدار 1.5.x من kubeadm في الريبو. ( bostone يتم الإشارة إلى مشكلتك هناك أيضًا)
2. اختبار kubeadm e2e على العلاقات العامة التي يتم تتبعها هنا: https://github.com/kubernetes/kubeadm/issues/190
3. بالنسبة للإعلان العام - لقد نشرت على تويتر ولكن هذا ليس رسميًا. ليس من الواضح ما هي القنوات الصحيحة لقضايا حرجة مثل هذا.

هذه كلها قضايا جيدة يجب طرحها في رئيس الوزراء. لقد تطوعت pipejakob عن طيب خاطر لجمع هذا التشريح معًا.

obnoxxx كان شرط نسخ / chown admin.conf ضروريًا من قبل لأنه مع 1.5 كان لدينا خادم API يعرض منفذًا غير آمن. لقد غيرنا ذلك في 1.6. الآن يجب عليك استخدام بيانات اعتماد آمنة للوصول إلى خادم واجهة برمجة التطبيقات (راجع https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#kubeadm-2)

mikedanese هذا يبدو رائعًا ، شكرًا!
بالنسبة إلى الدمية التي أنا عليها فقط - ما هو تأثير هذا الإصدار 1.6.1 فيما يتعلق بهذه المشكلة؟
هل سيبدأ kubelet بدون التغيير إلى /etc/systemd/system/kubelet.service.d/10-kubeadm.conf (الحل البديل لـ coeki ) أم أنه سيحتوي على إصلاح # 43835 (الذي يبدو أنه ليس له أي تأثير بالنسبة لي)؟

jbeda شكرا على الشرح!

jbeda أعتقد أن الالتباس يأتي من إعداد مستند تثبيت kubadm الرسمي من إعداد YUM repo إلى 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 هل اختبرت kubeadm قبل إغلاق هذا الخطأ؟ الآن أنا أحدق في [apiclient] Created API client, waiting for the control plane to become ready لمدة 10 دقائق بالفعل. على CentOS 7 مع تثبيت جديد تمامًا 1.6.1

bostone ربما تكون قد

حاول تحرير /etc/systemd/system/kubelet.service.d/10-kubeadm.conf وإضافة --cgroup-driver=systemd

تذكر تشغيل systemctl daemon-reload; systemctl restart kubelet

gtirloni مع اقتراحنا وصلت إلى نهاية kubeadm init ولكن أي محاولة لتشغيل kubectl ينتج عنها هذا الخطأ: The connection to the server localhost:8080 was refused - did you specify the right host or port? لست متأكدًا من مكان وكيفية تغيير ذلك أو ما هو المنفذ الصحيح في هذه النقطة؟

لست متأكدًا مما إذا كان هذا مرتبطًا ولكن هذا ما أراه عند تشغيل systemctl status kubelet :
"" systemctl status kubelet -l
● kubelet.service - kubelet: وكيل عقدة Kubernetes
مُحمَّل: مُحمَّل (/etc/systemd/system/kubelet.service ؛ مُمكّن ؛ الإعداد المسبق للمورد: معطل)
إسقاط في: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf
نشط: نشط (قيد التشغيل) منذ الاثنين 2017-04-03 17:31:07 بتوقيت المحيط الهادئ الصيفي ؛ قبل 11 دقيقة
المستندات: http://kubernetes.io/docs/
PID الرئيسي: 10382 (kubelet)
CGroup: /system.slice/kubelet.service
├─10382 / usr / bin / kubelet --kubeconfig = / etc / kubernetes / kubelet.conf --require-kubeconfig = true --pod-manifest-path = / etc / kubernetes / manifests --allow -ivileged = true - -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 جريدة ctl -k -f

03 أبريل 17:41:56 sdl02269 kubelet [10382]: W0403 17: 41: 56.645299 10382 cni.go: 157] تعذر تحديث تكوين cni: لم يتم العثور على شبكات في /etc/cni/net.d
03 أبريل 17:41:56 sdl02269 kubelet [10382]: E0403 17: 41: 56.645407 10382 kubelet.go: 2067] شبكة وقت تشغيل الحاوية غير جاهزة: NetworkReady = سبب خاطئ message: docker : network plugin not ready: 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 الموضحة هنا . يبدو أن هذا مرتبط بخطأ تكوين cni الذي تحصل عليه.

يحدق أيضًا في [apiclient] عميل API الذي تم إنشاؤه ، في انتظار أن تصبح طائرة التحكم جاهزة لمدة 10 دقائق بالفعل مع Ubuntu 16.04 وتثبيت جديد لـ 1.6.1

pingthings أوصي بالانضمام إلى Slack Kubernetes وقناة kubeadm . يمكننا مساعدتك في التصحيح هناك.

لقد نجحت في إعداد مجموعة Kubernetes الخاصة بي على centos-release-7-3.1611.el7.centos.x86_64 باتباع الخطوات التالية (أفترض أن Docker مثبت بالفعل):

1) (من /etc/yum.repo.d/kubernetes.repo) baseurl = http: //yum.kubernetes.io/repos/kubernetes-el7-x86_64-unstable
=> لاستخدام المستودع غير المستقر لأحدث إصدار من Kubernetes 1.6.1
2) yum install -y kubelet kubeadm kubectl kubernetes-cni
3) (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) أضف "--cgroup-driver = systemd" في نهاية السطر الأخير.
=> هذا لأن Docker يستخدم systemd لبرنامج cgroup-driver بينما يستخدم kubelet cgroupfs لمحرك cgroup.
4) يمكّن systemctl kubelet && systemctl start kubelet
5) kubeadm init --pod-network-cidr 10.244.0.0/16
=> إذا كنت تستخدم لإضافة عناوين --api-advertise-، فستحتاج إلى استخدام --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 -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml
=> 1.6.0 يقدم عنصر تحكم في الوصول يستند إلى الدور ، لذا يجب عليك إضافة ClusterRole و ClusterRoleBinding قبل إنشاء مجموعة Flannel daemonset
8) إنشاء kubectl -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
=> أنشئ مجموعة شيطان من الفانيلا
9) (على كل عقدة تابعة) kubeadm Join --token (your token) (ip) :( المنفذ)
=> كما هو موضح في نتيجة kubeadm init

كل الخطوات المذكورة أعلاه هي نتيجة الجمع بين الاقتراحات من مختلف القضايا حول Kubernetes-1.6.0 ، وخاصة kubeadm.

أتمنى أن هذا سيوفر وقتك.

يبدو أن هذا لم يتم حله (Ubuntu LTS ، kubeadm 1.6.1).

أولاً ، جربت أيضًا تعليق kubeadm على "عميل واجهة برمجة التطبيقات المُنشأ ، في انتظار أن يصبح مستوى التحكم جاهزًا" عند استخدام --apiserver-advertise-address flag .. تذكر سجلات دفتر اليومية:

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

إذا لم أقدم هذا العلم ، فإن kubeadm يمر ، ولكن حتى ذلك الحين أحصل على الخطأ التالي لبدء kubelet:

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

يرفض Kubelet البدء بشكل صحيح ، ولا يمكنني الاتصال بالعنقود بـ kubectl بأي شكل من الأشكال

يبدو أنه تمت إزالة إصدارات 1.5.x kubeadm ليس فقط من مستودع سنتوس ، ولكن أيضًا من Ubuntu LTS: https://packages.cloud.google.com/apt/dists/kubernetes-xenial/main/binary-amd64/Packages It يجعل من الصعب الرجوع إلى إصدار أقدم ، ويؤدي في الواقع إلى تعطيل التوافق مع الإصدارات السابقة

تضمين التغريدة

هل اكتشفت تعليق "انتظار طائرة التحكم لتصبح جاهزة"؟ أرى نفس الشيء بعد تجربة كل التغييرات مع 1.6.1.

gtirlonisrzjulio إضافة هذه الخطوات بعد kubeadm init لم المساعدة. لقد قامت بالفعل بتغيير خدمة kubelet من failed إلى active (running) لكن لا يزال لدي رسالة The connection to the server localhost:8080 was refused - did you specify the right host or port? . وإذا نظرت إلى خدمات الاستماع ، لا يمكنني رؤية 8080 في أي مكان. ما يمكنني رؤيته هو أن kubelet يستمع عبر هذه المنافذ:

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 ليس منفذ kubelet الذي تحتاجه ، إنه kube-apiserver ، يجب أن يستمع على منفذ 6443.

sbezverk لم إعدادات افتراضية فيما يتعلق بالمنافذ (ليس في أي تعليمات) ماذا علي أن أفعل للتبديل من 8080 إلى 6443؟

bostone إذا لم تقم بتعديل أي شيء في بيان apiserver ، فسيتم الاستماع إليه افتراضيًا على منفذ 6443. ما عليك سوى نسخ /etc/kubernetes/admin.conf إلى $ HOME / .kube / config وتغيير الأذونات في ملف التكوين ويجب أن تكون جاهزًا.

sbezverk راجع للشغل - أقوم بتشغيل جميع خطوات التثبيت كجذر ولكن سطور التعليمات الثلاثة هذه من إخراج kubeadm init تقترح استخدام مستخدم sudo. ما هي التوصية في هذا؟ هل يجب تشغيل جميع خطوات التثبيت على أنها 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.

جرب "kubectl application -f https://git.io/weave-kube-1.6 "

في الثلاثاء 4 أبريل 2017 الساعة 12:24 ظهرًا ، كتب Bo Stone [email protected] :

حسنًا ، لقد قمت بكل الخطوات من البداية ويبدو أنها أفضل. هنا
الخطوات التي نجحت معي حتى الآن وأنا أعمل كجذر.

قطة <

[kubernetes]
الاسم = Kubernetes
baseurl = http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
تمكين = 1
gpgcheck = 1
repo_gpgcheck = 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
EOF

setenforce 0

yum install -y عامل إرساء kubelet kubeadm kubectl kubernetes-cni

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

إضافة -cgroup-driver = systemd إلى 10-kubeadm.conf وحفظه

يمكّن systemctl docker && systemctl start docker

يمكّن systemctl kubelet && systemctl start kubelet

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

توقف جدار الحماية systemctl ؛ systemctl تعطيل جدار الحماية

الحرف الأول kubeadm

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

في هذه المرحلة ، يمكنني تشغيل kubectl للحصول على العقد ورؤية العقدة الرئيسية الخاصة بي في ملف
قائمة.
كرر جميع الخطوات مع العميل باستثناء بالطبع تشغيل kubeadm Join
--token a21234.c7abc2f82e2219fd 12.34.567.89:6443 كما تم إنشاؤه بواسطة kubeadm
فيه
تكتمل هذه الخطوة ويمكنني رؤية العقد الرئيسية والتابعين

والآن - المشكلة:

kubectl الحصول على العقد

اسم النسخة العمرية
abc02918 NotReady 42m v1.6.1
abc04576 NotReady 29m v1.6.1

تصف kubectl العقدة abc02918

الأحداث:
FirstSeen LastSeen Count من SubObjectPath Type Reason Message
--------- -------- ----- ------------- -------- - - -------
43m 43m 1 kubelet، sdl02918 بدء عادي kubelet.
43m 43m 1 kubelet ، sdl02918 تحذير ImageGC فشل في العثور على بيانات للحاوية /
43m 43m 29 kubelet، sdl02918 Normal NodeHasSufficientDisk Node sdl02918 الحالة الآن: NodeHasSufficientDisk
43m 43m 29 kubelet، sdl02918 العقدة العادية
43m 43m 29 kubelet، sdl02918 Normal NodeHasNoDiskPressure Node sdl02918 الحالة الآن: NodeHasNoDiskPressure
42m 42m 1 kube-proxy ، sdl02918 بدء عادي بدء kube-proxy.

لذلك يبدو أن العقد لم تصبح جاهزة أبدًا. أي اقتراحات؟

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-291571437 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAeJQ6OFBV3s6OHmfOkUdwqQsJ1sjg23ks5rsnzMgaJpZM4MtMRe
.

باستخدام إصدار CentOS و 1.6.1-1 من kubeadm ، واتباع الخطوات المذكورة أعلاه ، أحصل على سلوك مختلف قليلاً: تم الإبلاغ عن الكتلة على أنها جاهزة ولكن بعد ذلك أعلق في هذه الرسالة:

[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 لقد اتبعت نفس الوصفة التي استخدمتها ، لكنني حصلت على نتائج مختلفة - لم أتجاوز kubeadm init. ما هو إصدار عامل الميناء الذي تستخدمه؟ ربما هذا هو الفرق في حالتي؟

dcowden إنه أي شيء نظامي Docker version 1.12.6, build 96d83a5/1.12.6 . ما ساعدني أيضًا هو إعادة توفير جميع الأجهزة الافتراضية التي كنت أستخدمها بدلاً من محاولة الإصلاح فوق عمليات التثبيت السابقة الخاصة بي

bostone شكرا. سأقوم بالرجوع إلى هذا الإصدار لمعرفة ما إذا كان بإمكاني الحصول على إعداد عمل. على نظامي ، الأحدث هو إصدار غريب 17.03.1.ce (من الواضح أنه الأحدث)

لست متأكدًا مما إذا كان مفيدًا بشكل عام ، لكن لدي كتاب قواعد اللعبة
يقوم بجميع خطوات CentOS 7

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

YMMV ، لكنه على الأقل يوثق العملية. أنا أيضا أفعل بعض الأشياء مثل
قم بتبديل عامل الإرساء لاستخدام تسجيل ملفات json وتخزين التراكب.

قد يكون مفيدًا كمرجع حتى لو لم تقم بالفعل بتشغيل كتيب اللعبة.

يوم الثلاثاء 4 أبريل 2017 الساعة 12:55 مساءً ، ديف كاودن [email protected]
كتب:

bostone https://github.com/bostone شكرا. سوف أنزل إلى ذلك
الإصدار لمعرفة ما إذا كان بإمكاني الحصول على إعداد عمل. على نظامي الأحدث هو
إصدار غريب 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 على السيد والعميل وإعادة تشغيل Docker and kubelet services kubeadm init توقف على Created API client, waiting for the control plane to become ready مرة أخرى. هل يمكن لأي شخص تقديم خطوات كاملة لإعادة تعيين kubeadm؟
sjenning هل حاولت إعادة تشغيل

bostone في حالتي نقل /var/lib/etcd/ هو الذي أدي الحيلة.

autostatic ، كان الدليل فارغًا ولم تساعد إعادة تسميته. sjenning توقف كتاب اللعب ، لقد أنشأت تذكرة لك

هل حاول أي شخص تشغيل لوحة القيادة على v1.6.1؟ أتلقى خطأ ينص على ما يلي:

"ممنوع (403)

المستخدم " system: serviceaccount : kube- system: default " لا يمكنه سرد مساحات الأسماء في نطاق الكتلة. (الحصول على مساحات الأسماء)
"

أظن أنني بحاجة إلى تكوين المزيد من RBAC ، كما هو الحال بالنسبة لك لتشغيل Flannel؟

srzjulio هل يمكنك تقديم إصدار جديد لذلك؟ أعتقد أن هذا شيء يجب أن يعمل عليه SIG Auth وفريق Dashboard معًا. ربما يكون تغيير YAML بسيطًا.

srzjulio تحتاج إلى تحديث قواعد RBAC ، لقد استخدمناها

الإصدار: rbac.authorization.k8s.io/v1alpha1
النوع: ClusterRoleBinding
البيانات الوصفية:
الاسم: مدير الكتلة
الدور
apiGroup: rbac.authorization.k8s.io
النوع: ClusterRole
الاسم: مدير الكتلة
المواضيع:

• النوع: المجموعة
  الاسم: النظام: الماجستير
• النوع: المجموعة
  الاسم: النظام: موثق
• النوع: المجموعة
  الاسم: النظام: غير مصدق

كن حذرًا - الارتباط الذي يحتويهsbezverk هو في الأساس إيقاف تشغيل RBAC. سيكون لديك كتلة غير آمنة للغاية إذا قمت بذلك.

kind: Group
name: system:unauthenticated

هذا سيء بشكل خاص. هذا يعني أن أي شخص يمكنه الاتصال بخادم API الخاص بك ، حتى بدون أي بيانات اعتماد ، يمكنه تشغيل أوامر عشوائية.

jbeda يتطابق مع السلوك الذي كان لدينا مع 1.5.6 مباشرة خارج الصندوق. إنه يمنح الأشخاص فرصة لمراجعة تكوين الأمان وتعديله تدريجيًا بدلاً من عدم القدرة على فعل أي شيء بقواعد الأمان الجديدة.

في الواقع ، جعل النظام: مدير الكتلة الذي لم

إذا كنت لا تريد الحصول على إذن ، فاستخدم المصادقة AlwaysAllow

إذا كنت تريد السماح للكل أثناء قيامك بالتدقيق ، فاستخدم مزيجًا من RBAC ، AlwaysAllow

سيؤدي ذلك إلى تعطيل الطلبات المجهولة ، وتسجيل عمليات رفض RBAC في سجل خادم واجهة برمجة التطبيقات ، مع الاستمرار في السماح لجميع الطلبات المصادق عليها بالقيام بكل ما يريدون

عذرًا ، وأكرر هذا مرة أخرى ، فهذا لا علاقة له بالمشكلة الأصلية. وعلى الرغم من المشكلات والقضايا الصحيحة ، يجب علينا نقل المحادثة إلى مكان آخر.

آسف مرة أخرى ، اضغط على مفتاح الإدخال في وقت مبكر جدًا ، ولكن كما هو الحال:

1 - الإصدار 1.6.0 يسبب مشاكل
2 - ليست كلها ثابتة
3 - الانتقال إلى RBAC (حسن في رأيي) ولكن مشكلة ، لماذا؟ انظر النقطة 4
4 - لم يتم توصيل هذا بشكل جيد ، وليس هناك الكثير من المستندات / المدونات أو أي شيء آخر لشرح ذلك
5 - أنحني لجميع الأشخاص الذين يحاولون الإنقاذ ، لكننا بحاجة إلى طريقة أفضل للقيام بذلك

https://kubernetes.io/docs/admin/authorization/rbac/#service -account-أذونات هو دليل جيد لأكثر الخيارات دقة المتاحة أمامك لفتح الأذونات.

تؤدي إضافة " --cgroup-driver = systemd " في kublet إلى حدوث مشكلة جديدة في Centos / RHEL 7.3 (محدث بالكامل - ويعرف أيضًا باسم Docker 1.10.3):

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"

بينما يمكننا أن نرى بوضوح أن native.cgroupdriver = systemd تم تعيينه في

 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 تعمل بالكامل مع الفانيلا. كل شيء الآن في قواعد اللعبة.
تم اختباره على Centos / RHEL. بدأت الاستعدادات لـ Debian المستندة أيضًا (مثل Ubuntu) ، ولكن قد تحتاج إلى بعض التنقية.

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

ملاحظة: العمل على أساس sjenning / kubeadm-playbook - شكرا جزيلا sjenning !

تضمين التغريدة
مرحبًا ، لدي كتاب لعب متشرد + لا يمكن إصلاحه [0] يشبه إلى حد بعيد ما قمت بإنشائه ، لكنني ما زلت غير قادر على تشغيله ، وأعتقد أنه فشل في إعداد الشبكات. لقد جربت استخدام كاليكو ، ونسج ، وفانيلا ، وفشل الثلاثة جميعًا (على الرغم من ظهور أعراض مختلفة).

أنا أقوم بتشغيل هذه الإصدارات:
[ المتشرد @ سيد ~] عامل عامل - نسخة
إصدار Docker 1.12.6 ، النسخة 3a094bd / 1.12.6
[ المتشرد @ سيد ~] $ kubelet - الإصدار
Kubernetes v1.6.1
[ المتشرد @ سيد ~] نسخة $ kubeadm
إصدار kubeadm: version.Info {Major: "1"، Minor: "6"، GitVersion: "v1.6.1"، GitCommit: "b0b7a323cc5a4a2019b2e9520c21c7830b7f708e"، GitTreeState: "clean"، BuildDate: "33-04-03T20 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

أي مساعدة سيكون موضع تقدير كبير ...

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

لم أتمكن من تحديد ما هو الخطأ من جانبك.
أقترح بشدة محاولة إنشاء تثبيت منفصل باستخدام قواعد اللعبة هنا: https://github.com/ReSearchITEng/kubeadm-playbook ومحاولة معرفة الفرق.
ملاحظة: اختباراتي الأخيرة مع 1.6.2 ، كل من kube * والصور ويبدو أنها جيدة.

تضمين التغريدة

ReSearchITEng آسف لقد نسيت الإبلاغ مرة أخرى ، لكنني في النهاية نجحت في العمل ، ملفاتي المتشرد + ansible موجودة هنا: https://github.com/thiagodasilva/kubernetes-swift

حصلت أيضًا على نفس المشكلة ، لكنني قمت فقط بنسخ تكوين cni على العقدة الرئيسية إلى الموقع المقابل للعقدة العاملة ، ثم أصبحت على ما يرام.

systemctl حالة kubelet.service -l

● kubelet.service - kubelet: وكيل عقدة Kubernetes
مُحمَّل: مُحمَّل (/etc/systemd/system/kubelet.service ؛ مُمكّن ؛ الإعداد المسبق للمورد: معطل)
إسقاط في: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf
نشط: نشط (قيد التشغيل) منذ الثلاثاء 2017-06-06 10:42:00 CST ؛ قبل 18 دقيقة
المستندات: http://kubernetes.io/docs/
معرف المريض الرئيسي: 4414 (كيوبليت)
الذاكرة: 43.0 م
CGroup: /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 - ترخيص -ca-file = / etc / kubernetes / pki / ca.crt --cgroup-driver = cgroupfs
مجلة └─4493 ctl -k -f

يونيو 06 10:59:46 contiv1.com kubelet [4414]: W0606 10: 59: 46.215827 4414 cni.go: 157] تعذر تحديث تكوين cni: لم يتم العثور على شبكات في /etc/cni/net.d
يونيو 06 10:59:46 contiv1.com kubelet [4414]: E0606 10: 59: 46.215972 4414 kubelet.go: 2067] شبكة وقت تشغيل الحاوية غير جاهزة: NetworkReady = رسالة استعداد خاطئة: docker: المكون الإضافي للشبكة غير جاهز: تكوين cni غير مهيأ
يونيو 06 10:59:51 kubelet [4414]: W0606 10: 59: 51.216843 4414 cni.go: 157] تعذر تحديث تكوين cni: لم يتم العثور على شبكات في /etc/cni/net.d
يونيو 06 10:59:51 contiv1.com kubelet [4414]: E0606 10: 59: 51.216942 4414 kubelet.go: 2067] شبكة وقت تشغيل الحاوية غير جاهزة: NetworkReady = رسالة جاهزة كاذبة: docker: المكون الإضافي للشبكة غير جاهز: تكوين cni غير مهيأ
يونيو 06 10:59:56 kubelet [4414]: W0606 10: 59: 56.217923 4414 cni.go: 157] تعذر تحديث تكوين cni: لم يتم العثور على شبكات في /etc/cni/net.d
يونيو 06 10:59:56 contiv1.com kubelet [4414]: E0606 10: 59: 56.218113 4414 kubelet.go: 2067] شبكة وقت تشغيل الحاوية غير جاهزة: NetworkReady = رسالة استعداد خاطئة: docker: المكون الإضافي للشبكة غير جاهز: تكوين cni غير مهيأ
يونيو 06 11:00:01 kubelet [4414]: W0606 11: 00: 01.219251 4414 cni.go: 157] تعذر تحديث تكوين cni: لم يتم العثور على شبكات في /etc/cni/net.d
Jun 06 11:00:01 contiv1.com kubelet [4414]: E0606 11: 00: 01.219382 4414 kubelet.go: 2067] شبكة وقت تشغيل الحاوية غير جاهزة: NetworkReady = رسالة استعداد خاطئة
Jun 06 11:00:06 contiv1.com kubelet [4414]: W0606 11: 00: 06.220396 4414 cni.go: 157] تعذر تحديث تكوين cni: لم يتم العثور على شبكات في /etc/cni/net.d
Jun 06 11:00:06 contiv1.com kubelet [4414]: E0606 11: 00: 06.220575 4414 kubelet.go: 2067] شبكة وقت تشغيل الحاوية غير جاهزة: NetworkReady = رسالة استعداد خاطئة

حالة جميع العقد:
[ root @ swarm net.d] # kubectl الحصول على عقدة
اسم النسخة العمرية
contiv1.com جاهز لمدة ساعة واحدة v1.6.4
contiv2.com Ready 1h v1.6.4
swarm.com جاهز 1 ساعة v1.6.4

أي قرار بشأن هذا؟ لم أتمكن من القيام بذلك حتى بعد تجربة جميع القرارات المذكورة.

كوني جديدًا على إعداد Kubernetes ، أشعر بالارتباك الشديد. حاولت اتباع https://medium.com/@SystemMining/setup -kubenetes-cluster-on-ubuntu-16-04-with-kubeadm-336f4061d929 التي تستخدم weave-kube للشبكة لكنني أيضًا عالق بنفس المشكلة . بأي حال من الأحوال أن يحل هذا؟
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 مع آخر التحديثات باستخدام مستودعات k8s الرسمية مع 1.6.4 واتباع الخطوات الموضحة هنا: https://kubernetes.io/docs/setup/independent/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 لا ، لقد أثر هذا على الإصدار 1.6.0_ فقط . من المتوقع أن kubelet لم يعثر على شبكة لأنك لم تقم بتثبيت أي منها. على سبيل المثال ، فقط قم بتشغيل

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

لتثبيت Weave Net وستختفي هذه المشاكل. يمكنك اختيار تثبيت Flannel أو Calico أو Canal أو أي شبكة CNI إذا كنت ترغب في ذلك

luxas ما زلت أرى إشارات إلى هذا ولكن كيف أفترض تطبيق شيء ما على كتلة لا تعمل؟ ليس لدي أي شيء للاتصال به.

drajen أعتقد أن نقطة luxas هي أن هذا هو المكان الخطأ الذي يجب أن تسأل فيه عن الإعداد.
ستساعدك أدلة الإعداد المتنوعة على تجاوز هذه النقطة - الخطوة النموذجية المفقودة في الأدلة القديمة ، والتي يذكرها luxas بشكل مفيد ، حيث تحتاج إلى تطبيق تكوين الشبكة قبل أن يبدأ كل شيء في العمل بشكل صحيح.

نعم ، قد يكون الأمر غير واضح ونحن آسفون لذلك ، ولكن لا يمكننا أيضًا الحصول على اسم واحد لمقدمي الخدمة.

تحدثت مع drajen على Slack وكانت المشكلة متعلقة بمجموعة cgroup ، كان kubelet غير صحي ولم يكن قادرًا على إنشاء أي Pods ، ومن هنا جاءت المشكلة.

بفضل luxas لمصارعة مشكلتي الخاصة على الأرض: https://github.com/kubernetes/kubeadm/issues/302

لا يزال يصل إلى هذا في قوس على 1.7 ، هل هناك حل سريع في أي مكان؟

يحرر:

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

فعل الحيلة ، يبدو أننا نحتاج فقط إلى تشغيل CNI

على الأقل بالنسبة لـ 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/

لقد تناولت هذه المشكلة ، ولم ينجح أي شيء قرأته أعلاه على الإطلاق. لذلك حاولت مرة أخرى بإعداد أكثر تحكمًا ، حيث قمت بالتبديل من Ubuntu إلى أحدث CoreOS ، والانتقال إلى إصدار سابق من k8s لتبدأ به ، وبصفة عامة كونك شرجًا جدًا حول كل شيء تم تثبيته في كل جهاز افتراضي. أنا لا أستخدم kubeadm ، ولكن بدلاً من ذلك مزيج من المتشرد والمجهول.

(لماذا؟ لأنني لم يكن لدي أي فكرة عما كان يحدث في kubeadm ورأيت بهذه الطريقة على الأقل سيكون لدي السيطرة وأكون قادرًا على تجاوز أي فحوصات مسبقة مفرطة ، ناهيك عن الشعور بأن لدي المزيد من التحكم في الأتمتة بشكل عام ، وأيضًا لا داعي للقلق بشأن التحذير من عدم تطبيق برنامج ألفا في الإنتاج.)

عندما جربت هذا الإعداد مع إصدار أقدم (1.4.3) من k8s ، كان هذا النهج ذهبيًا. ثم حاولت الترقية إلى 1.71. مرة أخرى ، ما زلت أعاني من نفس المشكلة على الرغم من عدم استخدام kubeadm على الإطلاق.

لقد أكدت أنني أدير كاليكو في كل عقد من عقدتي ، بما في ذلك السيد والعمال الثلاثة المحتملين. تبلغ جميع العقد الخاصة بي على أنها NotReady ، لذلك لست متأكدًا حقًا من كيفية تطبيق النسج (أو أي شيء آخر) لتشغيله.

يبدو هذا الأمر برمته مجرد دجاجة / بيضة ... لا يمكن تخصيص حجرة لأن الشبكات تعطل ، ولكنها تحتاج إلى تشغيل شبكة لإنشاء شبكة على /etc/cni/net.d حتى تتمكن من تخصيص البودات. ومرة أخرى ، كان كل هذا يعمل منذ ساعات قليلة مع k8s 1.4.3. أنا محبط جدا!

سأقدر أي رؤى يمكن أن يقدمها أي شخص.

الحواشي:

في الماجستير: جورنال سي تي إل -ر-يو كوبليت يعطيني

24 يوليو 00:48:16 rogue-kube-master-01 kubelet-wrapper [7647]: E0724 00: 48: 16.592274 7647 kubelet.go: 2136] شبكة وقت تشغيل الحاوية غير جاهزة: NetworkReady = سبب خاطئ message: docker : البرنامج المساعد للشبكة لا
24 يوليو 00:48:16 rogue-kube-master-01 kubelet-wrapper [7647]: W0724 00: 48: 16.590588 7647 cni.go: 189] تعذر تحديث تكوين cni: لم يتم العثور على شبكات في / etc / cni / net .د

عامل ميناء ملاحظة | جريب كاليكو

(مقطوع لسهولة القراءة)
cde ... quay.io/calico/ leader -elector
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 الخاص بي:
kubectl الحصول على العقد
10.0.0.111 غير جاهز ، جدولة معطلة 8 ساعات v1.7.1 + coreos.0
10.0.0.121 NotReady 8 ساعات v1.7.1 + coreos.0
10.0.0.122 NotReady 8 h v1.7.1 + coreos.0
10.0.0.123 NotReady 8 h v1.7.1 + coreos.0

تطبيق kubectl -f https://git.io/weave-kube-1.6

لم تقم بإصلاح أي شيء ويبدو في الواقع أنه يخلق المزيد من المشاكل.

بيل @ روغ : ~ / vagrant_rogue / rogue-class $ kubectl application -f https://git.io/weave-kube-1.6
تم إنشاء حساب الخدمة "نسج الشبكة"
تم إنشاء الربط العنقودي "شبكة نسج"
تم إنشاء daemonset "weave-net"
خطأ من الخادم (محظور): clusterroles.rbac.authorization.k8s.io ممنوع "weave-net": محاولة منح امتيازات إضافية: [PolicyRule {Resources: ["pods"]، APIGroups: [""]، Verbs: ["get"]} PolicyRule {Resources: ["pods"]، APIGroups: [""]، Verbs: ["list"]} PolicyRule {Resources: ["pods"]، APIGroups: [""]، Verbs: ["مشاهدة"]} PolicyRule {Resources: ["namespaces"]، APIGroups: [""]، Verbs: ["get"]} PolicyRule {Resources: ["namespaces"]، APIGroups: [""]، Verbs: ["list"]} PolicyRule {Resources: ["namespaces"]، APIGroups: [""]، Verbs: ["watch"]} PolicyRule {Resources: ["nodes"]، APIGroups: [""]، Verbs: ["get"]} PolicyRule {Resources: ["nodes"]، APIGroups: [""]، Verbs: ["list"]} PolicyRule {Resources: ["nodes"]، APIGroups: [""]، Verbs: ["مشاهدة"]} PolicyRule {Resources: ["networkpolicies"]، APIGroups: ["extension"]، Verbs: ["get"]} PolicyRule {Resources: ["networkpolicies"]، APIGroups: ["extension"]، الأفعال: ["list"]} PolicyRule {Resources: ["networkpolicies"]، APIGroups: ["extensions"]، Verbs: ["watch"]}] user = & {kube-admin [النظام: a uthenticated] الخريطة []} ownerrules = [] ruleResolutionErrors = []

بيل @ روغ : ~ / vagrant_rogue / rogue-cluster $ kubectl get pods --namespace = kube-system
إعادة تعيين الوضع الجاهز للاسم العمر
kube-apiserver-10.0.0.111 1/1 تشغيل 1 8h
kube-controller-manager-10.0.0.111 1/1 تشغيل 1 8h
kube-dns-v20-fcl01 0/3 معلق 0 8h
kube-proxy-10.0.0.111 1/1 تشغيل 1 8h
kube-proxy-10.0.0.121 1/1 تشغيل 1 8h
kube-proxy-10.0.0.122 1/1 تشغيل 1 8h
kube-proxy-10.0.0.123 1/1 تشغيل 1 8h
kube-Scheduler-10.0.0.111 1/1 تشغيل 1 8h
kubernetes-dashboard-v1.4.1-29zzk 0/1 معلق 0 8h
نسج صافي 2lplj 1/2 تحطم لوب باك أوف 3 3 م
نسج صافي 2nbgd 1/2 تحطم لوب باك أوف 3 3 م
نسج صافي fdr1v 2/2 الجري 0 3 م
weave-net-jzv50 1/2 تحطم لوب باك أوف 3 3 م

يشير التحقيق الأعمق في أخطاء النسج إلى أنها إما (أ) لا يمكنها الاتصال بالمقدمة ، أو (ب) في حالة الشخص الذي يحمل علامة "قيد التشغيل" ، فإنه يشتكي من أنه لا يمكنه الاتصال بنفسه.

billmilligan عند وجود مشكلات مماثلة ، توقف نظام أسماء النطاقات عن العمل بعد دقائق قليلة من بدء الحاوية

Paxabillmilligan إذا كنت ترغب في الحصول على المساعدة، لا تعليق على هذه المسألة. بدلاً من ذلك ، افتح ملفات جديدة في kubeadm repo بتفاصيل كافية مطلوبة.

luxas مع احترام ، يجب أن بدون kubeadm كما يحصل أي شخص آخر مع kubeadm ، يبدو أن هذا يلغي kubeadm كمصدر للمشكلة. ربما يجب إعادة تسمية هذه المشكلة وفقًا لذلك؟

billmilligan بكل احترام ، نظرًا لأن المشكلة تتعلق بـ kubeadm ، وقدرتك على إعادة إنتاجه بدون kubeadm ، فهل هو المكان الخطأ لتقديمه؟ أعتقد أن هذا الموضوع حل مشكلة kubeadm. هذه قضية جديدة. أعتقد أنها ستحظى بمزيد من الاهتمام كقضية جديدة. نظرًا لأن الأشخاص في هذا الموضوع يعتقدون أنه تم حله بالفعل ويتجاهلونه.

أستخدم kubeadm وقد تأثرت بهذه المشكلة ، وقد تم حلها منذ 1.6.1. لقد نشرت فقد k8s منذ ذلك الحين ، لذلك أعتقد حقًا أن لديك مشكلة منفصلة.

@ kfox1111 شكرا لملاحظاتك. سأقدم مشكلة جديدة ، لكن عدد الأشخاص الذين لا يزالون يواجهونها في مكان آخر في 1.7.x لا يزال يجعلني أتساءل.

TL ؛ DR ؛

رسالة الخطأ

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

ليس بالضرورة سيئا.

تخبرك رسالة الخطأ هذه أنه يتعين عليك إضافة مكون إضافي في موفر تنفيذ مواصفات CNI تابع لجهة خارجية .

ما هو CNI وكيف يتكامل مع Kubernetes؟

يرمز CNI إلى واجهة شبكة الحاوية ويحدد المواصفات التي يستخدمها kubelet لإنشاء شبكة للمجموعة. راجع هذه الصفحة لمزيد من المعلومات حول كيفية استخدام Kubernetes لمواصفات CNI لإنشاء شبكة للمجموعة.

لا تهتم Kubernetes بكيفية إنشاء الشبكة طالما أنها تفي بمواصفات CNI.

kubelet مسؤول عن توصيل أجهزة Pods الجديدة بالشبكة (يمكن أن تكون شبكة تراكب على سبيل المثال).
يقرأ kubelet دليل التكوين (غالبًا /etc/cni/net.d ) لاستخدام شبكات CNI.
عندما يتم إنشاء Pod جديد ، يقرأ kubelet الملفات في دليل التكوين ، ويخرج exec إلى ملف CNI الثنائي المحدد في ملف التكوين (يكون الملف الثنائي غالبًا في /opt/cni/bin ). الثنائي الذي سيتم تنفيذه ينتمي إلى طرف ثالث ويقوم بتثبيته (مثل Weave و Flannel و Calico وما إلى ذلك).

kubeadm هي أداة عامة لتدوير مجموعات Kubernetes ولا تعرف حل الشبكات الذي تريده ولا تفضل أي شخص محدد. بعد تشغيل kubeadm init ، لا يوجد ثنائي CNI ولا تكوين . هذا يعني أن kubeadm init ليس كافيًا للحصول على مجموعة تعمل بكامل طاقتها وتشغيلها.

هذا يعني أنه بعد kubeadm init ، ستقول سجلات kubelet

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

هذا متوقع جدا. إذا لم يكن الأمر كذلك ، لكنا نفضل مزود شبكة معين.

فكيف يمكنني "إصلاح" هذا الخطأ؟
الخطوة التالية في دليل بدء kubeadm هي "تثبيت شبكة Pod".
هذا يعني ، kubectl apply بيان من موفر شبكة CNI المفضل لديك.

ستقوم DaemonSet بنسخ ثنائيات CNI المطلوبة إلى /opt/cni/bin والتكوين المطلوب إلى /etc/cni/net.d/ . كما سيتم تشغيل البرنامج الخفي الفعلي الذي ينشئ الشبكة بين العقد (عن طريق كتابة قواعد iptables على سبيل المثال).

بعد تثبيت موفر CNI ، سوف يلاحظ kubelet أن "لدي بعض المعلومات حول كيفية إعداد الشبكة" ، وسوف يستخدم تكوين الطرف الثالث والثنائيات.

وعندما يتم إعداد الشبكة بواسطة موفر الجهة الخارجية (عن طريق استدعاء kubelet لها) ، فإن العقدة ستضع علامة على نفسها Ready .

كيف ترتبط هذه القضية بـ kubeadm؟

في أواخر دورة الإصدار 1.6 ، تم دمج العلاقات العامة التي غيرت الطريقة التي أبلغت بها kubelet عن حالة Ready/NotReady . في الإصدارات السابقة ، أبلغ kubelet دائمًا عن حالة Ready ، بغض النظر عما إذا كانت شبكة CNI قد تم إعدادها أم لا. كان هذا في الواقع خطأ نوعًا ما ، وتغير لاحترام حالة شبكة CNI. أي ، NotReady عندما كان CNI غير مهيأ و Ready عند التهيئة.

انتظر kubeadm في الإصدار 1.6.0 بشكل خاطئ أن تكون العقدة الرئيسية في حالة Ready قبل متابعة باقي مهام kubeadm init . عندما تغير سلوك kubelet للإبلاغ عن NotReady عندما كان CNI غير مهيأ ، كان kubeadm ينتظر إلى الأبد حتى تحصل العقدة على Ready .

انتظر فكرة خاطئة على جانب KUBEADM هو ما يدور حوله هذا الموضوع

ومع ذلك ، قمنا بسرعة بإصلاح الانحدار في الإصدار 1.6.1 وقمنا بإصداره بعد بضعة أيام من الإصدار 1.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

بعد كل kubeadm init في جميع الإصدارات التي تزيد عن v1.6 ، لكن هذا ليس سيئًا

على أي حال ، يرجى فتح مشكلة جديدة إذا رأيت شيئًا غير متوقع في kubeadm

من فضلك لا تعلق أكثر على هذه المسألة. بدلا من ذلك افتح واحدة جديدة.

billmilligan لذلك عليك فقط kubectl apply بيان موفر CNI لتنشيط مجموعتك وتشغيلها على ما أعتقد

أنا ألخص إلى حد كبير ما قيل أعلاه ، ولكن آمل أن يكون ذلك بطريقة أكثر وضوحًا وتفصيلاً.
إذا كانت لديك أسئلة حول كيفية عمل CNI ، فيرجى الرجوع إلى قنوات الدعم العادية مثل StackOverflow أو مشكلة أو Slack.

(أخيرًا ، آسف على هذا النص الجريء ، لكنني شعرت أنه مطلوب لجذب انتباه الناس.)