Kubeadm: Kubeadm cassé sur armv6l

Créé le 23 avr. 2017  ·  21Commentaires  ·  Source: kubernetes/kubeadm

J'ai essayé d'installer kubeadm sur mon raspberry pi zero W, mais j'obtiens une "instruction illégale"
Sur un raspberry pi 3 (armv7), cela fonctionne très bien.

Commentaire le plus utile

Est-il possible de discuter d'une réintégration d'armv6l Support. J'ai trouvé de nombreux articles montrant l'intérêt d'utiliser Kubernetes sur Pi Zero et d'autres appareils Armv6l Pi. P Zero est bon pour l'hébergement de Micro Services dans des environnements Kubernetes ou Swarm Cluster. Docker Swarm fonctionne bien pour moi. Ce serait donc bien si quelqu'un pouvait recycler la discussion. Pi clusterhat est à proprement parler une belle infrastructure de démonstration.

Tous les 21 commentaires

Je suis confronté au même problème avec kubeadm 1.6.1 sur un Raspberry Pi modèle B+, également 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

J'ai rétrogradé à kubeadm 1.5.6 et cela fonctionne. 1.6.0 donne la même erreur que 1.6.1.

@clabu ouais, la rétrogradation à 1.5.6 fonctionne mais ne peut pas rejoindre un cluster 1.6+.

Tout d'abord, merci d'avoir utilisé Kubernetes sur ARM :smile:!

C'est un problème connu; il a été discuté dans https://github.com/kubernetes/kubernetes/issues/38067 et nous avons abandonné le support armel (quelle partie de RPi 1 utilise lors de la compilation croisée).

Fondamentalement, armhf (GOARM=7) ne peut pas fonctionner sur le Pi 1, nous avons donc utilisé armel avec GOARM=6 en -v1.5 pour prendre en charge RPi 1. Cependant, nous avons utilisé tous les armhf en v1.6, donc cela ne fonctionne pas sur le Pi 1.

Déprécier armel et utiliser les images armhf à la place et utiliser GOARM=7 au lieu de GOARM=6
Motivation:

  • La seule carte GOARM=6 que Go prendra en charge dans go1.8 est le Raspberry Pi 1 qui est tout simplement trop lent pour exécuter les nouvelles versions de Kubernetes.
  • Petites améliorations des performances lors de l'utilisation de GOARM=7
  • Les images armel (http://hub.docker.com/u/armel) ne sont pas mises à jour aussi souvent que les images armhf (http://hub.docker.com/u/armhf).

Par exemple, https://hub.docker.com/r/armel/debian/ a été mis à jour il y a 8 mois, ce qui est vraiment mauvais du point de vue de la sécurité, par rapport à https://hub.docker.com/r/armhf/debian/ qui a été mis à jour il y a 3 jours.

De plus, avec le commutateur armhf, nous avons pu utiliser https://hub.docker.com/r/armhf/alpine , ce qui est génial.

J'espère que cela vous aidera, mais désolé de ne plus pouvoir prendre en charge le RPi 1.

Si vous voulez aider à le documenter/à faire passer le mot, veuillez faire ou venir avec des suggestions

J'ai le même problème sur un Pi Zero

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

Est-il possible de discuter d'une réintégration d'armv6l Support. J'ai trouvé de nombreux articles montrant l'intérêt d'utiliser Kubernetes sur Pi Zero et d'autres appareils Armv6l Pi. P Zero est bon pour l'hébergement de Micro Services dans des environnements Kubernetes ou Swarm Cluster. Docker Swarm fonctionne bien pour moi. Ce serait donc bien si quelqu'un pouvait recycler la discussion. Pi clusterhat est à proprement parler une belle infrastructure de démonstration.

En regardant la version actuelle de docker.io pour le pi zéro,
Version Go : go1.9.3
et version docker : 18.02.0-ce

Il semble utiliser une version récente de go.

Je suis d'accord qu'il n'y a pas assez de RAM pour utiliser k8s dessus en mode autonome, mais en le faisant esclave sur un maître plus gros, il devrait avoir suffisamment de ressources pour faire encore des choses utiles.

Est-ce que quelqu'un sait s'il est possible de simplement construire à partir de la source pour utiliser mes zéros pi comme nœuds k8s?

Par exemple, https://hub.docker.com/r/armel/debian/ a été mis à jour il y a 8 mois, ce qui est vraiment mauvais du point de vue de la sécurité, par rapport à https://hub.docker.com/r/armhf/debian/ qui a été mis à jour il y a 3 jours.

Ce n'est plus vrai aujourd'hui puisque les images officielles sur différentes architectures sont mises à jour simultanément. Par exemple https://hub.docker.com/r/arm32v5/debian/ , https://hub.docker.com/r/arm32v7/debian/ et https://hub.docker.com/r/amd64/ debian/ ont tous été mis à jour il y a 9 jours.

De plus, avec le commutateur armhf, nous avons pu utiliser https://hub.docker.com/r/armhf/alpine , ce qui est génial.

https://hub.docker.com/r/arm32v6/alpine/ fonctionne bien sur Pi Zero.

J'espère que vous le reconsidérerez. Empêcher Pi Zero d'exécuter les derniers k8 est tellement décevant.

@luxas

+1. une certaine confusion s'est produite car le hub a été réorganisé et les anciens repos sont toujours là. Les plus récents semblent recevoir des mises à jour fréquentes.

Salut @juliancheal ,

Je suis toujours en train de construire des k8 sur ClusterHAT, mais j'ai pu compiler et construire des binaires pour Pi Zero.

Fondamentalement, j'ai suivi ce qui suit avec quelques modifications :
https://povilasv.me/raspberrypi-kubelet/

J'ai travaillé sur wsl :
Linux DESKTOP-6GRDDIN 4.4.0-17134-Microsoft #48-Microsoft ven 27 avril 18:06:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux

1 installer gcc-arm-linux-gnueabi au lieu de gcc-arm-linux-gnueabihf

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

2 avant de compiler pour linux/arm, apportez deux modifications à set_platform_envs() dans hack/lib/golang.sh

* ajouter GOARMexporter GOOS=${plateforme%/ }export GOARCH=${plateforme## /}export GOARM=5 <- ajouter* changer de CC
cas "${plateforme}" dans
"linux/bras")
exporter CGO_ENABLED=1
export CC=arm-linux-gnueabi-gcc <-change
;;

GOARM doit être 5. Si vous spécifiez 6, vous obtiendrez une erreur d'éditeur de liens lors de la construction. (Ce que je n'ai pas pu résoudre.)

@shinichi-hashitani Cela fonctionne pour mon Pi Zero ! Merci!

J'ai également résolu votre problème d'erreur de l'éditeur de liens. Pour Pi Zero, définissez GOARM=6 et conservez gcc-arm-linux-gnueabihf. Cependant, pour Pi 1, vous devez définir GOARM=5 et utiliser à la place gcc-arm-linux-gnueabi.

@shinichi-hashitani c'est super ! je vais essayer merci !

@shinichi-hashitani Avez-vous utilisé make all KUBE_BUILD_PLATFORMS=linux/arm pour le construire ? Et si vous avez utilisé kubeadm pour configurer votre cluster, comment avez-vous fait ? Avez-vous copié kubelet , le script d'initialisation povilasv mentionné, kubeadm , et kubectl ? Cela a-t-il fonctionné ?

@dbwest Oui, j'ai utilisé make all pour créer des binaires. Les commandes exactes que j'ai utilisées étaient :

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

J'avais besoin de binaires pour les nœuds, donc seuls ces trois binaires étaient nécessaires.

Je n'ai pas utilisé kubeadm. Je suivais "Kubernetes the Hard Way" de Kelsey Hightower. Comme décrit ici , il vous suffit de placer ces binaires à l'emplacement approprié.

@shinichi-hashitani une idée de la version de kubernetes que vous construisiez ?

Je n'ai pas eu de chance pour que cela soit construit pour arm v6 (en espérant fonctionner sur un pi zero w).

Sur les versions >= 1.12.0 j'obtiens quelque chose comme ça...

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

Et à partir de >= 1.10.0 & < 1.12.0 ( 1.10.0 était le premier que j'ai essayé jusqu'à présent), j'obtiens quelque chose comme ça...

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

EDIT: Nevermind... on dirait que si je construis sur une machine Linux, cela fonctionne. j'essayais de le faire depuis mon mac

@ammmze ,

Je ne sais pas exactement ce qui cause des problèmes de votre côté, mais voici les détails de mon côté :
Kubernetes - 1.10.2
Aller - 19.4
J'ai utilisé WSL (probablement Ubuntu 16.x) pour la compilation croisée de ces binaires.

Encore une fois, j'ai suivi ce qui suit avec quelques modifications :
https://povilasv.me/raspberrypi-kubelet/
Vous pouvez vous y référer pour confirmer les étapes à suivre.

J'ai préparé ma note et les étapes exactes que j'ai suivies, mais désolé, ce n'est disponible qu'en japonais :
https://qiita.com/ShinHashitani/items/ea9ffdefce8ca5786da6

Un mouvement sur l'ajout du support armel pour les pi zéros? J'en ai pas mal et j'aimerais faire un cluster à faible coût/puissance à des fins de démonstration

Un mouvement sur l'ajout du support armel pour les pi zéros? J'en ai pas mal et j'aimerais faire un cluster à faible coût/puissance à des fins de démonstration

salut, comme vous pouvez le voir dans la discussion ci-dessus, le noyau Kubernetes a abandonné la prise en charge d'armv6l.
donc je ne pense pas qu'il y ait une chance que ce support soit rajouté.

si vous voulez utiliser k8s / kubeadm sur armv6l vous devez tout recompiler (y compris les images CNI).

Je viens juste de dire que j'ai compilé avec succès K8s 1.18.3 à partir de la source en le compilant dans l'image docker golang:1.13-alpine, qui est une image multi-arch et inclut un armv6. (J'ai Docker configuré pour utiliser QEMU pour l'émulation et je peux exécuter des conteneurs pour d'autres architectures.)

En clonant simplement le dépôt git et en suivant le processus de création en 4 étapes sur la page readme (c'est-à-dire en faisant simplement tout WHAT=cmd/component), tous les composants de k8s, à l'exception de kubelet, ont été compilés de manière statique et exécutés en tant qu'exécutables autonomes sur mon pi zero, sans dépendances. (Et si golang-alpine cesse de fonctionner, je peux simplement amorcer Arch Linux ARM à partir de zéro, ce qui devrait fonctionner correctement pour la compilation.)

Le seul problème est que la compilation de kubelet est toujours liée de manière dynamique à la bibliothèque système glibc, et je n'ai pas encore trouvé comment résoudre ce problème. Je ne suis pas un programmeur de go, et aucun des indicateurs de compilation que j'ai ajoutés pour go ou pour gcc ne semblait faire de différence. (Kubelet a du code C, je suppose, car il a besoin de gcc pour compiler.) Je suppose que dans le pire des cas, je peux amorcer une image docker pour chaque type de système d'exploitation que j'exécute, donc les liens dynamiques glibc fonctionneront, mais je ne veux pas fais ça.

Debian prend toujours officiellement en charge armel et possède des packages avec une version kubelet liée de manière statique, donc ma solution de piratage consiste actuellement à utiliser simplement leur binaire statique à l'intérieur du package armel deb.

Enfin, vous devez créer votre propre référentiel avec des images contenant ces binaires (ainsi que les autres versions) et configurer kubeadm pour les extraire. Et encore plus amusant, bien que Docker fonctionne sur arm6, il extrait de manière incorrecte les images arm7 (un bug connu depuis plus de 3 ans), vous devez donc soit modifier l'image arm7 pour exécuter simplement la version armel, soit créer à la fois arm6 et arm7 dans le même image et que le point d'entrée soit simplement un script shell qui détermine au moment de l'exécution s'il faut lancer le programme arm6 ou arm7. Les nœuds non maîtres n'ont besoin que d'exécuter kubelet et kube-proxy, ce sont donc probablement les seules images pour lesquelles vous devez le faire. (Un autre hack que j'ai lu sur les personnes qui utilisent est de tirer la bonne image, puis de la re-étiqueter localement pour être l'image que kubeadm veut extraire, donc il utilisera simplement la version locale.)

En fait, j'utilise simplement ansible pour configurer k8s "à la dure", mais j'ai l'intention de continuer à créer des images Docker conformes qui peuvent être des remplacements instantanés afin que kubeadm fonctionne avec eux. Si et quand je peux faire en sorte que kubelet compile correctement de manière statique, j'automatiserai le processus dans un Dockerfile et collerai les images sur Docker Hub. Ces images auront autant d'architectures que je peux utiliser, donc idéalement, nous pourrons utiliser kubeadm sur un cluster multi-architecture. Par exemple amd64, arm64, arm6 et arm7. J'estime que la pleine production Docker et K8 sur Pi Zero (en tant que nœuds de travail) laisse encore au moins 50 Mo à 100 Mo de RAM pour exécuter de petites images. Et si je supprime le noyau, je peux probablement libérer 30 ou 40 Mo supplémentaires. Mais c'est loin dans le futur. Si je peux obtenir une seule page statique servie par un conteneur nginx géré par K8s sur mon Pi Zero, j'appelle cela une victoire pour le moment.


Edit du 7 août: j'ai réussi à tout faire fonctionner et j'ai actuellement un cluster K8s composé de arm6, arm7, arm8 et amd64. Je rédigerai bientôt un compte rendu de mon processus ici, mais pour l'instant, l'important est de faire une installation de kubeadm sur un appareil arm6 en tant que nœud de travail, vous avez besoin de binaires pour kubeadm et kubelet, et seulement deux conteneurs, le conteneur pause et le conteneur kube-proxy. Vous pouvez construire les binaires nativement avec buildx si vous avez QEMU, et simplement modifier mon Dockerfile . (Pour le moment, ce Dockerfile ne fonctionne pas complètement - la version kube-controller-manager ne cesse de se bloquer. Mais vous pouvez créer kubelet, kubeadm, pause, kube-proxy et les plugins CNI.)

Alternativement, vous pouvez extraire les binaires statiques du répertoire /usr/bin dans les packages Arch que j'ai créés pour kubeadm et kubelet . J'ai installé Arch Linux ARM sur mon Pi Zero, et donc les plugins CNI ont été installés dans mon système par un package, mais vous pouvez les construire avec mon Dockerfile (ou les extraire du package Arch Linux ARM) puis placer les binaires CNI dans le répertoire "/opt/cni/bin/" sur votre système. Si vous avez ces binaires CNI dans ce dossier et que kubelet est installé et prêt en tant que service , vous pouvez simplement exécuter kubeadm sur l'appareil et cela devrait fonctionner correctement. La seule exigence est que vous ayez besoin des conteneurs kube-proxy et pause corrects déjà disponibles pour votre moteur de conteneur.

Sur mes Pi Zeroes, j'ai installé Docker d'origine et j'ai utilisé les binaires que j'ai construits à partir du fichier Docker, combinés à l'analyse des conteneurs officiels K8s pour créer un conteneur arm6 compatible pour kube-proxy et pause . Spécifier la version de Kubernetes en tant que v1.18.6 sur kubeadm, nécessitait de ré-étiqueter ces conteneurs comme "k8s.gcr.io/kube-proxy:v1.18.6" et "k8s.gcr.io/pause:3.2" respectivement, mais si ceux-ci conteneurs sont déjà présents et étiquetés correctement sur votre système, alors kubeadm réussira sans se plaindre.

Le seul autre problème est un réseau superposé fonctionnel. Je ne voulais pas vivre plus d'enfer de compilation, alors j'ai utilisé Flannel, dont la variante "arm" fonctionne sur arm6 et arm7. Vous pouvez l'installer avec leur fichier yaml par défaut . Cependant, vous devez ajouter une var env pour toutes les sections appelées FLANNEL_MTU et la définir sur 1430 ou moins. La valeur par défaut, 1500, provoque des problèmes avec metrics-server. De plus, j'ai combiné toutes les images de Flannel en une seule image multi-arches si vous souhaitez l'utiliser. Cela vous permettra de faire ce que j'ai fait et de réduire le fichier d'installation yaml par défaut à une seule section.

Avec cette installation "complète" de K8s utilisant kubeadm et Docker CE, mes Pi Zeroes sont inactifs à environ 55% d'utilisation du processeur et disposent d'environ 160 Mo de mémoire libre. Si nous supposons que je veux laisser au moins 25% pour la capacité de rafale, cela laisse encore environ 20%, ce qui équivaut à 200 millis. (Pi Zero a un processeur monocœur à 1 GHz.) Pour donner une marge de manœuvre supplémentaire, j'ai arrondi et défini ma demande de conteneur et ma limite à 120 m, et la RAM à 100 Mo. Jusqu'à présent, tout fonctionne très bien. Le seul problème est la chaleur, car mes zéros sont tous entassés dans un joli boîtier empilable qui n'a pas beaucoup d'espace d'air.

(Et bien sûr, le nœud du gestionnaire n'est pas un Pi Zero, c'est un Pi 4.)


Edit à partir du 1er décembre 2020 : ce sera ma dernière mise à jour. En fait, il n'y a pas grand chose à ajouter. Kubeadm a un fichier de configuration yaml, comme tous les autres composants k8s, dont aucun n'est très bien documenté... mais vous pouvez vous débrouiller si vous essayez.

L'une des options de kubeadm consiste à utiliser un registre personnalisé pour vos images, afin que vous puissiez créer une image multi-arch et la pousser vers un registre privé, puis l'utiliser pour votre configuration plutôt que de simplement retaper une image dans docker. C'est ce que j'ai fait pour me débarrasser de docker et utiliser directement containerd.

Je n'ai toujours pas compris comment compiler les composants du plan de contrôle pour arm6. QEMU et les périphériques natifs n'autoriseront pas plus de 1 Go de RAM, ce qui n'est pas suffisant pour que Go compile la majeure partie du plan de contrôle. Je suis conscient que Go peut théoriquement compiler pour d'autres architectures, je devrais donc être capable de compiler arm6 sur ma machine amd64, en utilisant toute sa RAM. Mais pour la vie de moi, je ne peux pas faire fonctionner cela, donc je dois compiler les choses nativement dans QEMU ou sur les appareils eux-mêmes. Ce qui signifie qu'il n'y a aucun composant du plan de contrôle arm6.

Mais c'est le seul hic. Kubelet et kubeadm compilent, et le conteneur pause et les conteneurs kube-proxy peuvent également être construits avec buildx. Il est donc encore assez facile de faire fonctionner les composants du nœud de travail pour arm6. Si vous créez un cluster avec des pi zéros, lisez certainement le fichier de configuration de kubelet afin de le modifier pour l'utilisation des ressources. (Ou, vous savez, utilisez des k3 ou une autre distribution légère plutôt que des k8 d'origine.)

J'ai des binaires pour les anciens modèles de framboises publiés ici https://github.com/aojea/kubernetes-raspi-binaries
Ils sont créés avec un travail d'actions github, alors n'hésitez pas à le réutiliser

Cette page vous a été utile?
0 / 5 - 0 notes