Helm chart for Kubernetes

[shairozan]

Summary

The manifests were a good starting point, but there's a lot of variances that need to be accommodated for:

• NGINX as an ingress controller won't be everyone's preferred. Most people default to the K8s native ingress controller
  • This is because most cloud integrations (ACM Certificates in AWS, DNS Integration) etc work via annotations on the controller
• Users should have the option to either run the DB in K8s or just provide a connection string
• Users should have the option to either run redis in K8s or just provide a connection
• Scaling a resiliency should be an option
• I still need to verify if the requests / limits are appropriate to avoid memory pressure termination of the services
• The option of using NFS file systems for the docker-data and the server-data volumes should be an option
  • If that's not used, and a volume from a PVC is used, an init container should be added to the server to chown the volumes recursively

Raw manifests are opinionated, but helm lets a user provide some answers to questions in the values.yml file that conditionally applies manifests based on that input. the only better option would be building an operator (since it controls upgrades as well) but that's a tremendous undertaking. Makes more sense to start with helm and move that way.

Questions for the Community

1. What cloud providers are you using (since this will drive how many api specs need to support custom annotations in helm)
2. What ingress controller are you using
3. Can you list any cloud integrations you have such as:
   4. Load balancer integration
   5. DNS integration
   6. Volume / NFS integration