I’m having an issue with

syncresources

and

flyte-pod-webhook

deployments from the

flyte-core

helm chart (Flyte v1.X - OSS) I’m hoping you can help me validate if there are options available for dealing with this issue, and understand the consequences of disabling these deployments. The issue I’m having is that these deployments don’t support user specified

tolerations

. This makes it difficult for my team to manage these deployments on the cluster nodes that we reserve for “always up” deployments. Short of PR’ing an update to

flyte-core

, I see my only options to be.. 1. Break and/or redesign the containment strategy for “always up deployments” (ex remove taint, or schedule these deployments on different nodes) 2. Disable these deployments I’d like to explore the impact of option 2. From what I understand, turning off

syncresources

adds some operational responsibilities for the team, especially when things like new projects get added. That seems acceptable. Turning off

flyte-pod-webhook

however seems to be more impactful. If we turn this off, I believe this means that secret injection via

@task(secret_requests=[fl.Secret(…)])

will no longer function. Is that correct? Thank you in advance for the help

Yes, your understanding is correct: disabling the

flyte-pod-webhook

deployment will break Flyte's ability to inject secrets into task pods using the

@task(secret_requests=[Secret(...)])

pattern. The webhook is responsible for mutating pods to inject secrets from Kubernetes or other secret managers, and without it, Flytekit tasks will not be able to access requested secrets at runtime. Disabling

syncresources

is less critical but will require you to manually manage project/domain resources (like namespaces and quotas) when new projects are added or updated, as the automation provided by the cluster resource syncer will be lost. There is currently no documented support for user-specified

tolerations

for these deployments in the official Helm chart, so your options are as you described: either redesign your node containment strategy or contribute a PR to add this configurability. Would you like more detail on the technical consequences or possible workarounds for tolerations in these deployments? Sources: - Flyte secret management and webhook mechanism 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

Thanks for the confirmation. I’ll look into setting overriding the webhook deployment behavior for my team, and then try to loop back to adding toleration support to the OSS project when I have time