feat: bundle k3d binary + explicit kubeconfig merge for --cluster=k3d

[szhekpisov-katanox]

Two changes that make the existing --cluster=k3d option work reliably in the published image:

• Bundle the k3d binary in the image. The image shipped kind but not k3d, so --cluster=k3d failed out of the box. Adds the k3d binary alongside kind in the Dockerfile.
• Explicit kubeconfig merge after k3d cluster create. k3d's end-of-create kubeconfig merge is best-effort: on failure it only logs a warning and still exits 0, and its output was discarded. The tool then died later with a cryptic No kubeconfig file found. Running k3d kubeconfig merge --kubeconfig-merge-default explicitly surfaces the real error at the point of failure.

Split out of #452 per review.

[dag-andersen]

Hi @szhekpisov-katanox
Thank you for splitting this out into a separate PR.

Before deciding whether we should add k3d to the image, I would like to understand the motivation a bit better. Why would you prefer using k3d inside the container instead of kind? What benefits do you see? 👀 I am just curious about the use case.

The current behavior is actually intentional. The published container image only ships with kind, to keep the image smaller and avoid bundling multiple cluster providers. Users can still use other cluster types, including k3d, when running argocd-diff-preview as a binary instead of using the container image.

[szhekpisov-katanox]

Hi @dag-andersen, k3d takes less time to spin up, has smaller binary size and consumes less resources due to it's architecture. Hence the intention to use it instead of kind. Just did a parallel run on the same PR, results are on the screenshot.

[dag-andersen]

Hi @dag-andersen, k3d takes less time to spin up, has smaller binary size and consumes less resources due to it's architecture. Hence the intention to use it instead of kind. Just did a parallel run on the same PR, results are on the screenshot.

@szhekpisov-katanox That is interesting!
Because when i test it locally from my machine, then i get the opposite result. kind is 3 times faster than k3d.
But to be honest i have never tried in a GitHub action workflow

> make run-with-docker target_branch=helm-example-3 cluster_type=k3d
⏰ Run time stats: [Applications: 36], [Full Run: 1m47s], [Rendering: 17s], [Cluster: 29s], [Argo CD: 59s]

vs.

> make run-with-docker target_branch=helm-example-3 cluster_type=kind
⏰ Run time stats: [Applications: 36], [Full Run: 1m10s], [Rendering: 12s], [Cluster: 9s], [Argo CD: 46s]

So [Cluster: 29s] vs. [Cluster: 9s]

Would you mind testing if locally from your machine?

[szhekpisov-katanox]

Hi @dag-andersen ,

Thank you for provided commands. With them and 0 agents I was able to achieve median 1m46s for k3d and 1m23s for kind (7 local runs). With that I can conclude that kind is faster indeed.

I'll run more performance tests on GitHub Actions to understand, why runs there are different, and will let you know about results.

[dag-andersen]

Hi @dag-andersen ,

Thank you for provided commands. With them and 0 agents I was able to achieve median 1m46s for k3d and 1m23s for kind (7 local runs). With that I can conclude that kind is faster indeed.

I'll run more performance tests on GitHub Actions to understand, why runs there are different, and will let you know about results.

@szhekpisov-katanox Thank you! sounds good 🚀

[szhekpisov-katanox]

Hi @dag-andersen ,

I did additional benchmarks, and kind runs were faster anyway. Probably my previous results were a fluctuation in network or something. I'm closing this PR - thank you!