use kind build node images instead of relying on official images#1234
use kind build node images instead of relying on official images#1234kannon92 wants to merge 1 commit into
Conversation
k8s-ci-robot
added
the
kind/cleanup
✅ Deploy Preview for kubernetes-sigs-jobset ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
k8s-ci-robot
added
the
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kannon92 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
approved
There was a problem hiding this comment.
Pull request overview
Updates the e2e Kind test harness to build Kubernetes node images locally (via kind build node-image) rather than relying on pre-published Kind node images, aligning CI with upstream release artifacts.
Changes:
- Derives a Kubernetes version string from
E2E_KIND_VERSIONand adds abuild_node_imagestep before cluster creation. - Switches
kind create clusterto usekindest/node:latestinstead of the previously configured$E2E_KIND_VERSION.
Comments suppressed due to low confidence (1)
hack/e2e-test.sh:46
kind create clusteris pinned to--image kindest/node:latest, while the precedingkind build node-image $K8S_VERSIONdoes not specify an output image tag. This makes the cluster image selection dependent on kind defaults and risks still pulling/running an officiallatestimage (non-reproducible and contrary to the PR goal). Explicitly tag the built node image and use the same tag increate cluster(ideally derived fromE2E_KIND_VERSION/K8S_VERSION).
$KIND create cluster --name $KIND_CLUSTER_NAME --image kindest/node:latest --wait 1m
| fi | ||
| export KUBECONFIG | ||
| $KIND create cluster --name $KIND_CLUSTER_NAME --image $E2E_KIND_VERSION --wait 1m | ||
| $KIND create cluster --name $KIND_CLUSTER_NAME --image kindest/node:latest --wait 1m |
There was a problem hiding this comment.
you can also explicitly set the image name in the build command and then here, for local development that might make more sense, e.g. jobset/kind-node:${K8s_VERSION} just to avoid conflicts between say, another repo using another kind version
There was a problem hiding this comment.
The biggest downside of kind build node-image vs pulling a pre-built image locally is losing the docker cache (in CI you are probably not persisting the docker image cache because it's usually huge).
For local development, you could skip re-building your custom named image if it already exists.
For extra security something roughly like jobset/kind-node:$(kind version)-${K8s_VERSION}.
There was a problem hiding this comment.
cc @BenTheElder ptal at the sibling PR in Kueue: kubernetes-sigs/kueue#11251
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Build kind images from upstream rather than relying on Kind to host official images.
Which issue(s) this PR fixes:
Fixes #1233
Special notes for your reviewer:
Does this PR introduce a user-facing change?