Compatibility with Aspire K3s integration

[jmezach]

The Aspire CommunityToolkit recently gained a K3s hosting integration, see https://github.com/CommunityToolkit/Aspire/tree/main/src/CommunityToolkit.Aspire.Hosting.K3s. This allows you to spin up a local Kubernetes cluster which is ideal for testing an operator locally. While trying this out though I found some incompatibilities with the current KubeOps Aspire integration. Specifically the RunWithKubernetes() extension method requires a KubernetesEnvironmentResource as the parameter, but the K3s integration has a custom K3sClusterResource which does not inherit from that.

I have worked around this for now by doing a WithReference(k3sCluster) on the result of AddKubeOps<T>() which injects a KUBECONFIG environment variable pointing at the correct kubernetes config file so that the operator talks to the correct cluster. But that requires me to manually start the operator and it also doesn't deploy the CRD's automatically.

Now I realise both of these are fairly new, but it would be great if these two things could be working together so I just wanted to get the ball rolling here ;).

[kimpenhaus]

Hey Jonathan @jmezach - thanks for reaching out and raising this issue. I have to admit I am not familiar with Aspire and didn't built much parts of the initial integration. I think I understood where the problems are and tried to give you a better support for the k3s.

If you could give that pull request a try and give me some feedback that would be more than awesome.

it should work something like that:

  var k3s = builder.AddK3sCluster("k3s");
  builder.AddKubeOps<Projects.MyOperator>("operator").RunWithKubernetes(k3s);

Thanks,
m

[jmezach]

@kimpenhaus Thanks for the quick turnaround. Would love to give this a try, but is there a prerelease package I can use? Or do I have to checkout the source and use a project reference?

[kimpenhaus]

@jmezach unluckily pre-releases are only generated after merging a pr to main. release cycle is on Tuesdays - until than pre-release versions are created.

to workaround that I usually check out the code and created local pre-release packages that I include via nuget than. something like that:

dotnet pack -p:PackageVersion=12.0.0.pre.1 --output ../packages/

you can use a local nuget folder as package source.

I know it is not perfect - but hopefully helps

[jmezach]

Thanks, that worked. I just gave it a spin and worked like a charm on the first try. Would be nice to have this as an option :).

[kimpenhaus]

that's pretty cool - I am going to complete the pull request. it will be included in the next main release - until than as mentioned pre-release 😄

thanks for testing it out!