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:

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.

Regardless of using single or multiple Kubernetes clusters for Flyte, note that FlytePropeller -the main data plane component- can be scaled out as well by using sharding if scale demands require it. See Automatic scale-out to learn more about the sharding mechanism.

Helm

Flyte uses Helm as the K8s release packaging solution. 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://kubeflow.github.io/spark-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://kubeflow.github.io/spark-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 Ingress controllers, auth providers, and versions of different dependent libraries that may interact with other parts of your stack.

Considering the above, we recommend checking out the “Flyte The Hard Way” set of community-maintained tutorials that can guide you through the process of preparing the infrastructure and deploying Flyte.

In addition to searching and posting on the #flyte-deployment Slack channel, 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.