Raspberry Pi Model B+ 및 armv6에서도 kubeadm 1.6.1과 동일한 문제에 직면하고 있습니다.

$ 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 예 1.5.6으로 다운그레이드하면 작동하지만 1.6+ 클러스터에 참여할 수 없습니다.

먼저 ARM :smile:에서 Kubernetes를 사용해 주셔서 감사합니다.

이것은 알려진 문제입니다. https://github.com/kubernetes/kubernetes/issues/38067 에서 논의되었으며 armel 지원을 중단했습니다(RPi 1에서 크로스 컴파일할 때 사용하는 부분).

기본적으로 armhf(GOARM=7)는 Pi 1에서 실행할 수 없으므로 RPi 1을 지원하기 위해 -v1.5에서 GOARM=6인 armel을 사용했습니다. 그러나 v1.6에서 모두 armhf를 사용했기 때문에 작동하지 않습니다. 파이 1.

armel을 더 이상 사용하지 않고 armhf 이미지를 대신 사용하고 GOARM=6 대신 GOARM=7을 사용합니다.
동기 부여:

• Go1.8에서 Go가 지원하는 유일한 GOARM=6 보드는 최신 Kubernetes 버전을 실행하기에는 너무 느린 Raspberry Pi 1입니다.
• GOARM=7을 사용할 때 약간의 성능 향상
• armel(http://hub.docker.com/u/armel) 이미지는 armhf(http://hub.docker.com/u/armhf) 이미지만큼 자주 업데이트되지 않습니다.

예를 들어 https://hub.docker.com/r/armel/debian/ 은 8개월 전에 업데이트되어 보안 관점에서 매우 좋지 않습니다. vs 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 지원의 재통합을 논의할 수 있습니까? Pi Zero 및 기타 armv6l Pi 장치에서 Kubernetes를 사용하는 데 관심을 보이는 많은 게시물을 찾았습니다. P Zero는 Kubernetes 또는 Swarm 클러스터 환경에서 Micro Services를 호스팅하는 데 적합합니다. Docker Swarm은 저에게 잘 맞습니다. 따라서 누구든지 토론을 재활용할 수 있다면 좋을 것입니다. Pi clusterhat은 적절한 데모 인프라입니다.

파이 제로에 대한 현재 docker.io 빌드를 보면,
이동 버전: go1.9.3
및 도커 버전: 18.02.0-ce

최신 버전의 go를 사용하는 것 같습니다.

독립 실행형 모드에서 k8을 사용하기에는 램이 충분하지 않다는 데 동의하지만 더 큰 마스터의 슬레이브가 되려면 여전히 유용한 작업을 수행할 수 있는 충분한 리소스가 있어야 합니다.

내 파이 0을 k8 노드로 사용하기 위해 소스에서 빌드하는 것이 가능한지 아는 사람이 있습니까?

예를 들어 https://hub.docker.com/r/armel/debian/ 은 8개월 전에 업데이트되어 보안 관점에서 매우 좋지 않습니다. vs 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가 최신 k8을 실행하지 못하도록 막는 것은 매우 실망스럽습니다.

@luxas

+1. 허브가 재정렬되고 이전 저장소가 여전히 주변에 있기 때문에 약간의 혼란이 발생했습니다. 최신 제품은 자주 업데이트되는 것 같습니다.

안녕하세요 @juliancheal ,

나는 여전히 ClusterHAT에서 k8을 구축하는 중이지만 Pi Zero용 바이너리를 컴파일하고 구축할 수 있었습니다.

기본적으로 몇 가지 수정 사항을 적용하여 다음을 수행했습니다.
https://povilasv.me/raspberrypi-kubelet/

나는 wsl에서 일했다.
Linux DESKTOP-6GRDDIN 4.4.0-17134-Microsoft #48-Microsoft 금 4월 27일 18:06:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux

1 gcc-arm-linux-gnueabihf 대신 gcc-arm-linux-gnueabi를 설치합니다.

sudo apt-get install gcc-arm-linux-gnueabi <- 변경

2 linux/arm용으로 빌드하기 전에 hack/lib/golang.sh에서 set_platform_envs()를 두 번 수정합니다.

* GOARM 추가내보내기 GOOS=${플랫폼%/ }내보내기 GOARCH=${플랫폼## /}내보내기 GOARM=5 <- 추가* CC 변경
대소문자 "${platform}"
"리눅스/암")
내보내기 CGO_ENABLED=1
내보내기 CC=arm-linux-gnueabi-gcc <-변경
;;

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 , init 스크립트 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을 사용하지 않았다. 나는 Kelsey Hightower의 "Kubernetes 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

편집 : 신경 쓰지 마세요 ... Linux 시스템에서 빌드하면 작동하는 것처럼 보입니다. 맥에서 하려고 했는데

@ammmze ,

문제를 일으키는 원인이 무엇인지 정확히 알지 못하지만 아래는 내 쪽에서 자세히 설명한 내용입니다.
쿠버네티스 - 1.10.2
이동 - 19.4
이러한 바이너리를 크로스 컴파일하기 위해 WSL(아마도 Ubuntu 16.x)을 사용했습니다.

다시, 나는 약간의 수정과 함께 아래를 따랐다:
https://povilasv.me/raspberrypi-kubelet/
이를 참조하여 거쳐야 할 단계를 확인할 수 있습니다.

메모와 정확한 단계를 준비했지만 일본어로만 제공되어 죄송합니다.
https://qiita.com/ShinHashitani/items/ea9ffdefce8ca5786da6

파이 제로에 대한 백 armel 지원 추가에 대한 움직임이 있습니까? 나는 꽤 많은 것을 가지고 있으며 데모 목적으로 저렴한 비용/전력 클러스터를 만들고 싶습니다.

파이 제로에 대한 백 armel 지원 추가에 대한 움직임이 있습니까? 나는 꽤 많은 것을 가지고 있으며 데모 목적으로 저렴한 비용/전력 클러스터를 만들고 싶습니다.

안녕하세요, 위의 논의에서 볼 수 있듯이 핵심 Kubernetes는 armv6l에 대한 지원을 중단했습니다.
그래서 이 지원이 다시 추가될 가능성이 없다고 생각합니다.

armv6l에서 k8s / kubeadm을 사용하려면 모든 항목(CNI 이미지 포함)을 다시 컴파일해야 합니다.

multi-arch 이미지이고 armv6을 포함하는 golang:1.13-alpine docker 이미지에서 컴파일하여 소스에서 K8s 1.18.3을 성공적으로 컴파일했다고 말하려고 합니다. (저는 에뮬레이션에 QEMU를 사용하도록 Docker를 구성했으며 다른 아키텍처용 컨테이너를 실행할 수 있습니다.)

git repo를 복제하고 readme 페이지의 4단계 make 프로세스를 따르면(즉, 모든 WHAT=cmd/component를 작성) kubelet을 제외한 모든 k8s 구성 요소는 정적으로 컴파일되어 내 파이 제로에서 독립 실행형 실행 파일로 실행됩니다. 종속성이 없습니다. (그리고 golang-alpine이 작동을 멈추면 Arch Linux ARM을 처음부터 부트스트랩할 수 있습니다. 컴파일에 잘 작동해야 합니다.)

유일한 문제는 kubelet을 컴파일하는 것이 여전히 시스템 glibc 라이브러리에 동적으로 연결된다는 것인데, 아직 해결 방법을 찾지 못했습니다. 저는 go 프로그래머가 아니며 go 또는 gcc에 대해 추가한 컴파일 플래그 중 어떤 것도 차이를 만드는 것 같지 않았습니다. (Kubelet에는 컴파일에 gcc가 필요하기 때문에 일부 C 코드가 있는 것 같습니다.) 최악의 경우에는 내가 실행하는 모든 유형의 OS에 대해 도커 이미지를 부트스트랩할 수 있으므로 glibc 동적 링크가 작동하지만 원하지 않습니다. 그렇게.

데비안은 여전히 ​​공식적으로 armel을 지원하고 정적으로 링크된 kubelet 버전이 있는 패키지를 가지고 있으므로 현재 저의 해키 솔루션은 armel deb 패키지 내부에서 정적 바이너리를 사용하는 것입니다.

마지막으로 이러한 바이너리(및 다른 버전)가 있는 이미지로 자신의 저장소를 만들고 이를 가져오도록 kubeadm을 구성해야 합니다. 그리고 더 재미있는 것은 Docker가 arm6에서 실행되지만 arm7 이미지를 잘못 가져옵니다(3년 이상 알려진 버그). 따라서 arm7 이미지를 변경하여 armel 버전만 실행하거나 arm6과 arm7을 둘 다 만들어야 합니다. 동일한 이미지를 만들고 진입점이 arm6 또는 arm7 프로그램을 시작할지 여부를 런타임에 결정하는 셸 스크립트가 되도록 합니다. 마스터가 아닌 노드는 kubelet 및 kube-proxy만 실행하면 되므로 이 작업을 수행하는 데 필요한 유일한 이미지일 수 있습니다. (내가 사용하는 사람들에 대해 읽은 또 다른 해킹은 올바른 이미지를 가져온 다음 kubeadm이 가져오려는 이미지가 되도록 로컬에서 태그를 다시 지정하는 것이므로 로컬 버전만 사용합니다.)

저는 실제로 k8s를 "어려운 방법"으로 설정하기 위해 가능한 것을 사용하고 있지만, kubeadm이 함께 작동하도록 드롭인 교체가 될 수 있는 호환 Docker 이미지를 계속 만들 생각입니다. kubelet이 정적으로 올바르게 컴파일되도록 할 수 있다면 프로세스를 Dockerfile로 자동화하고 이미지를 Docker Hub에 고정할 것입니다. 이러한 이미지에는 내가 사용할 수 있는 만큼의 아키텍처가 있으므로 이상적으로는 다중 아키텍처 클러스터에서 kubeadm을 사용할 수 있습니다. 예: amd64, arm64, arm6 및 arm7. Pi Zero의 전체 프로덕션 Docker 및 K8(작업자 노드)은 여전히 ​​작은 이미지를 실행하기 위해 최소 50MB-100MB 램을 남겨 둡니다. 커널을 제거하면 30 또는 40메가를 추가로 확보할 수 있습니다. 그러나 그것은 먼 미래입니다. 내 Pi Zero에서 K8s가 관리하는 nginx 컨테이너가 제공하는 단일 정적 페이지를 얻을 수 있다면 나는 그것을 당분간 승리라고 부르겠습니다.

8월 7일부터 편집: 모든 것이 작동하도록 관리했으며 현재 arm6, arm7, arm8 및 amd64로 구성된 K8 클러스터가 있습니다. 여기에서 내 프로세스를 곧 작성할 예정이지만 현재로서는 kubeadm을 작업자 노드로 arm6 장치에 설치하는 것입니다. kubeadm 및 kubelet용 바이너리와 두 개의 컨테이너만 필요합니다. 일시 중지 컨테이너 및 kube-proxy 컨테이너. QEMU가 있는 경우 기본적으로 buildx를 사용하여 바이너리를 빌드하고 내 Dockerfile 을 수정

또는 kubeadm 및 kubelet 용으로 만든 Arch 패키지의 /usr/bin 디렉토리에서 정적 바이너리를 가져올 수 있습니다. 내 Pi Zero에 Arch Linux ARM을 설치했으므로 CNI 플러그인이 내 시스템에 패키지로 설치되었지만 내 Dockerfile로 빌드(또는 Arch Linux ARM 패키지 에서 가져옴)한 다음 CNI 바이너리를 다음 위치에 배치할 수 있습니다. 시스템의 "/opt/cni/bin/" 디렉토리. 해당 폴더에 해당 CNI 바이너리가 있고 kubelet이 설치되어 서비스 로 준비되어 있는 경우 장치에서 kubeadm을 실행할 수 있으며 제대로 작동합니다. 유일한 요구 사항은 컨테이너 엔진에 이미 사용 가능한 올바른 kube-proxy 및 일시 중지 컨테이너가 필요하다는 것입니다.

내 Pi Zeroes에는 재고 Docker가 설치되어 있고 Docker 파일에서 빌드한 바이너리와 공식 K8s 컨테이너 분석을 결합하여 kube-proxy 및 pause 용 호환 가능한 arm6 컨테이너를 빌드했습니다. Kubernetes 버전을 kubeadm에서 v1.18.6으로 지정하려면 해당 컨테이너에 각각 "k8s.gcr.io/kube-proxy:v1.18.6" 및 "k8s.gcr.io/pause:3.2"로 태그를 다시 지정해야 하지만, 컨테이너가 이미 존재하고 시스템에 올바르게 태그가 지정되어 있으면 kubeadm은 불만 없이 성공할 것입니다.

유일한 다른 문제는 작동하는 오버레이 네트워크입니다. 더 많은 컴파일 지옥을 겪고 싶지 않았기 때문에 "arm" 변형이 arm6 및 arm7에서 작동하는 Flannel을 사용했습니다. defautl yaml 파일을 사용 하나의 다중 아치 이미지로 결합했습니다. 그러면 내가 한 작업을 수행하고 기본 yaml 설치 파일을 한 섹션으로 줄일 수 있습니다.

kubeadm 및 Docker CE를 사용하는 이 "전체" K8 설치로 내 Pi Zeroes는 약 55%의 CPU 사용량에서 유휴 상태이며 약 160MB의 메모리를 사용할 수 있습니다. 버스트 용량을 위해 최소 25%를 남겨두고 싶다고 가정하면 여전히 약 20%가 남습니다. 이는 200밀리초에 해당합니다. (Pi Zero에는 단일 코어 1GHz CPU가 있습니다.) 약간의 추가 공간을 제공하기 위해 저는 반올림하여 컨테이너 요청 및 제한을 120m로, RAM을 100MB로 설정했습니다. 지금까지는 모든 것이 잘 작동합니다. 유일한 문제는 열입니다. 왜냐하면 제 0은 공기 공간이 많지 않은 귀여운 쌓을 수 있는 케이스에 모두 함께 쌓여 있기 때문입니다.

(물론 관리자 노드는 Pi Zero가 아니라 Pi 4입니다.)

2020년 12월 1일부터 편집: 이것이 저의 마지막 업데이트가 될 것입니다. 사실 추가할 내용은 많지 않습니다. Kubeadm에는 다른 모든 k8s 구성 요소와 마찬가지로 yaml 구성 파일이 있습니다. 어느 것도 잘 문서화되어 있지 않습니다... 하지만 시도하면 혼란스러울 수 있습니다.

kubeadm 옵션 중 하나는 이미지에 대한 사용자 지정 레지스트리를 사용하는 것이므로 다중 아치 이미지를 만들어 개인 레지스트리에 푸시한 다음 도커에서 단순히 이미지에 태그를 다시 지정하는 해킹 대신 설정에 사용할 수 있습니다. 이것은 도커를 제거하고 스트레이트 컨테이너를 사용하기 위해 수행한 작업입니다.

arm6용으로 컴파일된 컨트롤 플레인 구성 요소를 가져오는 방법을 아직 이해하지 못했습니다. QEMU와 기본 장치 모두 1GB 이상의 램을 허용하지 않으므로 Go가 대부분의 제어 평면을 컴파일하기에 충분하지 않습니다. 나는 그 숫양을 모두 사용하여 내 AMD64 시스템에 ARM6 컴파일 할 수 있어야하므로 이동이 이론적으로, 다른 아키텍처에 대해 컴파일 할 수 있다는 것을 알고 있습니다. 그러나 평생 동안 나는 그것이 작동하도록 할 수 없으므로 QEMU 또는 장치 자체에서 기본적으로 컴파일하는 것으로 남아 있습니다. 이는 arm6 제어 평면 구성 요소가 없음을 의미합니다.

그러나 그것은 유일한 딸꾹질입니다. Kubelet 및 kubeadm은 컴파일되고 일시 중지 컨테이너와 kube-proxy 컨테이너는 마찬가지로 buildx로 빌드할 수 있습니다. 따라서 작업자 노드 구성 요소가 arm6에서 작동하도록 하는 것은 여전히 ​​쉽습니다. 하지만 파이 0으로 클러스터를 만드는 경우 리소스 사용을 위해 조정하려면 kubelet 구성 파일을 반드시 읽으십시오. (또는 전체 재고 k8 대신 k3 또는 다른 경량 배포판을 사용하십시오.)

여기에 게시된 오래된 라스베리 모델에 대한 바이너리가 있습니다. https://github.com/aojea/kubernetes-raspi-binaries
github 작업 작업으로 생성되었으므로 자유롭게 재사용하십시오.