Kubernetes provides a command line tool for communicating with a Kubernetes cluster's control plane , using the Kubernetes API. This tool is named kubectl . For configuration, kubectl looks for a file named config in the $HOME/.kube directory. You can specify other kubeconfig files by setting the KUBECONFIG environment variable or by setting the --kubeconfig flag. This overview covers kubectl syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the kubectl reference documentation. For an overview, see The kubectl command-line tool . For installation instructions, see Installing kubectl ; for a quick guide, see the cheat sheet . If you're used to using the docker command-line tool, kubectl for Docker Users explains some equivalent commands for Kubernetes. Use the following syntax to run kubectl commands from your terminal window: where command , TYPE , NAME , and flags are: command : Specifies the operation that you want to perform on one or more resources, for example create , get , describe , delete . command : Specifies the operation that you want to perform on one or more resources, for example create , get , describe , delete . TYPE : Specifies the resource type . Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. For example, the following commands produce the same output: kubectl get pod pod1 kubectl get pods pod1 kubectl get po pod1 TYPE : Specifies the resource type . Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. For example, the following commands produce the same output: NAME : Specifies the name of the resource. Names are case-sensitive. If the name is omitted, details for all resources are displayed, for example kubectl get pods . When performing an operation on multiple resources, you can specify each resource by type and name or specify one or more files: To specify resources by type and name: To group resources if they are all the same type: TYPE1 name1 name2 name<#> . Example: kubectl get pod example-pod1 example-pod2 To specify multiple resource types individually: TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#> . Example: kubectl get pod/example-pod1 replicationcontroller/example-rc1 To specify resources with one or more files: -f file1 -f file2 -f file<#> Use YAML rather than JSON since YAML tends to be more user-friendly, especially for configuration files. Example: kubectl get -f ./pod.yaml NAME : Specifies the name of the resource. Names are case-sensitive. If the name is omitted, details for all resources are displayed, for example kubectl get pods . When performing an operation on multiple resources, you can specify each resource by type and name or specify one or more files: To specify resources by type and name: To group resources if they are all the same type: TYPE1 name1 name2 name<#> . Example: kubectl get pod example-pod1 example-pod2 To specify multiple resource types individually: TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#> . Example: kubectl get pod/example-pod1 replicationcontroller/example-rc1 To specify resources by type and name: To group resources if they are all the same type: TYPE1 name1 name2 name<#> . Example: kubectl get pod example-pod1 example-pod2 To group resources if they are all the same type: TYPE1 name1 name2 name<#> . Example: kubectl get pod example-pod1 example-pod2 To specify multiple resource types individually: TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#> . Example: kubectl get pod/example-pod1 replicationcontroller/example-rc1 To specify multiple resource types individually: TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#> . Example: kubectl get pod/example-pod1 replicationcontroller/example-rc1 To specify resources with one or more files: -f file1 -f file2 -f file<#> Use YAML rather than JSON since YAML tends to be more user-friendly, especially for configuration files. Example: kubectl get -f ./pod.yaml To specify resources with one or more files: -f file1 -f file2 -f file<#> Use YAML rather than JSON since YAML tends to be more user-friendly, especially for configuration files. Example: kubectl get -f ./pod.yaml flags : Specifies optional flags. For example, you can use the -s or --server flags to specify the address and port of the Kubernetes API server. flags : Specifies optional flags. For example, you can use the -s or --server flags to specify the address and port of the Kubernetes API server. If you need help, run kubectl help from the terminal window. In-cluster authentication and namespace overrides By default kubectl will first determine if it is running within a pod, and thus in a cluster. It starts by checking for the KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT environment variables and the existence of a service account token file at /var/run/secrets/kubernetes.io/serviceaccount/token . If all three are found in-cluster authentication is assumed. To maintain backwards compatibility, if the POD_NAMESPACE environment variable is set during in-cluster authentication it will override the default namespace from the service account token. Any manifests or tools relying on namespace defaulting will be affected by this. POD_NAMESPACE environment variable If the POD_NAMESPACE environment variable is set, cli operations on namespaced resources will default to the variable value. For example, if the variable is set to seattle , kubectl get pods would return pods in the seattle namespace. This is because pods are a namespaced resource, and no namespace was provided in the command. Review the output of kubectl api-resources to determine if a resource is namespaced. Explicit use of --namespace <value> overrides this behavior. How kubectl handles ServiceAccount tokens there is Kubernetes service account token file mounted at /var/run/secrets/kubernetes.io/serviceaccount/token , and the KUBERNETES_SERVICE_HOST environment variable is set, and the KUBERNETES_SERVICE_PORT environment variable is set, and you don't explicitly specify a namespace on the kubectl command line then kubectl assumes it is running in your cluster. The kubectl tool looks up the namespace of that ServiceAccount (this is the same as the namespace of the Pod) and acts against that namespace. This is different from what happens outside of a cluster; when kubectl runs outside a cluster and you don't specify a namespace, the kubectl command acts against the namespace set for the current context in your client configuration. To change the default namespace for your kubectl you can use the following command: The following table includes short descriptions and the general syntax for all of the kubectl operations: To learn more about command operations, see the kubectl reference documentation. The following table includes a list of all the supported resource types and their abbreviated aliases. (This output can be retrieved from kubectl api-resources , and was accurate as of Kubernetes 1.25.0) Use the following sections for information about how you can format or sort the output of certain commands. For details about which commands support the various output options, see the kubectl reference documentation.

Formatting output The default output format for all kubectl commands is the human readable plain-text format. To output details to your terminal window in a specific format, you can add either the -o or --output flags to a supported kubectl command. Depending on the kubectl operation, the following output formats are supported: In this example, the following command outputs the details for a single pod as a YAML formatted object: Remember: See the kubectl reference documentation for details about which output format is supported by each command. To define custom columns and output only the details that you want into a table, you can use the custom-columns option. You can choose to define the custom columns inline or use a template file: -o custom-columns=<spec> or -o custom-columns-file=<filename> . where the template.txt file contains: The result of running either command is similar to: Server-side columns kubectl supports receiving specific column information from the server about objects. This means that for any given resource, the server will return columns and rows relevant to that resource, for the client to print. This allows for consistent human-readable output across clients used against the same cluster, by having the server encapsulate the details of printing. This feature is enabled by default. To disable it, add the --server-print=false flag to the kubectl get command. To print information about the status of a pod, use a command like the following: The output is similar to: Sorting list objects To output objects to a sorted list in your terminal window, you can add the --sort-by flag to a supported kubectl command. Sort your objects by specifying any numeric or string field with the --sort-by flag. To specify a field, use a jsonpath expression. To print a list of pods sorted by name, you run: Examples: Common operations Use the following set of examples to help you familiarize yourself with running the commonly used kubectl operations: kubectl apply - Apply or Update a resource from a file or stdin. kubectl get - List one or more resources. kubectl describe - Display detailed state of one or more resources, including the uninitialized ones by default. kubectl delete - Delete resources either from a file, stdin, or specifying label selectors, names, resource selectors, or resources. kubectl exec - Execute a command against a container in a pod. kubectl logs - Print the logs for a container in a pod. kubectl diff - View a diff of the proposed updates to a cluster. Examples: Creating and using plugins Use the following set of examples to help you familiarize yourself with writing and using kubectl plugins: With a plugin written, let's make it executable: In order to view all of the plugins that are available to kubectl , use the kubectl plugin list subcommand: The output is similar to: kubectl plugin list also warns you about plugins that are not executable, or that are shadowed by other plugins; for example: You can think of plugins as a means to build more complex functionality on top of the existing kubectl commands: The next few examples assume that you already made kubectl-whoami have the following contents: Running the above command gives you an output containing the user for the current context in your KUBECONFIG file: Read the kubectl reference documentation: the kubectl command reference the command line arguments reference the kubectl command reference the command line arguments reference Learn about kubectl usage conventions Read about JSONPath support in kubectl Read about how to extend kubectl with plugins To find out more about plugins, take a look at the example CLI plugin . To find out more about plugins, take a look at the example CLI plugin . Was this page helpful? Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow . Open an issue in the GitHub Repository if you want to report a problem or suggest an improvement .