Multiarch image is missing for 1.5 (k8s.gcr.io/defaultbackend-amd64:1.5)

[ialidzhikov]

What happened:
k8s.gcr.io/defaultbackend (https://console.cloud.google.com/gcr/images/google-containers/global/defaultbackend) does not have image with tag 1.5.

While k8s.gcr.io/defaultbackend-am64 (https://console.cloud.google.com/gcr/images/google-containers/global/defaultbackend-amd64) has image with tag 1.5.

Is the multi-arch image k8s.gcr.io/defaultbackend deprecated and no longer maintained? Or was the 1.5 image for some reason not published for it?

What you expected to happen:
To be clearly stated in the docs whether the multi-arch image is deprecated or not. If it is not deprecated the 1.5 image to be available for it.

How to reproduce it (as minimally and precisely as possible):
See above.

Anything else we need to know?:
N/A

[swetharepakula]

Hello @ialidzhikov,

The container image you are referencing is outdated. We have not updated that image registry in a few years. However we currently do not build multi-arch images for the default backend image yet. We are working on this.

[ialidzhikov]

Thanks for the update! Let's us know in this issue once we can try out multi-arch images for the default backend.
IMO, a short section in the README.md would be useful for the end users to know the details that you shared in #1719 (comment). For example a section similar to https://github.com/kubernetes/cloud-provider-aws#container-images explaining what is the official supported registry, are multi-arch images supported or not.

[ialidzhikov]

@swetharepakula do you have any updates on this one? Thanks in advance!

[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

[FernandoMiguel]

/remove-lifecycle stale

[sdickhoven]

we use ingress-nginx which uses this image as default backend:

https://github.com/kubernetes/ingress-nginx/blob/controller-v1.5.1/charts/ingress-nginx/values.yaml#L779-L780

we have just spun up a new kubernetes node pool with arm instances (which are cheaper, have better performance, and are better for the environment ♻️) and we would like to run all of our cluster's core services (which includes ingress-nginx and therefore also the default backend) on those arm nodes.

i realize that i could easily update the image that is used by the default backend deployment to e.g. nginxinc/nginx-unprivileged:1.23-alpine-slim (using defaultBackend.image.repository & defaultBackend.image.tag) and then mount in an nginx config along the lines of this (using defaultBackend.extraVolumes & defaultBackend.extraVolumeMounts):

  server {
      listen  8080;
      location / {
          return  404;
      }
      location = /healthz {
          return  204;
      }
  }

...but it would make the lives of those using ingress-nginx and wanting to run on arm that much easier if this image was simply built for multiple hardware architectures.

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[ialidzhikov]

/remove-lifecycle rotten

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[swetharepakula]

The build scripts have been updated to create multiarch images for the default backends (404-server & 404-server-with-metrics). You should be able to push an image to the registry of your choice with:

CONTAINER_BINARIES="404-server-with-metrics" REGISTRY=<registry> make all-push ALL_ARCH='amd64 arm64'

We however no longer publish a default-backend image and expect users to build and maintain their own.

[nlamirault]

/remove-lifecycle rotten

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[ialidzhikov]

We however no longer publish a default-backend image and expect users to build and maintain their own.

Why? Is it possible to reconsider this?

/remove-lifecycle rotten

[ialidzhikov]

/lifecycle frozen