Unable to deploy k3d bundle while kubectl context is set to different architecture

[JeffResc]

Environment

Device and OS: MacOS 15.5
App version: v0.27.9
Kubernetes distro being used: EKS for amd64, k3d for arm64, likely irrelevant
Other:

Steps to reproduce

1. On an arm64 device, set your kubectl context to an amd64 cluster
2. Run uds deploy k3d-core-slim-dev:0.46.0
3. It will fail with failed to validate bundle: arch arm64 does not match cluster arch, [amd64 amd64 amd64 amd64 amd64]

Expected result

Since k3d bundle deploys k3d locally to the device, the architecture of the kubectl context cluster is irrelevant and the k3d bundle deploy should deploy

Visual Proof (screenshots, videos, text, etc)

Screen.Recording.2025-07-16.at.1.12.24.PM.mov

Severity/Priority

Additional Context

While having kubectl context set to amd64 on an arm64 device, I have been unsuccessful in finding a workaround. I have tried the following commands for good measure:

uds deploy k3d-core-slim-dev:0.46.0
uds deploy k3d-core-slim-dev:0.46.0 -a arm64
UDS_ARCHITECTURE="arm64" uds deploy k3d-core-slim-dev:0.46.0
UDS_ARCHITECTURE="arm64" uds deploy k3d-core-slim-dev:0.46.0 -a arm64

[joelmccoy]

This is probably more relevant to UDS CLI. I've had this happen to me before. As I understand it, essentially the k3d zarf package creates a k3d cluster locally (ref). This updates your kubecontext to your local arch, but deploying the bundle is using the kubecontext set before the command. I'm pretty sure UDS CLI has some validation of the architecture based on your current kubecontext.

I think ideally, UDS CLI should honor the architecture flag for the kubecontext as well?

Quick work arounds in the meantime:
If you already have a k3d cluster up: kubectl config use-context k3d-uds
If you don't have a k3d cluster up: k3d cluster create uds

Then the above commands will work because your kubecontext before running the uds command will be set to your local arch. Might be worth dropping an issue on UDS CLI? I'm not sure core has the power to fix this.

[mjnagel]

Yep I think @joelmccoy nailed it from my understanding as well. The issue is that CLI is assuming you are going to deploy the bundle to your existing cluster. It looks like this behavior was added/introduced in #657.

Probably worth a CLI issue to identify if there's any way to bypass this or if something should be added. (this issue was just transferred) From CLI's perspective there's not a clear indicator that the bundle itself is going to create a new cluster, or what arch that cluster would be, so it might be tricky to "automatically" solve.

[mjnagel]

Seems like there's two things going on here:

• Package artifact lookup goes off of system arch or architecture flag: If you specify -a amd64 you will actually get the amd64 bundle pulled down, and get past the arch check. But in this case that's actually a problem because you want this bundle to deploy locally rather than on the remote cluster. This likely should evaluate the cluster context as well for arch (that wouldn't solve the issue here, but feels relevant to discuss).
• Package validation always goes off of the existing cluster/kube context if available. So even if you explicitly request the arm64 bundle, it blocks you from deploying it.

Identified a workaround that is pretty gross but appears to work?

• uds pull k3d-core-slim-dev:0.46.0 -a arm64: Explicitly pull the arm64 package first
• uds deploy uds-bundle-k3d-core-slim-dev-arm64-0.46.0.tar.zst -a amd64: Deploy the local package, setting arch to amd64. This appears to get around the cluster arch check, and then since you already pulled the arm artifact it will deploy that one.

This is definitely not ideal but worth mentioning in case someone hits this and it's a blocker.