Kubernetes deployment with "nested" Helm charts

[jmezach]

I have been looking into the Kubernetes deployment feature to figure out if we could leverage this for our deployments. We have also recently started looking into using Helm to do our Kubernetes deployments. This has led us down a path of building a couple of "helper" charts that deploy specific "types" of services, ie. web API's or micro-frontends. These "helper" charts also take care of a lot of plumbing such as injecting a sidecar or init containers and setting certain environment variables that we need everywhere. So in order to deploy a typical solution we'd have a Chart.yaml that contains a set of dependencies that point to these "helper"-charts which then do the heavy lifting.

Looking at the current Kubernetes deployment feature there doesn't seem to way to further customize the Chart.yaml being generated and it currently doesn't seem to support dependencies at all. Ideally what I would like to be able to do is to define for each resource in our Aspire AppHost to point to the "helper"-chart needed to deploy that resource and then the Chart.yaml would have the dependency for that. So for example:

var builder = DistributedApplication.CreateBuilder(args);

builder.AddKubernetesEnvironment("k8s");

builder.AddProject<Projects.WebApi>("mywebapi")
    .WithHelmChart("webapi", "oci://mycontainerregistry.azurecr.io/helm-charts")

builder.AddProject<Projects.frontend>("myfrontend")
    .WithHelmChart("frontend", "oci://mycontainerregistry.azurecr.io/helm-charts")

would then result in the following Chart.yaml:

apiVersion: v2
name: myapp
description: A Helm chart for deploying my app
type: application
version: "0.0.1"
appVersion: "0.0.1"

dependencies:
  - name: webapi
    version: "^1"
    repository: "oci://mycontainerregistry.azurecr.io/helm-charts"
    alias: mywebapi
  - name: frontend
    version: "^1"
    repository: "oci://mycontainerregistry.azurecr.io/helm-charts"
    alias: myfrontend

This is not something that we can currently do with Aspire as far as I can tell. But would it make sense to add this? Or are we perhaps going down the wrong path?

[mitchdenny]

Thanks for sharing this idea. We are continuing to build out our Kubernetes support. The first step is end to end deployment, but this is the second time this week that folks have suggested something similar to this.

I think our first exploration in this space would be referencing external charts as dependencies to the app model and being able to have a run-time Kubernetes cluster (this would allow folks to build operators etc).