-
Notifications
You must be signed in to change notification settings - Fork 41.3k
Add a multi-platform proposal #26863
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
Conversation
@luxas thanks for your proposal, but I don't think this is required for 1.3 release. We are clearing up our 1.3 merging queue, once we are done with that, we are open for prs like this to main branch. Thanks! |
@dchen1107 It's okay, it would have been nice to have, but agree that it isn't so important if you're branching soon. I guess I was a bit too slow to send a PR for it. I would be interested in your opinion on this topic though, but understand if you have too much things to do atm and wait until after the release. |
|
||
## Abstract | ||
|
||
Kubernetes is written in Go, and Go is ported to multiple platforms. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Go code is portable across platforms
.
This is an interesting read. It's a mix of background info, things that are already done, and some open issues for the future. I'd really like to see those facets split out, so it is easier to figure out how much work is left on this, what's next to do, and what external deps we have. E.g. when Docker delivers multi-arch images, how much of what we've done will change? |
Thanks The kind of problematic thing with creating a proposal like this is,
So all comments appreciated.
Not much. We will still build I'm investigating if we can take advantage of @estesp's project already for v1.4 for this, given the 1.10+ docker requirement (btw, is kubernetes.gcr.io a v2.3+ registry?) cc @jfrazelle |
Along with this we should scale the testing infrastructure across platforms, we did this for docker, and maybe we can reuse some of the logic for the "go build dashboard". Otherwise stuff will constantly be broken on the other arches I don't see a problem in having to change things when docker supports multi-arch images. It should be a streamlined change, and +1 to @estesp tool, he is definitely one of the major people working on that effort |
|
||
This is especially useful if we want to include the binary in a container. | ||
If the binary is statically compiled, we may use `busybox` or even `scratch` as the base image. | ||
This should be the preferred way of compiling binaries that strictly require C code to be a part of it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fwiw you can statically cross compile cgo from linux to all other arches, it's not something I am proud of knowing how to do though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for pointing at a doc flaw.
That's exactly what my the intention is with this section, to describe how to cross-compile statically with CGO code for another architecture.
However, I see that here it says compilation
in the header, when it should be cross-compilation
, and likewise in other places. Will fix.
ping @vishh @david-mcmahon @jfrazelle PTAL |
@luxas +1 from me |
### Support all platforms in a "run everywhere" deployment | ||
|
||
The easiest way of running Kubernetes on another architecture is probably by using the docker or the docker-multinode deployment. Of course, you may choose whatever deployment you want, the binaries are easily downloadable from the URL above. But [docker-multinode](https://github.com/kubernetes/kube-deploy/tree/master/docker-multinode) should be a "just works" multi-platform solution with docker as the only real dependency. | ||
Note: That doesn't mean _everything_ "just works" with the docker-multinode setup, but basic functionality is there. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not confident that docker multinode is an acceptable production solution. It might be worth mentioning that. It is mainly meant for "kick the tires" experience.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No it isn't a production env deployment; and that's why I wrote the basic functionality is there (it nearly passes all tests; I think there were 5 fails of all e2e tests)
I can clarify that's it's meant for a "kick the tires"-cluster even more if you want me to
d7dd7cc
to
c60490d
Compare
@vishh Please LGTM this now. :) |
@k8s-bot test this please github issue: #IGNORE |
- Relying on platform-specific syscalls (e.g. `syscall.Dup2`) | ||
|
||
If someone tries to add a dependency that doesn't satisfy these requirements; he/she should first fix the problem in the repository that is about to be added. | ||
When the dependency satisfies the Kubernetes requirements for compiling on all platforms, the PR can be merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The CI should catch incompatible vendor dependencies.
@luxas I'd gate this proposal on requiring testing for additional |
@vishh Thanks for the review! Self-applying |
GCE e2e build/test passed for commit b033b25. |
Automatic merge from submit-queue |
👍 |
…tname Automatic merge from submit-queue Cross-build test/images/serve_hostname <!-- Thanks for sending a pull request! Here are some tips for you: 1. If this is your first time, read our contributor guidelines https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md and developer guide https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md 2. If you want *faster* PR reviews, read how: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md 3. Follow the instructions for writing a release note: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes --> **What this PR does / why we need it**: **cross build** `test/images/serve_hostname` https://github.com/kubernetes/kubernetes/tree/master/test/images/serve_hostname This PR is an effort to achieve multiarch Kubernetes(#26863) **Which issue this PR fixes** : fixes #31238 @luxas @spxtr
Automatic merge from submit-queue Add a multi-platform proposal This is a proposal for the work I've done with multiarch Kubernetes. I've worked quite a lot on it and now I've written it down so others may easily use and learn from it, while at the same time pointing out issues that we should fix in the future. I would like to get this in before `v1.3`. Feel free to comment on it if it's something that's unclear. @david-mcmahon @ixdy @mikedanese @Pensu @davidopp @bgrant0607 @dlorenc @eparis @vishh @thockin @dchen1107 @lavalamp
This is a proposal for the work I've done with multiarch Kubernetes. I've worked quite a lot on it and now I've written it down so others may easily use and learn from it, while at the same time pointing out issues that we should fix in the future.
I would like to get this in before
v1.3
.Feel free to comment on it if it's something that's unclear.
@david-mcmahon @ixdy @mikedanese @Pensu @davidopp @bgrant0607 @dlorenc @eparis @vishh @thockin @dchen1107 @lavalamp
This change is