Skip to main content

Kubectl job reference

Field reference for Add a Kubectl job.

Kubectl job fields

FieldMeaning
Job nameName of the Job.
OperationThe kubectl operation to run. See Operations below.
EnvironmentTarget Kubernetes cluster, from Manage environments.
NamespaceRead-only. Filled in automatically from the selected Environment.
Kubectl VersionRead-only. The kubectl client version used to execute the Job.
Manifest SourceApply only. Git repository or Inline YAML.
Git account connectionsApply with Git repository only, from Manage credentials.
Repository URL / BranchApply with Git repository only. Branch defaults to main.
Manifest file or directoryApply with Git repository only. A single YAML file, or a directory applied recursively.
YAML ManifestApply with Inline YAML only.
ArgumentsRequired for every operation except Apply, where it's optional (extra apply flags). Namespace always comes from the Environment field — don't repeat -n/--namespace here.

Operations

Each Operation maps to the matching kubectl subcommand. For Apply, the Arguments field holds only optional extra flags — the manifest itself comes from Manifest Source. For every other Operation, Arguments holds everything that follows the subcommand name, exactly as you'd type it on the kubectl command line — except Namespace, which always comes from the Environment field and should not be repeated with -n/--namespace.

OperationPurposeSyntax (Arguments field)Example
ApplyApply Kubernetes manifests from Git or inline YAML, with an automatic server-side dry-run first.[extra flags] (optional; manifest comes from Manifest Source)--prune -l app=my-service
CreateCreate a resource from the given Arguments.<resource-type> <name> [flags]configmap app-config --from-literal=ENV=production
DeleteDelete a resource.<resource-type> <name> or <resource-type> -l <label-selector>pod -l app=my-service,version=v1
ExposeExpose a resource as a new Service.<resource-type>/<name> --port=<port> --target-port=<port> --type=<type>deployment/my-service --port=80 --target-port=8080 --type=ClusterIP
GetList resources and capture the output in the run log.<resource-type> [name] [-o <format>]pods -l app=my-service -o wide
LogsPrint container logs.<pod-or-resource> [-c <container>] [--tail=<n>]deployment/my-service --tail=100
RolloutManage the rollout of a resource — check status, restart, or undo.<subcommand> <resource-type>/<name>restart deployment/my-service
RunRun a container image as a Pod.<pod-name> --image=<image> [flags]debug-shell --image=busybox --rm -it --restart=Never -- sh
SetUpdate a field of an existing resource.<field> <resource-type>/<name> <value>image deployment/my-service my-service={{BUILD_REPOSITORY}}:{{BUILD_TAG}}
TopShow resource (CPU/Memory) usage.<resource-type> [name]pods -l app=my-service
ExecExecute a command inside a container.<pod-name> [-c <container>] -- <command>my-service-7f8b9c-abcd -- printenv
tip

The Set example reuses the {{BUILD_REPOSITORY}} and {{BUILD_TAG}} template variables confirmed on the Apply operation — use them to point at the image a preceding Build and push Job just pushed, without hardcoding a tag.

tip

Pair Delete or Exec with an Approval Job placed immediately before the Kubectl Job — these are the two highest-risk operations.

note

Only Apply and Get were confirmed against the live config panel this session. The syntax above for the other operations follows standard kubectl command syntax — verify against your cluster's kubectl version if a flag behaves unexpectedly.

See also