Kubernetes support via Helm chart

[bartversluijs]

I've spent quite some time in creating a Helm Chart for Kubernetes to deploy openBalena via Kubernetes.
I'm confident now that this Helm Chart is stable enough to be supported in the main openBalena repository and I'd like to get the opinion of the openBalena contributors as well as the community what could be improved and what's needed to get this PR merged.

The Helm Chart will create the following services, with the same versions as the current openBalena version:

• openBalena API
  • Deployment
  • Service for port 80
  • Ingress to api.<hostname> with TLS rule
• openBalena VPN
  • Deployment
  • Service for port 443 and 3128
  • Ingress to vpn.<hostname>
  • HAProxy snippet to get the VPN working over port 443
• openBalena Registry
  • StatefulSet with PVC
  • Service for port 80
  • Ingress to registry.<hostname> with TLS rule
• openBalena S3
  • StatefulSet with PVC
  • Service for port 80
  • Ingress to s3.<hostname> with TLS
  • Can be disabled if you're using an external S3, which can be configured in the values.yaml
• openBalena DB
  • StatefulSet with PVC
  • Service for port 5432
• Redis
  • StatefulSet with PVC
  • Service to port 6379
• VPN Tunnel via TLS
  • HAProxy Ingress TCP service with TLS to VPN service port 3128
  • Ingress to tunnel.<hostname> with TLS

This will also resolve #6.

---

Please let me know what you think!

[fabienheureux]

Hi @bartversluijs I would be very interested in this PR.
Is there anything that can be done to help getting this through ?

[bartversluijs]

Hi @fabienheureux,
I don't think this PR will be merged, but I can be wrong.
However, you can still use the Helm chart! Take a look here on how to use it.

I'm using it in production for a few years now and it works really well. And I'm not the only one using it!

When I have the time, I'll create a different repo with just the Helm chart and a script that can convert the current config to a Kubernetes Helm values file. This way, it doesn't need to keep up to date with the master branch here and versioning is somewhat simpler.

Hope it helps!

[fabienheureux]

Thanks a lot for your reply.
No worries it does not get merged, I was wondering how stable it was, but if you use it on prod then I will go ahead and start using it 🎉

An external repo would be great, I would be happy to help.

[nargetdev]

@bartversluijs very excited to deploy to my cluster, thanks for spearheading

[ab77]

@bartversluijs you've probably see my comment in your dependency bump PR already, but in any case, thank you again! :)

If you are still interested making this contribution, would you consider refactoring to use https://kompose.io/ to generate Helm (and hopefully also vanilla Kubernetes manifests) programatically from the existing docker-compose.yml composition?

We could add that logic to the existing Flowzone CI workflow, and using "custom actions" workflow (e.g.):

• https://github.com/balena-io/balena-cli/tree/master/.github/actions/publish
• https://github.com/balena-io/etcher/blob/master/.github/actions/publish/action.yml

.. run kompose to generate manifests (programatically edit/modify/cleanup them if required) and add to a GitHub release.

We could eventually even add them to the e2e test framework, by standing up a small kXs cluster programatically and making a test deployment.

[bartversluijs]

@ab77 very interested in doing so, also learning about the CI/CD sides of things to get this automatically tested. Just need to find some time, but I'll definitely look into it!

[ab77]

@ab77 very interested in doing so, also learning about the CI/CD sides of things to get this automatically tested. Just need to find some time, but I'll definitely look into it!

Awesome, and I am more than happy to help as well as answer any questions wrt to our CI, etc.

[flowzone-app]

A repository maintainer needs to approve these workflow run(s).

To approve, maintainers can either:

• Submit an approval review on this pull request, OR

• Submit a review comment starting with /deploy

Then re-run the failed job(s) via the Checks tab above.

Reviews must be on the specific commit SHA of the workflow run to be considered.