أواجه نفس المشكلة مع kubeadm 1.6.1 على Raspberry Pi Model B + ، وكذلك armv6.

$ kubelet --help
Illegal instruction

$ uname -a
Linux pi1 4.4.50-hypriotos+ #2 PREEMPT Sun Mar 19 14:44:01 UTC 2017 armv6l GNU/Linux

خفضت إلى kubeadm 1.5.6 وهو يعمل. 1.6.0 يعطي نفس خطأ 1.6.1.

clabu ، نعم ، الرجوع إلى

أولاً ، شكرًا لاستخدام Kubernetes على ARM: ابتسم!

هذه مشكلة معروفة؛ تمت مناقشته في https://github.com/kubernetes/kubernetes/issues/38067 وقمنا بإسقاط دعم armel (الذي يستخدمه جزء من RPi 1 عند التجميع المتقاطع).

بشكل أساسي ، لا يمكن تشغيل armhf (GOARM = 7) على Pi 1 ، لذلك استخدمنا armel مع GOARM = 6 في -v1.5 لدعم RPi 1. ومع ذلك ، فقد ذهبنا إلى armhf في الإصدار 1.6 ، وبالتالي فهو لا يعمل ال Pi 1.

قلل من قيمة armel واستخدم صور armhf بدلاً من ذلك واستخدم GOARM = 7 بدلاً من GOARM = 6
التحفيز:

• GOARM = 6 board Go الوحيدة التي ستدعمها في go1.8 هي Raspberry Pi 1 وهي بطيئة جدًا لتشغيل إصدارات Kubernetes الأحدث.
• تحسينات صغيرة في الأداء عند استخدام GOARM = 7
• لا يتم تحديث صور armel (http://hub.docker.com/u/armel) بقدر ما يتم تحديث صور armhf (http://hub.docker.com/u/armhf).

على سبيل المثال ، تم تحديث https://hub.docker.com/r/armel/debian/ منذ 8 أشهر وهو أمر سيء حقًا من وجهة نظر الأمان ، مقابل https://hub.docker.com/r/armhf/debian/ الذي تم تحديثه منذ 3 أيام.

أيضًا ، باستخدام مفتاح armhf ، تمكنا من استخدام https://hub.docker.com/r/armhf/alpine ، وهو أمر رائع.

آمل أن يساعدك ذلك ، ولكن آسف لعدم قدرتك على دعم RPi 1 بعد الآن.

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

أواجه نفس المشكلة على Pi Zero

Linux p1 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l GNU/Linux

هل من الممكن مناقشة إعادة تكامل armv6l Support. لقد وجدت العديد من المشاركات التي تظهر الاهتمام باستخدام Kubernetes على Pi Zero وأجهزة armv6l Pi الأخرى. P Zero جيد لاستضافة Micro Services في Kubernetes أو بيئات Swarm Cluster. يعمل Docker Swarm بشكل جيد بالنسبة لي. لذلك سيكون من الرائع أن يتمكن أي شخص من إعادة تدوير المناقشة. Pi الكتلة هي بشكل صحيح بنية تحتية تجريبية لطيفة.

بالنظر إلى بناء docker.io الحالي لصفر pi ،
إصدار Go: go1.9.3
وإصدار عامل التحميل: 18.02.0 م

يبدو أنه يستخدم إصدارًا حديثًا من go.

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

هل يعرف أي شخص ما إذا كان من الممكن فقط البناء من المصدر لاستخدام أصفار pi كعقد k8s؟

على سبيل المثال ، تم تحديث https://hub.docker.com/r/armel/debian/ منذ 8 أشهر وهو أمر سيء حقًا من وجهة نظر الأمان ، مقابل https://hub.docker.com/r/armhf/debian/ الذي تم تحديثه منذ 3 أيام.

هذا ليس صحيحًا اليوم حيث يتم تحديث الصور الرسمية على البنى المختلفة في وقت واحد. على سبيل المثال https://hub.docker.com/r/arm32v5/debian/ و https://hub.docker.com/r/arm32v7/debian/ و https://hub.docker.com/r/amd64/ تم تحديث

أيضًا ، باستخدام مفتاح armhf ، تمكنا من استخدام https://hub.docker.com/r/armhf/alpine ، وهو أمر رائع.

https://hub.docker.com/r/arm32v6/alpine/ يعمل جيدًا على Pi Zero.

أتمنى أن تعيد النظر في الأمر. منع Pi Zero من تشغيل أحدث k8s أمر مخيب للآمال للغاية.

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

+1. حدث بعض الالتباس أثناء إعادة ترتيب المحور ولا تزال عمليات إعادة الشراء الأقدم موجودة. يبدو أن الإصدارات الأحدث تحصل على تحديثات متكررة.

مرحبا juliancheal ،

ما زلت في منتصف بناء k8s على ClusterHAT ، لكنني تمكنت من تجميع وبناء ثنائيات لـ Pi Zero.

في الأساس ، لقد اتبعت ما يلي مع بعض التعديلات:
https://povilasv.me/raspberrypi-kubelet/

عملت على wsl:
Linux DESKTOP-6GRDDIN 4.4.0-17134-Microsoft # 48-Microsoft الجمعة 27 أبريل 18:06:00 PST 2018 x86_64 x86_64 x86_64 GNU / Linux

1 قم بتثبيت gcc-arm-linux-gnueabi بدلاً من gcc-arm-linux-gnueabihf

sudo apt-get install gcc-arm-linux-gnueabi <- change

2 قبل إنشاء نظام Linux / arm ، قم بإجراء تعديلين على set_platform_envs () في hack / lib / golang.sh

* إضافة GOARMتصدير GOOS = $ {platform٪ / }تصدير GOARCH = $ {platform ## /}تصدير GOARM = 5 <- add* تغيير CC
حالة "$ {platform}" في
"لينكس / ذراع")
تصدير CGO_ENABLED = 1
تصدير CC = arm-linux-gnueabi-gcc <-change
؛؛

يجب أن يكون GOARM هو 5. إذا حددت 6 ، فستتلقى خطأ رابط أثناء الإنشاء. (الذي لم أتمكن من حله.)

@ shinichi-hashitani إنه يعمل مع Pi Zero الخاص بي! شكرا!

كما أنني حل مشكلتك على خطأ رابط. بالنسبة إلى Pi Zero ، اضبط GOARM = 6 واحتفظ بـ gcc-arm-linux-gnueabihf. لكن بالنسبة إلى Pi 1 ، يجب عليك تعيين GOARM = 5 واستخدام gcc-arm-linux-gnueabi بدلاً من ذلك.

@ shinichi-hashitani هذا شيء عظيم! سأجربها شكرا!

@ shinichi-hashitani هل استخدمت make all KUBE_BUILD_PLATFORMS=linux/arm لإنشائه؟ وإذا استخدمت kubeadm لإعداد مجموعتك ، فكيف فعلت ذلك؟ هل قمت بنسخ ما يزيد عن kubelet ، و povilasv النص البرمجي الأولي المذكور ، و kubeadm ، و kubectl ؟ هل نجحت؟

dbwest نعم ، كنت أجعل كل شيء لبناء ثنائيات. الأوامر الدقيقة التي استخدمتها هي:

make all WHAT=cmd/kube-proxy KUBE_VERBOSE=5 KUBE_BUILD_PLATFORMS=linux/arm
make all WHAT=cmd/kubelet KUBE_VERBOSE=5 KUBE_BUILD_PLATFORMS=linux/arm
make all WHAT=cmd/kubectl KUBE_VERBOSE=5 KUBE_BUILD_PLATFORMS=linux/arm

كنت بحاجة إلى ثنائيات للعقد ، لذلك كانت هناك حاجة إلى تلك الثنائيات الثلاثة فقط.

لم أستخدم kubeadm. كنت أتابع أغنية Kubernetes the Hard Way لكيلسي هايتاور. كما هو موضح هنا ، تحتاج فقط إلى وضع هذه الثنائيات في المكان المناسب.

@ shinichi-hashitani أي فكرة ما هو إصدار kubernetes الذي كنت تقوم ببنائه؟

لم يحالفني الحظ في الحصول على هذا من أجل arm v6 (آمل أن يتم تشغيله على pi zero w).

في الإصدارات >= 1.12.0 أحصل على شيء مثل هذا ...

vendor/github.com/google/cadvisor/accelerators/nvidia.go:30:2: build constraints exclude all Go files in /private/var/folders/hn/gt2l8vq56vx9slvwry43xmz40000gn/T/tmp.A83ZihlF/_output/local/go/src/k8s.io/kubernetes/vendor/github.com/mindprince/gonvml
!!! [0511 07:36:41] Call tree:
!!! [0511 07:36:41]  1: /private/var/folders/hn/gt2l8vq56vx9slvwry43xmz40000gn/T/tmp.A83ZihlF/hack/lib/golang.sh:601 kube::golang::build_some_binaries(...)
!!! [0511 07:36:41]  2: /private/var/folders/hn/gt2l8vq56vx9slvwry43xmz40000gn/T/tmp.A83ZihlF/hack/lib/golang.sh:736 kube::golang::build_binaries_for_platform(...)
!!! [0511 07:36:41]  3: hack/make-rules/build.sh:27 kube::golang::build_binaries(...)
!!! Error in /private/var/folders/hn/gt2l8vq56vx9slvwry43xmz40000gn/T/tmp.A83ZihlF/hack/lib/golang.sh:561
  Error in /private/var/folders/hn/gt2l8vq56vx9slvwry43xmz40000gn/T/tmp.A83ZihlF/hack/lib/golang.sh:561. 'go install "${build_args[@]}" "$@"' exited with status 1

ومن >= 1.10.0 & < 1.12.0 ( 1.10.0 كانت الأقدم التي جربتها حتى الآن) ، حصلت على شيء كهذا ...

F0511 07:39:30.480641   26683 openapi.go:116] Failed loading boilerplate: open /private/var/folders/hn/gt2l8vq56vx9slvwry43xmz40000gn/T/tmp.A83ZihlF/_output/local/go/src/k8s.io/gengo/boilerplate/boilerplate.go.txt: no such file or directory
!!! Error in ./hack/run-in-gopath.sh:33
  Error in ./hack/run-in-gopath.sh:33. '"${@}"' exited with status 255
Call stack:
  1: ./hack/run-in-gopath.sh:33 main(...)
Exiting with status 1
make[1]: *** [pkg/generated/openapi/zz_generated.openapi.go] Error 1
make: *** [generated_files] Error 2

تحرير: لا يهم ... يبدو كما لو أنني بنيت على جهاز لينكس يعمل. كنت أحاول القيام بذلك من جهاز Mac الخاص بي

@ ammmze ،

لست متأكدًا تمامًا من سبب المشكلات من جانبك ، ولكن ما يلي هو التفاصيل من ناحيتي:
Kubernetes - 1.10.2
اذهب - 19.4
لقد استخدمت WSL (ربما Ubuntu 16.x) لتجميع تلك الثنائيات.

مرة أخرى ، اتبعت ما يلي مع بعض التعديلات:
https://povilasv.me/raspberrypi-kubelet/
يمكنك الرجوع إلى هذا للتأكيد على الخطوات التي يجب اتباعها.

لقد أعددت ملاحظتي والخطوات الدقيقة التي اتبعتها ، ولكن آسف أن هذا متاح باللغة اليابانية فقط:
https://qiita.com/ShinHashitani/items/ea9ffdefce8ca5786da6

أي حركة لإضافة دعم خلفي Armel لـ pi Zero's؟ لدي عدد غير قليل من الأشياء وأرغب في إنشاء مجموعة منخفضة التكلفة / الطاقة للأغراض التجريبية

أي حركة لإضافة دعم خلفي Armel لـ pi Zero's؟ لدي عدد غير قليل من الأشياء وأرغب في إنشاء مجموعة منخفضة التكلفة / الطاقة للأغراض التجريبية

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

إذا كنت تريد استخدام k8s / kubeadm على armv6l ، فيجب إعادة تجميع كل شيء (بما في ذلك صور CNI).

أنا فقط أدق صوتي لأقول إنني نجحت في تجميع K8s 1.18.3 من المصدر من خلال تجميعها في golang: 1.13-alpine docker image ، وهي صورة متعددة الأقواس وتتضمن armv6. (لقد تم تكوين Docker لاستخدام QEMU للمضاهاة ويمكنه تشغيل حاويات لأبنية أخرى.)

بمجرد استنساخ git repo ، واتباع عملية التصنيع المكونة من 4 خطوات على الصفحة التمهيدية (على سبيل المثال ، قم فقط بإجراء جميع WHAT = cmd / المكون) ، تم تجميع جميع مكونات k8s باستثناء kubelet بشكل ثابت وتشغيلها كملفات تنفيذية مستقلة على pi صفر ، بدون تبعيات. (وإذا توقف golang-alpine عن العمل ، يمكنني فقط تمهيد Arch Linux ARM من البداية ، والذي يجب أن يعمل بشكل جيد للتجميع.)

المشكلة الوحيدة هي أن تجميع kubelet لا يزال يرتبط ديناميكيًا بمكتبة النظام glibc ، ولم أتوصل بعد إلى معرفة كيفية إصلاح ذلك. أنا لست مبرمج go ، ولا يبدو أن أيًا من علامات التجميع التي أضفتها لـ go أو gcc قد أحدثت فرقًا. (يحتوي Kubelet على بعض رموز C على ما أعتقد ، لأنه يحتاج إلى دول مجلس التعاون الخليجي لتجميعه.) أعتقد أن أسوأ حالة يمكنني من خلالها تمهيد صورة عامل تشغيل لكل نوع من أنظمة التشغيل التي أقوم بتشغيلها ، لذا ستعمل الروابط الديناميكية glibc ، لكنني لا أريد ذلك إفعل ذلك.

لا يزال Debian يدعم Armel رسميًا ولديه حزم بإصدار kubelet مرتبط بشكل ثابت ، لذا فإن الحل المبتكر الذي أقدمه حاليًا هو استخدام ثنائي ثابت من داخل حزمة armel deb.

أخيرًا ، عليك إنشاء مستودعك الخاص بالصور التي تحتوي على هذه الثنائيات (بالإضافة إلى الإصدارات الأخرى) ، وتكوين kubeadm لسحبها. وحتى أكثر متعة ، على الرغم من أن Docker يعمل على arm6 ، إلا أنه يسحب بشكل غير صحيح صور arm7 (خطأ معروف لأكثر من 3 سنوات) ، لذلك تحتاج إما إلى تغيير صورة arm7 لتشغيل إصدار armel فقط ، أو إنشاء كل من arm6 و arm7 في نفس الصورة ويكون فقط نقطة الدخول عبارة عن نص برمجي يحدد في وقت التشغيل ما إذا كان سيتم تشغيل برنامج arm6 أو arm7. تحتاج العقد غير الرئيسية فقط إلى تشغيل kubelet و kube-proxy ، لذلك ربما تكون هذه هي الصور الوحيدة التي تحتاج إلى القيام بذلك من أجلها. (اختراق آخر قرأته عن الأشخاص الذين يستخدمونه هو سحب الصورة الصحيحة ثم إعادة وضع علامات عليها محليًا لتكون أي صورة يريد kubeadm سحبها ، لذلك سيستخدم الإصدار المحلي فقط.)

أنا في الواقع أستخدم فقط ansible لإعداد k8s "بالطريقة الصعبة" ، لكنني ما زلت أعتزم إنشاء صور Docker متوافقة يمكن أن تكون بدائل سهلة الاستخدام حتى يعمل kubeadm معهم. إذا وعندما يمكنني الحصول على kubelet للترجمة الثابتة بشكل صحيح ، فسوف أقوم بأتمتة العملية في Dockerfile وألصق الصور على Docker Hub. ستحتوي هذه الصور على العديد من البنى التي يمكنني استخدامها ، لذلك من الناحية المثالية ، سنكون قادرين على استخدام kubeadm في مجموعة متعددة البنى. على سبيل المثال amd64 و arm64 و arm6 و arm7. أقدر أن الإنتاج الكامل Docker و K8s على Pi Zero (كعقد عاملة) لا يزال يترك ما لا يقل عن 50 ميجابايت -100 ميجابايت من ذاكرة الوصول العشوائي المتبقية لتشغيل الصور الصغيرة. وإذا جردت النواة ، يمكنني على الأرجح تحرير 30 أو 40 ميغا أخرى. لكن هذا بعيد في المستقبل. إذا كان بإمكاني الحصول على صفحة ثابتة واحدة يتم تقديمها بواسطة حاوية nginx تُدار بواسطة K8s على Pi Zero ، فأنا أعتبر هذا فوزًا في الوقت الحالي.

تحرير من 7 أغسطس: لقد تمكنت من تشغيل كل شيء ، ولدي حاليًا مجموعة K8s تتكون من arm6 و arm7 و arm8 و amd64. سأقوم بعمل كتابة لعمليتي في وقت ما قريبًا هنا ، ولكن في الوقت الحالي ، المهم هو إجراء تثبيت kubeadm على جهاز arm6 كعقدة عاملة ، فأنت بحاجة إلى ثنائيات لـ kubeadm و kubelet ، وحاويتين فقط ، حاوية الإيقاف المؤقت وحاوية وكيل kube. يمكنك إنشاء الثنائيات محليًا باستخدام buildx إذا كان لديك QEMU ، وقم فقط بتعديل Dockerfile الخاص بي. (في الوقت الحالي ، لا يعمل Dockerfile هذا بشكل كامل - يستمر بناء kube-controller-manager في التجمد. ولكن يمكنك إنشاء kubelet و kubeadm و pause و kube-proxy و CNI plugins.)

بدلاً من ذلك ، يمكنك سحب الثنائيات الثابتة من / usr / bin dir في حزم Arch التي صنعتها لـ kubelet . لقد قمت بتثبيت Arch Linux ARM على Pi Zero الخاص بي ، ولذا تم تثبيت مكونات CNI الإضافية في نظامي بواسطة حزمة ، ولكن يمكنك بناؤها باستخدام Dockerfile الخاص بي (أو سحبها من حزمة Arch Linux ARM) ثم وضع ثنائيات CNI في الدليل "/ opt / cni / bin /" على نظامك. إذا كان لديك ثنائيات CNI هذه في هذا المجلد ، وكان لديك kubelet مثبتًا وجاهزًا كخدمة ، فيمكنك فقط تشغيل kubeadm على الجهاز ويجب أن يعمل بشكل جيد. الشرط الوحيد هو أنك بحاجة إلى حاويات kube-proxy الصحيحة والإيقاف المؤقت المتوفرة بالفعل لمحرك الحاوية الخاص بك.

على Pi Zeroes ، لدي مخزون Docker مثبت ، واستخدمت الثنائيات التي أنشأتها من ملف Docker ، جنبًا إلى جنب مع تحليل حاويات K8s الرسمية لبناء حاوية arm6 متوافقة مع وكيل kube والتوقف المؤقت . تحديد إصدار Kubernetes كـ v1.18.6 على kubeadm ، يتطلب إعادة وضع علامات على هذه الحاويات كـ "k8s.gcr.io/kube-proxy:v1.18.6" و "k8s.gcr.io/pause:3.2" على التوالي ، ولكن إذا كانت هذه الحاويات موجودة بالفعل وتم وضع علامات عليها بشكل صحيح على نظامك ، ثم سينجح kubeadm دون شكوى.

المشكلة الأخرى الوحيدة هي شبكة تراكب عاملة. لم أكن أرغب في الخوض في المزيد من جحيم التجميع ، لذلك استخدمت Flannel ، الذي يعمل متغير "arm" الخاص به على arm6 و arm7. يمكنك تثبيته مع ملف defautl yaml الخاص بهم . ومع ذلك ، يجب عليك إضافة var var لجميع الأقسام المسماة FLANNEL_MTU وتعيينه على 1430 أو أقل. الافتراضي ، 1500 ، يسبب بعض المشاكل مع خادم المقاييس. بالإضافة إلى ذلك ، قمت بدمج جميع صور Flannel في صورة واحدة متعددة الأقواس إذا كنت تريد استخدام ذلك. سيسمح لك ذلك بالقيام بما قمت به وتجريد ملف تثبيت yaml الافتراضي إلى قسم واحد فقط.

مع تثبيت K8s "الكامل" باستخدام kubeadm و Docker CE ، فإن Pi Zeroes الخاصة بي تكون خاملة عند استخدام حوالي 55٪ من وحدة المعالجة المركزية ، ولديها حوالي 160 ميجابايت من الذاكرة الخالية. إذا افترضنا أنني أريد ترك ما لا يقل عن 25٪ لسعة الانفجار ، فإن ذلك لا يزال يترك حوالي 20٪ ، وهو ما يعادل 200 مللي. (يحتوي Pi Zero على وحدة معالجة مركزية أحادية النواة بسرعة 1 جيجاهرتز.) لإعطاء مساحة إضافية للمناورة ، قمت بتقريب وتعيين طلب الحاوية الخاص بي إلى 120 مترًا والحد الأقصى لذاكرة الوصول العشوائي إلى 100 ميجا بايت. حتى الآن ، كل شيء يعمل بشكل جيد. المشكلة الوحيدة هي الحرارة ، نظرًا لأن أصفاري كلها محشورة معًا في علبة لطيفة قابلة للتكديس لا تحتوي على مساحة هوائية كبيرة.

(وبالطبع ، عقدة المدير ليست Pi Zero ، إنها Pi 4.)

تحرير من 1 كانون الأول (ديسمبر) 2020: سيكون هذا آخر تحديث لي. في الواقع ، ليس هناك الكثير لإضافته. يحتوي Kubeadm على ملف تكوين yaml ، كما هو الحال مع جميع مكونات k8s الأخرى ، والتي لم يتم توثيق أي منها جيدًا ... ولكن يمكنك الخوض في الأمر إذا حاولت.

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

ما زلت لم أكتشف بعد كيفية تجميع مكونات طائرة التحكم لـ arm6. لن تسمح كل من QEMU والأجهزة الأصلية بأكثر من 1 جيجابايت من ذاكرة الوصول العشوائي ، وهو ما لا يكفي لـ Go لتجميع معظم مستوى التحكم. أدرك أن Go نظريًا يمكنه تجميع أبنية أخرى ، لذلك يجب أن أكون قادرًا على تجميع arm6 على جهاز amd64 الخاص بي ، باستخدام كل ذاكرة الوصول العشوائي الخاصة به. لكن بالنسبة لحياتي ، لا يمكنني تشغيل ذلك ، لذلك تركت تجميع الأشياء محليًا إما في QEMU أو على الأجهزة نفسها. مما يعني عدم وجود مكونات طائرة التحكم arm6.

لكن هذا هو الفواق الوحيد. تجميع Kubelet و kubeadm ، ويمكن أيضًا بناء حاوية الإيقاف المؤقت وحاويات وكيل kube باستخدام buildx. لذلك لا يزال من السهل جعل مكونات العقدة العاملة تعمل مع arm6. إذا كنت تقوم بإنشاء مجموعة باستخدام أصفار pi ، فقم بالتأكيد بقراءة ملف تكوين kubelet من أجل تعديله لاستخدام الموارد. (أو ، كما تعلم ، استخدم k3s أو توزيعة أخرى خفيفة الوزن بدلاً من k8s كامل المخزون.)

لدي ثنائيات لنماذج التوت القديمة منشورة هنا https://github.com/aojea/kubernetes-raspi-binaries
تم إنشاؤها بوظيفة إجراءات جيثب ، لذلك لا تتردد في إعادة استخدامها