Bring your towel and join one of the fastest growing data communities. Welcome to our second-generation open source orchestration platform, a completely rethought approach to dataflow automation.

Prefect Community

I'm trying to configure the final bits of my install on Kubernetes. I'm looking at <https://docs.prefect.io/api/latest/cli/agent.html#kubernetes-install> — vs the `start` command that also takes `--job-template &lt;path&gt;` — how do I configure my own job template when using `prefect agent kubernetes install`?

Also the docs say that `prefect agent kubernetes install` creates a supervisord.conf file, which is wrong.

I was just doing this the other day and couldn’t find an option for a `job-template` but the thing I was trying to replace (image pull policy) had its own command line flag.

~The agent runs as a kubernetes deployment, so you do not need a job template.~ The github issue below has your answer.

If you'd like to configure a custom job template for your flows, you can use `KubernetesRun` like this. I have code that looks something like this:
```KubernetesRun(
        env={"SOME_KEY": "SOME_VALUE"},
        image="some_image_name",
        service_account_name="name_of_a_service_account,
        job_template="your_yaml_template",
    )```

I asked a similar question earlier this year: <https://github.com/PrefectHQ/prefect/issues/4022>

<@U01CFMJ6LGK> I don't see how this is the solution — if I want to keep the flow agnostic to the runner?

Surely this shold be configured in the agent/deployment?

Also, when using prefect cloud, it would seem I'm using CloudTaskRunner

This solution works for me, but I don't work for or speak for prefect. :shrug:

I like attaching the job template to the `KubernetesRun` object because the template is configurable at the flow level, and the agent doesn't have to know about it at all. I think this is a good design and appropriate separation, however if you'd like to provide a custom template attached to your agent as a default for all flows, that is possible too. It's very flexible.

Also - it seems very likely to me that there is perhaps a language or cultural barrier, but your questions are coming across as somewhat aggressive. I think you might get a better response if you take some more time to be a little bit more specific and polite in your requests.

image.png

I see, my use case is an infrastructural concern — the job is intercepted by Istio, so I need to change it to be like this when starting, but am having trouble making it stick

I ended up shoe-horning this in; but it doesn't accept modifications to neither `command` nor `args` despite also overwriting the `job-spec` file, so I had to deploy it outside of Istio.

This is still an open and troublesome issue.