Working with kubectl

Learn about the main Kubernetes command-line tool: kubectl.

We'll cover the following

What is kubectl?

kubectl is the Kubernetes command-line tool, and you’ll use it in all the hands-on examples. You’ll already have it if you’ve followed the instructions to install either of the clusters.

Type kubectl in a terminal window to check if you have it. If you don’t have it, search the web for install kubectl and follow the instructions for your system.

It’s important that your kubectl version is no more than one minor version higher or lower than your cluster. For example, if your cluster is running Kubernetes 1.29.x, your kubectl should be no lower than 1.28.x and no higher than 1.30.x.

At a high level, kubectl converts user-friendly commands into HTTP REST requests and sends them to the API server. Behind the scenes, it reads a kubeconfig file to know which cluster to send commands to and which credentials to use.

The kubeconfig file is called config and lives in your home directory’s hidden .kube folder. It contains definitions for:

  • Clusters

  • Users (credentials)

  • Contexts

Clusters is a list of Kubernetes clusters that kubectl knows about and allows a single kubectl installation to manage multiple clusters. Each cluster definition has a name, certificate info, and API server endpoint.

Users is a list of user credentials. For example, you might have a dev user and an ops user with different permissions. Each of these exists in the kubeconfig file and has a friendly name and a set of credentials. If you’re using X.509 certificates, the username and group Kubernetes uses is embedded in the certificate.

Contexts are how kubectl groups clusters and users under a friendly name. For example, you might have a context called ops-prod that combines the ops user credentials with the prod cluster. Using kubectl with this context will send commands to the API server of the prod cluster and authenticate as the ops user.

The following is a simple kubeconfig file with a single cluster called shield, a single user called coulson, and a single context called director. The director context combines the coulson user and the shield cluster. It’s also set as the default context.

Get hands-on with 1400+ tech skills courses.