Publish webhook docker image to k8s production container registry

[hbagdi]

What would you like to be added:

• Publish a production image of 0.4.0 tag for admission-server
• Document the steps necessary so that future maintainers doing a release can do this

Why this is needed:

We should have users relying on the production image rather than the staging ones.

Additional context:

• https://console.cloud.google.com/gcr/images/k8s-staging-gateway-api/global/admission-server

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[robscott]

Update: We are working on this. @youngnick updated the build script and we released v0.4.2 to test it out, unfortunately not quite working yet: https://prow.k8s.io/view/gs/kubernetes-jenkins/logs/post-gateway-api-push-images/1503442368546738176

/lifecycle frozen

[youngnick]

Okay, with #1043 and #1044 merged, we've validated that we've got images correctly labelled and in the staging GCR. Now to figure out how to get it to prod.

[youngnick]

The folks at ingress-nginx have really great RELEASE docs that include how they handle promoting images: https://github.com/kubernetes/ingress-nginx/blob/main/RELEASE.md#3-promote-the-images

In short:

• we PR to kubernetes/k8s.io, adding the SHA of the image we sent to staging to a YAML file.
• Once that PR is merged, that tag (and only that tag) will be promoted.

This means that once we do this, our release YAMLs will be able to use k8s.gcr.io/gateway-api/controller:<semver>.

I think we should keep our master YAMLs using the staging repo and :latest, maybe?

[hbagdi]

I think we should keep our master YAMLs using the staging repo and :latest, maybe?

That sounds good as long as we make sure to have YAML in the release tag pointing to the production image. I expect implemeneters to point to the repo with a release tag to do installation. That is what we do in our docs as well: https://gateway-api.sigs.k8s.io/v1alpha2/guides/getting-started/#installing-gateway-api-crds-manually

[shaneutt]

@youngnick where did we leave off with this one?

[youngnick]

It's still TODO, but I think that following what the ingress-nginx folks do seems like the way to go to me.

[gauravkghildiyal]

I've taken a shot at this. Would like to direct attention to PR https://github.com/kubernetes/k8s.io/pull/5030 as that is outside this repo and might get missed