-
Notifications
You must be signed in to change notification settings - Fork 41.3k
Push server docker images during the release (attempt 2) #19061
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
Push server docker images during the release (attempt 2) #19061
Conversation
Labelling this PR as size/M |
GCE e2e test build/test passed for commit 7cb6d74efff8ca3e27fdb47bd83c6381de26fa96. |
7cb6d74
to
3f939af
Compare
GCE e2e build/test failed for commit 3f939af292326db99f771bc39930a8f9d1b19ad6. |
Last failure is a flake in test:
|
) | ||
|
||
local platforms=( | ||
"linux-amd64" |
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.
Shouldn't this be just amd64
? Or am I missing something here?
Because I think the docker images should be named gcr.io/google_containers/binary-arch
e.g. gcr.io/google_containers/hyperkube-amd64
instead of gcr.io/google_containers/hyperkube-linux-amd64
But, maybe you want darwin
support in the future 😄
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.
My initial motivation was consistency with how we name our server .tar.gz
files with a release. However keeping only architecture has the advantage of being shorter.
@zmerlynn Any preference?
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.
Another advantage with just the arch is consistency with hyperkube and some other images
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.
What other images? I wouldn't take hyperkube
as an example yet. It's still more like an experiment..
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.
AFAIK @brendandburns has pushed the pause, skydns, exechealthz and other addon images as experimental images (with the arch naming)
The thing is just that we have to keep it consistent. I am working on first-class ARM support and the naming here is quite important.
I think we should go with arch only naming, because docker runs natively only on linux for the time being. If we want to support darwin or windows in the future is another (probably long) discussion
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 agree that consistency is important. But as you can see it's not obvious with what we should be consistent :)
Indeed some images have been pushed with -arm
suffix. I'll change the naming to just the arch
.
BTW - I've noticed non-trivial ARM images cannot be build on amd64 machines. That means that we'll not be able to officially release those. How do you envision releasing ARM images?
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.
@fgrzadkowski I'm working on it.
And yes, it's possible to dynamically
cross-compile ARM binaries on amd64
hosts.
It's even possible to build ARM docker images on amd64
, like hyperkube
for example.
Inspiration: https://resin.io/blog/building-arm-containers-on-any-x86-machine-even-dockerhub/
I was so happy when I got this working: https://gist.github.com/luxas/e319b314f22b18243b1d
I have (locally) integrated this gist into kube-build
and it worked even on ARMv6
(e.g. hyperkube
as it is pushed now, only works on ARMv7
)
So I'm gonna upload a PR with my work when it's ready.
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.
Cool. Good to know.
I changed docker images naming to follow hyperkube convention.
Fyi, I want to include hack/lib in the release tar (see #19086). That would be a good place to share library code between build/ and cluster/ if you want to go with something more similar to the previous PR. |
3f939af
to
f46ed7e
Compare
GCE e2e test build/test passed for commit f46ed7ecc1827dc8a3408489e87c026ab68a214c. |
f46ed7e
to
b207cc8
Compare
@mikedanese To be hones I like the new approach more :) @zmerlynn I have updated this PR to also build and push docker image for |
"kube-controller-manager" | ||
"kube-scheduler" | ||
"kube-proxy" | ||
"hyperkube" |
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.
What about kubelet
? Just asking
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.
Kubelet is not running in docker container yet (I'm working on it...)
GCE e2e test build/test passed for commit b207cc80a40c2a8a98b55df26848b7631a235cd2. |
@@ -13,6 +16,12 @@ TEMP_DIR:=$(shell mktemp -d) | |||
all: build | |||
|
|||
build: | |||
ifndef REGISTRY |
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.
@fgrzadkowski Same comment here probably as: #19177 (comment)
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.
Done.
b207cc8
to
e7e8c5a
Compare
GCE e2e test build/test passed for commit e7e8c5a. |
@k8s-bot test this @fgrzadkowski Sorry, I've been on holidays and sick. Looking soon. |
This will be great to have merged 👍 |
The Travis failure is weird. Kicking forcibly. |
GCE e2e build/test failed for commit e7e8c5a. |
GCE e2e test build/test passed for commit e7e8c5a. |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
GCE e2e test build/test passed for commit e7e8c5a. |
Automatic merge from submit-queue |
Auto commit by PR queue bot
|
||
for arch in "${archs[@]}"; do | ||
for binary in "${binaries[@]}"; do | ||
local docker_target="${KUBE_DOCKER_REGISTRY}/${binary}-${arch}:${KUBE_DOCKER_IMAGE_TAG}" |
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.
@fgrzadkowski @mikedanese @zmerlynn
This creates compability issues when it doesn't push hyperkube
only, it just pushes hyperkube-arch
...
I assume we need to support hyperkube
only until all guides etc. are updated.
…-#19061-upstream-release-1.1 Automated cherry pick of #19061
…ry-pick-of-#19061-upstream-release-1.1 Revert "Automated cherry pick of #19061"
…ry-pick-of-#19061-upstream-release-1.1 Automated cherry pick of kubernetes#19061
…mated-cherry-pick-of-#19061-upstream-release-1.1 Revert "Automated cherry pick of kubernetes#19061"
…ry-pick-of-#19061-upstream-release-1.1 Automated cherry pick of kubernetes#19061
…mated-cherry-pick-of-#19061-upstream-release-1.1 Revert "Automated cherry pick of kubernetes#19061"
This will release the following images:
Fixes #11751
@ihmccreery @mikedanese @quinton-hoole