Skip to main content

Flyte SDK Deployment and Runtime Architecture

The deployment architecture of the Flyte SDK illustrates a multi-environment setup involving local development, CI/CD pipelines, and a containerized runtime on Kubernetes.

Key Components:​

  • Local Developer Machine: Developers use the Flyte CLI to author, test, and deploy workflows. Local execution runs tasks directly on the machine, while remote execution submits them to the Remote Orchestration & Management.
  • CI/CD Runner: Automated pipelines (GitHub Actions) handle the building and publishing of the SDK to PyPI and base Docker images to the Container Image Lifecycle.
  • Flyte Control Plane: Consists of Flyte Admin, which provides the API for registration and execution management, and Flyte Propeller, the core orchestration engine that manages workflow state and schedules tasks.
  • Kubernetes Cluster: The data plane where Flyte Worker Pods execute user code. It also hosts Image Builder Pods for remote image construction when local Docker is not used.
  • External Infrastructure: Includes Object Storage (S3/GCS) for persisting task inputs, outputs, and code bundles, and Docker Registries for managing container images.

Data Flow:​

  1. Developers register workflows via the CLI to Flyte Admin.
  2. Flyte Propeller receives execution requests and creates Kubernetes Pods.
  3. Pods pull required images from the Docker Registry and download code bundles/data from Object Storage.
  4. Task results are written back to Object Storage and tracked by the control plane.

Key Architectural Findings:

  • The SDK supports both local and remote image builders, utilizing Docker Buildx locally or a specialized Flyte task for remote builds.
  • Flyte Propeller acts as the primary orchestrator within the Kubernetes cluster, managing the lifecycle of worker pods.
  • The 'a0' entrypoint in the SDK is the primary runtime wrapper used inside containerized tasks to load and execute user code.
  • CI/CD pipelines are responsible for multi-platform image builds (Python 3.10-3.14) and publishing to PyPI.
  • Object storage (S3/GCS) is used as the source of truth for task data and serialized code bundles (TGZ/PKL).
Loading diagram...