Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal] Make Kubernetes run on ARM devices #17981

Closed
17 tasks done
luxas opened this issue Nov 30, 2015 · 20 comments
Closed
17 tasks done

[Proposal] Make Kubernetes run on ARM devices #17981

luxas opened this issue Nov 30, 2015 · 20 comments
Assignees
Labels
area/build-release area/images-registry area/release-eng Issues or PRs related to the Release Engineering subproject area/test-infra kind/feature Categorizes issue or PR as related to a new feature. priority/backlog Higher priority than priority/awaiting-more-evidence.

Comments

@luxas
Copy link
Member

luxas commented Nov 30, 2015

Edited to reflect current status
Since Kubernetes is written in Go, it's possible to add support for ARM devices like Raspberry Pi.
I have done this, it's published here: https://github.com/luxas/kubernetes-on-arm
And it would be great to merge this to mainline k8s.

This work focuses on making it easier for other architectures too, like arm64 and ppc64le

TODO:

Status of multiarch images:
Get docker-multinode working:

Get DNS working:

Docker wrapped Kubernetes binaries:

I worked with the dashboard team, and it has had multiarch support from the first release.
I'm maybe gonna add multiarch support for official heapster too, now when it has reached v1.
On kubernetes-on-arm, I already have heapster, influxdb and grafana nicely running as a cluster addon.

Things to have in mind:

I thought about making a proposal earlier, and now when #17629 was merged, it might be time

/cc
@dalanlan (k8s-in-docker interest)
@resouer (k8s-in-docker interest)
@guybrush (k8s-in-docker interest)
@davidopp (who was involved in #17629)
@roberthbailey (who was involved in #17629)
@zmerlynn (who was mentioned in #17629)
@DieterReuter (interested in Raspberry Pi things)

@fabioy fabioy added sig/node Categorizes an issue or PR as relevant to SIG Node. team/cluster area/test-infra kind/feature Categorizes issue or PR as related to a new feature. area/release-eng Issues or PRs related to the Release Engineering subproject labels Dec 1, 2015
@luxas
Copy link
Member Author

luxas commented Dec 5, 2015

I've digged into this a little bit more, and here are the results:

  • hyperkube must be compiled dynamically, I tested it and it exited if it was built statically:
Error: failed to create kubelet: cAdvisor is unsupported in this build
failed to create kubelet: cAdvisor is unsupported in this build
  • armbuild/debian, which is the image currently used for ARM, doesn't work on ARMv6
    • the reason why armbuild fails is probably because the packages are built for ARMv7
    • the other option would be resin/rpi-raspbian which is a very good debian image
  • Now I may run any ARM docker image on my amd64 machine. This is very interesting.
    • I'm using moul's binfmt-register. However, it should only be able to run and compile binaries with go 1.5.2 or newer.
    • Edit: Even better method: https://resin.io/blog/building-arm-containers-on-any-x86-machine-even-dockerhub/
    • If we use this method, we may compile the binaries dynamically for ARM on a amd64 machine.
    • Some drawbacks though:
      • We can't use the normal kube-build:cross method as it is right now. It just cross-compiles statically. So just adding linux/arm to server platforms in hack/lib/golang.sh won't work. I'm working on this Fixed in Official ARM builds for every new release #19769
      • Only the go base image must be built on a real ARM machine. That's because, using qemu we can't compile go1.4.3, which is required for go1.5.2. The chicken-or-egg problem.
    • So if we create a gcr.io/google_containers/golang-arm:v1.5.2 (maybe with some other prefix) and build that on a ARM machine, we could build all binaries on amd64
    • Edit: It's possible to cross-compile dynamically with golang:1.5.2 as base image.

So here are some questions for you to answer

  • Should I start working on a WIP: Kubernetes on ARM PR? Yes, but splitting the work in separate PRs
  • Is it acceptable to include flannel in cluster/images and maybe build them there? The same method as skydns... Yes
  • Is using qemu for building ARM docker images OK?
  • Should ARMv6 be supported? That would be great. You've already set GOARM=5 in kube-build:cross Yes
  • Could we switch armbuild/debian for resin/rpi-raspbian or some other ARMv6 compatible image? Yes

At least I would like to discuss these things
Just say if you don't want this functionality at this time in Kubernetes
Personally, I don't think it's that good to promote usage of k8s on Pis on your blog when you have to hack things for it to work (on the other hand, it's very fun 😄)

@ikehz ikehz added area/build-release and removed area/release-eng Issues or PRs related to the Release Engineering subproject labels Dec 11, 2015
@ikehz
Copy link
Contributor

ikehz commented Dec 11, 2015

@brendandburns I know you were working on some Pi stuff; want to chime in here?

@luxas
Copy link
Member Author

luxas commented Dec 12, 2015

Yes #17629

I thought about making a proposal earlier, and now when #17629 was merged, it might be time

There are lots of folks who want this, and since 1st Oct, my project may help with this.
Or one have to hack it by hand...

@ihmccreery At least, should I start writing on the ARM docs?
E.g. about what's different with ARM and what needs to be customized.

@ikehz
Copy link
Contributor

ikehz commented Dec 16, 2015

Assigning to @brendandburns to advise.

@brendandburns
Copy link
Contributor

@luxas I have a working Raspberry PI cluster and have built a bunch of ARM binaries for various pieces. I'm happy to advise and review the PRs..

We can keep this open as a tracking issue. Please assign the PRs to me.

@luxas
Copy link
Member Author

luxas commented Dec 17, 2015

@brendandburns Are you OK with using resin/rpi-raspbian instead for armbuild/debian for ARMv6 compability?
And how about including flannel besides etcd in cluster/images?

@ikehz ikehz added priority/backlog Higher priority than priority/awaiting-more-evidence. and removed area/test-infra priority/backlog Higher priority than priority/awaiting-more-evidence. labels Dec 22, 2015
@luxas
Copy link
Member Author

luxas commented Dec 26, 2015

@brendandburns Great news! I've been able to compile all kubernetes binaries on my amd64 laptop.
This makes ARM building a lot easier and faster, and the ARM binaries works on both ARMv6 and ARMv7 (aka RPi 1 and 2)

The code is here and it uses golang:1.5.2 as the base image. I could test if it also works with golang:1.4-cross, which you are using today.

hyperkube and flannel is built dynamically for ARM on amd64 thanks to some libraries described here

I also think it would be possible to build ARM docker images on amd64 (only images with COPY works today) using qemu
Here is a blog post about that: https://resin.io/blog/building-arm-containers-on-any-x86-machine-even-dockerhub/

WDYT?

@ikehz
Copy link
Contributor

ikehz commented Dec 29, 2015

cc @david-mcmahon

@luxas
Copy link
Member Author

luxas commented Apr 5, 2016

Again, a major milestone was merged for cross-platform Kubernetes: #21617!
When the v1.3.0-alpha.2 release is out, one is able to run Kubernetes on ARM by following the docker guide.

k8s-github-robot pushed a commit that referenced this issue Apr 11, 2016
Automatic merge from submit-queue

Make kube2sky and skydns docker images cross-platform

ARM tracking issue: #17981
Continues on: #19216

Make it possible to create `kube2sky` and `skydns` docker images for ARM and other architectures too
Build in a container, so `golang` isn't a dependency
I've preserved the original default behaviour:
 - `skydns`: It just compiles with go on host
 - `kube2sky`: Build an image

@brendandburns @dchen1107 @ArtfulCoder @thockin @fgrzadkowski
@luxas luxas assigned luxas and unassigned brendandburns Apr 21, 2016
@coryjamesfisher
Copy link

@luxas Thanks so much for the work you and the others have put into this. I was smacking my head against the wall trying to get Kubernetes running on a rpi 3 last night using the guide... Then I saw your comment this morning so I changed the k8 version number to the latest alpha and everything just works :) Thank you thank you thank you :)

k8s-github-robot pushed a commit that referenced this issue May 13, 2016
Automatic merge from submit-queue

Automatically add node labels beta.kubernetes.io/{os,arch}

Proposal: #17981
As discussed in #22623:
> @davidopp: #9044 says cloud provider but can also cover platform stuff.

Adds a label `beta.kubernetes.io/platform` to `kubelet` that informs about the os/arch it's running on.
Makes it easy to specify `nodeSelectors` for different arches in multi-arch clusters.

```console
$ kubectl get no --show-labels
NAME        STATUS    AGE       LABELS
127.0.0.1   Ready     1m        beta.kubernetes.io/platform=linux-amd64,kubernetes.io/hostname=127.0.0.1
$ kubectl describe no
Name:			127.0.0.1
Labels:			beta.kubernetes.io/platform=linux-amd64,kubernetes.io/hostname=127.0.0.1
CreationTimestamp:	Thu, 31 Mar 2016 20:39:15 +0300
```
@davidopp @vishh @fgrzadkowski @thockin @wojtek-t @ixdy @bgrant0607 @dchen1107 @preillyme
k8s-github-robot pushed a commit that referenced this issue May 28, 2016
Automatic merge from submit-queue

Use pause image depending on the server's platform when testing

Removed all pause image constant strings, now the pause image is chosen by arch. Part of the effort of making e2e arch-agnostic.

The pause image name and version is also now only in two places, and it's documented to bump both
Also removed "amd64" constants in the code. Such constants should be replaced by `runtime.GOARCH` or by looking up the server platform

Fixes: #22876 and #15140
Makes it easier for: #25730
Related: #17981

This is for `v1.3`
@ixdy @thockin @vishh @kubernetes/sig-testing @andyzheng0831 @Pensu
@luxas
Copy link
Member Author

luxas commented Jun 25, 2016

@david-mcmahon How is the release note writing process for v1.3 managed?
It would be really great to mention a few words about the new non-business-supported architectures in the v1.3 release notes, ideally both on the blog and in the changelog.
WDYT? Please respond when you're seeing this and if you want me to write a short summary, just ping me

@roberthbailey
Copy link
Contributor

Release notes are handled in a few chunks. There are the auto-generated notes from github labels that are bundled up since the last release. And there are hand-curated release notes, which this falls under. Please write up what you'd like to see and send it to @david-mcmahon

@luxas
Copy link
Member Author

luxas commented Jun 29, 2016

@david-mcmahon Did you get my email message I sent some days ago?

@david-mcmahon
Copy link
Contributor

@luxas Yes and I replied.

@luxas
Copy link
Member Author

luxas commented Jul 2, 2016

Yes, thanks!
Looking forward to see the full release notes for v1.3 😄

@m1093782566
Copy link
Contributor

/cc

@luxas
Copy link
Member Author

luxas commented Oct 16, 2016

For everyone interested, arm binaries has been released for kubernetes since v1.2.

For v1.2.x, use my project kubernetes-on-arm v0.7.0
For v1.3.x, use docker-multinode or kubernetes-on-arm v0.8.0
For v1.4.x, use kubeadm

You may also read https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/multi-platform.md

I consider this work done since a while ago thanks to the linked PRs above.
Still, there are work to do mentioned in the proposal, but the original issue Make Kubernetes on ARM devices has worked "officially" since v1.2.x, which is more than a half year ago, so closing this issue

@luxas luxas closed this as completed Oct 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/build-release area/images-registry area/release-eng Issues or PRs related to the Release Engineering subproject area/test-infra kind/feature Categorizes issue or PR as related to a new feature. priority/backlog Higher priority than priority/awaiting-more-evidence.
Projects
None yet
Development

No branches or pull requests

9 participants