Tutorials should aim to use multi-arch container images with source code transparency

[spurin]

This is a Feature Request

What would you like to be added

Kubernetes documentation tutorials should integrate multi-architecture container images alongside full source code transparency.

This approach provides universal accessibility of tutorials across amd64, ARM-based, and other Kubernetes-supported architectures, therefore ensuring a consistent learning experience.

Utilising images with open access to their source code is also beneficial. It improves transparency, facilitates auditing and independent builds whilst improving trust and security within the Kubernetes community.

From an implementation perspective, automating this process would be benefical. Upon detecting an image in a request, the system could automatically verify the image's multi-arch support or prompt for additional labels or notes before approval. For instance, images could be referenced as image=linux/amd64, image=linux/arm/v7, image=linux/arm/v8, linux/arm64 and/or require the inclusion of a note for the image source code. This approach could significantly enhance future efficiency and compliance.

Why is this needed

Issues have emerged where tutorial examples do not work for users using architectures beyond the traditional amd64 CPU instruction set as highlighted in the issue: https://github.com/kubernetes/website/issues/45809.

In the referenced issue, the image registry.k8s.io/liveness, last updated in 2014, supports only amd64. I have also been unsuccessful in identifying the source code for this image at present.

Reports of related issues can also be found in https://github.com/kubernetes/website/issues/45420 and https://github.com/kubernetes/website/issues/45783

[sftim]

Seems very reasonable

/triage accepted /priority backlog /lifecycle frozen

[sftim]

BTW, we already have some tests for verifying example manifests; we could extend those to report on whether referenced images are multi-arch (or multi-arch enough), and someone with capacity could change the PR process to run these automatically.

There's a good chance that other SIGs can help out with work in this area (eg SIG Release, SIG Testing).

[spurin]

The available architectures that are available in the pause container image may be a good starting point given that this represents a namespace in which containers will run alongside in a pod. Using the convenient google container registry explorer: https://explore.ggcr.dev/?image=registry.k8s.io%2Fpause%3A3.9

The linux supported architectures are -

• linux/amd64
• linux/arm/v7
• linux/arm64
• linux/ppc64le
• linux/s390x

There are also two windows ones listed as

• windows/amd64 (OS Version: 10.0.17763.2928)
• windows/amd64 (OS Version: 10.0.20348.707)

I'm guessing and open to constructive feedback that the windows specific ones are possibly not a strict requirement in this and are there from a pause viewpoint for support.

Regarding help from SIG Release and SIG Testing, is there a preferred way to start discussions in this space, i.e. via this feature request or via communication on slack?

[sftim]

Slack's a good place to start.