Hi team, first off — thanks for v0.1.0. We've been putting the agent through a 3-node Raspberry Pi 5 rack as the edge tier for an AKS cluster (part of an edge-tolerance demo), and wanted to share a few observations from the journey. Apologies if any of these are already known or have workarounds we missed.
What we observed
In Arc mode the installer seems to look up the target AKS cluster in the same resource group as the Arc machine. In pkg/arc/arc_installer.go we noticed:
clusterRG := arcConfig.ResourceGroup
In our test the Arc machine lived in rg-edge and the cluster lived in rg-aks, and listClusterAdminCredentials returned 404 because the agent looked for the cluster in rg-edge. Moving the Arc machine into the same RG worked around it.
Impact for our scenario
Several customer topologies we're prototyping for (retail, manufacturing) keep edge devices in a per-site or per-region RG and the managed-service control plane in a separate platform-team RG, mainly for blast-radius, RBAC scoping, billing and lifecycle reasons. Putting them in one RG is a tough conversation, so we wanted to flag this early.
One possible direction
Would it be feasible to add an explicit targetCluster.resourceGroup (and optionally targetCluster.subscriptionID) to the agent config, defaulting to the Arc machine's RG/sub for backward compatibility? Happy to test a prototype on the Pi rack if useful.
Version tested: v0.1.0 (git 65d8d38, build 2026-05-22).
Other observations from the same Pi-rack edge demo
Hi team, first off — thanks for v0.1.0. We've been putting the agent through a 3-node Raspberry Pi 5 rack as the edge tier for an AKS cluster (part of an edge-tolerance demo), and wanted to share a few observations from the journey. Apologies if any of these are already known or have workarounds we missed.
What we observed
In Arc mode the installer seems to look up the target AKS cluster in the same resource group as the Arc machine. In
pkg/arc/arc_installer.gowe noticed:In our test the Arc machine lived in
rg-edgeand the cluster lived inrg-aks, andlistClusterAdminCredentialsreturned 404 because the agent looked for the cluster inrg-edge. Moving the Arc machine into the same RG worked around it.Impact for our scenario
Several customer topologies we're prototyping for (retail, manufacturing) keep edge devices in a per-site or per-region RG and the managed-service control plane in a separate platform-team RG, mainly for blast-radius, RBAC scoping, billing and lifecycle reasons. Putting them in one RG is a tough conversation, so we wanted to flag this early.
One possible direction
Would it be feasible to add an explicit
targetCluster.resourceGroup(and optionallytargetCluster.subscriptionID) to the agent config, defaulting to the Arc machine's RG/sub for backward compatibility? Happy to test a prototype on the Pi rack if useful.Version tested: v0.1.0 (git 65d8d38, build 2026-05-22).
Other observations from the same Pi-rack edge demo
assignRBACRolesvalidateExclusiveAuthSettingstreats Arc and bootstrap-token as mutually exclusivekube1systemd-nspawn launcher passes--network-vethbut actually shares host netns