<@U06RKAMK0UC> what is the reason for the ephemera...
# ask-ai
n
@ancient-wolf-19325 what is the reason for the ephemeral storage in a flyte task? Can’t I eliminate it completely ? My flyte tasks are filling up my node storage and creating diskpressure issues
a
It could be possible that ephemeral storage in a Flyte task is used for temporary files, intermediate outputs, and local scratch space during task execution, mirroring Kubernetes' native ephemeral storage for containers. This storage is not persistent and is deleted when the pod terminates, but tasks that write large files or have high I/O can fill up node storage, leading to disk pressure issues. According to the documentation, you can set both requests and limits for ephemeral storage in your Flyte task resource configuration, and if you set both to zero, it might prevent allocation, but this could cause tasks that need any local disk to fail or be unschedulable. There is no explicit mention in the data sources that ephemeral storage can be eliminated entirely for all tasks, especially if your code or dependencies write to disk at runtime. Though I'm not entirely certain, it might be that to avoid disk pressure, you should minimize ephemeral storage requests/limits and ensure your tasks write outputs directly to object storage (like S3 or GCS) instead of local disk. You can also adjust the default platform or namespace-level quotas to restrict ephemeral storage usage cluster-wide. For more details, see the guidance on customizing task resources and Kubernetes resource management in Flyte tasks at Customizing task resources. Would you like a step-by-step breakdown of how to set these resource limits or strategies to refactor your tasks to avoid local disk usage? Sources: - Customizing task resources 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.
n
what does flyte usage in ephemeral storage ? how should I configure the request limit values @ancient-wolf-19325?
a
Flyte uses ephemeral storage for temporary files, intermediate data, and local scratch space needed during task execution—this is mapped directly to Kubernetes ephemeral storage for containers. If your task or its dependencies write to disk (e.g., for temp files, unpacking, or caching), this storage is consumed and released when the pod ends; it is not persistent across runs or pods. You should configure ephemeral storage requests and limits in your Flyte task's resource specification to match the expected disk usage of your code. Set
requests
to the minimum needed for scheduling and
limits
to the maximum your task should use; exceeding the limit will cause the pod to be killed. For example, use
disk="10Gi"
in Flyte 2 or
ephemeral_storage="10Gi"
in Flyte 1. For details and examples, see Customizing task resources. Would you like a code example or more detailed guidance on estimating these values? Sources: - Customizing task resources 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.