kubectl-edit

Edit a pod in the default namespace

$ kubectl edit [[po|pod]]/[pod_name]

$ kubectl edit [[deploy|deployment]]/[deployment_name]

$ kubectl edit [[svc|service]]/[service_name]

$ kubectl edit [resource] [[-n|--namespace]] [namespace]

$ KUBE_EDITOR=[nano] kubectl edit [resource]/[resource_name]

$ kubectl edit [resource]/[resource_name] [[-o|--output]] json

kubectl edit (TYPE NAME | TYPE/NAME | -f FILENAME) [options]

TYPE NAME | TYPE/NAME
    The specific Kubernetes resource to edit. TYPE refers to the resource kind (e.g., pod, deployment, service), and NAME is its unique identifier.

-f, --filename FILENAME
    Specifies a file, directory, or URL containing the resource definition to be edited. Useful for editing resources that are not yet created or for applying changes from a local file.

-o, --output FORMAT
    Sets the format in which the resource will be presented to the editor. Valid options are yaml (default) or json.

--save-config
    If set to true, the object's configuration will be saved in a kubectl.kubernetes.io/last-applied-configuration annotation on the object itself. This is used by kubectl apply for future updates.

--output-patch
    If set to true, instead of applying the changes to the API server, the generated patch will be printed to standard output. This is useful for debugging or integrating with other tools.

-k, --kustomize PATH
    Processes a Kustomization directory, allowing editing of resources defined within a Kustomization project.

--field-manager MANAGER_NAME
    Specifies the field manager for the client-side apply request. Defaults to kubectl-edit.

kubectl edit provides an interactive way to modify any live Kubernetes API resource directly from your terminal. It retrieves the current configuration of a specified resource (e.g., a Deployment, Service, or ConfigMap), opens it in your default text editor (or one defined by KUBE_EDITOR or EDITOR environment variables), and upon saving and exiting the editor, attempts to apply the changes back to the Kubernetes API server.

This command is invaluable for making quick, on-the-fly adjustments, debugging misconfigurations, or experimenting with resource definitions without the need for manual YAML file manipulation and kubectl apply commands. It streamlines the workflow by handling the fetch-edit-update cycle, ensuring atomicity and providing immediate feedback on validation errors.

Validation Errors: Changes made in the editor are subject to Kubernetes API validation. Invalid YAML/JSON or schema errors will prevent the update, often giving you options to re-edit or discard.

Concurrency: If another process modifies the resource concurrently, a conflict might occur, potentially requiring you to re-edit based on the updated object.

Immutable Fields: Be aware that some fields are immutable after resource creation (e.g., metadata.name or spec.clusterIP for certain services). Attempting to change these will result in an error.

RBAC Permissions: You must have sufficient Role-Based Access Control (RBAC) permissions to get, update, and potentially patch the specified resource.

The kubectl edit command determines the text editor to use based on a specific precedence:
1. The KUBE_EDITOR environment variable.
2. The EDITOR environment variable.
3. A system-dependent default editor (commonly vi or nano).
Users can set these variables (e.g., export KUBE_EDITOR="code --wait") to integrate with their preferred code editor.

The command operates by first fetching the specified resource's definition and saving it to a temporary file. This file is then opened in your chosen editor. After you make changes, save the file, and exit the editor, kubectl edit reads the modified content and attempts to apply these changes to the Kubernetes API server. If successful, the temporary file is deleted. In case of validation errors, kubectl usually prompts you to re-edit or discard the changes, ensuring a robust interactive experience.

kubectl edit is a fundamental command within the kubectl command-line interface, which has been a core component of Kubernetes since its inception by Google and subsequent adoption by the Cloud Native Computing Foundation (CNCF). Introduced to provide an interactive and immediate way to manage live cluster resources, it complements the more declarative kubectl apply -f workflow. Its design facilitates rapid iteration, debugging, and administrative tasks, embodying Kubernetes' dual philosophy of offering both powerful declarative APIs and convenient imperative tools.

kubectl apply(1), kubectl get(1), kubectl describe(1), vi(1), nano(1)