Kubeadm: فشل apiserver في البدء لأن livenessprobe عدواني للغاية

يبدو أننا عيّننا كلاً من InitialDelaySeconds و TimeoutSeconds على 15 لقرون مستوى التحكم حاليًا ، وهو ما يطابق ما يفعله kube-up.sh أيضًا. أتفهم أن الإطلاق الأولي كان بطيئًا ، حيث يتم سحب جميع الصور مرة واحدة ، ولكن بعد سحب جميع الصور ، ما هو الوقت الذي يستغرقه خادمك للرد على شيكات /healthz بعد إطلاقه؟

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

بمجرد أن تبدأ ، يمكنها الاستجابة للفحوصات الصحية في << 15 ثانية - إنها حقًا مجرد كل الأشياء الإضافية التي يقوم بها الخادم بين exec () والاستعداد فعليًا لخدمة afaics.

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

أنا أواجه نفس المشكلة. مع الآلات البطيئة kubeadm يجلس إلى الأبد. باستخدام v1.7.4

anguslees و koalalorenzo ، هل يمكنك التأكيد على أنه إذا قمت بتغيير إعدادات مسبار الحياة يدويًا (عن طريق تحرير ملفات البيان في /etc/kubernetes/manifests/ ) فإن هذا سيؤدي إلى حل مشكلتك؟ لقد رأيت مؤخرًا أيضًا حالة على Slack حيث كان لدى المستخدم نفس الأعراض ولكن من المحتمل أن يواجه قيودًا في الذاكرة ، لأن المشكلة اختفت عندما انتقلوا إلى نوع مضيف به ذاكرة أكبر.

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

أواجه هذه المشكلة أيضًا عند محاولة استخدام kubeadm في QEMU بدون المحاكاة الافتراضية بمساعدة الأجهزة (وهي فكرة سيئة لأنها بطيئة للغاية). زيادة InitialDelaySeconds و TimeoutSeconds يساعد؛ ثم تظهر الكتلة في النهاية.

pipejakob يمكنني أن أؤكد أنه (على bananapi الخاص بي) تشغيل هذا في محطة أخرى في النقطة الصحيحة في تشغيل kubeadm يجعل كل شيء يأتي بنجاح:

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

(عادةً ما أقوم أيضًا يدويًا بـ docker kill حاوية apiserver القديمة / إعادة التشغيل ، لست متأكدًا مما إذا كان يتم تنظيفها تلقائيًا باستخدام القرون الثابتة)

anguslees عظيم! شكرا للتاكيد.

يمكنني أن أؤكد أنني واجهت هذه المشكلة أيضًا ، في حالتي على Raspberry Pi 3. التغيير إلى 180s تم إصلاحه ، ومع ذلك أعتقد أنني واجهت أيضًا المشكلة رقم 106 كما في حالتي ، لقد ماتت ببساطة:

1 سبتمبر 10:47:30 raspberrypi kubelet [6053]: W0901 10: 47: 30.020409 6053 kubelet.go: 1596] حذف جراب المرآة "kube-apiserver-raspberrypi_kube-system (7c03df63-8efa-1
1e7-ae86-b827ebdd4b52) "لأنها قديمة

اضطررت إلى HUP عملية kubelet يدويًا لإعادتها إلى الحياة.

يمكنني أيضًا أن أؤكد أنني حصلت على هذا وأردت أن أشكرك على حفظ سلامة عقلي. لدي Raspberry Pi 2B وكنت عالقًا في مرحلة البدء في الشهر الماضي. بعد تشغيل ذلك الخط المفرد بمجرد أن بدأ في انتظار طائرة التحكم ، قمت بالمضي قدمًا.

لا تزال هذه المشكلة موجودة في kubeadm v1.8.0 ، وهي أسوأ لأن kubeadm نفسها لديها الآن مهلة دقيقة واحدة على معظم الإجراءات. يبدو أن مهلة 1min قد تم اختيارها بشكل تعسفي ، وللأسف أ) لا تمنحك الوقت الكافي للدخول في المشكلة وتصحيحها / حلها (على سبيل المثال: sed hack أعلاه) ، ب) وقت كافٍ لبدء Apiserver (~ 90s بالنسبة لي) ، حتى عندما تم تمديد firstDelaySeconds ، و c) لا يمكن زيادتها دون القرصنة / إعادة بناء afaics kubeadm .

المهلات تكسر المنطق الصحيح ، لا سيما في الأنظمة المعقدة المتسقة في النهاية - يجب ألا نضيفها أبدًا "لمجرد" :( ما أفهمه هو أن kubeadm يُقصد به أن يكون لبنة يمكن أن تعتمد عليها أنظمة النشر الأكبر. وبالتالي ، أقترح بجرأة إزالة جميع المهلات من kubeadm نفسها (يجب أن تستمر المراحل المختلفة في إعادة المحاولة إلى الأبد) ، والاعتماد على عملية المستوى الأعلى لإضافة مهلة إجمالية إذا / عندما يكون ذلك مناسبًا في سياق المستوى الأعلى هذا. في حالة الاستخدام البسيط / المباشر هذا قد يعني "أعد المحاولة حتى يستسلم المستخدم ويضغط على ^ c". هل هذا PR مقبول؟

anguslees كان لدينا

المشكلة هي أن استخدام kubeadm ذو شقين. كلانا لديه مستخدمون يكتبون kubeadm بشكل تفاعلي ويريدون معرفة ما إذا كان هناك شيء ما يحدث أم لا _والمستهلكين ذوي المستوى الأعلى.

.. إذن ما هو الاتجاه الذي سنذهب إليه هنا؟ أستخدم حاليًا مفترقًا kubeadm يحتوي على العديد من المهلات التي تم رفعها بمقدار 10x ، وأود _أود _ أن أصدق أنه يمكنني العودة إلى استخدام الثنائيات القياسية kubeadm في مرحلة ما.

anguslees كان لدينا

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

/ أولوية مهمة قريبا

هل يعقل أن يكون لديك خيار واحد يمتلكها جميعًا؟

ربما ، أو نوعًا ما من "الوزن" لجميع المهلات المراد ضربها ... وإلا فإننا سندخل في جحيم التكوين مع 20 نوعًا مختلفًا من علامات المهلة :)

تشغيل نفس المشكلة باستخدام ترقية kubeadm على مجموعة raspberry pi 2. فشل الترقية بسبب المهلات العدوانية. لا يساعد تغيير إعدادات مسبار الحيوية في البيانات. أيه أفكار؟

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

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

بالنسبة إلى مهلات llifeProbe الواضحة الأصلية ، فهي حرفياً عبارة عن رقعة ذات بطانة واحدة. لسوء الحظ ، لم يعد إصلاح livityProbe وحده كافياً لأن مغالطة "الانحراف عن الخطأ == العادي" انتشرت أكثر في جميع أنحاء قاعدة الكود kubeadm. يعد تغيير الوعي الثقافي أمرًا صعبًا ، لذلك في هذه الأثناء لدي نسخة متشعبة من kubeadm هنا ، إذا كان أي شخص يريد فقط التثبيت على raspberry pi. (إنشاء باستخدام make cross WHAT=cmd/kubeadm KUBE_BUILD_PLATFORMS=linux/arm )

anguslees هل لديك نسخة مجمعة 1.9.4 من kubeadm المصحح؟ أواجه مشكلة في تجميع نسختك المصححة.

أنا مندهش من أن kubeadm ليس لديه هذا السلوك وراء العلم. ربما العلاقات العامة في محله؟

/ تعيين liztio

لذلك قمنا بإصلاح مشكلتين في 1.11 يمكن أن تؤثر على ذلك.

1. قم بإعداد صورة الخردة قبل بدء التشغيل.
2. إصلاح فحص حالة السباق عند بدء التشغيل.
   ...

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

ما هي أقل منصة مستهدفة نخطط لدعمها؟

أعتقد أن Raspberry Pi 2 هو أدنى منصة (منصات) تريد تشغيل Kubernetes عليها. اختباراتي مع QEMU التي لا

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

imo rasberry pi2 قديم جدًا بحيث يتعذر دعمه - http://socialcompare.com/en/comparison/raspberrypi-models-comparison ، صدر في عام 2015.

>= 3 أكثر معقولية IMO.

لن يساعد سحب الصور. لا يبدأ مؤقت livenessProbe إلا بعد سحب الصورة (كما أشرت أعلاه ).

الإصلاح هو فقط لتوسيع مهلة (فترات) initialDelaySeconds . يتم إساءة استخدام قيم المهلة الحالية في kubeadm "لفرض" تجربة UX سريعة ، وليس اكتشاف الأخطاء.

تحرير: ولكي نكون واضحين ، فإن بدء التشغيل فقط هو الذي يستغرق وقتًا طويلاً - تعمل مجموعة التحكم الخاصة بي على 3xRPi2 على ما يرام ، بمجرد زيادة مهلة apiserver intialDelaySeconds (ومهلة التثبيت الأخرى المستخدمة داخل kubeadm نفسها). لا أفهم لماذا ما زلنا نتحدث عن هذا: /

لدي مجموعة ARM64 على 1.9.3 وتم تحديثها بنجاح إلى 1.9.7 ولكن حصلت على مشكلة المهلة للترقية من 1.9.7 إلى 1.10.2.

حتى أنني حاولت تحرير وإعادة ترجمة kubeadm لزيادة المهلات (مثل هذه الالتزامات الأخيرة https://github.com/anguslees/kubernetes/commits/kubeadm-gusfork) بنفس النتائج.

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

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

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

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

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

carlosedp ما أفعله أثناء الترقية هو إزالة kubelet أثناء تمهيد الخادم. إنه نوع من الاختراق ، لكنه يمنع الفحص الصحي من إطلاق النار حتى ينتهي apiserver.

لكن بصراحة kubeadm upgrade و ARM لا يعملان جيدًا معًا في تجربتي ...

brendandburns لقد عملت بشكل مثالي حتى 1.9. لقد قمت بنشر مجموعة 1.8 الخاصة بي معها بدون عوائق ، ثم قمت بالترقية إلى 1.9 مرتين. لا توجد فكرة عما قد تغير في 1.10 لسبب هذه المشاكل.

رأيت أن المهلة تغيرت في 1.11 إلى 5 دقائق (https://github.com/kubernetes/kubernetes/pull/64988/files#diff-2056df5f0c3a4828b3f9a2510a7533c7L45). هل جربت 1.11؟

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

تضمين التغريدة
نعم ، يرجى المحاولة 1.11 لتأكيد أن زيادة المهلة تعد بمثابة حل لك.

/ cc @ kubernetes / sig-الكتلة-دورة الحياة-البق

مهلا! أواجه هذه المشكلة أيضًا.
ومن المثير للاهتمام ، أنني تمكنت من بناء مجموعة رئيسية من نقطة الصفر على جهاز Raspberry 3 الخاص بي ، لكنني أخفق باستمرار في بناء 3+.
على أي حال ، الإصدار الذي أستخدمه حاليًا (وفقًا للوثائق التفصيلية على https://blog.hypriot.com/post/setup-kubernetes-raspberry-pi-cluster/) هو
kubeadm version: &version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:14:41Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/arm"}

كما هو الحال مع الآخرين ، فإن حاوية apiserver تستيقظ في النهاية ، ولكن ليس قبل أن يخرج kubeadm بكفالة ، مما يتركني في طي النسيان لأنني لست خبيرًا في الالتقاط يدويًا من هناك.

تحديث سريع: قيد التشغيل
watch -n 1.0 "sed -i 's/initialDelaySeconds: [0-9]\+/initialDelaySeconds: 180/' /etc/kubernetes/manifests/kube-apiserver.yaml"
في محطة طرفية منفصلة سمحت لكتلتي بالاستيقاظ.

تضمين التغريدة
شكرا لاختبار 1.11.

كما هو الحال مع الآخرين ، فإن حاوية apiserver تستيقظ في النهاية ، ولكن ليس قبل أن يخرج kubeadm بكفالة ، مما يتركني في طي النسيان لأنني لست خبيرًا في الالتقاط يدويًا من هناك.

كم من الوقت يستغرقه المنفذ ليبدأ في حالتك؟
يبدو أننا قد نضطر إلى جعل هذا قابلًا للتكوين.

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

بالإضافة إلى ذلك ، بعد أن أصبح معلمي جاهزًا للعمل ، أخفق في إضافة عقدة إليه فيما يبدو أنه مشكلة أخرى تتعلق بالمهلة.
"[الاختبار المبدئي] إجراء فحوصات ما قبل الرحلة
[تحذير مطلوب IPVSKernelModulesAvailable]: لن يتم استخدام الخادم الوكيل IPVS ، لأنه لم يتم تحميل وحدات kernel المطلوبة التالية: [ip_vs_rr ip_vs_wrr ip_vs_sh ip_vs] أو عدم دعم kernel ipvs المدمج: map [ip_vs_rr_ {}: ip_vr_} nf_conntrack_ipv4: {} ip_vs: {}]
يمكنك حل هذه المشكلة بالطرق التالية:

1. قم بتشغيل "modprobe -" لتحميل وحدات kernel المفقودة ؛
   
   
   
   1. توفير دعم ipvs المدمج المفقود في kernel
   
   

I0708 19: 02: 20.256325 8667 kernel_validator.go: 81] التحقق من إصدار kernel
I0708 19: 02: 20.256846 8667 kernel_validator.go: 96] التحقق من صحة تهيئة kernel
[WARNING SystemVerification]: إصدار عامل الإرساء أكبر من أحدث إصدار تم التحقق من صحته. إصدار عامل الإرساء: 18.03.1 م. أقصى إصدار تم التحقق منه: 17.03.2020
[اكتشاف] محاولة الاتصال بخادم API "192.168.2.2:6443"
[اكتشاف] تم إنشاء عميل اكتشاف معلومات الكتلة ، لطلب معلومات من " https://192.168.2.2 : 6443"
[اكتشاف] طلب معلومات من " https://192.168.2.2 : 6443" مرة أخرى للتحقق من صحة TLS مقابل المفتاح العام المثبت
[اكتشاف] توقيع معلومات الكتلة ومحتوياتها صالحة ويتم التحقق من صحة شهادة TLS مقابل الجذور المثبتة ، وستستخدم خادم API "192.168.2.2:6443"
[اكتشاف] تم بنجاح إنشاء اتصال بخادم API "192.168.2.2:6443"
[kubelet] تنزيل تكوين kubelet من ConfigMap "kubelet-config-1.11" في مساحة اسم نظام kube
[kubelet] كتابة تكوين kubelet في ملف "/var/lib/kubelet/config.yaml"
[kubelet] كتابة ملف بيئة kubelet مع إشارات إلى الملف "/var/lib/kubelet/kubeadm-flags.env"
[الاختبار المبدئي] تفعيل خدمة kubelet
[tlsbootstrap] في انتظار kubelet لأداء TLS Bootstrap ...
[kubelet-check] يبدو أن الكوبيليت لا يعمل أو لا يتمتع بصحة جيدة.
[kubelet-check] يبدو أن الكوبيليت لا يعمل أو لا يتمتع بصحة جيدة.
[kubelet-check] يبدو أن الكوبيليت لا يعمل أو لا يتمتع بصحة جيدة.
[kubelet-check] يبدو أن الكوبيليت لا يعمل أو لا يتمتع بصحة جيدة.
[kubelet-check] يبدو أن الكوبيليت لا يعمل أو لا يتمتع بصحة جيدة.
للأسف ، حدث خطأ:
انتهت مهلة انتظار الشرط

من المحتمل أن يكون سبب هذا الخطأ:
- الكوبيليت لا يعمل
- kubelet غير صحي بسبب خطأ في تكوين العقدة بطريقة ما (cgroups المطلوبة معطلة)

إذا كنت تستخدم نظامًا يعمل بنظام systemd ، فيمكنك محاولة استكشاف الخطأ وإصلاحه باستخدام الأوامر التالية:
- "kubelet حالة systemctl"
- "Journalctl -xeu kubelet"
انتهت مهلة انتظار الشرط

خلال هذا الوقت ، لا تظهر حاوية عامل إرساء واحدة على عقدي.

[تحذير مطلوب IPVSKernelModulesAvailable]:

خارج الموضوع ، نحن نتحدث عن هذا هنا:
https://github.com/kubernetes/kubeadm/issues/975

بالإضافة إلى ذلك ، بعد أن أصبح معلمي جاهزًا للعمل ، أخفق في إضافة عقدة إليه فيما يبدو أنه مشكلة أخرى تتعلق بالمهلة.
[kubelet-check] فشل استدعاء HTTP الذي يساوي "curl -sSL http: // localhost : 10248 / healthz" بسبب الخطأ: احصل على http: // localhost : 10248 / healthz: dial tcp [:: 1]: 10248: connect : الاتصال مرفوض.

kubelet لا يمكن أن تبدأ. نظرة أفضل على سجلات kubelet.

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

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

أعتقد أن هذه هي القيم المستخدمة ، لذلك إذا كنت تقوم ببناء kubeadm بنفسك ، فحاول اللعب بها:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96
لكن ضع في اعتبارك أن هذا من شأنه أن يزيد المهلات على جميع مكونات مستوى التحكم.

تحرير: يبدو أنني غبي جدًا بحيث لا يمكنني تنسيق التعليقات بشكل صحيح في Github :-(

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

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

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






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

من فضلك ، ضع في اعتبارك أن هذه السجلات لا تظهر أي أخطاء.

نعم ولكن هذا جزء من المشكلة على ما أعتقد. لا يمكنني العثور على سطر نهائي واحد من [ERROR] في أي مكان لتبدأ به. هذا ما يحبطني كثيرًا :-)

على أي حال ، شكرًا لتنسيق هذه الفوضى الخاصة بي :- D

إذن ما هي الخطوة التالية الجيدة؟

إذن ما هي الخطوة التالية الجيدة؟

كما تم ذكره سابقا:

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

أعتقد أن هذه هي القيم المستخدمة ، لذلك إذا كنت تقوم ببناء kubeadm بنفسك ، فحاول اللعب بها:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96
لكن ضع في اعتبارك أن هذا من شأنه أن يزيد المهلات على جميع مكونات مستوى التحكم.

لا أقوم ببناء kubeadm بنفسي ، فأنا أسحبه عبر apt من apt.kubernetes.io. ليس لدي أي شيء يشبه خط أنابيب البناء عن بعد للذهاب إلى أي من أجهزتي (لم يتم العبث به بعد). كنت آمل أن يكون هناك ملف مشابه يمكن تعديله عند الانضمام إلى مجموعة مثل تلك التي كانت موجودة في إنشائها ، ولكن يبدو أن هذه القيم مشفرة بشكل ثابت في utils.go: - |

يمكنك تجربة هذا الحل ، لكنه صعب:
https://github.com/kubernetes/kubeadm/issues/413#issuecomment -402916173

المشكلة هي أن هذا يحتاج إلى تغيير في التكوين ولا أعتقد أنه يمكن تضمينه في إصدار 1.11.X (ولكن يمكننا المحاولة). يجب أيضًا مناقشتها أولاً.

هذا ما فعلته بالفعل في التعليق حيث أخبرتك أن السيد يعمل (هذا ما كان يفعله أمر ساعتي -n 1.0). ما يحدث الآن هو أن kubeadm Join لا يعمل ، وبقدر ما أستطيع أن أرى ، لا يضع kubeadm Join ملفات yaml بالنسبة لي لتصحيحها في أي مكان: - /

قد تواجه مشكلة أخرى. من الصعب القول.

هذه هي القيم المستخدمة ، لذلك إذا كنت تقوم ببناء kubeadm بنفسك فحاول اللعب بها:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96

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

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

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

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

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

نعم ، تمت مناقشة الخيارات بالفعل في هذا الموضوع. إنها مسألة اختيار الخيار الصحيح وتنفيذ التنفيذ.

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

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

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

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

angusleesDJGummikuh كان لدينا نقاش حول ذلك في الاجتماع SIG مؤخرا.

هذه مشكلة شائكة ، ولكن فيما يلي بعض الملاحظات العشوائية أدناه.

ملاحظات:

• يتمتع بعض موظفينا بخبرة كبيرة ويقولون أن هذه الرائحة تشبه رائحة العرق التي توقف بداية الخادم. لن يستغرق الأمر كل هذا الوقت. قد يكون هذا شيء ARM مقابل GOLANG.
• لقد طلبت من SIG API Machinery ولكن لم أحصل على أي رد على قيم مسبار الحياة المقترحة وإذا كانوا يشكون في نوع مختلف من المشكلات هنا.
• لقد اتفقنا على أن عرض خيار التكوين أو متغير البيئة أو معلمة سطر الأوامر فكرة سيئة لـ kubeadm . السبب وراء ذلك هو أننا لا نريد كشف المعلمات التي يمكن أن يكون لها معنى تعسفي تمامًا للمستخدمين.
• لم يرَ أحد في الفريق مثل هذه المشكلة على الأجهزة البطيئة (مثل الأجهزة الافتراضية البطيئة) ، مما يعني أن هذا قد يكون متعلقًا بـ RPi وأن الحجة الكاملة القائلة بأن هذا يرجع إلى الأجهزة "البطيئة" غير صالحة.
• ألق نظرة على هذا: https://github.com/kubernetes/kubernetes/issues/64357 لا يقوم المستخدم بالإبلاغ عن مشكلة تحقيق في الحياة على الإطلاق. اي فكرة لماذا هذا؟
• هل رأى أي شخص مشكلة في شيء مثل https://www.scaleway.com/ ، وفقًا للنظرية الواردة في هذا الموضوع ، يجب أن تحدث مشكلة أيضًا؟
• كخط أساسي ، لقد ناقشنا أن إنشاء قيم مهلة / تأخير أكبر لن يكون مهمًا جدًا بالنسبة لـ kubeadm ، لذلك إذا أراد شخص ما إرسال PR لذلك ، فتابع. ( anguslees )

ألق نظرة على هذا: kubernetes / kubernetes # 64357 ، لا يقوم المستخدم بالإبلاغ عن مشكلة مسبار حيوي على الإطلاق. اي فكرة لماذا هذا؟

لا ، حتى أنه لا يبدو قابلاً للتكرار حقًا على أجهزتي الآن. نظرًا لانقضاء الرمز المميز للانضمام إلى العقد ، فكرت في "ما هيك" و kubeadm إعادة تعيين مدير المجموعة الخاص بي وحاولت إعادة تهيئته (بعد تشغيل الحل البديل للساعة) - الآن حتى مع هذا الحل البديل لم أعد قادرًا على سحب ماجستير في Raspberry Pi 3+. لقد قمت بزيادة المهلة المكونة من 180 إلى 300 ثانية دون أي فرق. لذلك أحب فكرة أن تكون هذه حالة سباق.
ما زلت أرحب باقتراحك لسحب طلب مهلات أعلى. لن يضر كثيرًا ويمنح pi (وهو جهاز بطيء ، أعتقد أننا جميعًا يمكننا الاتفاق على ذلك :-)) مساحة أكبر للتنفس.

قضية ذات صلة على ARM64 في apiserver:
https://github.com/kubernetes/kubernetes/issues/64649

قمت ببعض البحث مع (ما زلت فاشلة :-() Pi Cluster خلال عطلة نهاية الأسبوع.

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

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

أي شخص على مستوى التحدي؟ ^ ^

هذه مشكلة حقيقية خارج kubeadm ...

لم ينظر العاملون في ماكينات api إلى طلبي للتعليق على المشكلة ، لذا ما لم يتم تسجيل تذكرة لهذا بالفعل ، يجب على شخص ما تسجيل واحدة في الريبو kubernetes/kubernetes وعلامة /sig api-machinery .

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

كبداية ، يمكن للمرء تمكين --v 4 لـ kubelet في ملف إسقاط systemd ، والذي سيخبر مسجل GLOG لتمكين الإسهاب العالي.
يمكن للمرء أيضًا أن يفعل الشيء نفسه لمكونات مستوى التحكم من تكوين kubeadm مع هذا:
https://kubernetes.io/docs/setup/independent/control-plane-flags/

أدى هذا إلى حل المشكلة في مجموعة Raspberry Pi 3 الخاصة بي: https://github.com/kubernetes/kubernetes/pull/66264

joejulian nice لقد تمكنت من تصحيح ذلك والآن أيضًا تشتعل الكتلة الخاصة بي. أخيرا ، بعد أسابيع من العذاب! شكرا لك :-)

@ joejulian شكرا على التحقيق!
يمكن العثور على إصلاح محتمل في https://github.com/kubernetes/kubernetes/pull/66264

يغلق حتى إشعار آخر.

/قريب

هل هناك طريقة لتمرير مثل هذه الإعدادات في ملف البادئة kubeadm؟ ربما بدولار apiServerExtraArgs ؟ إنه لأمر مؤلم أن تراقب الملفات من أجل تصحيحها ، نوعًا ما يصعب أتمتة

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

أضافت التحديثات اللاحقة المزيد من الأشياء للتحقق منها ولم تعد المهلة الممتدة التي قدمتها للعلاقات العامة كافية. لقد تخليت عن إدارة المهلة. كان الحل بالنسبة لي هو استخدام شهادات ecdsa.

بالإضافة إلى ذلك ، تستهلك خدمات التحكم بما في ذلك etcd المزيد من ذاكرة الوصول العشوائي ، الآن ، مقارنةً بـ Raspberry Pi بدلاً من مضاعفة عدد العقد لاستضافة مستوى التحكم ، لقد قمت بالترقية إلى Rock64s.

عفواً ، لكن طائرة التحكم الخاصة بي كانت صلبة منذ ذلك الحين.

لقد كنت أحاول فقط إجراء تثبيت على Raspberry Pi 3+ ويمكنني أن أؤكد أن التثبيت فشل بالفعل. يبدو أن استخدام خدعة "الساعة" على kube-apiserver.yaml المذكورة أعلاه تعمل باستمرار ... ولكن فقط إذا غيرت التأخير الأولي إلى 360. تبدو القيمة المقترحة 180 هامشية على أجهزتي.

فقط عندما تصبح الأمور سهلة للغاية ، يشتكي kubeadm الآن من أن إصدار Docker (18.09) غير مدعوم. عودة سريعة إلى 18.06 تم إصلاح المشكلة.

في kubeadm 1.13 نضيف علامة التكوين ضمن ClusterConfig-> ApiServer التي يمكنها التحكم في مهلة خادم api.
https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1
timeoutForControlPlane

علامة التكوين ضمن ClusterConfig-> ApiServer التي يمكنها التحكم في مهلة خادم api.

عند البحث في قاعدة الشفرة عن TimeoutForControlPlane ، أعتقد أن هذا الإعداد الافتراضي هو 4 دقائق ، ويستخدم فقط للتأخير الذي يستخدمه kubeadm نفسه لانتظار أن يصبح الخادم سليمًا. على وجه الخصوص ، لا يغير مجس حياة apiserver المستخدم بواسطة kubelet نفسه. هل هذا صحيح؟

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

بعيدًا: بقدر ما أستطيع أن أرى من قراءة سريعة ، لا يأخذ TimeoutForControlPlane أيضًا في الاعتبار أسباب عدم فشل أخرى لزيادة تأخير بدء تشغيل الخادم ، مثل الازدحام أثناء سحب صور متعددة ، أو مهلة إضافية + حلقة إعادة المحاولة التكرارات بينما يتقارب كل شيء في وقت التثبيت الأولي (المهلة + إعادة المحاولة بشكل متكرر هو نمط تصميم k8s ... وهذا يحدث أحيانًا على نظام محمل ، وهو أمر متوقع وعلى ما يرام). أنا شخصياً أشعر أن 4minutes طويلة جدًا بالنسبة للمستخدمين التفاعليين غير الصبورين الذين يتوقعون فشلًا سريعًا ، وقصر جدًا لعملية التثبيت على نظام محمّل / بطيء / آلي جاهز للانتظار لفترة أطول لتحقيق النجاح المتوقع. كيف تم التوصل إلى هذا ، هل يمكننا التقصير في 5 دقائق؟ هل يمكننا الاستمرار في المحاولة حتى SIGINT؟ لماذا نفرض موعدًا نهائيًا مصطنعًا على مدار الساعة داخليًا بدلاً من أن نرثه من بيئة الاتصال؟

يقوم Afaics TimeoutForControlPlane بالكشف عن موعد نهائي داخلي فادح تعسفي كمعامل حيث يكون UX المقصود الوحيد هو زيادة المعلمة حتى لا يتم الوصول إلى الموعد النهائي مطلقًا. بدلاً من ذلك ، يمكننا فقط _لا_ فرض ذلك الموعد النهائي الداخلي القاتل التعسفي في المقام الأول ...

هذه نقطة ممتازة وأنا أتفق معها بصدق.

على وجه الخصوص ، لا يغير مجس حياة apiserver المستخدم بواسطة kubelet نفسها. هل هذا صحيح؟

نعم ، لا توجد خطط لتعديل تحقيقات الحياة من kubeadm ، حتى الآن.

تم تصنيف مشكلة rpi هذه في اجتماع sig-الكتلة-lifecyle على أنها "شيء لا يجب أن يحدث" ، "يبدو تقريبًا مثل حالة سباق في kubelet" ، "لماذا يحدث ذلك فقط على rpi وليس على الأجهزة الأخرى الأبطأ". يجب أن أعترف أنني لم أختبر الأجهزة البطيئة بنفسي.

أي كان هناك اتفاق على أن زيادة هذه القيمة:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L97
ليس حلاً جيدًا ويبدو أنه حل بديل لخلل آخر.

كيف تم التوصل إلى هذا ، هل يمكننا التقصير في 5 دقائق؟

كانت المهلة 30 دقيقة قبل أن تكون 4 دقائق ، لأنها أخذت سحب الصور في الاعتبار قبل 1.11.
إذا كان لديك رأي في 4 مقابل 5 دقائق ، فقد تصل العلاقات العامة المحددة جيدًا مع نقاط قوية حول الموضوع إلى 1.14.

تم تصنيف مشكلة rpi هذه في اجتماع sig-الكتلة-lifecyle على أنها "شيء لا يجب أن يحدث" ، "يبدو تقريبًا مثل حالة سباق في kubelet" ، "لماذا يحدث ذلك فقط على rpi وليس على الأجهزة الأخرى الأبطأ".

هذه كلها أسباب لمواصلة البحث عن خطأ آخر في مكان آخر أيضًا ، ولكن لا أحد من هذه الأسباب _ لا _ لزيادة التأجيل الأولي. هل هناك بالفعل جانب سلبي لزيادة التأخير الأولي؟

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

(أعتذر عن السماح لبعض إحباطي حول هذه المشكلة بالتسرب إلى نبرة صوتي)

إذا كان لديك رأي في 4 مقابل 5 دقائق

تنهد. كنت أحاول إثبات قضية _ no_ timeout في kubeadm ، لكنني لم أجد طريقة لتعبير هذا الاقتراح بشكل مقنع (انظر هذا والمحاولات الفاشلة الأخرى في هذه المسألة ، على سبيل المثال) :(

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

إنه تغيير بسيط ، ولكن تم الاتفاق على عدم إضافة هذه الزيادة لأنها ستنطبق أيضًا على الأنظمة التي لا تمارس المشكلة.

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

مواجهة المستخدم النهائي هو هدف kubeadm ، هذا صحيح.
ولكن مرة أخرى ، إنه مجرد تقرير لـ rpis ويجب تصعيد الخطأ الفعلي إلى sig-api-machinery (خادم api) و sig-node (kubelet) ومن المحتمل إعادة إنتاجه خارج kubeadm.

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

ليس عليك تصحيح kubeadm ، يمكنك تصحيح ملفات البيان بدلاً من ذلك.
يخرج kubeadm 1.13 مراحل init لأوامر المستوى الأعلى - على سبيل المثال kubeadm init phase [phase-name]
توجد المراحل في الغالب لأن المستخدمين يريدون التحكم المخصص في كيفية إنشاء عقدة مستوى التحكم ..

إذا قمت بعمل kubeadm init --help فسوف يظهر لك الترتيب الذي يتم به تنفيذ المراحل.

حتى تتمكن من تقسيم الأمر kubeadm init إلى المراحل المناسبة ، يمكنك استخدام البيانات المخصصة لمكونات مستوى التحكم وتخطي المرحلة control-plane . هناك أيضًا --skip-phases الآن.

يمكنك فعل ذلك بالفعل في 1.11 و 1.12 ، لكنه أقل مباشرة.

لأنه سينطبق أيضًا على الأنظمة التي لا تمارس المشكلة.

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

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

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

إضافة خيار تكوين kubeadm لهذا الأمر غير مرجح في هذه المرحلة.

أحاول أن أوضح أن هذا ممكن بالفعل من خلال 3 أوامر في 1.13:

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

لا أريد خيارًا ، أحاول أن أقول إن القيمة الثابتة الحالية (15) يجب تغييرها إلى قيمة ثابتة مختلفة (تم اقتراح 360 أعلاه).

.. لكني لا أريد أن أمضي قدما في هذا أكثر من ذلك. واضح أن القرار هو التمسك بالقيمة الحالية ، لذا سأنسحب مهزومة. شكرا لصبرك :)

@ neolit123 يبدو هذا المزيج رائعًا - أسهل بكثير مما https://github.com/alexellis/k8s-on-raspbian/blob/master/GUIDE.md

سأختبر التعليمات وسأبحث عن تحديث الدليل.

@ neolit123 هذا ما حصلت عليه باستخدام التكوين أعلاه على RPi3 B +

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

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

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

في kubeadm-config.yaml - 192.168.0.26 هو LB يشير إلى 192.168.0.110

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

أحصل على نفس الشيء حتى بدون التكوين الخارجي / lb IP.

اليكس

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

ماذا عن التسوية؟ بدلاً من جعله قابلاً للتكوين ، أضف إرشادًا بسيطًا يقول ، إن لم يكن x86_64 ، فقم بتعيين المهلة الافتراضية أعلى؟

[kubeconfig] كتابة ملف "admin.conf" kubeconfig
[kubeconfig] كتابة ملف "kubelet.conf" kubeconfig
الذعر: خطأ وقت التشغيل: عنوان ذاكرة غير صالح أو عدم وجود إشارة مرجعية
[إشارة SIGSEGV: رمز انتهاك التجزئة = 0x1 addr = 0x8 pc = 0xaa7204]

غريب ، admin.conf تم إنشاؤه آليًا ويجب أن يحتوي على نوع Config صالح مع ملف current-context يشير إلى سياق.

الذعر يأتي من هذا الخط:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go#L236

أشاهد نفس الخطأ تمامًا مثل: point_up: أعلاه مع ما يلي:

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

البرنامج النصي التالي يحل المشكلة بالنسبة لي باستخدام إصدارات kubeadm 1.12 و 1.13 ( معظم الوقت)

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

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

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

كنت في نفس الموقف ، وحصلت على نفس الخطأ مع النهج الذي اقترحه @ neolit123 .
لم أتمكن من تشغيل البرنامج النصي بواسطة stephenmoloney ، لست على دراية

لذلك قمت بنقل البرنامج النصي إلى python (والذي يتم تثبيته افتراضيًا على Raspbian ، لذلك لا داعي لمزيد من التبعيات) ، في حالة اهتمام أي شخص:

import os
import time
import threading

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

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

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

لتشغيله: sudo python however_you_name_the_file.py
شكرًا لك على توجيهي إلى الحل ، @ neolit123 !

أهلا! كانت هذه المسألة مفيدة للغاية

لقد وجدت طريقة رائعة لحل هذا باستخدام التخصيص

mkdir /tmp/kustom

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

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

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