GCI: Ensure that the right version of kubelet is used #25504
Conversation
k8s-github-robot
added
size/S
| # So, we compare the versions to ensure this run-time binary replacement is only | ||
| # applied for OSS kubernetes. | ||
| readonly builtin_version="$(/usr/bin/kubelet --version=true | cut -f2 -d " ")" | ||
| readonly required_version="$(/home/kubernetes/bin/kubelet --version=true | cut -f2 -d " ")" |
There was a problem hiding this comment.
shouldn't this be taken from some environment var?
There was a problem hiding this comment.
Originally, I thought we can get version info from kube-env. But later I noticed there is no version var in that file. Theoretically, we can add KUBE_VERSION in kube-env file. There two downsides: (1) it will change much more places; (2) the meaning of KUBE_VERSION itself is complex (https://github.com/kubernetes/kubernetes/blob/master/cluster/common.sh#l257). A similar way is get version from the tarball URL listed in kube-env, but it has the same problem. So, the simplest way is to run "kubelet --version" just like what ContainerVM's config does (https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/configure-vm.sh#l89)
|
@roberthbailey will you please take a look? We will need to cherry pick it to release-1.2 before the next 1.2.X release. Thanks |
|
This looks ok to me but I'm going to assign to @zmerlynn to take a look since I won't be able to review it in the next couple of days. |
zmerlynn
added
release-note
zmerlynn
added
cherrypick-candidate
cherry-pick-approved
|
GCE e2e build/test passed for commit 63494f6. |
|
Do we have an e2e job that tests this? (build cop wondering how safe this is to merge) |
|
This change only affects GCI. We don't have a e2e job to test a pending PR. But I had manually ran e2e to verify it. And also ssh into instances to verify the logic. It is safe to merge I think |
|
@andyzheng0831 In the future, if you know something won't be tested by our e2e tests, please add the "e2e-not-required" label, otherwise the submit queue runs a pointless 40 minute test on it. |
|
@lavalamp Thanks for the suggestion! That will be better for both submit queue and GCI-specific changes |
|
Commit found in the "release-1.2" branch appears to be this PR. Removing the "cherrypick-candidate" label. If this is an error find help to get your PR picked. |
roberthbailey
added
the
release-note-none
roberthbailey
removed
the
release-note
…ry-pick-of-#24609-kubernetes#25504-kubernetes#25763-kubernetes#25609-kubernetes#25706-upstream-release-1.2 Automated cherry pick of kubernetes#24609 kubernetes#25504 kubernetes#25763 kubernetes#25609 kubernetes#25706
…ry-pick-of-#24609-kubernetes#25504-kubernetes#25763-kubernetes#25609-kubernetes#25706-upstream-release-1.2 Automated cherry pick of kubernetes#24609 kubernetes#25504 kubernetes#25763 kubernetes#25609 kubernetes#25706
This PR fixes a binary version issue in using GCI image. Unlike ContainerVM, we don't hard-code a GCI image version in kubernetes code. When a user creates a cluster using GCI, by default the latest "gci-dev" will be used, in which the latest kubelet and kubectl release binary are built. The problem is that the user may not intend to use the latest version. This PR is for fixing it.
@roberthbailey @dchen1107 please review it or assign it to a suitable reviewer. Please also mark it as a cherry-pick candidate.
cc/ @fabioy @wonderfly @kubernetes/goog-image