kubernetes-sigs/cluster-api-provider-aws

e2e: build kind node images instead of pulling prebuilt kindest/node

Open

#6,033 opened on May 27, 2026

View on GitHubContributor guide
 (5 comments) (1 reaction) (0 assignees)Go (689 forks)auto 404
help wantedpriority/important-soontriage/accepted

Repository metrics

Stars
 (723 stars)
PR merge metrics
 (PR metrics pending)

Description

Our e2e tests currently depend on prebuilt kindest/node images being published for the exact Kubernetes version we target. This creates a recurring pain point: when we bump Kubernetes (e.g. to v1.34.8), the matching kindest/node image often doesn't exist yet, breaking CI.

We had to work around this in #5857 by pinning the management cluster to an older kind image (v1.34.3) while using v1.34.8 for workload clusters.

Proposal

Switch to building kind node images with kind build node-image <version> instead of relying on prebuilt kindest/node images. As noted in kubernetes-sigs/kind#4157 (comment: https://github.com/kubernetes-sigs/kind/issues/4157#issuecomment-4555966335), this is not more expensive than pulling a prebuilt image, either way you download a tarball of k8s binaries + the base image layer.

This would allow us to use the same Kubernetes version for both management and workload clusters, and avoid breakage when kindest/node images lag behind Kubernetes releases.

Contributor guide

Research direction
Investigate the current e2e test setup in the repository, specifically the CI configuration that pulls prebuilt kindest/node images. Determine how to replace the pull step with 'kind build node image' using the desired Kubernetes version. Examine the kind documentation and existing patterns, such as the comment referenced in kubernetes sigs/kind#4157. Ensure the change works for both management and workload clusters. Test the new approach locally and update the CI pipeline accordingly.
Tech stack
go
Domain
backendinfrastructuredevopsci cdtesting
Issue type
Refactor
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
GoKuberneteskindCI/CD
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40