A Jumpstart for Flyte Deployment, Inspired by the Community

Flyte, the open-source orchestrator for ML and data workloads, aims to facilitate building and running workflows on top of Kubernetes in a way that doesn’t require you to be a Kubernetes expert (if Kubernetes experts exist at all).

Helm is a package manager for Kubernetes. Like package managers for operating systems (such as apt for Ubuntu), Helm helps you manage applications in a way that can be ported, customized and repeated. Helm’s main construct is the Chart, a mechanism not only to package an application but also to define how to install it.

Some time ago, Flyte maintainers developed and open-sourced a set of Helm charts designed to fit the most common types of deployments for AWS. (Deployments for other platforms will be available in the future.)

You can find them under the /charts folder. They include some of the deployment models for Flyte: single-binary, core and sandbox. 

Flyte’s documentation assumes a set of prerequisites already in place before using the Helm charts but doesn’t provide guidance on how to prepare those requirements, especially because of the wide spectrum of options and policies an organization may have to prepare infrastructure pieces, such as a database.

In response to community feedback, we have developed a new set of guides and tested them with members of the Flyte community. Our goal: to provide individuals evaluating Flyte with a “golden path” for a deployment that becomes more robust at each step. We’ve called it “Flyte the Hard Way” (FTHW) inspired by “Kubernetes The Hard Way” created by Kelsey Hightower several years ago. While steps in FTHW are not as manual as in the Kubernetes guide, it should give readers a better understanding of the infrastructure touchpoints of Flyte and enable higher autonomy for individuals without access to an infrastructure/platform team.

Part I: Simple deployment from scratch

The steps in this section will guide you to deploy Flyte on EKS, going through the configuration of each resource for a successful deployment. It doesn’t include secure communication from the client to the cluster (SSL) nor Kubernetes Ingress, so for connecting to Flyte you’ll have to use port-forwarding (a one-liner also covered in the guide).

Part II: Adding scalable networking

Even if you’re not familiar with the Kubernetes Ingress concepts, this section aims to provide an overview and walk you through the minimal set of steps for a deployment that’s more robust and better prepared to handle production workloads.

Future work

Adding instructions to set up authentication and authorization will be the next section in the guide, as this is a common requirement for production-grade infrastructure.

In the longer term, the plan is to expand the guides to cover other environments like GCP and local Kubernetes clusters. 

Feel free to explore the repo, file issues if you find better ways to do things, and fork/push if you want to extend the guides. Your contributions are welcome!