Session cluster creation fails: admission policy blocks custom resources
Kyverno or another admission controller can block the Kubernetes custom resources the Ververica agent needs, causing BYOC session cluster or deployment creation to hang.
Symptom
A session cluster, or another deployment, never finishes starting in a BYOC workspace. Ververica Platform logs show that a required Kubernetes resource, such as the JobManager deployment, was never created, for example:
1Failed: get [DEPLOYMENT] name [sessioncluster-...-jobmanager] in namespace [...] because it does not exist.Custom resources that the Ververica agent depends on are missing or unhealthy. ControlPlane resources have no status field, so the only failure mode for them is missing entirely. RAMSecurityToken does report status, and can be missing or stuck in a NotReady state.
A RAMSecurityToken stuck in NotReady can also be caused by an unrelated IAM misconfiguration. Rule out admission control first with the steps below before you start debugging cloud credentials.
Cause
BYOC runs the data plane in your own Kubernetes cluster, so any admission controller you enforce there, such as Kyverno or OPA/Gatekeeper, also applies to the resources the Ververica agent creates on your behalf. A policy written for your own workloads can unintentionally reject ControlPlane, RAMSecurityToken, or other Ververica custom resources, even when the rest of the cluster is healthy and the agent itself is running correctly.
Resolution
- Check whether the custom resources the agent needs actually exist and, where applicable, are ready:
1kubectl get controlplane,ramsecuritytoken -n <workspace-namespace>Verify: ControlPlane has no status field, so only check that it exists: you should see some default ControlPlane resources plus one specific to the affected workspace, identified by the workspace's ID. RAMSecurityToken does report status, so check that it shows Ready. A ControlPlane that's missing entirely, or a RAMSecurityToken that's missing or not Ready, points to admission control rather than a runtime error inside the agent.
- List the admission policies active in the namespace and check for denials:
1kubectl get clusterpolicy,policy -A
2kubectl get events -n <workspace-namespace> --field-selector reason=PolicyViolationVerify: an event or policy report references the missing custom resource kind, for example a group or kind matching controlplanes or ramsecuritytokens.
- Update the policy to exempt Ververica-managed custom resources. Exclude the namespace the platform uses, or add an exception for the affected CRD group and kind, then reapply the policy.
Verify: re-run the resource check from step 1. The missing ControlPlane resources now exist, RAMSecurityToken moves to Ready, and the deployment or session cluster finishes creating.
If that didn't resolve it
If the custom resources already exist, and RAMSecurityToken shows Ready, but creation still fails, the cause isn't admission control. Collect the Ververica agent logs together with kubectl describe output for the failing resource, and contact Ververica Support.
Prevent it
Before you enable Kyverno, OPA/Gatekeeper, or any other admission controller on a cluster that hosts a BYOC workspace, exempt the namespaces and custom resource kinds the Ververica agent manages. Review new or updated policies against the platform's required custom resources before rolling them out to that cluster.