The articles in this section will guide a new Flyte administrator through deploying Flyte.
The most complex parts of a Flyte deployment are authentication, ingress, DNS, and SSL support. Due to the complexity introduced by these components, we recommend deploying Flyte without these at first and relying on K8s port forwarding to test your Flyte cluster. After the base deployment is tested, these additional features can be turned on more seamlessly.
Components of a Flyte Deployment#
We recommend working with your infrastructure team to set up the cloud service requirements below.
Two of Flyte’s components, FlyteAdmin and DataCatalog, rely on PostgreSQL to store persistent records. In the sandbox deployment, a containerized version of Postgres is included but for a proper Flyte installation, we recommend one of the cloud provided databases.
Production Grade Object Store#
Core Flyte components such as FlyteAdmin, FlytePropeller, DataCatalog, and user runtime containers rely on an object store to hold files. The sandbox deployment comes with a containerized Minio, which offers AWS S3 compatibility.
Flyte configures K8s clusters to work with it. For example, as your Flyte userbase evolves, adding new projects is as simple as registering them through the command line:
flytectl create project \ --id my-flyte-project \ --name "My Flyte Project" \ --description "My first project onboarding onto Flyte"
Once you invoke this command, this project should immediately show up in the Flyte console after refreshing.
Flyte runs at a configurable cadence that ensures that all Kubernetes resources necessary for the new project are created and new workflows can successfully be registered and executed within it.
For more information, see flytectl.
Flyte Deployment Paths#
There are three different paths for deploying a Flyte cluster:
This uses portable replacements for the relational database and blob store. It’s good for testing out and experimenting with Flyte.
This bundles Flyte as one executable. It runs on a single K8s cluster and supports all of Flyte’s extensions and plugins. Once the simple deployment is established, you can follow steps to productionize it.
For large-scale deployments that require multiple K8s clusters. Flyte’s control plane (FlyteAdmin, FlyteConsole, and DataCatalog) is separated from Flyte’s execution engine, FlytePropeller, which runs typically once per compute cluster.
We recommend the Single Cluster option for a capable though not massively scalable cluster.
This option is appropriate if all your compute can fit on one EKS cluster . As of this writing, a single Flyte cluster can handle more than 13,000 nodes.
Whatever path you choose, note that
FlytePropeller itself can be sharded as well, though typically it’s not required.
Flyte uses Helm as the K8s release packaging solution, though you may still see some old Kustomize artifacts in the flyte repo. The core Flyte team maintains Helm charts that correspond with the latter two deployment paths.
Technically there is a Helm chart for the sandbox environment as well, but it’s been tested only with the Dockerized K3s bundled container.
flyte-binary: chart for the Single Cluster option.
apiVersion: v2 name: flyte-binary description: Chart for basic single Flyte executable deployment type: application # This is the chart version. This version number should be incremented each time you make changes # to the chart and its templates, including the app version. # Versions are expected to follow Semantic Versioning (https://semver.org/) version: v0.1.10 # VERSION # This is the version number of the application being deployed. This version number should be # incremented each time you make changes to the application. Versions are not expected to # follow Semantic Versioning. They should reflect the version the application is using. # It is recommended to use it with quotes. appVersion: "1.16.0" dependencies: - name: flyteagent condition: flyteagent.enabled alias: flyteagent version: v0.1.10 # VERSION repository: file://../flyteagent # REPOSITORY
flyte-core: chart for the Multiple Cluster option.
apiVersion: v2 name: flyte-core description: A Helm chart for Flyte core type: application version: v0.1.10 # VERSION dependencies: - name: flyteagent condition: flyteagent.enabled alias: flyteagent version: v0.1.10 # VERSION repository: file://../flyteagent # REPOSITORY
flyte-deps: chart that installs additional useful dependencies alongside Flyte.
apiVersion: v2 name: flyte-deps description: A Helm chart for Flyte dependency type: application version: v0.1.10 # VERSION dependencies: - name: contour version: 7.10.1 repository: https://charts.bitnami.com/bitnami condition: contour.enabled - name: spark-operator alias: sparkoperator version: 1.1.15 repository: https://googlecloudplatform.github.io/spark-on-k8s-operator condition: sparkoperator.enabled - name: dask-kubernetes-operator alias: daskoperator version: 2022.12.0 repository: https://helm.dask.org condition: daskoperator.enabled - name: kubernetes-dashboard version: 4.0.2 repository: https://kubernetes.github.io/dashboard/ condition: kubernetes-dashboard.enabled
flyte: chart that depends on
flyte-core, installing additional dependencies to Flyte deployment.
apiVersion: v2 name: flyte description: A Helm chart for Flyte Sandbox type: application version: v0.1.10 # VERSION dependencies: - name: flyte-core alias: flyte version: v0.1.10 # VERSION repository: file://../flyte-core # REPOSITORY - name: contour version: 7.10.1 repository: https://charts.bitnami.com/bitnami condition: contour.enabled - name: spark-operator alias: sparkoperator version: 1.1.15 repository: https://googlecloudplatform.github.io/spark-on-k8s-operator condition: sparkoperator.enabled - name: dask-kubernetes-operator alias: daskoperator version: 2022.12.0 repository: https://helm.dask.org condition: daskoperator.enabled - name: kubernetes-dashboard version: 4.0.2 repository: https://kubernetes.github.io/dashboard/ condition: kubernetes-dashboard.enabled
Deployment Tips and Tricks#
Due to the many choices and constraints that you may face in your organization, the specific steps for deploying Flyte can vary significantly. For example, which cloud platform to use is typically a big fork in the road for many, and there are many choices to make in terms of ingresses, auth providers, and versions of different dependent libraries that may interact with other parts of your stack.
In addition to searching and posting on the Flyte Slack community, we have a Github Discussion section dedicated to deploying Flyte. Feel free to submit any hints you’ve found helpful as a discussion, ask questions, or simply document what worked or what didn’t work for you.