Synthesize cdk8s apps into Helm Charts

[iliapolo]

---

• Hit the like (👍) or dislike (👎) button to let us know what you think about this feature.
• Feel free to ask any clarifying questions or suggest enhancements.
• This is just a proposal and intentionally doesn’t focus on technical details but rather on customer experience. If the proposal is accepted we will publish a detailed RFC where you’ll get a chance to provide more feedback.

---

Currently, synthesizing a cdk8s application will produce a set of Kubernetes manifest files into a target output directory (e.g ./dist). Customers can then take these manifests and deploy them to a cluster using their preferred deployment tool.

One such popular deployment tool is Helm. However, trying to deploy the dist directory with helm will result in an error:

helm install <release-name> ./dist
Error: Chart.yaml file is missing

This is because helm expects its input to be structured as a Helm Chart. To make it easier to deploy cdk8s applications with helm, we propose a new option to the cdk8s synth command, that will allow synthesize a cdk8s app directly into a Helm Chart, which can be passed as is to helm. The proposed customer experience would be:

cdk8s synth --format helm --output dist && helm install <release-name> ./dist

Internally cdk8s will generate the Chart.yaml file and whatever else is needed to adhere to the Helm chart format.

Note that this capability does not facilitate the synthesis of cdk8s libraries into helm charts, only cdk8s apps. The difference being that an app contains the inputs, while a library only defines constructs. See this issue for more details on that.

[mbonig]

I assume the output in the dist won't fundamentally change, just the addition of a Chart file? What about about a values file?

[iliapolo]

I believe the manifests also need to be placed in a templates directory. There might be more changes i'm not aware of.
A values file won't be necessary because the manifests will already contain the inputs as they are part of the cdk8s application.

This will of course be optional, we won't change the default output of cdk8s synth.

[reitzig]

A values file won't be necessary because the manifests will already contain the inputs as they are part of the cdk8s application.

That does not cover our use case; we need to deliver configurable Helm charts to customers. In that case, cdk8s would have to provide some programmatic way to output {{ .Values.some.path }} into the manifest (template), and put any defaults into values.yaml. (If I were allowed to dream, we'd also get values.schema.json. ;) )

[s-silvius]

values are needed. Common use case for bigger companies would be to use cdk8 to help dev velocity on hundreds of dev teams for huge projects involving many hundreds of complex k8s applications. But reality of of big corporations are that they never yet got even close to gitops or cd delivery of any kind. Customer deliveries always needs packaging hundreds of Helm charts and it's difficult to replace Helm package as delivery artifact any time soon. And those packages are installed years to hundreds of customers with variety of environments. so yes values are needed to override many values at install time.

[zhelyan]

It is possible to deploy a cdk8s chart with Helm but it's hacky:

• create a dummy chart containing only Chart.yaml, templates/resources.yaml and values.yaml. The template loops over and renders a list of dicts

# in ../dummy_chart

# helm values.yaml
resources: {}

# templates/resources.yaml
{{- range $v := .Values.resources }}
---
{{$v | toYaml }}
{{- end }}

Then synth your cdk8s app and pass the output ( list of yaml strings ) to the chart template by setting the relevant override in HelmChart.values. This allows for any cdk tokens in the synth output to be resolved

import cdk8s_plus_26.k8s as cdk8splus

bucket = Bucket(self, "Bucket)

app = cdk8s.App(outdir="dist/test")
chart = cdk8s.Chart(app, "Test")

# cdk8s resource containing a token
cdk8splus.KubeConfigMap(chart, "ConfigMap", data={
    "s3_bucket": bucket.bucket_name
})

data = app.synth_yaml()
helm_overrides = { "resources": list(yaml.safe_load_all(data)) }

asset = Asset(self, "ChartAsset2", path=path.join(
    path.dirname(path.realpath(__file__)), "../dummy_chart"
))

HelmChart(
    self,
    "Cdk8sHelmRelease",
    chart_asset=asset,
    cluster=cluster,
    create_namespace=False,
    release="test",
    namespace=namespace,
    wait=True,
    timeout=Duration.minutes(15),
    values=helm_overrides
)

you can wrap all this in L2 that generates and deploys the Helm chart e.g

Cdk8sHelmChart(self, "Chart",
     version="1.0.0",
     chart_version="2.0",
     resources=cdk8s_resources, # list[str]
     cluster=cluster,
     namespace=namespace,
    .....

[cdecoux]

Isn't this what the helmify project is for?

[bdoyle0182]

So it seems like today there is the capability that's been discussed ad nauseum in several issues / proposals to generate the output as a helm chart. But, nothing has been done to be parameterizable? I understand the difficulty with translating programming language logic into go templates, but as noted in this comment #1196 (reply in thread), supporting values alone seems reasonable