chara
11/02/2023, 1:04 PMKevin Grismore
11/02/2023, 8:28 PMjob_variable
override in your deployment), the worker will get a 403 and fail to start the job.
My worker is in the prefect
namespace so I made a namespace called prefect2
and edited my work pool to start jobs there to demonstrate:
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {},
"status": "Failure",
"message": "jobs.batch is forbidden: User \"system:serviceaccount:prefect:prefect-worker\" cannot create resource \"jobs\" in API group \"batch\" in the namespace \"prefect2\"",
"reason": "Forbidden",
"details": {
"group": "batch",
"kind": "jobs"
},
"code": 403
}
The easiest way around this would probably be to create a ClusterRole with the same rules as the existing Role, with the addition of the events
resource in the first rule:
rules:
- apiGroups: [""]
resources: ["pods", "pods/log", "pods/status", "events"]
verbs: ["get", "watch", "list"]
- apiGroups: ["batch"]
resources: ["jobs"]
verbs: [ "get", "list", "watch", "create", "update", "patch", "delete" ]
and then a ClusterRoleBinding that references this ClusterRole and targets the prefect-worker
ServiceAccount that already exists.
Then your worker can create and monitor jobs in any namespace in the cluster.Kevin Grismore
11/02/2023, 8:32 PMchara
11/03/2023, 7:00 AM