Estoy enfrentando el mismo problema con kubeadm 1.6.1 en una Raspberry Pi Model B +, también 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

Bajé a kubeadm 1.5.6 y funciona. 1.6.0 da el mismo error que 1.6.1.

@clabu sí, la degradación a 1.5.6 funciona pero no puede unirse a un clúster 1.6+.

En primer lugar, gracias por usar Kubernetes en ARM: smile :!

Este es un problema conocido; se discutió en https://github.com/kubernetes/kubernetes/issues/38067 y eliminamos el soporte de armel (que parte de RPi 1 usa cuando se realiza la compilación cruzada).

Básicamente armhf (GOARM = 7) no se puede ejecutar en Pi 1, por lo que usamos armel con GOARM = 6 en -v1.5 para admitir RPi 1. Sin embargo, usamos armhf en v1.6, por lo que no está funcionando el Pi 1.

Desactive armel y use imágenes armhf en su lugar y use GOARM = 7 en lugar de GOARM = 6
Motivación:

• La única placa GOARM = 6 que Go admitirá en go1.8 es la Raspberry Pi 1, que es demasiado lenta para ejecutar versiones más nuevas de Kubernetes.
• Pequeñas mejoras de rendimiento al usar GOARM = 7
• Las imágenes de armel (http://hub.docker.com/u/armel) no se actualizan con tanta frecuencia como las imágenes de armhf (http://hub.docker.com/u/armhf).

Por ejemplo, https://hub.docker.com/r/armel/debian/ se actualizó hace 8 meses, lo cual es realmente malo desde el punto de vista de la seguridad, frente a https://hub.docker.com/r/armhf/debian/ que se actualizó hace 3 días.

Además, con el interruptor armhf, pudimos usar https://hub.docker.com/r/armhf/alpine , lo cual es genial.

Espero que ayude, pero lamento no poder soportar más el RPi 1.

Si desea ayudar a documentarlo / correr la voz, hágalo o venga con sugerencias

Tengo el mismo problema en un Pi Zero

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

¿Es posible discutir una reintegración de armv6l Support? Encontré muchas publicaciones que muestran interés por usar Kubernetes en Pi Zero y otros dispositivos armv6l Pi. P Zero es bueno para alojar microservicios en Kubernetes o entornos de clúster Swarm. Docker Swarm funciona bien para mí. Así que sería bueno si alguien pudiera reciclar la discusión. Pi clusterhat es una buena infraestructura de demostración.

Mirando la compilación actual de docker.io para pi zero,
Go versión: go1.9.3
y versión de Docker: 18.02.0-ce

Parece estar usando una versión reciente de go.

Estoy de acuerdo en que no hay suficiente RAM para usar k8s en él en modo independiente, pero al ser esclavo de un maestro más grande, debería tener suficientes recursos para hacer algunas cosas útiles todavía.

¿Alguien sabe si es posible simplemente construir desde la fuente para usar mis ceros pi como nodos k8s?

Por ejemplo, https://hub.docker.com/r/armel/debian/ se actualizó hace 8 meses, lo cual es realmente malo desde el punto de vista de la seguridad, frente a https://hub.docker.com/r/armhf/debian/ que se actualizó hace 3 días.

Esto no es cierto hoy en día, ya que las imágenes oficiales en diferentes arquitecturas se actualizan simultáneamente. Por ejemplo https://hub.docker.com/r/arm32v5/debian/ , https://hub.docker.com/r/arm32v7/debian/ y https://hub.docker.com/r/amd64/ Debian / se actualizaron hace 9 días.

Además, con el interruptor armhf, pudimos usar https://hub.docker.com/r/armhf/alpine , lo cual es genial.

https://hub.docker.com/r/arm32v6/alpine/ funciona bien en Pi Zero.

Espero que lo reconsidere. Evitar que Pi Zero ejecute los últimos k8 es muy decepcionante.

@luxas

+1. Se ha producido cierta confusión cuando se reorganizó el centro y los repositorios más antiguos todavía existen. Los más nuevos parecen recibir actualizaciones frecuentes.

Hola @juliancheal ,

Todavía estoy en medio de la construcción de k8s en ClusterHAT, pero pude compilar y crear binarios para Pi Zero.

Básicamente, he seguido lo siguiente con algunas modificaciones:
https://povilasv.me/raspberrypi-kubelet/

Trabajé en wsl:
Linux DESKTOP-6GRDDIN 4.4.0-17134-Microsoft # 48-Microsoft Vie 27 de abril 18:06:00 PST 2018 x86_64 x86_64 x86_64 GNU / Linux

1 instale gcc-arm-linux-gnueabi en lugar de gcc-arm-linux-gnueabihf

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

2 antes de compilar para linux / arm, haga dos modificaciones a set_platform_envs () en hack / lib / golang.sh

* agregar GOARMexportar GOOS = $ {plataforma% / }exportar GOARCH = $ {plataforma ## /}exportar GOARM = 5 <- agregar* cambiar CC
caso "$ {plataforma}" en
"linux / arm")
exportar CGO_ENABLED = 1
exportar CC = arm-linux-gnueabi-gcc <-cambiar
;;

GOARM tiene que ser 5. Si especifica 6, obtendrá un error de vinculador durante la compilación. (Lo cual no pude resolver).

@ shinichi-hashitani ¡Funciona para mi Pi Zero! ¡Gracias!

También resolví su problema en el error del vinculador. Para Pi Zero, establezca GOARM = 6 y mantenga gcc-arm-linux-gnueabihf. Sin embargo, para Pi 1 debes establecer GOARM = 5 y usar gcc-arm-linux-gnueabi en su lugar.

@ shinichi-hashitani ¡esto es genial! ¡Lo intentaré gracias!

@ shinichi-hashitani ¿Usaste make all KUBE_BUILD_PLATFORMS=linux/arm para construirlo? Y si usó kubeadm para configurar su clúster, ¿cómo lo hizo? ¿Copiaste más de kubelet , el script de inicio povilasv mencionado, kubeadm y kubectl ? ¿Funcionó?

@dbwest Sí, usé make all para construir binarios. Los comandos exactos que utilicé fueron:

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

Necesitaba binarios para los nodos, por lo que solo se necesitaban esos tres binarios.

No usé kubeadm. Estaba siguiendo "Kubernetes the Hard Way" de Kelsey Hightower. Como se describe aquí , solo necesita colocar esos binarios en la ubicación adecuada.

@ shinichi-hashitani ¿alguna idea de qué versión de kubernetes estabas construyendo?

No he tenido suerte al hacer que esto se compile para arm v6 (con la esperanza de ejecutar en un pi zero w).

En las versiones >= 1.12.0 obtengo algo como esto ...

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

Y desde >= 1.10.0 & < 1.12.0 ( 1.10.0 fue lo primero que probé hasta ahora), obtengo algo como esto ...

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

EDITAR: No importa ... parece que si construyo en una máquina Linux, funciona. Estaba tratando de hacerlo desde mi mac

@ammmze ,

No estoy exactamente seguro de qué está causando problemas en su extremo, pero los detalles a continuación son los míos:
Kubernetes - 1.10.2
Ir - 19.4
Usé WSL (probablemente Ubuntu 16.x) para la compilación cruzada de esos binarios.

Nuevamente, seguí lo siguiente con algunas modificaciones:
https://povilasv.me/raspberrypi-kubelet/
Puede consultar esto para confirmar los pasos a seguir.

He preparado mi nota y los pasos exactos que seguí, pero lo siento, solo está disponible en japonés:
https://qiita.com/ShinHashitani/items/ea9ffdefce8ca5786da6

¿Algún movimiento para volver a agregar soporte de armel para pi zero's? Tengo bastantes por ahí y me encantaría hacer un clúster de bajo costo / energía para fines de demostración

¿Algún movimiento para volver a agregar soporte de armel para pi zero's? Tengo bastantes por ahí y me encantaría hacer un clúster de bajo costo / energía para fines de demostración

hola, como puede ver en la discusión anterior, el núcleo de Kubernetes dejó de admitir armv6l.
así que no creo que exista la posibilidad de que se vuelva a agregar este soporte.

si desea utilizar k8s / kubeadm en armv6l, debe volver a compilar todo (incluidas las imágenes CNI).

Solo estoy interviniendo para decir que he compilado con éxito K8s 1.18.3 desde la fuente compilándolo en la imagen de la ventana acoplable golang: 1.13-alpine, que es una imagen de múltiples arcos e incluye un armv6. (Tengo Docker configurado para usar QEMU para la emulación y puedo ejecutar contenedores para otras arquitecturas).

Simplemente clonando el repositorio de git y siguiendo el proceso de creación de 4 pasos en la página Léame (es decir, haga todo WHAT = cmd / component), todos los componentes de k8s excepto kubelet se compilaron estáticamente y se ejecutaron como ejecutables independientes en mi pi zero, sin dependencias. (Y si golang-alpine deja de funcionar, puedo arrancar Arch Linux ARM desde cero, lo que debería funcionar bien para la compilación).

El único problema es que la compilación de kubelet todavía se vincula dinámicamente a la biblioteca glibc del sistema, y ​​aún no he descubierto cómo solucionarlo. No soy un programador de go, y ninguno de los indicadores de compilación que agregué para go o gcc pareció marcar la diferencia. (Kubelet tiene algo de código C, supongo, porque necesita gcc para compilar). Supongo que en el peor de los casos puedo arrancar una imagen de la ventana acoplable para cada tipo de sistema operativo que ejecuto, por lo que los enlaces dinámicos glibc funcionarán, pero no quiero Haz eso.

Debian todavía es compatible oficialmente con armel y tiene paquetes con una versión de kubelet enlazada estáticamente, por lo que mi solución hacky actualmente es usar su binario estático desde dentro del paquete deb de armel.

Por último, debe crear su propio repositorio con imágenes que tengan estos binarios (así como las otras versiones) y configurar kubeadm para extraerlos. Y aún más divertido, aunque Docker se ejecuta en arm6, extrae incorrectamente las imágenes de arm7 (un error conocido desde hace más de 3 años), por lo que debe cambiar la imagen de arm7 para ejecutar la versión de armel, o hacer que tanto arm6 como arm7 en el misma imagen y que el punto de entrada sea un script de shell que determina en tiempo de ejecución si se debe iniciar el programa arm6 o arm7. Los nodos no maestros solo necesitan ejecutar kubelet y kube-proxy, por lo que probablemente sean las únicas imágenes para las que necesita hacer esto. (Otro truco que he leído sobre el uso de personas es extraer la imagen correcta y luego volver a etiquetarla localmente para que sea la imagen que kubeadm quiera extraer, por lo que solo usará la versión local).

En realidad, solo estoy usando ansible para configurar k8s "de la manera difícil", pero tengo la intención de seguir creando imágenes Docker compatibles que puedan ser reemplazos directos para que kubeadm funcione con ellas. Si puedo hacer que kubelet se compile estáticamente correctamente, automatizaré el proceso en un Dockerfile y pegaré las imágenes en Docker Hub. Esas imágenes tendrán tantas arquitecturas como pueda usar, así que idealmente, podremos usar kubeadm en un clúster de múltiples arquitecturas. Por ejemplo, amd64, arm64, arm6 y arm7. Calculo que la producción completa de Docker y K8 en Pi Zero (como nodos de trabajo) todavía deja al menos 50 MB-100 MB de RAM para ejecutar imágenes pequeñas. Y si elimino el núcleo, probablemente pueda liberar otros 30 o 40 megas. Pero eso es un futuro lejano. Si puedo obtener una sola página estática servida por un contenedor nginx administrado por K8s en mi Pi Zero, lo llamo una victoria por el momento.

Edición del 7 de agosto: he logrado que todo funcione y actualmente tengo un grupo de K8 compuesto por arm6, arm7, arm8 y amd64. Pronto haré un informe de mi proceso aquí, pero por ahora, la conclusión importante es hacer una instalación de kubeadm en un dispositivo arm6 como nodo de trabajo, necesita binarios para kubeadm y kubelet, y solo dos contenedores, el contenedor de pausa y el contenedor de proxy kube. Puede crear los binarios de forma nativa con buildx si tiene QEMU y simplemente modificar mi Dockerfile . (En este momento, ese Dockerfile en realidad no funciona por completo; la compilación kube-controller-manager se sigue congelando. Pero puede compilar kubelet, kubeadm, pause, kube-proxy y los complementos CNI).

Alternativamente, puede extraer los binarios estáticos del directorio / usr / bin en los paquetes Arch que hice para kubeadm y kubelet . Instalé Arch Linux ARM en mi Pi Zero, por lo que los complementos CNI se instalaron en mi sistema mediante un paquete, pero puede compilarlos con mi Dockerfile (o extraerlos del paquete Arch Linux ARM) y luego colocar los binarios CNI en el directorio "/ opt / cni / bin /" en su sistema. Si tiene esos binarios CNI en esa carpeta y tiene kubelet instalado y listo como servicio , entonces puede ejecutar kubeadm en el dispositivo y debería funcionar bien. El único requisito es que necesita los contenedores de pausa y proxy de kube correctos ya disponibles para su motor de contenedores.

En mi Pi Zeroes, tengo instalado Docker de stock y utilicé los binarios que construí a partir del archivo Docker, combinados con el análisis de los contenedores oficiales de K8 para construir un contenedor arm6 compatible para kube-proxy y pausar . Al especificar la versión de Kubernetes como v1.18.6 en kubeadm, era necesario volver a etiquetar esos contenedores como "k8s.gcr.io/kube-proxy:v1.18.6" y "k8s.gcr.io/pause:3.2" respectivamente, pero si esos Los contenedores ya están presentes y etiquetados correctamente en su sistema, entonces kubeadm tendrá éxito sin quejas.

El único otro problema es una red superpuesta en funcionamiento. No quería pasar por más infiernos de compilación, así que usé Flannel, cuya variante "arm" funciona en arm6 y arm7. Puede instalarlo con su archivo yaml predeterminado . Sin embargo, debe agregar una var env para todas las secciones llamadas FLANNEL_MTU y configurarlo en 1430 o menos. El valor predeterminado, 1500, causa algunos problemas con el servidor de métricas. Además, combiné todas las imágenes de Flannel en una imagen de varios arcos si quieres usarla. Eso le permitirá hacer lo que yo hice y quitar el archivo de instalación de yaml predeterminado a solo una sección.

Con esta instalación "completa" de K8s usando kubeadm y Docker CE, mi Pi Zeroes está inactivo con un 55% de uso de CPU y tiene aproximadamente 160 MB de memoria libre. Si asumimos que quiero dejar al menos el 25% para la capacidad de explosión, eso todavía deja alrededor del 20%, lo que equivale a 200 milis. (Pi Zero tiene una CPU de 1 GHz de un solo núcleo). Para dar un margen de maniobra adicional, redondeé hacia abajo y establecí mi solicitud y límite de contenedor en 120 my RAM en 100 MB. Hasta ahora, todo funciona bien. El único problema es el calor, ya que mis ceros están todos amontonados en un lindo estuche apilable que no tiene mucho espacio para el aire.

(Y, por supuesto, el nodo administrador no es un Pi Zero, es un Pi 4.)

Editar desde el 1 de diciembre de 2020: esta será mi última actualización. De hecho, no hay mucho que agregar. Kubeadm tiene un archivo de configuración yaml, al igual que todos los demás componentes de k8s, ninguno de los cuales está tan bien documentado ... pero puede salir adelante si lo intenta.

Una de las opciones de kubeadm es usar un registro personalizado para sus imágenes, por lo que puede crear una imagen de varios arcos y enviarla a un registro privado y luego usarla para su configuración en lugar del truco de simplemente volver a etiquetar una imagen en la ventana acoplable. Esto es lo que he hecho para deshacerme de la ventana acoplable y usar simplemente containerd.

Todavía no he descubierto cómo compilar los componentes del plano de control para arm6. Tanto QEMU como los dispositivos nativos no permitirán más de 1 GB de RAM, lo que no es suficiente para que Go compile la mayor parte del plano de control. Soy consciente de que, en teoría, Go puede compilar para otras arquitecturas, por lo que debería poder compilar arm6 en mi máquina amd64, usando toda su memoria RAM. Pero por mi vida, no puedo hacer que eso funcione, así que me quedo compilando cosas de forma nativa en QEMU o en los propios dispositivos. Lo que significa que no hay componentes del plano de control arm6.

Pero ese es el único contratiempo. Kubelet y kubeadm compilan, y el contenedor de pausa y los contenedores de proxy kube también se pueden construir con buildx. Por lo tanto, aún es bastante fácil hacer que los componentes del nodo trabajador funcionen para arm6. Sin embargo, si está creando un clúster con ceros pi, definitivamente lea el archivo de configuración de kubelet para ajustarlo para el uso de recursos. (O, ya sabe, use k3s u otra distribución liviana en lugar de k8s completos).

Tengo binarios para viejos modelos de frambuesas publicados aquí https://github.com/aojea/kubernetes-raspi-binaries
Se crean con un trabajo de acciones de github, así que siéntete libre de reutilizarlo