Similar to #109 it seems that the designated ARM64 images don't actually contain an ARM64 binary.
Behavior
I have an EKS cluster with Graviton (ARM) nodes. When running the following test:
kubectl run test --image=ghcr.io/nirmata/kyverno-notation-aws:latest@sha256:f6a531c5f6af9d2797c176d3ae337e07adf24aba9a39d51693fce15fdd9ea01c
the pod will fail with the folowing message indicating an arch mismatch:
exec /kyverno-notation-aws: exec format error
The specific ARM image SHA I took from here: https://github.com/nirmata/kyverno-notation-aws/pkgs/container/kyverno-notation-aws/340382674?tag=latest
Root cause
The reason for this happening is actually a problem in the Dockerfile.
Although the Makefile correctly initiates a build for ARM and AMD using the following:
docker buildx build --platform linux/amd64,linux/arm64 -t $(REPO_IMAGE):$(IMAGE_TAG) --push .
the Dockerfile actually hardcodes a GO build for the AMD platform:
RUN GOOS=linux GOARCH=amd64 go build -ldflags="-w -s" -o kyverno-notation-aws .
The result is an ARM image with an AMD binary inside.
Solution
The solution is to correctly write the Dockerfile to accept arch arguments:
ARG BUILDER_IMAGE="golang:1.22.3-alpine3.18"
FROM --platform=$BUILDPLATFORM $BUILDER_IMAGE AS builder
ARG TARGETOS
ARG TARGETARCH
WORKDIR /
COPY . ./
# Get Signer plugin binary (keep architecture hardcoded for now if plugin isn't multi-arch)
ARG SIGNER_BINARY_LINK="https://d2hvyiie56hcat.cloudfront.net/linux/amd64/plugin/latest/notation-aws-signer-plugin.zip"
ARG SIGNER_BINARY_FILE="notation-aws-signer-plugin.zip"
RUN wget -O ${SIGNER_BINARY_FILE} ${SIGNER_BINARY_LINK}
RUN apk update && apk add unzip && unzip -o ${SIGNER_BINARY_FILE}
# Build Go binary correctly for target platform
RUN CGO_ENABLED=0 GOOS=$TARGETOS GOARCH=$TARGETARCH go build -ldflags="-w -s" -o kyverno-notation-aws .
FROM gcr.io/distroless/static:nonroot
WORKDIR /
ENV PLUGINS_DIR=/plugins
COPY --from=builder notation-com.amazonaws.signer.notation.plugin plugins/com.amazonaws.signer.notation.plugin/notation-com.amazonaws.signer.notation.plugin
COPY --from=builder kyverno-notation-aws kyverno-notation-aws
ENTRYPOINT ["/kyverno-notation-aws"]
Similar to #109 it seems that the designated ARM64 images don't actually contain an ARM64 binary.
Behavior
I have an EKS cluster with Graviton (ARM) nodes. When running the following test:
kubectl run test --image=ghcr.io/nirmata/kyverno-notation-aws:latest@sha256:f6a531c5f6af9d2797c176d3ae337e07adf24aba9a39d51693fce15fdd9ea01cthe pod will fail with the folowing message indicating an arch mismatch:
exec /kyverno-notation-aws: exec format errorThe specific ARM image SHA I took from here: https://github.com/nirmata/kyverno-notation-aws/pkgs/container/kyverno-notation-aws/340382674?tag=latest
Root cause
The reason for this happening is actually a problem in the Dockerfile.
Although the Makefile correctly initiates a build for ARM and AMD using the following:
docker buildx build --platform linux/amd64,linux/arm64 -t $(REPO_IMAGE):$(IMAGE_TAG) --push .the Dockerfile actually hardcodes a GO build for the AMD platform:
RUN GOOS=linux GOARCH=amd64 go build -ldflags="-w -s" -o kyverno-notation-aws .The result is an ARM image with an AMD binary inside.
Solution
The solution is to correctly write the Dockerfile to accept arch arguments: