Flyte Production Deployment Architecture
The deployment architecture of Flyte is centered around a unified backend service and a web console, both typically deployed on a Kubernetes Resource Plugins cluster.
The Flyte Binary is a single container that consolidates multiple microservices, including the Workflow & Run Management, Execution Engine, and Data Proxy and Translation Services. It acts as a Kubernetes controller, interacting with the K8s Control Plane to orchestrate Task Pods.
For data persistence, Flyte relies on an external PostgreSQL instance for metadata and Object Storage (such as AWS S3 or Google Cloud Storage) for large data artifacts.
The Flyte Console provides a web-based interface for users, communicating with the Flyte Binary via an Ingress layer that handles both HTTP and gRPC traffic.
Within the execution environment, Flyte Copilot is injected into user-defined Task Pods as both an init container (for downloading inputs) and a sidecar (for uploading outputs), ensuring seamless data movement between the task's local environment and the central object store.
Key Architectural Findings:
- Flyte is primarily deployed as a unified binary (flyte-binary) that bundles multiple services like manager, runs, and executor into a single container.
- The system uses a sidecar pattern called Flyte Copilot, which is injected into user task pods to handle data ingress and egress.
- Metadata is stored in a PostgreSQL database, while workflow artifacts and user data are stored in cloud-native Object Storage (S3/GCS/Azure).
- The Flyte Binary acts as a Kubernetes operator, managing the lifecycle of Task Pods and Custom Resource Definitions (CRDs) like TaskActions.
- Traffic is routed through a Kubernetes Ingress, supporting both REST/HTTP and gRPC protocols for the console and CLI tools.