kubectl

Q: What is the difference between kubectl apply and kubectl create?

kubectl create makes a new object and fails if it already exists. kubectl apply creates the object or updates it to match the file, so you can run it again and again; that is why it suits configuration kept in files.

Q: Where does kubectl get its credentials?

From a kubeconfig file, ~/.kube/config unless the KUBECONFIG variable points elsewhere. It lists clusters, users and contexts, each context pairing a cluster with a user and a namespace; kubectl config use-context switches between them.

Pronunciation: KOOB kun-TROHL

Updated October 5, 20262 min read

In short

kubectl is the command-line tool for Kubernetes: it sends requests to a cluster's API server to deploy applications, inspect them and change them.

What is kubectl?

kubectl is how most people talk to a Kubernetes cluster. Every command becomes a request to the cluster's API server: kubectl get pods lists the running pods, kubectl describe shows the details and recent events of one object, kubectl logs prints a container's output, and kubectl exec runs a command inside a container. Which cluster it talks to, and as whom, comes from a kubeconfig file, usually ~/.kube/config, which can hold several clusters as named contexts.

There are two ways to change a cluster. Imperative commands such as kubectl create deployment or kubectl scale say what to do right now. The declarative way, preferred for anything that lasts, is to describe the desired state in YAML files and run kubectl apply -f, which compares the files with what is running and makes only the changes needed. Keeping those files in Git turns every change into a reviewed commit, and tools built on the same idea, such as Helm and GitOps controllers, take it further.

kubectl is to a cluster what a remote control is to a television: the work happens elsewhere, and the tool only sends instructions. Because it can change anything the credentials allow, access to production is usually narrowed with role-based access control (RBAC), and kubectl diff or --dry-run=server show what a change would do before it is applied. People say its name in several ways, such as kube control, kube cuttle or kube C-T-L.

Key takeaways

kubectl is the Kubernetes command-line tool; every command is a call to the API server.
get, describe, logs and exec inspect what is running.
kubectl apply -f makes the cluster match YAML files that describe the desired state.
The kubeconfig file decides which cluster kubectl talks to, and as whom.

Example

Everyday kubectl commandsbash

kubectl config get-contexts               # the clusters you can talk to
kubectl get pods -n shop                   # pods in the "shop" namespace
kubectl describe pod web-7d9f-x2kq -n shop # details and recent events
kubectl logs -f deploy/web -n shop         # follow the logs of the deployment's pod
kubectl diff -f web.yaml                   # what applying the file would change
kubectl apply -f web.yaml                  # make the cluster match the file
kubectl rollout undo deploy/web -n shop    # go back to the previous version

Readers ask

What is the difference between kubectl apply and kubectl create?

kubectl create makes a new object and fails if it already exists. kubectl apply creates the object or updates it to match the file, so you can run it again and again; that is why it suits configuration kept in files.

Where does kubectl get its credentials?

From a kubeconfig file, ~/.kube/config unless the KUBECONFIG variable points elsewhere. It lists clusters, users and contexts, each context pairing a cluster with a user and a namespace; kubectl config use-context switches between them.

Sources

Spotted a mistake or something missing on this page?Suggest an edit