feat: cache managed Cilium dns-proxy images in Linux VHDs

[ttevatia]

Is your feature request related to a problem?/Why is this needed

Managed Cilium deploys
mcr.microsoft.com/containernetworking/cilium/dns-proxy:<managed-tag> in the
Linux-only acns-security-agent DaemonSet. The image is not currently listed
in AgentBaker parts/common/components.json, so every fresh node requires a
successful runtime MCR pull before this ACNS DNS component can start.

Fleet investigation found repeated dns-proxy image-pull failures during a
registry transport anomaly. A separate large node-replacement wave also
confirmed that each new node performed the network pull, adding avoidable
registry demand and startup variance.

This image is not part of the Cilium CNI installation init chain. The request
is therefore an ACNS availability and deterministic-startup improvement, not a
claim that dns-proxy blocks core CNI initialization.

Describe the solution you'd like in detail

Add mcr.microsoft.com/containernetworking/cilium/dns-proxy:* to
parts/common/components.json, following the current-and-previous version
pattern already used by cilium-distroless and cilium-distroless-init.

Proposed initial entries:

• Cilium 1.18: v1.18.12-260811 and v1.18.11-260622
• Cilium 1.19: v1.19.6-260811 and v1.19.5-260714

All four tags are published for Linux amd64 and arm64. windowsVersions
should remain empty.

The final versions should be checked against the exact tags rendered by the
AKS RP/chart. AgentBaker should preserve both current and previous tags while
they coexist in the managed fleet.

Acceptance criteria:

1. A fresh amd64 and arm64 node from the target VHD already contains the exact
   managed dns-proxy image before acns-security-agent starts.
2. Kubelet reports the image already present and does not issue a registry
   Pulling event for that tag.
3. Current and previous managed tags remain cached during version transitions.
4. A large replacement-wave test confirms there is no dns-proxy
ErrImagePull or ImagePullBackOff.
5. Release validation detects an RP/chart tag that is absent from the VHD
   manifest.

Describe alternatives you've considered

• Runtime retries leave node startup dependent on registry and network
  availability.
• Karpenter or Cluster Autoscaler pacing reduces concurrency but does not
  remove the dependency.
• A local mirror adds another serving path and operational dependency.
• Monitoring detects delayed startup but does not prevent it.

VHD caching is the existing AgentBaker mechanism used by neighbouring managed
Cilium images and removes the pull from the fresh-node critical path.

Additional context

Related work: #9325 adds azure-iptables-monitor to the Linux VHD cache for
the separate CNI-bootstrap path.

[ttevatia]

Do we want to cache another image?

Yes, subject to Node SIG approval of the storage tradeoff. This is one logical Linux-only image, containernetworking/cilium/dns-proxy, used by the managed ACNS acns-security-agent DaemonSet. It is not part of CNI installation; the value is removing the runtime MCR dependency before ACNS DNS policy and visibility become available on a fresh node.

Who maintains the version?

The proposed AgentBaker change adds containernetworking/cilium/dns-proxy to the existing cilium-ipam Renovate group. AgentBaker's custom Docker manager then discovers new MCR tags and rolls latestVersion to previousLatestVersion, while routing update PRs to team:acn-cni-reviewers and the existing Cilium assignees.

Ownership should be explicit:

• ACNS/Cilium image owners: own the supported tag set, verify parity with the tag rendered by the AKS RP/chart, and approve/adjust Renovate PRs.
• AgentBaker/Node Lifecycle: own the VHD cache mechanism and VHD-size/build validation, not selection of the managed Cilium version.

Renovate alone is not sufficient evidence to ship a tag because the newest published MCR tag can precede RP rollout. The ACNS owner must validate RP/chart parity before approval.

Storage cost

Measured from the published multi-arch OCI manifests, counting unique compressed layers per VHD architecture:

Cache set	amd64	arm64
Current tags only: 1.18.12 + 1.19.6	62.1 MiB	56.8 MiB
1.18 current + previous	79.2 MiB	73.3 MiB
1.19 current + previous	75.5 MiB	69.8 MiB
Both tracks, current + previous (four tags)	141.2 MiB	130.0 MiB

Individual images are approximately 35-41 MiB compressed. The actual final VHD delta can differ because containerd also unpacks snapshots and may share filesystem content; the Linux VHD gate should report the before/after disk delta before approval.