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.