Flyte is designed to be highly extensible and can be customized in multiple ways.
Flytekit plugins are simple plugins that can be implemented purely in python, unit tested locally and allow extending Flytekit functionality. These plugins can be anything and for comparison can be thought of like Airflow Operators.
Using flytekit plugins
Data is automatically marshalled and unmarshalled in and out of the plugin. Users should mostly implement the
PythonTask API defined in Flytekit.
Flytekit Plugins are lazily loaded and can be released independently like libraries. We follow a convention to name the
flytekitplugins-*, where * indicates the package to be integrated into Flytekit. For example
flytekitplugins-papermill enables users to author Flytekit tasks using Papermill.
You can find the plugins maintained by the core Flyte team here.
Native Backend Plugins¶
Native Backend Plugins are the plugins that can be executed without any external service dependencies because the compute is orchestrated by Flyte itself, within its provisioned Kubernetes clusters.
Execute K8s pods for arbitrary workloads.
Run Spark jobs on a K8s Cluster.
Run distributed PyTorch training jobs using
Run distributed TensorFlow training jobs using
Run distributed deep learning training jobs using Horovod and MPI.
External Service Backend Plugins¶
As the term suggests, external service backend plugins relies on external services like AWS Sagemaker, Hive or Snowflake for handling the workload defined in the Flyte task that use the respective plugin.
Train models with built-in or define your own custom algorithms.
Train Pytorch models using Sagemaker, with support for distributed training.
Execute queries using AWS Athena
Running tasks and workflows on AWS batch service
Run Hive jobs in your workflows.
Run Snowflake jobs in your workflows.
Run BigQuery jobs in your workflows.
Enabling Backend Plugins
To enable a backend plugin you have to add the
ID of the plugin to the enabled plugins list. The
enabled-plugins is available under the
tasks > task-plugins section of FlytePropeller’s configuration.
The plugin configuration structure is defined here. An example of the config follows,
tasks: task-plugins: enabled-plugins: - container - sidecar - k8s-array default-for-task-types: container: container sidecar: sidecar container_array: k8s-array
Flyte uses Kustomize to generate the the deployment configuration which can be leveraged to kustomize your own deployment.
Custom Container Tasks¶
SDKs for Writing Tasks and Workflows¶
The community would love to help you with your own ideas of building a new SDK. Currently the available SDKs are: