amd64 docker images have not been published

[bgoareguer]

Which version of kube-score are you using?

I am using the zegl/kube-score:v1.15.0-helm3 docker image on an x86_64 system:

$ uname -a
Linux ubuntu 5.4.0-135-generic #152-Ubuntu SMP Wed Nov 23 20:19:22 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

What did you do?

I pulled the Docker image from the Docker Hub with the following command:

docker pull zegl/kube-score:v1.15.0-helm3

I then tried to run kube-score with the following command:

cat swiss-army-knife.yaml | docker run --rm -i zegl/kube-score:v1.15.0-helm3 kube-score score -

What did you expect to see?
I expected kube-score to run without warning

What did you see instead?

Docker shows a warning telling me that the image I am trying to run does not match my host platform:

$ cat swiss-army-knife.yaml | docker run --rm -i zegl/kube-score:v1.15.0-helm3 kube-score score -
WARNING: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested
apps/v1/Deployment swiss-army-knife                                           💥
    [CRITICAL] Pod NetworkPolicy
        · The pod does not have a matching NetworkPolicy
            Create a NetworkPolicy that targets this pod to control who/what
            can communicate with this pod. Note, this feature needs to be
            supported by the CNI implementation used in the Kubernetes cluster
            to have an effect.
    [CRITICAL] Container Security Context ReadOnlyRootFilesystem
        · swiss-army-knife -> Container has no configured security context
            Set securityContext to run the container in a more secure context.
    [CRITICAL] Container Resources
        · swiss-army-knife -> CPU limit is not set
            Resource limits are recommended to avoid resource DDOS. Set
            resources.limits.cpu
        · swiss-army-knife -> Memory limit is not set
            Resource limits are recommended to avoid resource DDOS. Set
            resources.limits.memory
        · swiss-army-knife -> CPU request is not set
            Resource requests are recommended to make sure that the application
            can start and run without crashing. Set resources.requests.cpu
        · swiss-army-knife -> Memory request is not set
            Resource requests are recommended to make sure that the application
            can start and run without crashing. Set resources.requests.memory
    [CRITICAL] Container Ephemeral Storage Request and Limit
        · swiss-army-knife -> Ephemeral Storage limit is not set
            Resource limits are recommended to avoid resource DDOS. Set
            resources.limits.ephemeral-storage
    [CRITICAL] Container Security Context User Group ID
        · swiss-army-knife -> Container has no configured security context
            Set securityContext to run the container in a more secure context.
    [CRITICAL] Container Image Tag
        · swiss-army-knife -> Image with latest tag
            Using a fixed tag is recommended to avoid accidental upgrades

Additional details

The digest of the image I pulled:

$ docker image inspect zegl/kube-score:v1.15.0-helm3 | jq ".[0].RepoDigests"
[
  "zegl/kube-score@sha256:8e794bb74eb171d065f4faed7d43f3a08995e2ce106326368eaf280a3701383b"
]

Even though I pulled the image from a x86_64 system, I got an arm64 image:

$ docker image inspect zegl/kube-score@sha256:8e794bb74eb171d065f4faed7d43f3a08995e2ce106326368eaf280a3701383b | jq ".[0].Architecture"
"arm64"

On Docker Hub, the zegl/kube-score@sha256:8e794bb74eb171d065f4faed7d43f3a08995e2ce106326368eaf280a3701383b docker image corresponds to a arm64 image. It seems no image has been published for the x86_64 architecture.

Kube-score manages to scan my manifest because the kube-score binary is a x86_64 binary. After extracting the image, here is the result of the file command on the kube-score binary that was inside the image:

$ file ./usr/bin/kube-score
./usr/bin/kube-score: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=U5aCVzrMF1jCUG3Y8UnR/4Y2YPR3xDaScAfEzWmBf/Dx6swBXZFofLvYid1Cz7/kMR0wBQneVKsqqfWthn4, stripped

So a x86_64 binary has been copied into an arm64 Docker image and no x86_64 image has been published.

Can you please:

• publish x86_64 Docker images for kube-score 1.15.0
• re-publish the arm64 Docker images with a arm64 kube-score binary

[zegl]

Hey @bgoareguer! Thanks for reaching out, yes something definitely went wrong with the Docker builds in the last release (due to breaking changes in goreleaser).

I've published an experimental multi-arch (arm64 and amd64) container as zegl/kube-score:v1.16.0-dev. It contains kube-score, helm3, and kustomize. Could you please give it a test, and let me know if it works for you?

[bgoareguer]

The zegl/kube-score:v1.16.0-dev image works great for x86_64:

• the architecture of the pulled image is x86_64
• the kube-score, helm and kustomize binaries are x86_64

I cannot test it on arm64 since I do not have such hardware to test on but I can see the arm64 image on Docker Hub.

The only issue I saw is that the kube-score binary has been added twice in the image:

$ find ./ -name kube-score
./kube-score
./usr/bin/kube-score

[zegl]

Great, thanks for your help!

Yes, the binary was added twice for backwards compatibility with the previous generation of images. Some had the kube-score binary at /kube-score and some in /usr/bin/kube-score. Thinking of it tough, one of those could be a symlink...

I'll add the symlink and make a new release of kube-score. :-)

[bgoareguer]

Hi @zegl! One last thing: it seems you already had a zegl/kube-score:latest image on quay.io but this image is not up to date. Can you please either delete this image from quay.io or update it?

I am using a Docker mirror that searches for images in quay.io before docker.io, so it always returns me the old image from quay.io.

[zegl]

@bgoareguer Oh, I'd totally forgotten about quay. I'll see what I can do, it seems like Red Hat has blocked my account (logging in sends me to this article). I'll see what I can do to recover it.