Kubeadm: تعليق إجراء فحوصات ما قبل الرحلة

تم إنشاؤها على ١ أبريل ٢٠١٩  ·  22تعليقات  ·  مصدر: kubernetes/kubeadm

ما الكلمات الرئيسية التي بحثت عنها في قضايا kubeadm قبل حفظ هذا؟

الاختبار المبدئي
يشنق
kubeadm الانضمام

تقرير الشوائب

إصدارات

إصدار kubeadm (استخدم kubeadm version ):
إصدار kubeadm: & version.Info {Major: "1"، Minor: "14"، GitVersion: "v1.14.0"، GitCommit: "641856db18352033a0d96dbc99153fa3b27298e5" ، GitTreeState: "نظيف" ، تاريخ الإنشاء: "2019-03-25T15: 51 21Z "، GoVersion:" go1.12.1 "، المترجم:" gc "، النظام الأساسي:" linux / amd64 "}

البيئة :

  • إصدار Kubernetes (استخدم kubectl version ):
    إصدار العميل: version.Info {Major: "1"، Minor: "14"، GitVersion: "v1.14.0"، GitCommit: "641856db18352033a0d96dbc99153fa3b27298e5"، GitTreeState: "clean"، BuildDate: "2019-03-25T15: 53: 57Z "، GoVersion:" go1.12.1 "، المترجم:" gc "، النظام الأساسي:" linux / amd64 "}
  • مزود السحابة أو تكوين الأجهزة :
  • نظام التشغيل (على سبيل المثال من / etc / os-release):
    NAME = "CentOS Linux"
    الإصدار = "7 (الأساسية)"
    المعرف = "centos"
    ID_LIKE = "ريل فيدورا"
    VERSION_ID = "7"
    PRETTY_NAME = "CentOS Linux 7 (Core)"
    ANSI_COLOR = "0 ؛ 31"
    CPE_NAME = "cpe: / o: centos: centos : 7"
    HOME_URL = " https://www.centos.org/ "
    BUG_REPORT_URL = " https://bugs.centos.org/ "

CENTOS_MANTISBT_PROJECT = "CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION = "7"
REDHAT_SUPPORT_PRODUCT = "سنتوس"
REDHAT_SUPPORT_PRODUCT_VERSION = "7"

  • Kernel (على سبيل المثال uname -a ):
    Linux vm02.andrefagundes.org 3.10.0-957.5.1.el7.x86_64 # 1 SMP الجمعة 1 فبراير 14:54:57 UTC 2019 x86_64 x86_64 x86_64 GNU / Linux

  • آخرون :

ماذا حدث؟

مشكلة عند الانضمام إلى طائرة تحكم. العملية معلقة برسالة تشغيل فحوصات ما قبل الرحلة. انظر أدناه:

[ root @ vm02 ~] # kubeadm انضم إلى vm10.andrefagundes. غزاله: 6443 --token 07nh7g.v8p5fcs61fn3o2h4 --discovery-رمزية-كاليفورنيا-سيرت التجزئة SHA256: 039a5f9229dafe39d4a51af6899c20adff1de5dda23f780ac9b896e95f95623a --experimental السيطرة على الطائرة، --certificate مفتاح 8afd066a7b8baa2abf86ba1b2d5e7f29625875d8f78a3e136f7fd35605b4775
[الاختبار المبدئي] إجراء فحوصات ما قبل الرحلة

ماذا توقعت أن يحدث؟

كنت أتوقع أن يتم ضم العقدة أو ظهور رسالة تشير إلى وجود خطأ.

كيف يتم إعادة إنتاجه (بأقل قدر ممكن من الدقة والدقة)؟

أنا أتابع الوثائق الرسمية أدناه.

https://kubernetes.io/docs/setup/independent/high-availability/#external -etcd-nodes

أي شيء آخر نحن بحاجة إلى معرفته؟

رقم.

kinsupport prioritawaiting-more-evidence sinetwork

التعليق الأكثر فائدة

تأكد من الاتصال بـ kubeadm init/join مع مثل --v=2 للحصول على مزيد من التفاصيل حول ما يحدث.

ال 22 كومينتر

مع المعلمة v10.

[ root @ vm03 etcd] # kubeadm انضم إلى vm10.andrefagundes. غزاله: 6443 --token 07nh7g.v8p5fcs61fn3o2h4 --discovery-رمزية-كاليفورنيا-سيرت التجزئة SHA256: 039a5f9229dafe39d4a51af6899c20adff1de5dda23f780ac9b896e95f95623a --experimental السيطرة على الطائرة، --certificate مفتاح cf3c8ca4f74751bfe7fc9d3e00e03a37619d36a6d6fb79fb5ba3645d74dd7bf4 -v10
I0401 00: 34: 08.531961 16893 Join.go: 367] عثر [الاختبار المبدئي] على NodeName فارغًا ؛ باستخدام اسم مضيف نظام التشغيل كـ NodeName
I0401 00: 34: 08.532014 16893 Join.go: 371] [الاختبار المبدئي] تم العثور على إعلان العنوان فارغ ؛ استخدام عنوان IP للواجهة الافتراضية كعنوان إعلاني
I0401 00: 34: 08.532048 16893 initconfiguration.go: 105] تم اكتشافه واستخدامه لمقبس CRI: /var/run/dockershim.sock
I0401 00: 34: 08.532179 16893 interface.go: 384] البحث عن المسارات الافتراضية بعناوين IPv4
I0401 00: 34: 08.532187 16893 interface.go: 389] واجهة عبور المسار الافتراضي "eth0"
I0401 00: 34: 08.532324 16893 interface.go: 196] الواجهة eth0 قيد التشغيل
I0401 00: 34: 08.532380 16893 interface.go: 244] واجهة "eth0" لها 4 عناوين: [192.168.122.103/24 fe80 :: a3c0: 2a34: 91f2: e0eb / 64 fe80 :: 8439: c3eb: 5848: c1f2 / 64 fe80 :: 4381: b4a5: 5836: a0e1 / 64].
I0401 00: 34: 08.532399 16893 interface.go: 211] التحقق من العنوان 192.168.122.103/24.
I0401 00: 34: 08.532407 16893 interface.go: 218] تم العثور على IP 192.168.122.103
I0401 00: 34: 08.532415 16893 interface.go: 250] تم العثور على عنوان IPv4 صالح 192.168.122.103 للواجهة "eth0".
I0401 00: 34: 08.532421 16893 interface.go: 395] تم العثور على عنوان IP نشط 192.168.122.103
[الاختبار المبدئي] إجراء فحوصات ما قبل الرحلة
I0401 00: 34: 08.532495 16893 preflight.go: 90] [الاختبار المبدئي] إجراء الفحوصات العامة
I0401 00: 34: 08.532539 16893 checks.go: 254] التحقق من وجود وفراغ الدليل / etc / kubernetes / manifests
I0401 00: 34: 08.532570 16893 checks.go: 292] التحقق من وجود الملف /etc/kubernetes/kubelet.conf
I0401 00: 34: 08.532579 16893 checks.go: 292] التحقق من وجود الملف /etc/kubernetes/bootstrap-kubelet.conf
I0401 00: 34: 08.532586 16893 checks.go: 105] التحقق من وقت تشغيل الحاوية
I0401 00: 34: 08.580885 16893 checks.go: 131] التحقق مما إذا كانت الخدمة ممكنة ونشطة
I0401 00: 34: 08.638659 16893 checks.go: 341] التحقق من صحة محتويات الملف / proc / sys / net / bridge / bridge-nf-call-iptables
I0401 00: 34: 08.638724 16893 checks.go: 341] التحقق من صحة محتويات الملف / proc / sys / net / ipv4 / ip_forward
I0401 00: 34: 08.638755 16893 checks.go: 653] التحقق من تمكين المبادلة أم لا
I0401 00: 34: 08.638788 16893 checks.go: 382] التحقق من وجود IP القابل للتنفيذ
I0401 00: 34: 08.638809 16893 checks.go: 382] التحقق من وجود iptables القابل للتنفيذ
I0401 00: 34: 08.638824 16893 checks.go: 382] التحقق من وجود التثبيت القابل للتنفيذ
I0401 00: 34: 08.638837 16893 checks.go: 382] التحقق من وجود nsenter القابل للتنفيذ
I0401 00: 34: 08.638849 16893 checks.go: 382] التحقق من وجود جداول إلكترونية قابلة للتنفيذ
I0401 00: 34: 08.638860 16893 checks.go: 382] التحقق من وجود أداة ethtool قابلة للتنفيذ
I0401 00: 34: 08.638871 16893 checks.go: 382] التحقق من وجود socat القابل للتنفيذ
I0401 00: 34: 08.638883 16893 checks.go: 382] التحقق من وجود tc القابل للتنفيذ
I0401 00: 34: 08.638894 16893 checks.go: 382] التحقق من وجود اللمس القابل للتنفيذ
I0401 00: 34: 08.638914 16893 checks.go: 524] تشغيل كافة الفحوصات
I0401 00: 34: 08.664826 16893 checks.go: 412] التحقق مما إذا كان اسم العقدة المحدد يمكن الوصول إليه باستخدام net.
I0401 00: 34: 08.665583 16893 checks.go: 622] التحقق من إصدار kubelet
I0401 00: 34: 08.709573 16893 checks.go: 131] التحقق مما إذا كانت الخدمة ممكنة ونشطة
I0401 00: 34: 08.716270 16893 checks.go: 209] التحقق من توفر المنفذ 10250
I0401 00: 34: 08.716418 16893 checks.go: 439] التحقق مما إذا كان نوع الاتصال عبر وكيل أو مباشر
I0401 00: 34: 08.716444 16893 Join.go: 427] [الاختبار المبدئي] اكتشاف معلومات المجموعة
I0401 00: 34: 08.716498 16893 token.go: 200] [discovery] محاولة الاتصال بخادم API "vm10.andrefagundes. org: 6443 "
I0401 00: 34: 08.716961 16893 token.go: 75] [discovery] عميل اكتشاف معلومات الكتلة ، يطلب معلومات من " https://vm10.andrefagundes.org : 6443"
I0401 00: 34: 08.717031 16893 round_trippers.go: 419] curl -k -v -XGET -H "Accept: application / json، / " -H "User-Agent: kubeadm / v1.14.0 (linux / amd64) kubernetes / 641856d "" https://vm10.andrefagundes.org : 6443 / api / v1 / namespaces / kube-public / configmaps / cluster-info '
I0401 00: 34: 08.722405 16893 round_trippers.go: 438] احصل على https://vm10.andrefagundes.org : 6443 / api / v1 / namespaces / kube-public / configmaps / cluster-info 403 ممنوع في 5 مللي ثانية
I0401 00: 34: 08.722423 16893 round_trippers.go: 444] رؤوس الاستجابة:
I0401 00: 34: 08.722432 16893 round_trippers.go: 447] نوع المحتوى: application / json
I0401 00: 34: 08.722441 16893 round_trippers.go: 447] خيارات نوع المحتوى X: nosniff
I0401 00: 34: 08.722450 16893 round_trippers.go: 447] طول المحتوى: 321
I0401 00: 34: 08.722458 16893 round_trippers.go: 447] التاريخ: الاثنين ، 01 أبريل 2019 03:34:08 بتوقيت جرينتش
I0401 00: 34: 08.722497 16893 request.go: 942] نص الاستجابة: {"kind": "Status"، "apiVersion": "v1"، "metadata": {}، "status": "Failure"، "message ":" configmaps \ "معلومات المجموعة \" ممنوعة: المستخدم \ " النظام: مجهول \ " لا يمكنه الحصول على الموارد \ "configmaps \" في مجموعة API \ "\" في مساحة الاسم \ "kube-public \" "،" السبب ":" Forbidden "،" details ": {" name ":" cluster-info "،" kind ":" configmaps "}،" code ": 403}
I0401 00: 34: 08.722937 16893 token.go: 83] [اكتشاف] فشل في طلب معلومات الكتلة ، ستحاول مرة أخرى: [configmaps "معلومات المجموعة" ممنوع: المستخدم " النظام: مجهول " لا يمكنه الحصول على "configmaps" للمورد في API مجموعة "" في مساحة الاسم "kube-public"]

معلومات أخرى ... vm10.andrefagundes.org هو Haproxy أمام طائرة التحكم الخاصة بي.

يبدو لي كأنه مشكلة في التواصل.
هل أنت متأكد من أن هذه العقدة المنضمة لها اتصال بالمنفذ 6443 على LB ويمكنها حل vm10.andrefagundes.org؟

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

هل ترى أي أخطاء معلقة في سجلات kubelet؟

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

هل إنشاء عقدة مستوى تحكم واحدة + بعض العقد العاملة تعمل من أجلك أم أن المشكلة تحدث فقط عند الانضمام إلى عقد مستوى تحكم إضافية؟

المستخدم " النظام: مجهول " لا يمكنه الحصول على "configmaps" للمورد في مجموعة API "" في مساحة الاسم "kube-public" "،" السبب ":" محظور "،" التفاصيل ": {" الاسم ":" معلومات المجموعة "، "النوع": "configmaps"} ، "الكود": 403

يبدو أن kubeadm init لم تقم بإنشاء / تكوين معلومات المجموعة بشكل صحيح
هل يمكنك مشاركة سجلات init kubeadm؟

لدي نفس الخطأ بعد أن قمت بتنفيذ الأمر "kubeadm Join ...": توقف إجراء فحوصات ما قبل الرحلة. ليس لدي فكرة للتعامل معها.

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

واجهت نفس المشكلات مع kubeadm v1.15 ، لا يعمل سيد إعادة التشغيل بالنسبة لي

واجهت نفس المشكلات مع kubeadm v1.15 ، لا يعمل سيد إعادة التشغيل بالنسبة لي

الرجوع إلى kubelet & kubeadm v1.13.1 لإصلاح هذه المشكلات

تأكد من الاتصال بـ kubeadm init/join مع مثل --v=2 للحصول على مزيد من التفاصيل حول ما يحدث.

اصطدمت بنفس المشكلة ولكن تم تتبع المشكلة وصولاً إلى اتصال الشبكة وجانبي من خلال شياطين الحفاظ على الحياة و haproxy التي تم تكوينها بشكل خاطئ لمنع عقدة hang الرئيسية من الانضمام إلى المجموعة عبر خدمة API VIP

تجدر الإشارة إلى أن تشغيل kubeadm init / انضم مع --v = 2 كان كيف يمكنني حلها

تأكد من الاتصال بـ kubeadm init/join مع مثل --v=2 للحصول على مزيد من التفاصيل حول ما يحدث.

kubeadm v1.15

kubeadm انضم .. --v = 2

I0802 11: 47: 31.027812 359 token.go: 202] [اكتشاف] فشل الاتصال بخادم API "": معرف الرمز "r5uyqk" غير صالح لهذه المجموعة أو انتهت صلاحيته. استخدم "إنشاء رمز مميز kubeadm" في عقدة مستوى التحكم لإنشاء رمز مميز جديد صالح

تحميل شهادات مرحلة kubeadm init-certs -upload-certs
إنشاء رمز kubeadm

ثم kubeadm الانضمام إلى النجاح

في حالتي ، تمكنت من الانضمام إلى العقدة بنجاح عن طريق إيقاف جدار الحماية على العقدة الرئيسية.

systemctl stop firewall

في حالتي ، تمكنت من الانضمام إلى العقدة بنجاح عن طريق إيقاف جدار الحماية على العقدة الرئيسية.

systemctl stop firewall

هذا واحد يعمل مثل السحر.
[ root @ localhost ~] # kubeadm انضم 192.168.8.128:6443 - Token 38lhr8.kxi5uy8aoy71dj17 --discovery-token-ca-cert-hash sha256: a12c805b8d98f42a256486d27e87463e22aaba190ab8b843bdce98ca
[الاختبار المبدئي] إجراء فحوصات ما قبل الرحلة
[تحذير IsDockerSystemdCheck]: تم اكتشاف "cgroupfs" على أنه برنامج تشغيل Docker cgroup. برنامج التشغيل الموصى به هو "systemd". يرجى اتباع الدليل على https://kubernetes.io/docs/setup/cri/
[WARNING SystemVerification]: إصدار Docker هذا غير موجود في قائمة الإصدارات التي تم التحقق من صحتها: 19.03.1. أحدث نسخة مصدقة: 18.09.2019
[الاختبار المبدئي] قراءة التكوين من المجموعة ...
[الاختبار المبدئي] لمعلوماتك: يمكنك إلقاء نظرة على ملف التكوين هذا باستخدام "kubectl -n kube-system get cm kubeadm-config -oyaml"
[kubelet-start] تنزيل التكوين لـ kubelet من ConfigMap "kubelet-config-1.14" في مساحة اسم نظام kube
[kubelet-start] كتابة تكوين kubelet في ملف "/var/lib/kubelet/config.yaml"
[kubelet-start] كتابة ملف بيئة kubelet مع إشارات إلى الملف "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] تفعيل خدمة kubelet
[kubelet-start] في انتظار kubelet لأداء TLS Bootstrap ...

انضمت هذه العقدة إلى الكتلة:

  • تم إرسال طلب توقيع الشهادة إلى apiserver وتم استلام استجابة.
  • تم إبلاغ Kubelet بتفاصيل الاتصال الآمن الجديد.

قم بتشغيل 'kubectl get nodes' على مستوى التحكم لرؤية هذه العقدة تنضم إلى الكتلة.

بالنظر إلى السجل في OP مرة أخرى ، هذا ليس "تعليق" في الاختبار المبدئي ، ولكن لا يمكن الوصول إلى خريطة تكوين معلومات المجموعة ، الطريقة الوحيدة التي يمكن أن يحدث هذا إذا كانت مرحلة "boostrap-token" من "init" تم تخطيه.

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

/ دعم الفرز
للأسئلة ، جرب stackoverflow أو reddit أو #kubeadm على k8s slack.

إذا وجدت خطأ حقيقيًا من فضلك ، افتح عددًا جديدًا.

في حالتي ، تمكنت من الانضمام إلى العقدة بنجاح عن طريق إيقاف جدار الحماية على العقدة الرئيسية.

systemctl stop firewall

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

أجد عدم السماح لحركة المرور بتوصيل العقدة الرئيسية.

إضافة القواعد في سان جرمان يحل مشكلتي

لدي نفس الخطأ بعد أن قمت بتنفيذ الأمر "kubeadm Join ...": توقف إجراء فحوصات ما قبل الرحلة. ليس لدي فكرة للتعامل معها.

هل وجدت اى حلول؟

أجد عدم السماح لحركة المرور بتوصيل العقدة الرئيسية.

إضافة القواعد في سان جرمان يحل مشكلتي

ما المنفذ الداخلي الذي سمحت به؟

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات