Add a Helm chart for deployment

[zanieb]

Summary

Adds a Helm chart to deploy Prefect Server to Kubernetes.

Branches off of #57. Thank you to the community for getting it started, especially @shaunc! This notably differs in the removal of deployment of ingresses which require an ingress controller to work and is not something we intend to provide out of the box right now.

See the rendered README at https://github.com/PrefectHQ/server/blob/pr/57/helm/prefect-server/README.md

Importance

• Improve accessibility to deployment on clusters
• Demonstrate best practices for deployments

Checklist

This PR:

• [ ] adds new tests (if appropriate)
• adds a change file in the changes/ directory (if appropriate)

Future work

• Release to a helm repo with pinned prefectVersionTag
• Improve documentation
• Respond to user feedback
• Add automated testing i.e. calling helm template then checking for expected values

[zanieb]

Example NOTES output:

#1 Run the following command to get the UI URL:

  UI_HOST=$( \
    kubectl get svc \
    --namespace default \
    --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}" \
    my-release-ui \
  ) \
  && echo "UI available at: http://$UI_HOST:8080"

  NOTE: It may take a few minutes for the LoadBalancer IP to be available. 
        You can watch the status of by running: kubectl get --namespace default svc -w my-release-ui

#2 Run the following command to get the Apollo GraphQL API URL:

  API_HOST=$( \
    kubectl get svc \
    --namespace default \
    --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}" \
    my-release-apollo \
  ) \
  && echo "API available at: http://$API_HOST:4200/graphql"

#3 The UI has been configured to point to 'http://localhost:4200/graphql' by default. 
  - The API location you retrieved in #2 should match this url
  - The default can be changed in the helm deployment at 'ui.apolloApiUrl' if it is incorrect
  - The location can also be changed within the UI itself per user
  - The API must be accessible from the the user's machine for the UI to work

#4 You or your admin will likely have to create a tenant before the dashboard in the UI will work. 
   The UI home page should have a 'Create tenant' tab to walk you through this process.

[zanieb]

I could create something like ebec163 for many of the things that need component/global merge. I could also abstract huge chunks of the deployments/services since they're all about the same but not sure how far it's worth going within helm.

[cicdw]

Minor request for changelog update; also noticed helm/prefect-server/charts/postgresql-9.3.2.tgz was included - was that intentional?

I'll give another pass before merging but overall this LGTM

[cicdw]

Awesome - nice work!

[tonycpsu]

@madkinsz : Is there a reason ingress support was removed? Running two application load balancers in cloud environments can be cost-prohibitive for customers with smaller deployments, and creates a potential security issue unless steps are taken to lock down the endpoints. Is the configuration with load balancers for both the UI and Apollo servers the only one supported? If so, I think that will limit adoption from people who are test-driving Prefect as compared to Airflow and other options.

[zanieb]

Hi @tonycpsu, to support ingresses we must make assumptions about the presence of an ingress controller and it seemed out of scope for this chart to manage an nginx subchart. It also significantly complicated the chart since we had to manage ingress hosts. We're not really helm chart experts, so I'm not sure what standard practice here is. If you can point me to a deployment with several components like this that supports ingresses well, I can take a look at the feasibility.

[tonycpsu]

I'm not a Helm chart expert either, but good artists copy, great artists steal, right? Airflow's chart seems to support ingresses.

The thing I ran into when trying to add ingresses on my own (and tried to ask about on the Prefect Slack but did not get a response to) is that the Prefect UI server doesn't seem to like having its URLs rewritten, and rewriting is kind of essential to how ingresses work, since it involves multiple services (in this case, at least Prefect and GraphQL) sharing the same HTTP/HTTPS server using different URL prefixes.

In the mean time, since ingresses aren't supported... Is there a way to run using a NodePort configuration instead of ClusterIP or LoadBalancer, so that we can have internal access to the Prefect UI without having to port forward or make use of expensive AWS load balancers?

[zanieb]

I'm not a Helm chart expert either, but good artists copy, great artists steal, right? Airflow's chart seems to support ingresses.

The thing I ran into when trying to add ingresses on my own (and tried to ask about on the Prefect Slack but did not get a response to) is that the Prefect UI server doesn't seem to like having its URLs rewritten, and rewriting is kind of essential to how ingresses work, since it involves multiple services (in this case, at least Prefect and GraphQL) sharing the same HTTP/HTTPS server using different URL prefixes.

This makes it sound like implementing an ingress is non-trivial and I'm not sure if we have the bandwidth to maintain something like ingresses on a kubernetes deployment of Server which is already a pretty advanced use-case. I'll definitely keep this in mind though, if I have spare time I can look into it further. Note to anyone else, airflow added ingress support in apache/airflow#10064

In the mean time, since ingresses aren't supported... Is there a way to run using a NodePort configuration instead of ClusterIP or LoadBalancer, so that we can have internal access to the Prefect UI without having to port forward or make use of expensive AWS load balancers?

I believe you can switch to a NodePort without much trouble but I'll have to test it out if you want a guide on how to do so. I've opened an issue so I can track this.

[shaunc]

When I originally contributed the PR that started this off, I copied ingress support guided by (a subset) of ingress support options in devspace. It wasn't much work, and worked/works well for me. nginx-ingress, at least, does almost everything with annotations, so the chart itself doesn't need much logic to support.

I'd guess that a reasonable goal wouldn't be so much "supporting ingresses" as "having a hook for an ingress so that a user who has one and is knowledgeable about how it works can configure as required."

[jcrist]

Yeah, I think having an ingress shouldn't be on by default (or required), but supporting an opt-in option which requires some user configuration makes sense to me. This is what JupyterHub does as well, and it seems to work well. https://zero-to-jupyterhub.readthedocs.io/en/latest/administrator/advanced.html#ingress, https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/master/jupyterhub/templates/ingress.yaml.

As noted above, this may require some changes to the UI to support running behind a prefix if that's not already working (not sure, cc @znicholasbrown ).