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.

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.