Helm chart

[viggin543]

Problem

Installing Jitsu on k8s takes some work

Solution

install Jitsu on k8s in a click ( almost ) using a community maintained helm chart

---

I've developed this chart for deploying jitsu on GKE. ( with slight modifications it can be installed on any k8s )

If this has any value to Jitsu project I suggest merging this repo to jitsu org.

The chart includes

• injecting Jitsu configurator/server with configuration files taken from config maps and mapped to a volume
• init containers to fix volume perms and download maxmind db from cloud storage
• integration with external DNS + GKE managed certificates
• Prometheus service monitor support
• terraform file including all needed GCP resources
  • reserved static ip
  • service account
  • workload identity annotations
  • GCS bucket with perms assigned to the service account

more details in chart readme Thanks in advance.

[absorbb]

@viggin543 Great work! Thank you! We plan to allocate more resources on k8s deployment in the near future. Your work will be very helpful

[viggin543]

@absorbb let me know if I can be of assistance.

[betocolon23]

Hi, any updates on k8s deployment? Thanks in advance.

[nandanrao]

Hi - just chiming in to say that a traditional, platform-neutral helm chart would be useful to me as well. Looking at the two helm charts, and having spent very little time investigating Jitsu architecture, I'm left with the following questions / list of things that I would look for in a helm chart. I'm using this note partially as a way to document what I'm finding as I'm looking around, partially as a way to open up for discussion to see if anyone more knowledgeable than me about Jitsu has already thought through these things:

1. @viggin543 - your chart has a Stateful Set and PVCs, the other (plural) does not have any PVCs or Stateful Sets. Digging a bit into the details, it seems like nothing is actually stateful, the configuration is in files that need to be mounted - configmaps mounted to a volume is a reasonable way to handle that, but that can be done with a deployment (it's not actually stateful nor does it need a persistent volume claim). Am I missing something?

2. Jitsu clearly requires redis, which is very easy to include as a (optional) helm dependency and allow for super easy deployment, but no chart seems to do this (the plural chart uses its own dependency process, it would seem).

3. No chart seems to allow secrets to be secrets, everything wants to generate the secret from values files, which combines infrastructure code (values.yaml) with secrets, something I'm not very excited about. Ideally, for example, redis password would be a secret managed separately from the helm chart, same with smtp login information.

4. It seems like with MaxMind, you just need a URL to download the dataset, which Jitsu then downloads and keeps in sync. This seems like it can be done locally by each pod. I guess that's what the Plural chart does automatically, not sure why a bucket is needed, @viggin543 maybe you can enlighten me on this. Or maybe there's no public URLs already available? I didn't look into it deeper.

5. The plural helm chart "ingress" in the values.yaml seems to be the boilerplate helm ingress, but it seems that the actual template expects a different, more custom format, as created in the values.yaml.tpl, and which explicitly sets up two hosts, one for an api one for something else. Ideally, the values.yaml in a helm chart would reflect that actual values format expected by the templates.

[viggin543]

1 - if you don't use a SS, and k8s evicts a Jitsu pod. data will be lost. 2 - I do not include redis on purpose, you want to manage your redis in a separate chart ( or using some cloud provider ) 2.5 - suggest using bitnami redis chart. https://github.com/bitnami/charts/tree/master/bitnami/redis 3 - use https://github.com/bitnami-labs/sealed-secrets 4 - if you're going to use the free MaxMind DB you have to download it from MaxMind manually and upload it to some cloud storage, If you have a MaxMind account and subscription then you get the URL 5-

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: {{ $.Release.Name }}
  annotations:
    kubernetes.io/ingress.global-static-ip-name: {{ .Values.ingress.reserevedIp }}
    networking.gke.io/managed-certificates: {{ .Values.ingress.certificateName }}
    kubernetes.io/ingress.class: "gce"
    kubernetes.io/ingress.allow-http: "{{ .Values.ingress.allowHttp }}"
spec:
  defaultBackend:
    service:
      name: {{ $.Release.Name }}
      port:
        number: 80

@nandanrao

all this ingress does is forward all traffic to a default backend on port 80

All the "GKE stuff" in this repo are those annotations, they automatically assign this ingress to a backend ( some GKE term) and a managed certificate, and the terraform code that creates a managed certificate and load balancer in google. The Help part is pretty generic

This chart is not Plug and Play, It can be though. Will appreciate contributions.

[Alessar]

Just FYI: One of helm charts can be found on the plural.sh artifacts

[vklimontovich]

To be continued at #880, closing this one