upgrade default node image #334
Conversation
k8s-ci-robot
added
the
do-not-merge/hold
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: BenTheElder The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
k8s-ci-robot
added
cncf-cla: yes
pkg/cluster/config/defaults/image.go
Outdated
| @@ -18,4 +18,4 @@ limitations under the License. | |||
| package defaults | |||
|
|
|||
| // Image is the default for the Config.Image field, aka the default node image. | |||
| const Image = "kindest/node:v1.13.3@sha256:d1af504f20f3450ccb7aed63b67ec61c156f9ed3e8b0d973b3dee3c95991753c" | |||
| const Image = "kindest/node:v1.13.3" | |||
There was a problem hiding this comment.
I'm extremely on the fence about pinning the image fully or not.
It's still possible to use a pinned image via --image, otoh being reproducible-ish out of the box is nice.
Any change we push to these images is arguably breaking, pinning avoids that 🤔
OTOH this allows us to push things like docker security fixes.
There was a problem hiding this comment.
i don't think pinning the image to the k8s patch release cycle is a good idea.
complex version schemas is a solution for that:
kindest/node:v1.13.3-0.1.0
where 0.1.0 is the kind version.
thus with a kind bump the image can be bumped too on security fixes.
There was a problem hiding this comment.
kindest/node:v1.13.3-0.1.0 is no different (in fact more complex and weaker) than putting the hash
There was a problem hiding this comment.
at this point IMO users should not depend on the specific contents of the node image, and kind itself handles this kind of image change fine.
There was a problem hiding this comment.
it's defenitely weaker than the hash but stronger than having the k8s release only.
There was a problem hiding this comment.
kubeadm itself seems to pin to stable-1?
https://github.com/kubernetes/kubernetes/blob/b96378c058c99180b84efb259ec56e5ee31941ae/cmd/kubeadm/app/apis/kubeadm/v1beta1/defaults.go#L36:2
There was a problem hiding this comment.
yes, it does. but we are bound to the k8s release cycle.
There was a problem hiding this comment.
AFAICT the stable-1 is not bound though, it's looked up from the published releases?
that would be like if we used kindest/node:stable-1
There was a problem hiding this comment.
i'm going to add the hash for now and we can revisit this at the meeting or something. I think it's worth considering futher before we get too many releases in.
There was a problem hiding this comment.
AFAICT the
stable-1is not bound though, it's looked up from the published releases?
it tends to resolve to latest stable - e.g. currently 1.13.x
not binding to the k8s release allows you to push immediate fixes and not wait on a upstream PATCH bump, to bump an image for a docker fix. but either way is fine, as PATCH releases get pushed relatively often.
/lgtm
BenTheElder
force-pushed
the
upgraded-node-image
branch
from
a502562 to
4937d13
Compare
|
/hold cancel |
k8s-ci-robot
removed
the
do-not-merge/hold
k8s-ci-robot
added
the
lgtm
* Bump version to 0.3.3 * Add snapshot versions * Add dependencies
picks up #331
/hold