test images: Mirrors dockerhub images to staging

[claudiubelu]

What type of PR is this?

What this PR does / why we need it:

Dockerhub will introduce rate limiting in November, and a lot of E2E tests are relying on the busybox image. It could potentially become an issue causing jobs to fail because of this.

Ideally, we'd have the busybox image mirrored on gcr.io, but that could take some time. Until then, we can just have the Image Builder mirror the image for us in the staging registry and use that for tests until this issue is solved. The busybox image should NOT be promoted out of staging.

During the sig-testing meeting, it was decided that we should do the same for the other images are hosted on dockerhub.

Two different versions of httpd and nginx have to build, and thus, the have different folders. An ALIAS file was added to httpd-new and nginx-new in order to keep the same image name.

Note that the image docker.io/gluster/glusterdynamic-provisioner:v1.0 only has a linux/amd64 image.

Which issue(s) this PR fixes:

Fixes #

Related PR: Adds Image Builder jobs for these images: kubernetes/test-infra#20265

Special notes for your reviewer:

Mitigate dockerhub changes rolling out Nov 1st: kubernetes/test-infra#19477

Image building logs: https://paste.ubuntu.com/p/9q8HtpwpnW/

Does this PR introduce a user-facing change?:

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[claudiubelu]

/cc @spiffxp @BenTheElder

[justaugustus]

/retest
The rationale SGTM!

[oomichi]

/retest

[claudiubelu]

/retest

[claudiubelu]

Image building logs: https://paste.ubuntu.com/p/jDvZHshhdV/ (+ commit from: #95032)

Note: I was already intending to add the nginx and httpd images (+ Windows support: #77269), so I've reused some bits from there.

[spiffxp]

/priority important-soon
/kind cleanup
/triage accepted
/hold
/cc @thockin @BenTheElder
I'd like your input

[claudiubelu]

/open

[claudiubelu]

/reopen

[k8s-ci-robot]

@claudiubelu: Reopened this PR.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[justaugustus]

/hold

I feel like this may be the wrong approach here
i.e.,:

• creating new Dockerfiles to maintain
• building and repushing

What I think we want is:

• a remote-to-remote repo copy
• digest preservation
• no fiddling with multi-arch
• stored in the mirror registry so others are aware and can take advantage of these mirrors

@claudiubelu -- can you get me the exact list of images/tags that you're interested in, and give me a few days to work a prototype, so you can see what I mean?

cc: @wilsonehusin

[claudiubelu]

/hold

I feel like this may be the wrong approach here
i.e.,:

* creating new Dockerfiles to maintain

* building and repushing

What I think we want is:

* a remote-to-remote repo copy

* digest preservation

* no fiddling with multi-arch

* stored in the mirror registry so others are aware and can take advantage of these mirrors

@claudiubelu -- can you get me the exact list of images/tags that you're interested in, and give me a few days to work a prototype, so you can see what I mean?

cc: @wilsonehusin

From #97027 , these are the images that are currently on dockerhub but used in E2E tests (as it can be seen in kubernetes/test/utils/image/manifest.go:

docker.io/gluster/glusterdynamic-provisioner:v1.0
docker.io/library/busybox:1.29
docker.io/library/httpd:2.4.38-alpine
docker.io/library/httpd:2.4.39-alpine
docker.io/library/nginx:1.14-alpine
docker.io/library/nginx:1.15-alpine
docker.io/library/perl:5.26
docker.io/library/redis:5.0.5-alpine

IMO, we can still go ahead with the images: busybox, httpd, nginx, since ultimately, what we need is not just a simple mirror for them. On dockerhub, they do not contain any Windows images in their manifest lists, but we need them for our test jobs (the Kubernetes busybox image already has a Windows manifest list). I have a PR opened for the nginx and httpd images here: #77269

[BenTheElder]

I think that's a good point #95567 (comment),
also, nothing precludes migrating from a repo to repo copy implementation later (except that it sounds like that won't be sufficient b/c windows), but in the meantime people reported hitting issues with pull limits running tests right now.

I asked for this explicitly when the topic came up in SIG testing, I'm inclined to recommend we take this straightforward approach now to bring things under our control.

Additionally: performing a build of a custom image discourages users from trying to use kubernetes as a mirror of these images for arbitrary purposes (which we shouldn't take the cost or maintenance load for), instead of seeing these as all our e2e custom images, even if customization is very light.

[BenTheElder]

/lgtm
/approve

[claudiubelu]

FWIW, the image build logs for the images added in this PR using this PR: https://paste.ubuntu.com/p/zYHHTF4QkW/

[claudiubelu]

/hold

I feel like this may be the wrong approach here
i.e.,:

* creating new Dockerfiles to maintain

* building and repushing

What I think we want is:

* a remote-to-remote repo copy

* digest preservation

* no fiddling with multi-arch

* stored in the mirror registry so others are aware and can take advantage of these mirrors

@claudiubelu -- can you get me the exact list of images/tags that you're interested in, and give me a few days to work a prototype, so you can see what I mean?

cc: @wilsonehusin

Any news?

[jayunit100]

Hi folks hitting rate limits on e2es. What's the simplest way to unblock this?

We can run our own builds and publish if needed . What's the easiest thing to do here that is iterable ?

[dims]

going with @BenTheElder 's comment here : #95567 (comment)

we can always iterate

/approve
/lgtm
/hold cancel

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: BenTheElder, claudiubelu, dims, spiffxp

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:

• test/images/OWNERS [BenTheElder,dims,spiffxp]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment