У меня такая же проблема с 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: smile :!

Это известная проблема; это обсуждалось в https://github.com/kubernetes/kubernetes/issues/38067, и мы отказались от поддержки armel (какая часть RPi 1 используется при кросс-компиляции).

В основном armhf (GOARM = 7) не может работать на Pi 1, поэтому мы использовали armel с GOARM = 6 в -v1.5 для поддержки RPi 1. Однако мы использовали все armhf в v1.6, поэтому он не работает. Пи 1.

Не рекомендуется использовать armel и использовать вместо него изображения armhf и использовать GOARM = 7 вместо GOARM = 6
Мотивация:

• Единственная плата GOARM = 6, которую 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. Я нашел много сообщений, показывающих интерес к использованию Kubernetes на Pi Zero и других устройствах armv6l Pi. P Zero хорош для размещения микросервисов в Kubernetes или Swarm Cluster Environments. Docker Swarm мне подходит. Так что было бы неплохо, если бы кто-нибудь мог переработать обсуждение. Pi clusterhat - по сути, хорошая демонстрационная инфраструктура.

Взглянув на текущую сборку docker.io для нулевого числа пи,
Версия Go: go1.9.3
и версия докера: 18.02.0-ce

Похоже, он использует последнюю версию go.

Я согласен с тем, что не хватает оперативной памяти для использования на нем k8s в автономном режиме, но, если он будет подчиненным на более крупном мастере, у него должно быть достаточно ресурсов для выполнения некоторых полезных вещей.

Кто-нибудь знает, можно ли просто собрать из исходников, чтобы использовать мои нули пи в качестве узлов 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/. debian / были обновлены 9 дней назад.

Кроме того, с переключателем armhf мы смогли использовать https://hub.docker.com/r/armhf/alpine , и это здорово.

https://hub.docker.com/r/arm32v6/alpine/ хорошо работает на Pi Zero.

Я надеюсь, что вы это передумаете. То, что Pi Zero не запускает последнюю версию k8s, очень разочаровывает.

@luxas

+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 <- изменить

2 перед сборкой для linux / arm внесите две модификации в set_platform_envs () в hack / lib / golang.sh

* добавить GOARMэкспорт GOOS = $ {platform% / }экспорт GOARCH = $ {платформа ## /}экспорт GOARM = 5 <- добавить* изменить CC
case "$ {platform}" в
"linux / arm")
экспорт 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 для сборки двоичных файлов. Я использовал следующие команды:

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 есть идеи, какую версию кубернетов вы создавали?

Мне не удалось собрать это для arm v6 (в надежде запустить на пи-нуле 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

РЕДАКТИРОВАТЬ: Nevermind ... похоже, если я построю на Linux-машине, это будет работать. Я пытался сделать это со своего Mac

@ammmze ,

Не совсем уверен, что вызывает проблемы с вашей стороны, но ниже приведены подробности с моей стороны:
Kubernetes - 1.10.2
Вперед - 19,4
Я использовал WSL (вероятно, Ubuntu 16.x) для кросс-компиляции этих двоичных файлов.

Опять же, я выполнил следующие действия с некоторыми изменениями:
https://povilasv.me/raspberrypi-kubelet/
Вы можете обратиться к этому, чтобы узнать, что нужно сделать.

Я подготовил свою заметку и точные шаги, которые я выполнил, но, к сожалению, это доступно только на японском языке:
https://qiita.com/ShinHashitani/items/ea9ffdefce8ca5786da6

Есть ли какие-нибудь предложения по добавлению поддержки armel для пи-нулей? У меня есть довольно много лежащих вокруг, и я хотел бы сделать кластер с низкой стоимостью / мощностью для демонстрационных целей.

Есть ли какие-нибудь предложения по добавлению поддержки armel для пи-нулей? У меня есть довольно много лежащих вокруг, и я хотел бы сделать кластер с низкой стоимостью / мощностью для демонстрационных целей.

привет, как вы можете видеть в обсуждении выше, ядро ​​Kubernetes отказалось от поддержки armv6l.
поэтому я не думаю, что есть шанс, что эта поддержка будет добавлена ​​повторно.

если вы хотите использовать k8s / kubeadm на armv6l, вы должны перекомпилировать все (включая образы CNI).

Я просто хочу сказать, что я успешно скомпилировал K8s 1.18.3 из исходных текстов, скомпилировав его в образ докера golang: 1.13-alpine, который является многоарочным образом и включает armv6. (У меня Docker настроен на использование QEMU для эмуляции и может запускать контейнеры для других архитектур.)

Просто клонировав репозиторий git и следуя четырехэтапному процессу make на странице readme (т.е. просто сделайте все WHAT = cmd / component), все компоненты k8s, кроме kubelet, были статически скомпилированы и запускались как отдельные исполняемые файлы на моем нулевом значении pi, без зависимостей. (И если golang-alpine перестанет работать, я могу просто загрузить Arch Linux ARM с нуля, что должно нормально работать для компиляции.)

Единственная проблема заключается в том, что компиляция kubelet по-прежнему динамически подключается к системной библиотеке glibc, и я еще не понял, как это исправить. Я не программист на go, и, похоже, ни один из флагов компиляции, которые я добавил для go или для gcc, не имел значения. (Думаю, в Kubelet есть код на C, потому что для компиляции ему нужен gcc.) В худшем случае я могу загрузить образ докера для каждого типа ОС, которую я запускаю, поэтому динамические ссылки 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-proxy. Вы можете собрать двоичные файлы изначально с помощью buildx, если у вас есть QEMU, и просто изменить мой Dockerfile . (Прямо сейчас этот Dockerfile на самом деле не работает полностью - сборка kube-controller-manager продолжает зависать. Но вы можете создать kubelet, kubeadm, pause, kube-proxy и плагины CNI.)

В качестве альтернативы вы можете вытащить статические двоичные файлы из каталога / usr / bin в пакетах Arch, которые я сделал для kubelet . Я установил Arch Linux ARM на свой Pi Zero, и поэтому плагины CNI были установлены в моей системе с помощью пакета, но вы можете собрать их с помощью моего Dockerfile (или вытащить их из пакета Arch Linux ARM), а затем поместить двоичные файлы CNI в каталог "/ opt / cni / bin /" в вашей системе. Если у вас есть эти двоичные файлы CNI в этой папке и kubelet установлен и готов как служба , вы можете просто запустить kubeadm на устройстве, и он должен работать нормально. Единственное требование - вам нужны правильные контейнеры kube-proxy и pause, уже доступные для вашего контейнерного движка.

На моем Pi Zeroes у меня установлен стандартный Docker, и я использовал двоичные файлы, которые я построил из файла Docker, в сочетании с анализом официальных контейнеров K8s, чтобы создать совместимый контейнер arm6 для pause . Указание версии Kubernetes как v1.18.6 на kubeadm потребовало повторной маркировки этих контейнеров как «k8s.gcr.io/kube-proxy:v1.18.6» и «k8s.gcr.io/pause:3.2» соответственно, но если они контейнеры уже присутствуют и правильно помечены в вашей системе, тогда kubeadm будет успешным без жалоб.

Единственная другая проблема - это работающая оверлейная сеть. Я не хотел проходить через ад компиляции, поэтому я использовал Flannel, чей вариант "arm" работает на arm6 и arm7. Вы можете установить его с помощью их файла yaml по умолчанию . Однако вы должны добавить переменную env для всех разделов с именем 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 - использовать настраиваемый реестр для ваших образов, чтобы вы могли создать образ с несколькими архивами и отправить его в частный реестр, а затем использовать его для своей настройки, а не просто изменить теги образа в докере. Это то, что я сделал, чтобы избавиться от докеров и просто использовать containerd.

Я до сих пор не понял, как скомпилировать компоненты плоскости управления для arm6. И QEMU, и собственные устройства не позволяют использовать более 1 ГБ оперативной памяти, чего недостаточно для Go для компиляции большей части плоскости управления. Я знаю , что Go теоретически может составить для других архитектур, поэтому я должен быть в состоянии собрать ARM6 на моем amd64, используя все его памяти. Но хоть убей, я не могу заставить это работать, поэтому мне приходится компилировать вещи изначально либо в QEMU, либо на самих устройствах. Это означает отсутствие компонентов плоскости управления arm6.

Но это единственная проблема. Kubelet и kubeadm компилируются, а контейнер pause и контейнеры kube-proxy также могут быть построены с помощью buildx. Так что заставить компоненты рабочего узла работать для arm6 по-прежнему достаточно просто. Если вы создаете кластер с нулями pi, обязательно прочтите файл конфигурации kubelet, чтобы настроить его для использования ресурсов. (Или, вы знаете, используйте k3s или другой легкий дистрибутив, а не полный стандартный k8s.)

У меня есть двоичные файлы для старых моделей малины, опубликованные здесь https://github.com/aojea/kubernetes-raspi-binaries
Они созданы с помощью работы действий github, поэтому не стесняйтесь использовать ее повторно.