لدي نفس المشكلة. حاولت أيضًا إزالة Network ARGS كما هو مقترح في قضية أخرى. لا يزال معلقًا عند waiting for control plane to be ready .

هل أعدت تحميل Daemon وأعدت تشغيل خدمة kubelet بعد إجراء التغييرات. عملت بعد تغيير السائق والتعليق على الشبكة. يستغرق الأمر من 10 إلى 11 دقيقة حتى تستعد طائرة التحكم لأول مرة بالنسبة لي ، وأود أن أقترح تركها لمدة 15 دقيقة لأول مرة.

لقد أعدت تحميل البرنامج الخفي وأعدت تشغيل خدمة kubelet في كل مرة. لقد تركت الإعداد دون عائق طوال الليل لكنه كان لا يزال ينتظر طائرة التحكم.

لقد أعدت تحميل البرنامج الخفي ( systemctl daemon-reload ) وأعدت تشغيل kubelet أيضًا. أقوم بتشغيل kubeadm reset ، وقم بتحرير تهيئة الخدمة ، وأعد تحميل البرنامج الخفي ، ثم شغّل kubeadm init .

تفشل حاويات Apiserver و etcd في العمل بعد التعليق على خيارات الشبكة. حاولت أيضًا تثبيت weave-net يدويًا حتى يتم ملء دليل تكوين cni ، لكن هذا لم ينجح أيضًا. للقيام بذلك ، قمت بتثبيت نسج ، وقمت بتشغيل weave setup و weave launch . لا أعرف حقًا كيف يقوم Kubeadm بتكوين Docker لاستخدام إعدادات CNI ، ولكن ربما تكون هناك خطوة مفقودة هنا.

يبدو أن kubelet لا يمكنه الوصول إلى خادم kube api.

لقد لاحظت أن etcd لم يكن قادرًا على الاستماع على المنفذ 2380 ، لقد اتبعت هذه الخطوات مرة أخرى وبدأت الكتلة الخاصة بي:

• قم بتشغيل kubeadm reset لإزالة أي تغييرات تم إجراؤها على الخادم.
• أعد الجهاز إلى حالته الأولية. عن طريق إعادة تثبيت kubeadm (لاستعادة ملفات التكوين الأصلية).
• قم بإزالة حاويات Docker المتعلقة بـ kubernetes إن وجدت.
• الحصول على نسج وتثبيته. لا تقم بتشغيله.
• أعد تشغيل الخادم.
• تأكد من عدم تشغيل kubelet .
• قم بتشغيل weave setup و weave launch .
• قم بتشغيل kubeadm init .

إذا كنت تريد التخلص من إدارة النسج باليد ...

• قم بتشغيل weave reset
• قم بتطبيق ملحق النسج لـ kubernetes 1.6.
• أعد تشغيل الخادم.

يجب أن تعمل Kubeadm Join على الخوادم الأخرى.

Yengas هل يمكنك تقديم مزيد من التفاصيل حول خطوات النسج؟ هل قمت بتشغيلها على جميع العقد ، أم مجرد المفتاح الرئيسي؟

jruels فقط العقدة الرئيسية. النسج هو مجرد ثنائي واحد. يقوم أمر الإعداد بدون أي وسائط بتنزيل صور عامل الإرساء المنسوجة وإنشاء تهيئة CNI. يبدأ أمر التشغيل بدون أي args حاويات النسج على المضيف فقط.

Yengas ما زلت غير متأكد ، ماذا تقصد ب - "الحصول على weave وتثبيته. لا تقم بتشغيله" لا يمكنني بالطبع تطبيق kubectl -f https://git.io/weave-kube-1.6 فكيف أقوم بتثبيت weave ؟

ماذا تقول سجلات apiserver؟

@ rushabh268
لتثبيت نسج ، قم بتشغيل ما يلي على الماستر
sudo curl -L git.io/weave -o /usr/local/bin/weave && chmod a+x /usr/local/bin/weave
ثم اركض
weave setup
عندما يكتمل ذلك المدى
weave launch

لا تحتاج إلى القيام بذلك. تطبيق kubectl -f https://git.io/weave-kube-1.6 يجب أن يكون كافيًا.

تقول سجلات خادم واجهة برمجة التطبيقات (API) نفس الشيء تمامًا كما ذكرت في الخطأ. أيضًا ، لا يمكنني عمل kubectl لأن Kubernetes غير مثبت

jruels سأحاول الخروج وتحديث هذا الموضوع!

يوجد في وصف الخطأ سجلات kubeadm وسجلات kubelet. لا توجد سجلات apiserver.

mikedanese كيف أحصل على سجلات apiserver؟
jruels أنا قادر على إحضار نسج
Yengas حتى بعد اتباع خطواتك ، أرى الخطأ التالي في سجلات kubelet:
Apr 06 12:55:56 hostname kubelet[5174]: E0406 12:55:56.858931 5174 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.556067 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://10.X.X.X:6443/api/v1/services?resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.557441 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://10.X.X.X:6443/api/v1/nodes?fieldSelector=metadata.name%3Dhostname&resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.558822 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://10.X.X.X:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:58 hostname kubelet[5174]: I0406 12:55:58.347460 5174 kubelet_node_status.go:230] Setting node annotation to enable volume controller attach/detach Apr 06 12:55:58 hostname kubelet[5174]: I0406 12:55:58.405762 5174 kubelet_node_status.go:77] Attempting to register node hostname1

أيضًا ، لقد أوقفت جدار الحماية ، لذا لست متأكدًا من سبب رفض الاتصال.

أواجه نفس المشكلة التي تم الإبلاغ عنها هنا.

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

12 أبريل 02:10:00 تدقيق المضيف المحلي: SERVICE_START pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = kubelet comm = "systemd" exe = "/ usr / lib / systemd / systemd" hostname =؟ العنوان =؟ المحطة =؟ الدقة = النجاح '
12 أبريل 02:10:00 تدقيق المضيف المحلي: SERVICE_STOP pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = kubelet comm = "systemd" exe = "/ usr / lib / systemd / systemd" hostname =؟ العنوان =؟ المحطة =؟ الدقة = النجاح '
12 أبريل 02:10:00 تدقيق المضيف المحلي: SERVICE_START pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = kubelet comm = "systemd" exe = "/ usr / lib / systemd / systemd" hostname =؟ العنوان =؟ المحطة =؟ الدقة = النجاح '
12 أبريل 02:10:00 المضيف المحلي systemd: kubelet.service: انتهى وقت توقف الخدمة ، جدولة إعادة التشغيل.
أبريل 12 02:10:00 نظام المضيف المحلي: kubelet المتوقفة: وكيل عقدة Kubernetes.
أبريل 12 02:10:00 نظام المضيف المحلي: بدأ kubelet: وكيل عقدة Kubernetes.
12 أبريل 02:10:00 localhost systemd: بدء تشغيل أداة محاسبة نشاط النظام ...
12 أبريل 02:10:00 تدقيق المضيف المحلي: SERVICE_START pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = sysstat-collection comm = "systemd" exe = "/ usr / lib / systemd / systemd" hostname = ؟ العنوان =؟ المحطة =؟ الدقة = النجاح '
12 أبريل 02:10:00 تدقيق المضيف المحلي: SERVICE_STOP pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = sysstat-collection comm = "systemd" exe = "/ usr / lib / systemd / systemd" hostname = ؟ العنوان =؟ المحطة =؟ الدقة = النجاح '
12 أبريل 02:10:00 localhost systemd: بدأت أداة محاسبة نشاط النظام.
12 أبريل 02:10:00 المضيف المحلي kubelet: I0412 02: 10: 00.924529 3445 feature_gate.go: 144] بوابات الميزات: خريطة []
12 أبريل 02:10:00 المضيف المحلي kubelet: I0412 02: 10: 00.928973 3445 docker.go: 364] التوصيل إلى عامل الإرساء على unix: ///var/run/docker.sock
12 أبريل 02:10:00 المضيف المحلي kubelet: I0412 02: 10: 00.929201 3445 docker.go: 384] بدء عميل Docker مع انتهاء مهلة الطلب = 2m0s
12 أبريل 02:10:00 المضيف المحلي kubelet: W0412 02: 10: 00.941088 3445 cni.go: 157] تعذر تحديث تكوين cni: لم يتم العثور على شبكات في /etc/cni/net.d
12 أبريل 02:10:00 المضيف المحلي kubelet: I0412 02: 10: 00.948892 3445 manager.go: 143] cAdvisor يعمل في الحاوية: "/system.slice"
أبريل 12 02:10:00 localhost kubelet: W0412 02: 10: 00.974540 3445 manager.go: 151] غير قادر على الاتصال بخدمة Rkt api: rkt: لا يمكن tcp خدمة واجهة rkt للاتصال: اطلب tcp [:: 1]: 15441: getsockopt: رفض الاتصال
أبريل 12 02:10:00 localhost kubelet: I0412 02: 10: 00.997599 3445 fs.go: 117] أقسام نظام الملفات: map [/ dev / root: {mountpoint: / var / lib / docker / devicemapper major: 8 ثانوي: 0 fsType: ext4 blockSize: 0 }]
أبريل 12 02:10:01 localhost kubelet: I0412 02: 10: 01.001662 3445 manager.go: 198] الجهاز: { NumCores: 1 Cpu Frequency: 2799998 Memorial yCapacity: 1037021184 MachineID: 5e9a9a0b58984bfb8766dba9afa8a191 S ystem9aUbafa: 5e9a9a0b58984bfb8766dba9afa8a191 S ystem9aUfa : 5 437b-9460-981eeefdfe5a أنظمة الملفات: [{الجهاز: / dev / root السعة: 15447539712 النوع: vfs Inodes : 962880 HasInodes: true }] DiskMap: map [43: 0: { الاسم: nbd0 التخصص: 43 ثانوي: 0 الحجم: 0 المجدول: لا شيء } 43:11: { الاسم: nbd11 الرئيسي: 43 ثانوي: 11 الحجم: 0 المجدول: لا شيء } 43:12: { الاسم: nbd12 الرئيسي: 43 ثانوي: 12 الحجم: 0 المجدول: بلا } 43:15: { الاسم: nbd15 رئيسي: 43 ثانوي: 15 الحجم: 0 مجدول: لا شيء } 43: 7: { الاسم: nbd7 رئيسي: 43 ثانوي: 7 الحجم: 0 مجدول: لا شيء } 8: 0: { الاسم: sda الرئيسي: 8 ثانوي : 0 الحجم: 15728640000 المجدول: cfq } 252: 0: { الاسم: dm-0 رئيسي: 252 ثانوي: 0 الحجم: 107374182400 المجدول: لا شيء } 43: 1: { الاسم: nbd1 التخصص: 43 ثانوي: 1 الحجم: 0 مجدول . _ _ _ _ _ _ _ _ _ _ 16: { الاسم: sdb الرئيسي: 8 ثانوي: 16 الحجم: 536870912 المجدول: cfq } 9: 0: { الاسم: md0 التخصص: 9 ثانوي: 0 الحجم: 0 المجدول: لا شيء } 43: 3: { الاسم: nbd3 الرئيسي: 43 ثانوي: 3 الحجم: 0 مجدول: لا شيء } 43: 9: { الاسم: nbd9 الرئيسي: 43 ثانوي: 9 الحجم: 0 المجدول: لا شيء } 43:10: { الاسم: nbd10 الرئيسي: 43 ثانوي: 10 الحجم: 0 المجدول : بلا } 43:14: { الاسم: nbd14 التخصص: 43 ثانوي: 14 الحجم: 0 المجدول: لا شيء } 43: 2: { الاسم: nbd2 التخصص: 43 ثانوي: 2 الحجم: 0 المجدول: لا شيء } 43: 4: { الاسم: nbd4 التخصص: 43 فرعي: 4 الحجم: 0 مجدول: لا شيء } 43: 5: { الاسم: nbd5 رئيسي: 43 ثانوي: 5 الحجم: 0 مجدول: لا شيء } 43: 6: { الاسم: nbd6 التخصص: 43 فرعي: 6 الحجم: 0 مجدول: لا شيء }] NetworkDevices: [{ الاسم: dummy0 M ac العنوان: 5a : 34: bf: e4: 23: cc السرعة: 0 Mtu: 1500 } { الاسم: eth0 M ac العنوان: f2 : 3c: 91: 1f: cd: c3 السرعة: -1 Mtu: 1500 } { Name: gre0 M ac العنوان: 00 : 00: 00: 00 السرعة: 0 Mtu: 1476 } { الاسم: gretap0 M العنوان: 00 : 00: 00: 00: 00 : 00 السرعة: 0 Mtu: 1462 } { Name: ip6_vti0 M ac العنوان: 00 : 00: 00: 00: 00: 00: 00: 00: 00: 00: 00: 00: 00: 00: 00 السرعة: 0 Mtu: 1500 } { Name: ip6gre0 M ac العنوان: 00 : 00: 00: 00: 00: 00: 00: 00: 00: 00: 00: 00: 00: 00: 00: 00 السرعة: 0 Mtu: 1448 } { Name: ip6tnl0 M ac العنوان: 00 : 00: 00: 00: 00: 00: 00: 00: 00: 00: 00 : 00: 00: 00: 00: 00 السرعة: 0 Mtu: 1452 } { Name: ip_vti0 Ma
أبريل 12 02:10:01 localhost kubelet: c Address: 00 : 00: 00: 00 Speed: 0 Mtu: 1428 } { Name: sit0 M ac العنوان: 00 : 00: 00: 00 Speed: 0 Mtu: 1480 } { Name: teql0 Mac العنوان: السرعة: 0 Mtu: 1500 } { الاسم: tunl0 M ac العنوان: 00 : 00: 00: 00 السرعة: 0 Mtu: 1480 }] الطوبولوجيا: [{المعرف: 0 الذاكرة: 1037021184 النوى: [{المعرف: 0 خيوط : [0] ذاكرات التخزين المؤقت: [{ الحجم: 32768 النوع: مستوى البيانات: 1 } { الحجم: 32768 النوع: مستوى التعليمات : 1 } { الحجم: 4194304 النوع: المستوى الموحد: 2 }]}] ذاكرات التخزين المؤقت: []}] Clou dProvider: غير معروف Ins tanceType: Unknown I nstanceID: لا شيء }
12 أبريل 02:10:01 كوبيليت المضيف المحلي: I0412 02: 10: 01.013353 3445 manager.go: 204] الإصدار: {Kern elVersion: 4.9.15-x86_64-linode81 Container OsVersion: Fedora 25 (Server Edition) Dock erVersion: 1.12. 6 CadvisorVersion: CadvisorRevision:}
أبريل 12 02:10:01 kubelet المضيف المحلي: I0412 02: 10: 01.014086 3445 server.go: 509] - تمكين المجموعات لكل جودة ، ولكن لم يتم تحديد جذر المجموعة. التقصير في /
Apr 12 02:10:01 localhost kubelet: W0412 02: 10: 01.016562 3445 container_manager_linux.go: 218] لا يتم دعم التشغيل مع تشغيل المبادلة ، يرجى تعطيل المبادلة! سيكون هذا خطأ فادحًا افتراضيًا بدءًا من K8s v1.6! في غضون ذلك ، يمكنك الاشتراك في جعل هذا خطأ فادحًا عن طريق تمكين - تجريبي - فشل - مبادلة.
Apr 12 02:10:01 localhost kubelet: I0412 02: 10: 01.016688 3445 container_manager_linux.go: 245] مدير الحاوية تم التحقق من وجود مستخدم cgroup-root تم التحقق منه: /
أبريل 12 02:10:01 كوبيليت المضيف المحلي: I0412 02: 10: 01.016717 3445 container_manager_linux.go: 250] إنشاء كائن مدير الحاوية بناءً على تكوين العقدة: {RuntimeCgroupsName: SystemCgroupsName: KubeletCgroups الاسم: احتواء erRuntime: عامل ميناء Cgro upsPerQOS: صحيح / Cgro upsPerQOS: صحيح / Cgr oupDriver: cgroupfs ProtectKerne lDefaults: false EnableCRI: true NodeAllocatableConfig: {KubeReservedCgroupName: SystemReservedCgroupName: EnforceNodeAl locatable: map [pods: {}] Kub eReserved: memory map [ ] Syste. : أقل من القيمة: { Quantity: 100Mi P ercentage: 0 } Gr acePeriod: 0s MinReclaim:}]} ExperimentalQO SR المحفوظ: خريطة []}
أبريل 12 02:10:01 kubelet localhost: I0412 02: 10: 01.016943 3445 kubelet.go: 255] إضافة ملف البيان: / etc / kubernetes / manifests
أبريل 12 02:10:01 المضيف المحلي kubelet: I0412 02: 10: 01.016966 3445 kubelet.go: 265] مشاهدة apiserver
12 أبريل 02:10:01 kubelet localhost: E0412 02: 10: 01.025058 3445 reflector.go: 190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: فشل في القائمة * v1.Node: Get https: //50.116.13.214 : 6443 / api / v1 / nodes؟
12 أبريل 02:10:01 kubelet localhost: E0412 02: 10: 01.025342 3445 reflector.go: 190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: فشل في القائمة * v1.Service: احصل على https: //50.116.13.214 : 6443 / api / v1 / services؟
أبريل 12 02:10:01 kubelet المحلية: E0412 02: 10: 01.025397 3445 reflector.go: 190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: فشل في القائمة * v1.Pod: Get https://50.116.13.214 : 6443 / api / v1 / pods؟
أبريل 12 02:10:01 kubelet localhost: W0412 02: 10: 01.026574 3445 kubelet_network.go: 70] تم ضبط وضع دبوس الشعر على "promiscuous-bridge" ولكن لم يتم تمكين kubenet ، والعودة إلى "hairpin-veth"
12 أبريل 02:10:01 المضيف المحلي kubelet: I0412 02: 10: 01.026599 3445 kubelet.go: 494] وضع دبوس الشعر مضبوط على "hairpin-veth"
12 أبريل 02:10:01 kubelet localhost: W0412 02: 10: 01.026661 3445 cni.go: 157] تعذر تحديث تكوين cni: لم يتم العثور على شبكات في /etc/cni/net.d
12 أبريل 02:10:01 kubelet localhost: W0412 02: 10: 01.034194 3445 cni.go: 157] تعذر تحديث تكوين cni: لم يتم العثور على شبكات في /etc/cni/net.d
12 أبريل 02:10:01 kubelet localhost: W0412 02: 10: 01.043157 3445 cni.go: 157] تعذر تحديث تكوين cni: لم يتم العثور على شبكات في /etc/cni/net.d
Apr 12 02:10:01 localhost kubelet: I0412 02: 10: 01.043183 3445 docker_service.go: 187] شبكة Docker cri التي تديرها cni
12 أبريل 02:10:01 المضيف المحلي kubelet: خطأ: فشل تشغيل Kubelet: فشل في إنشاء kubelet: التكوين الخاطئ: kubelet cgroup driver: "cgroupfs" يختلف عن Docker cgroup driver: "systemd"
12 أبريل 02:10:01 تدقيق المضيف المحلي: SERVICE_STOP pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = kubelet comm = "systemd" exe = "/ usr / lib / systemd / systemd" hostname =؟ العنوان =؟ المحطة =؟ الدقة = فشل '
12 أبريل 02:10:01 localhost systemd: kubelet.service: تم الخروج من العملية الرئيسية ، الرمز = تم الخروج منه ، الحالة = 1 / فشل
أبريل 12 02:10:01 نظام المضيف المحلي: kubelet.service: دخلت الوحدة في حالة فاشلة.
أبريل 12 02:10:01 localhost systemd: kubelet.service: فشل مع النتيجة "كود الخروج".

acloudiator أعتقد أنك بحاجة إلى تعيين برنامج تشغيل cgroup في تكوين kubeadm.

vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Environment="KUBELET_EXTRA_ARGS=--cgroup-driver=systemd"

ثم أعد تشغيل خدمة kubelet

سيكون من الرائع أن يتعامل kubeadm بطريقة ما مع مشكلة تكوين cgroup.
الأفكار:

• إحباط التهيئة في حالة الخطأ في التكوين
• تحقق من إعدادات Docker مسبقًا واستخدم ما يستخدمه Docker (لست متأكدًا من أي آثار هنا)

مجرد تحديث ، أيا كان الحل الذي جربته لم ينجح. لذلك انتقلت إلى CentOS 7.3 من أجل السيد وهو يعمل مثل السحر! مع ذلك ، احتفظت بالتوابع على CentOS 7.2.

@ rushabh268 مرحبًا ، لدي نفس المشكلة على Redhat Linux 7.2. بعد تحديث systemd ، تم حل هذه المشكلة. يمكنك محاولة تحديث systemd قبل التثبيت.
yum update -y systemd
وسجل الأخطاء من kubelet:
kubelet.go:1752] skipping pod synchronization - [Failed to start ContainerManager systemd version does not support ability to start a slice as transient unit]

لقد تعرضت لهذه المشكلة في CentOS 7.3. لقد اختفت المشكلة بعد أن قمت بإلغاء تثبيت docker-ce ثم تثبيت docker-io.
لست متأكدًا مما إذا كان هذا هو السبب الجذري. على أي حال ، يمكنك تجربة إذا لم تنجح الطرق المذكورة أعلاه.

ZongqiangZhang لدي عامل إرساء 1.12.6 مثبت على العقد الخاصة بي. juntaoXie حاولت تحديث systemd أيضًا وما زال عالقًا

لذلك كنت أقوم بتشغيل Centos 7.3 w / 1.6.4 بدون مشكلة على عدد من الأجهزة.

هل تأكدت من تعطيل selinux؟

timothysc لدي CentOS 7.2 وليس CentOS 7.3 وتم تعطيل selinux

لدي إصدار 7.3.1611 (Core) من CentOS Linux ولا يعمل KubeAdm 1.6.4.

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
EOF

setenforce 0
# edit /etc/selinux/config and set SELINUX=disabled
yum install docker kubelet kubeadm kubectl kubernetes-cni
systemctl enable docker
systemctl start docker
systemctl enable kubelet
systemctl start kubelet
reboot
kubeadm init

انتاج:

kubeadm init
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters.
[init] Using Kubernetes version: v1.6.4
[init] Using Authorization mode: RBAC
[preflight] Running pre-flight checks
[preflight] WARNING: hostname "kubernet01.localdomain" could not be reached
[preflight] WARNING: hostname "kubernet01.localdomain" lookup kubernet01.localdomain on XXXXXXX:53: read udp XXXXXXX:56624->XXXXXXX:53: i/o timeout
[preflight] Starting the kubelet service
[certificates] Generated CA certificate and key.
[certificates] Generated API server certificate and key.
[certificates] API Server serving cert is signed for DNS names [kubernet01.localdomain kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.11.112.51]
[certificates] Generated API server kubelet client certificate and key.
[certificates] Generated service account token signing key and public key.
[certificates] Generated front-proxy CA certificate and key.
[certificates] Generated front-proxy client certificate and key.
[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[apiclient] Created API client, waiting for the control plane to become ready

Jun 06 17:13:12 kubernet01.localdomain kubelet[11429]: W0606 17:13:12.881451   11429 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Jun 06 17:13:12 kubernet01.localdomain kubelet[11429]: E0606 17:13:12.882145   11429 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.519992   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://10.11.112.51:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dkubernet01.localdomain&resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.520798   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://10.11.112.51:6443/api/v1/services?resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.521493   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://10.11.112.51:6443/api/v1/nodes?fieldSelector=metadata.name%3Dkubernet01.localdomain&resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:14 kubernet01.localdomain kubelet[11429]: E0606 17:13:14.337588   11429 event.go:208] Unable to write event: 'dial tcp 10.11.112.51:6443: getsockopt: connection refused' (may retry after sleeping)

paulobezerr هل يمكنك مشاركة عدد أكبر قليلاً من سجلات kube-apiserver ؟ (هؤلاء في نهاية تعليقك)

هل الصفوف الموجودة فوق ما قمت بتضمينه بالفعل تذكر نفس عنوان IP؟ حاولت تشغيل k8s على وحدتي KVM جديدين مؤخرًا ، أحدهما مع Ubuntu 16.04 والآخر مع CentOS 7.3. كلاهما أعطى هذا:

​[restful] 2017/05/30 19:31:38 log.go:30: [restful/swagger] listing is available at https://x.x.x.x:6443/swaggerapi/
[restful] 2017/05/30 19:31:38 log.go:30: [restful/swagger] https://x.x.x.x:6443/swaggerui/ is mapped to folder /swagger-ui/
​E0530 19:31:38.313090 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Failed to list *rbac.RoleBinding: Get https://localhost:6443/apis/rbac.authorization.k8s.io/v1beta1/rolebindings?resourceVersion=0: dial tcp y.y.y.y:6443: getsockopt: connection refused

لاحظ أن عنوان IP المذكور أولاً هو x.x.x.x ، ولكن بعد ذلك يتم حل المضيف المحلي إلى y.y.y.y (والذي كان في حالتي عنوان IP عام لملف KVM آخر موجود على نفس الخادم الفعلي). يمكنني بدء تشغيل kubeadm على Ubuntu في النهاية ، ولكن فقط بعد تثبيت dnsmasq بطريقة مشابهة لـ https://github.com/kubernetes/kubeadm/issues/113#issuecomment -273115861. نفس الحل البديل على CentOS لم يساعد.

هل يمكن أن يكون هذا خطأ في kubedns أو شيء من هذا القبيل؟ ومن المثير للاهتمام ، أن نفس الخطوات على AWS VMs أدت إلى ظهور kubeadm. لكن مثيلات EC2 باهظة الثمن بالنسبة لمشاريعي الشخصية.

لدي نفس المشكلة مثلpaulobezerr.

## الإصدارات :
kubelet-1.6.4-0.x86_64
kubernetes-cni-0.5.1-0.x86_64
kubectl-1.6.4-0.x86_64
kubeadm-1.6.4-0.x86_64
عامل ميناء 1.12.6-28.git1398f24.el7.centos.x86_64
عامل ميناء عام 1.12.6-28.git1398f24.el7.centos.x86_64
عامل ميناء 1.12.6-28.git1398f24.el7.centos.x86_64

وبالتالي
uname -r> 3.10.0-229.1.2.el7.x86_64
cat / etc / redhat-release> إصدار CentOS Linux 7.3.1611 (Core)

## الخطوات المتبعة:

    1. sudo yum install -y docker
2. sudo groupadd docker
3. sudo usermod -aG docker $(whoami)
4. curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
5. chmod +x ./kubectl
6. sudo mv ./kubectl /usr/local/bin/kubectl
7. echo "source <(kubectl completion bash)" >> ~/.bashrc
8. sudo -i
9. cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/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
10. setenforce 0
11. yum install -y docker kubelet kubeadm kubectl kubernetes-cni
12. systemctl enable docker && systemctl start docker
13. systemctl enable kubelet && systemctl start kubelet
    14. echo -e "net.bridge.bridge-nf-call-ip6tables = 1\nnet.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.d/99-sysctl.conf && sudo service network restart
    15. firewall-cmd --zone=public --add-port=6443/tcp --permanent && sudo firewall-cmd --zone=public --add-port=10250/tcp --permanent  && sudo systemctl restart firewalld
    16. firewall-cmd --permanent --zone=trusted --change-interface=docker0

## سجلات خادم api:
-> 37.247.XX.XXX هو عنوان IP العام

[راحة] 2017/06/08 10:45:19 log.go: 30: قائمة [restful / swagger] متاحة على https://37.247.XX.XXX : 6443 / swaggerapi /
[restful] 2017/06/08 10:45:19 log.go: 30: [restful / swagger] https://37.247.XX.XXX : 6443 / swaggerui / تم تعيينه على المجلد / swagger-ui /
E0608 10: 45: 19.429839 1 reflector.go: 201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: فشل في القائمة * api. السر: احصل على https: // localhost : 6443 / api / v1 / secrets؟ ResourceVersion = 0: اطلب tcp 108.59.253.109:6443: getockopt: رفض الاتصال
E0608 10: 45: 19.430419 1 reflector.go: 201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: فشل في القائمة * api.ResourceQuota: احصل على https: // localhost : 6443 / api / v1 / Resourcequotas؟ ResourceVersion = 0: اطلب tcp 108.59.253.109:6443: getockopt: تم رفض الاتصال
E0608 10: 45: 19.430743 1 reflector.go: 201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: فشل إدراج * api.ServiceAccount: احصل على https: // localhost : 6443 / api / v1 / serviceaccounts؟ ResourceVersion = 0: اطلب tcp 108.59.253.109:6443: getockopt: رفض الاتصال
E0608 10: 45: 19.431076 1 reflector.go: 201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: فشل في سرد ​​* storage.StorageClass: احصل على https: // localhost : 6443 / apis / storage.k8s.io / v1beta1 / storageclasses؟
E0608 10: 45: 19.431377 1 reflector.go: 201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: فشل في القائمة * api.LimitRange: Get https: // localhost : 6443 / api / v1 / Limitranges؟ ResourceVersion = 0: اطلب tcp 108.59.253.109:6443: getockopt: تم رفض الاتصال
E0608 10: 45: 19.431678 1 reflector.go: 201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: فشل في القائمة * rbac.RoleBinding: احصل على https: // localhost : 6443 / apis / rbac.authorization.k8s.io / v1beta1 / rolebindings؟
E0608 10: 45: 19.431967 1 reflector.go: 201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: فشل في القائمة * rbac.ClusterRoleBinding: احصل على https: // localhost : 6443 / apis / rbac.authorization.k8s.io / v1beta1 / clusterrolebindings؟
E0608 10: 45: 19.432165 1 reflector.go: 201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: فشل في القائمة * api.Namespace: Get https: // localhost : 6443 / api / v1 / namespaces؟
E0608 10: 45: 19.432386 1 reflector.go: 201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: فشل في القائمة * rbac.ClusterRole: Get https: // localhost : 6443 / apis / rbac.authorization.k8s.io / v1beta1 / clusterroles؟
E0608 10: 45: 19.432619 1 reflector.go: 201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: فشل في القائمة * rbac. الدور: احصل على https: // localhost : 6443 / apis / rbac.authorization.k8s.io / v1beta1 / categories؟
I0608 10: 45: 19.481612 1 serve.go: 79] العرض بأمان على 0.0.0.0:6443
W0608 10: 45: 19.596770 1 storage_extensions.go: 127] فشل مزامنة مورد جهة خارجية: احصل على https: // localhost : 6443 / apis / extension / v1beta1 / thirdpartyresources: اطلب tcp 108.59.253.109:6443: getockopt: رفض الاتصال
E0608 10: 45: 19.596945 1 client_ca_hook.go: 58] انشر https: // localhost : 6443 / api / v1 / namespaces: اطلب tcp 108.59.253.109:6443: getockopt: رفض الاتصال
F0608 10: 45: 19.597174 1 controller.go: 128] تعذر إجراء فحص تخصيص IP الأولي: غير قادر على تحديث كتلة IP للخدمة: احصل على https: // localhost : 6443 / api / v1 / services: dial tcp 108.59.253.109: 6443: getockopt: رفض الاتصال

albpal كان لدي نفس المشكلة تمامًا قبل أسبوع: dial tcp X.X.X.X كان يعرض عنوان IP فرديًا ولم أتمكن من حل هذا على CentOS حتى بعد تثبيت dnsmasq والتبديل إلى خوادم Google DNS بدلاً من DNS من مزود الاستضافة الخاص بي. للفضول فقط: هل يمكنك التحقق مما إذا كان عنوان IP الخاطئ الذي تراه موجودًا في نفس مركز البيانات مثل جهاز VM الخاص بك؟ يمكنك استخدام http://ipinfo.io لتقدير ذلك بدرجة معينة من اليقين أو مجرد مسار التتبع.

في حالتي ، كان عنوان IP الخاطئ يشير إلى KVM آخر على نفس الخادم الفعلي. يمكن أن يكون شيئًا له علاقة بـ DNS على جهاز مادي ، الأمر الذي قد يتطلب حلًا بديلًا داخل kube api أو kube dns ، وإلا فإن بدء مجموعة يصبح مشكلة كبيرة للعديد من الوافدين الجدد! لقد أهدرت بعض الأمسيات قبل أن ألاحظ dial tcp باستخدام عنوان IP خاطئ في السجلات ، والتي كانت تجربة k8s محزنة جدًا. لا يزال ليس لديك حل جيد جاهز لـ CentOS KVMs على مزود الاستضافة الخاص بي ( firstvds.ru ).

ما الذي يمكن أن يسبب هذا عدم التطابق الغريب جدًا في عناوين IP؟

albpal الرجاء فتح مشكلة جديدة ، ما وصفته وما تدور حوله هذه المشكلة هما مشكلتان منفصلتان (أعتقد أنه بناءً على هذه المعلومات)

kachkaev لقد راجعت للتو ما اقترحته.

لقد وجدت أن عنوان IP الخاطئ ينتهي عند CPANEL: vps-1054290-4055.manage.myhosting.com.

من ناحية أخرى ، IP العام الخاص بخادم VPS الخاص بي من إيطاليا وهذا IP الخاطئ من الولايات المتحدة الأمريكية ... لذلك على الرغم من حقيقة أن IP الخاطئ له شيء متعلق بالاستضافة (CPANEL) لا يبدو أنه يشير إلى KVM آخر على نفس الخادم الفعلي.

هل كنت قادرا على تثبيت k8s؟

luxas لدي نفس السلوك ولكني قمت بنسخ سجلات عامل الإرساءالإخراج أيضا.

كلا / var / log / messages و kubeadm init's output هي نفسها النسخة الأصلية.

albpal إذاً جهاز VM الخاص بك والجهاز الثاني كلاهما على CPANEL؟ علامة جيدة ، لأن حالتي هي نفسها! حقيقة أنها كانت نفس الآلة المادية يمكن أن تكون مجرد حادثة مشتركة.

لقد استخدمت KVMs في تجاربي ، أحدهما مع Ubuntu 16.04 والآخر مع CentOS 7.3 كلاهما كان لهما نفس مشكلة عنوان IP dial tcp . تمكنت في النهاية من بدء kubeadm على Ubuntu من خلال التخلص من خوادم DNS الخاصة بمزودي. استند الحل إلى نصيحة crilozs :

​apt-get install dnsmasq

rm -rf /etc/resolv.conf
echo "nameserver 127.0.0.1" > /etc/resolv.conf
chmod 444 /etc/resolv.conf
chattr +i /etc/resolv.conf

echo "server=8.8.8.8
server=8.8.4.4" > /etc/dnsmasq.conf

service dnsmasq restart
​# reboot just in case

جلب هذا عنوان IP الصحيح بعد أن تمت تهيئة سجلات الدخول على Ubuntu و kubeadm dial tcp بعد دقيقتين! حاولت إعداد dnsmasq على CentOS بنفس الطريقة ، لكن هذا لم يحل المشكلة. لكنني مبتدئ كليًا في نظام التشغيل هذا ، لذا فقد نسيت للتو إعادة تشغيل بعض الخدمات أو تنظيف بعض ذاكرة التخزين المؤقت. جرب هذه الفكرة!

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

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

شكرا kachkaev ! سأحاول غدا

cc @ kubernetes / sig-network-bugs هل لديك فكرة عن سبب فشل حل DNS أعلاه؟

شكرا kachkaev سنحاول النظر في الأمر. لا أعتقد أنه خطأ kubeadm حقًا في حد ذاته ، ولكن إذا كان العديد من المستخدمين عالقين في نفس التكوين الخاطئ ، فقد نضيفه إلى تحرّي الخلل وإصلاحه في المستندات أو نحو ذلك ...

من المحتمل جدًا أن تشتمل سجلاتي على سجلات albpal .
ولكن سأحاول dnsmasq. شكرا لكم جميعا!

kachkaev ، لا يعمل. نفس المشكلة
السجل الكامل مرفق.

log.txt

لقد تمكنت من إصلاحه !! شكرًا جزيلاً @ kachkaev على تلميحاتك!

أعتقد أن المشكلة كانت:

### سيناريو:
خادم VPS بمخطط التكوين التالي:

resolv.conf
[ جذر @ apalau ~] # قطة resolv.conf
خادم الأسماء 8.8.8.8
خادم الأسماء 8.8.4.4
خادم الأسماء 2001: 4860: 4860 :: 8888
خادم الأسماء 2001: 4860: 4860 :: 8844

لا يوجد أي مجال بحث!

المضيفين
[ root @ apalau ~] # cat / etc / hosts
127.0.0.1 localhost.localhost.localhost
37.XXX.XX.XXX name.vpshosting.com

وفقًا للسجلات ، تحاول حاوية kubernetes الاتصال بـ:

احصل على https: // localhost : 6443 / api / v1 / secrets؟

وعندما أطلب:
$ nslookup "localhost. $ (hostname -d)"
عنوان IP الذي أحصل عليه هو العنوان الخطأ ، أي 108.59.253.109.

لذلك أعتقد أن هذه الحاويات تحاول حل المضيف المحلي (بدون مجال) ويحصلون على IP خاطئ. ربما لأن "localhost. $ (hostname -d)" يحل عنوان IP الذي أعتقد أنه سيحدث على أي من خدمات VPS تقريبًا.

## ما فعلته لإصلاح المشكلة على VPS CentOS 7.3 (بصرف النظر عن تلك الخطوات الموضحة على https://kubernetes.io/docs/setup/independent/install-kubeadm/#installing-kubelet-and-kubeadm):

كجذر:

1. إعادة تعيين kubeadm
2. يم تثبيت dnsmasq
3. cp /etc/resolv.conf ~ / resolv.conf_bck
4. rm -rf /etc/resolv.conf
5. صدى -e "خادم الأسماء 127.0.0.1 \ n خادم الأسماء $ (hostname -i)" >> /etc/resolv.conf
6. chmod 444 /etc/resolv.conf
7. chattr + i /etc/resolv.conf
8. echo -e "server = 8.8.8.8 \ n server = 8.8.4.4"> /etc/dnsmasq.conf
9. صدى -e "$ (hostname -i) \ tlocalhost. $ (hostname -d)" >> / etc / hosts
10. إعادة تشغيل خدمة dnsmasq
11. firewall-cmd --zone = public --add-port = 6443 / tcp - دائم && sudo firewall-cmd --zone = public --add-port = 10250 / tcp - دائم && sudo systemctl إعادة تشغيل جدار الحماية
12. الحرف الأول kubeadm

لقد أضفت اسم المضيف -i في الخطوة 5 لأنني إذا لم أفعل ، فسيضيف عامل الإرساء 8.8.8.8 إلى resolv.conf على الحاويات.

آمل أن يساعد الآخرين أيضًا.

شكرا!!

سعيد لسماع ذلكalbpal! لقد مررت بخطواتك قبل kubeadm init وتم تهيئة المجموعة أخيرًا داخل اختباري FirstVDS KVM باستخدام CentOS 7.3! الشيء الإضافي الوحيد الذي كان علي فعله هو إيقاف جدار الحماية وتعطيله لأنه كان يحظر الاتصالات الخارجية بالمنفذ 6443:

systemctl disable firewalld
systemctl stop firewalld

_ لا أوصي بالقيام بذلك لأنني لست على دراية بالعواقب - لقد ساعدني هذا فقط في إكمال اختبار على نظام تشغيل لا أستخدمه عادةً.

الآن أتساءل ما الذي يمكن فعله لتسهيل عملية التثبيت للمبتدئين مثلي. لا يزال المسار بين التعثر عند Created API client, waiting for the control plane to become ready وفرز الأشياء ضخمًا ، خاصة إذا أخذنا في الاعتبار الوقت اللازم لاستكشاف هذه المشكلة وقراءة جميع التعليقات. __ماذا يمكن أن تقترحوا يا رفاق؟ __

paulobezerr مما أراه في مرفقك أعتقد أن مشكلتك مختلفة قليلاً. تحتوي سجلات apiserver الخاصة بي على شيء مثل:

reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod:
Get https://localhost:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0:
dial tcp RANDOM_IP:6443: getsockopt: connection refused

بينما يقول لك:

reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod:
Get https://10.X.X.X:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0:
dial tcp 10.X.X.X:6443: getsockopt: connection refused

(في الحالة الأولى يكون localhost / RANDOM_IP ، بينما في الحالة الثانية يكون دائمًا 10.X.X.X )

لسوء الحظ ، لا أعرف ما الذي أنصح به باستثناء تجربة --apiserver-advertise-address=??? عندما تستخدم kubeadm init (انظر المستندات ). لقد وصلت خبرتي العملية في k8s للتو إلى 10 أيام ، معظمها كانت محاولات عبثية لبدء مجموعة أحادية العقدة على FirstVDS :-)

آمل أن يتم فرز هذا ومشاركة الحل مع الآخرين!

kachkaev لقد نسيت أن أذكر أنني قمت بتطبيق قاعدة جدار الحماية التالية:

$ firewall-cmd --zone = public --add-port = 6443 / tcp - دائم && sudo firewall-cmd --zone = public --add-port = 10250 / tcp - دائم && sudo systemctl إعادة تشغيل جدار الحماية

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

تضمين التغريدة يعمل تحديث إصدار systemd لكل تعليق من أجلي.

ما زلت أتلقى هذه المشكلة لمدة يومين حتى الآن ، فأنا أعمل كل هذا خلف وكيل ولا يبدو أن هناك مشكلة.
يتوقف kubeadm init على انتظار أن تصبح طائرة التحكم جاهزة. عندما أقوم بعمل docker ps ، يتم سحب الحاويات وتشغيلها ولكن لم يتم تخصيص منافذ خلفها (لا أعرف ما إذا كان من المفترض أن يتم ذلك أم لا). إلخ كما يعمل بشكل جيد. ومع ذلك ، عندما ألقي نظرة على خدمة kubelet الخاصة بي ، فإنها تقول غير قادر على تحديث تكوين cni: لم يتم العثور على شبكات في /etc/cni/net.d والتي https://github.com/kubernetes/kubernetes/issues/43815 تقول أنها على ما يرام ، أنت بحاجة إلى تطبيق شبكة cni.
الذي أفعله وفقًا لـ https://www.weave.works/docs/net/latest/kubernetes/kube-addon/. الآن ، يقول kubectl أنه تم رفض 8080 - هل حددت المضيف أو المنفذ الصحيح؟ تبدو مشكلة الدجاج والبيض ، كيف يمكنني تطبيق شبكة cni عندما يتوقف kubeadm init مؤقتًا ؟؟؟ هذا محير جدا

هذه أيضًا ليست مشكلة cgroup ، يستخدم كل من عامل الإرساء وخدمة kubelet الخاصة بي systemd.

FWIW ، لقد واجهت نفس المشكلة على GCP لقد حاولت استخدام Ubuntu 16.04 و CentOS باستخدام الأوامر التالية في مشروع نظيف:

تُنشئ مثيلات حساب gcloud بالدولار الأمريكي test-api-01 --zone us-west1-a - image-family ubuntu-1604-lts - image-project ubuntu-os-cloud - machine-type f1-micro --description ' العقدة 1 لاختبار API "

تُنشئ مثيلات حساب gcloud بالدولار الأمريكي test-api-02 --zone us-west1-b - image-family ubuntu-1604-lts - image-project ubuntu-os-cloud - machine-type f1-micro --description ' العقدة 2 لاختبار API "

تُنشئ مثيلات حساب gcloud بالدولار الأمريكي test-api-03 --zone us-west1-c - image-family ubuntu-1604-lts - image-project ubuntu-os-cloud - machine-type f1-micro --description ' العقدة 3 لاختبار API "

تحديث $ apt-get

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

$ apt-get update && apt-get install -qy docker.io && apt-get install -y apt-transport-https

$ echo "deb http://apt.kubernetes.io/ kubernetes-xenial main"> /etc/apt/sources.list.d/kubernetes.list

$ apt-get update && apt-get install -y kubelet kubeadm kubernetes-cni

إعادة تشغيل kubelet $ systemctl

$ kubeadm init

لذلك بعد أن ضربت رأسي عليها لعدة ساعات انتهى بي الأمر مع:

حاوية بيتا gcloud $ - مجموعات المشروع "weather-177507" تنشئ "weather-api-clustre-1" --zone "us-west1-a" --username = "admin" --cluster-version "1.6.7" - نوع الآلة "f1-micro" - نوع الصورة "COS" - حجم القرص "100" - نطاقات " https://www.googleapis.com/auth/compute " ، " https: // www.googleapis.com/auth/devstorage.read_only "،" https://www.googleapis.com/auth/logging.write "،" https://www.googleapis.com/auth/monitoring.write "،" https://www.googleapis.com/auth/servicecontrol "،" https://www.googleapis.com/auth/service.management.readonly "،" https://www.googleapis.com/auth/trace. إلحاق "--num-nodes" 3 "- network" default "- Enable-cloud-logging - no-enable-cloud-Monitoring --enable-legacy-التفويض

تمكنت من إنشاء مجموعة وتشغيل حيث لم أستطع من صورة فارغة.

حتى أنني أواجه نفس المشكلة مع إصدار Kubeadm:

تتعثر فيه
[apiclient] Created API client, waiting for the control plane to become ready

نفس المشكلة مثل paulobezerr - env ​​my env: CentOS 7.4.1708 kubeadm version: & version.Info {Major: "1"، Minor: "8"، GitVersion: "v1.8.0"، GitCommit: "6e937839ac04a38cac63e6a7a306c5d035fe7b0a" "، تاريخ الإصدار:" 2017-09-28 T22: 46: 41Z "، GoVersion:" go1.8.3 "، المترجم:" gc "، النظام الأساسي:" linux / amd64 "}

بالنسبة لي ، لم تكن هذه المشكلة تعمل مع تعطيل SELinux. كانت الفكرة هي خطواته ، التعليق:

تحرير / etc / selinux / config وضبط SELINUX = معطل

تنص خطوات التثبيت هنا (https://kubernetes.io/docs/setup/independent/install-kubeadm/) لـ CentOS على ما يلي:
"تعطيل SELinux عن طريق تشغيل setenforce 0 مطلوب للسماح للحاويات بالوصول إلى نظام ملفات المضيف"
لكنه لا يذكر (على الأقل في علامة التبويب CentOS / RHEL / Fedora) أنه يجب عليك تحرير / etc / selinux / config وضبط SELINUX = معطل

بالنسبة لي ، على الرغم من أنني قمت بتشغيل setenforce 0 ، إلا أنني ما زلت أتلقى نفس الأخطاء. تحرير / etc / selinux / config وضبط SELINUX = معطل ، ثم إعادة التشغيل أصلحه لي.

يبدو أن هناك الكثير من المشكلات (المتعامدة المحتملة) قيد التشغيل هنا ، لذا فأنا حريص على عدم ترك الأمور تتباعد. حتى الآن يبدو أننا حددنا 3 مشكلات:

1. فشل DNS في حل المضيف المحلي بشكل صحيح على بعض الأجهزة. kachkaevpaulobezerr هل تمكنت من إصلاح هذا؟ أتساءل كيف أجعل ذلك أكثر وضوحًا في متطلباتنا ، أي أفكار؟

2. تطابق غير صحيح بين cgroup-driver و Docker. يجب أن نضيف هذا إلى قائمة متطلباتنا.

3. لم يتم تعطيل SELinux. يجب أن نضيف هذا إلى قائمة متطلباتنا.

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

بالنسبة لي ، ذهبت مع Docker 17.06 (17.03 موصى به ، لكن غير متوفر في docker.io) وركضت في نفس المشكلة. الترقية إلى 17.09 أصلحت المشكلة بطريقة سحرية.

نظرًا لأن هذا الموضوع قد استغرق وقتًا طويلاً ، وربما هناك الكثير من المشكلات المختلفة تمامًا ، فإن الشيء الأكثر إنتاجية الذي يمكنني إضافته إلى جانب تعليقjamiehannaford الممتاز هو أنه يرجى فتح مشكلات جديدة ومستهدفة مع جميع السجلات / المعلومات ذات الصلة في حالة وجود شيء ما فشل _ مع أحدث إصدار من kubeadm v1.8_ ، والذي يكتشف تلقائيًا حالة خاطئة أفضل بكثير من الإصدارات السابقة. لقد قمنا أيضًا بتحسين توثيقنا حول المتطلبات وحالات الحافة التي نأمل أن توفر الوقت للأشخاص.

شكرا لكل شخص!

واجهت نفس المشكلة مع 1.8 في CENTOS 7 مع 1.8؟ أي شخص لديه نفس المشكلة أو يعرف كيفية إصلاحها.

rushins إذا كنت ترغب في الحصول على مساعدة بشأن المشكلة المحتملة التي تراها ، فافتح مشكلة جديدة هنا بتفاصيل كافية.

حصلت على نفس الإصدار مثل @ rushabh268 وهو connection refused وليس localhost:6443/api .
أخيرًا ، قمت بحلها بملاحظة المجال الذي يبحث عن search xxx.xx.xxxx.org .

vi /etc/resolv.congf

------ resolv.congf -----
# Generated by NetworkManager
#search xxx.xx.xxxx.org
nameserver 10.x.xxx.xx
nameserver 10.x.xxx.xx
nameserver 10.x.xxx.xx
--------------------------

Env:
-> CentOS-7-x86_64-Minimal-1708
-> K8s v1.9.2
-> Docker v17.12.0.ce
-> ضمن الشبكة الخاصة xxx.xx.xxxx.org

ارجوكم حب الله يضافوا هذا للمستندات. لقد كنت أحاول إعداد مجموعتي لعدة ليال بعد العمل تحت ستار "الاستمتاع واللعب بالتكنولوجيا" لقد انتهيت من خلال العقدة الرئيسية التي لم تحصل على IP الصحيح عند تشغيل nslookup localhost.

شكرا ل kachkaev على الحل.