Deployment Paths#

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#

Important

We recommend working with your infrastructure team to set up the cloud service requirements below.

Relational Database#

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.

Note

We recommend the following services, depending on your cloud platform of choice:

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.

Note

We recommend swapping this out for a production-grade object store, depending on your cloud platform of choice:

Cluster Configuration#

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.

Note

For more information, see flytectl.

Flyte Deployment Paths#

There are three different paths for deploying a Flyte cluster:

Deployment Path

Description

Production-grade?

Sandbox

This uses portable replacements for the relational database and blob store. It’s good for testing out and experimenting with Flyte.

❌

Single Cluster

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.

✅

Multiple Clusters

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.

✅

Important

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.

Helm#

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.

Note

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.
charts/flyte-binary/Chart.yaml#
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.
charts/flyte-core/Chart.yaml#
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.
charts/flyte-deps/Chart.yaml#
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.
charts/flyte/Chart.yaml#
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.