kubectl edit: Usage, Options & Common CI Errors
Edit a live resource in your editor - great locally, wrong in CI.
kubectl edit fetches an object, opens it in your $EDITOR, and applies whatever you save. It is excellent for ad-hoc debugging but is interactive by design, so CI should use apply, patch, or set instead.
What it does
kubectl edit RESOURCE NAME writes the live object to a temp file, launches the editor named by KUBE_EDITOR or EDITOR, and on save computes a patch and applies it. If you save no changes it is a no-op; if your edit is invalid it reopens the file with the error appended so you can fix it.
Common usage
kubectl edit deploy/web
KUBE_EDITOR="nano" kubectl edit configmap/app-cfg
kubectl edit svc/web -o json # edit as JSON instead of YAMLCommon errors in CI
In CI the failure mode is mechanical: with no TTY and no editor set, kubectl edit either hangs waiting for input or errors. Never script edit - use kubectl patch or set for targeted changes and apply for declarative ones. When you do edit interactively, "field is immutable" rejects changes to immutable fields (a Job's selector, a PVC's storage size on some classes, a Service's clusterIP); those require deleting and recreating the object, not editing it.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes