wrong architecture in v1.5.0 image
Closed this issue · 12 comments
Hi @nikolaydubina, could you provide more details for replicating this issue? Could you share more details about your setup and workload deployment?
Some other helpful information to know would be:
- Are you using non-managed driver?
- Are you using a privately hosted sidecar image?
Are you using non-managed driver?
I am following https://cloud.google.com/kubernetes-engine/docs/how-to/persistent-volumes/cloud-storage-fuse-csi-driver#private-image
I am running in private nodes, and have to use private image.
I guess this is "non-managed" driver.
Are you using a privately hosted sidecar image?
yes
Thanks! Could you confirm the image you're using and how you got it? Do you have the image SHA that's placed in your workload yaml? The links in the description point to the same place.
I get image from here:
https://cloud.google.com/kubernetes-engine/docs/how-to/persistent-volumes/cloud-storage-fuse-csi-driver#private-image > https://github.com/GoogleCloudPlatform/gcs-fuse-csi-driver/blob/main/docs/releases.md#gke-compatibility
then the one at the bottom for v1.5.0
image
gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter@sha256:a527a083127fb456c96a6e4a478639222065dc0c2d485729e63605035d624f8f
That's odd. I'll try to recreate this week... I see the manifests link to the right sha's too.
I'm curious if there's an external factor at play, could you share the cluster ID with me? You can get the ID by running gcloud container clusters describe <cluster-name> --location <cluster-location> | grep id:
, and share the id with me? Thanks!
hey, sorry will have to back off here. can't share cluster id (other ids from my GCP) for security reasons.
I can share details of my cluster / nodes tho. hope that helps:
1.30.5-gke.1014001
asia-southeast
IPv4
Cloud Storage Fuse CSI driver: Enabled
Container-Optimized OS with containerd (cos_containerd)
as for sidecar spec, I am closely following: https://github.com/GoogleCloudPlatform/gcs-fuse-csi-driver/blob/main/docs/sidecar-manual-injection.md
as for the rest, I think this should be possible to repro in brand new cluster.
Could you share the exact steps you are doing to:
- Copy the image from public artifact registry to your local machine
- Steps you're doing to prepare the image locally (if any, i don't think there should be any).
- Push image to your private registry
Our original image manifests have not changed. For example, the v1.5 image manifest still handles both arm and amd.
docker pull --platform=linux/amd64 gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter@sha256:a527a083127fb456c96a6e4a478639222065dc0c2d485729e63605035d624f8f
now produces amd64
maybe I did not use --platform
flag before? but I used same command to pull all images last time, how come other images were pulled correctly and this was not? anyways, odd!
ARG TARGETPLATFORM
can be set externally and can affect the selection of the gcsfuse binary architecture. I'm not entirely sure how this can happen when pulling the image locally or pushing it to private registry.
I'm not familiar with the interface that you're using to view the image architecture. Could you share what that is? If you could share the steps you took to get there would be helpful too (to document it)!!
thanks for investigating this @hime.
probably good idea to have test that hits image registry for all platforms you expect. 🤔
Created item to track documentation guide improvements. Closing as issue is now resolved.