This is a series on how to get your feet wet with Kubernetes (K8s). We won’t talk about the nitty-gritty details, since the K8s docs serve that purpose already. The purpose is to give an overview and some familiarity with what K8s is and how it works. In this post, we’ll set up your machine with the basics so that you can start working in a K8s cluster.

Assumptions for the series:

  • You have Docker experience
  • You have access to a K8s cluster somewhere; Kind lets you run K8s in a container with Docker or Podman

Kubectl

The kubectl CLI tool is your primary bread-and-butter interface for K8s work. If you’re on Ubuntu, you can install it with sudo snap install kubectl --classic, but I recommend installing it through Homebrew instead. In my experience, Homebrew tends to have more up-to-date packages and more of the kubectl plugins that I’m looking for. If you just want to get started quickly, the Snap way will be fine.

Once you have kubectl installed, you need to grab a config file. This will come from your K8s provider, whether that’s Rancher, AWS, GKE, etc., and it contains your credentials and the address(es) of the cluster. You should treat this file as sensitive. In Rancher, you can find it by going to the web interface, clicking the cluster, and clicking the Kubeconfig File button; other providers will have their own instructions for how to get it. Copy the contents into a file on your local machine named ~/.kube/config. This is where kubectl looks for config information.

With kubectl installed and your config file loaded, you’re ready to interact with the cluster. Try running kubectl get pods to list the pods in the cluster (more on pods in the next post). If you see the message No resources found in default namespace, that’s fine! It means that kubectl was able to talk to the cluster, and there aren’t currently any pods running in the default namespace.

Some basic K8s theory

Pretty much everything in a K8s cluster is a resource of some sort, whether it’s a container, a certificate, a volume for data, or any of the many types of plumbing to ultimately push traffic into, around, and out of the cluster. These resources go into namespaces. In general, resources in one namespace can’t see or interact with resources in another namespace, though this rule starts to change with more complicated and sophisticated applications.

You can see what namespaces are in your cluster by running kubectl get ns. You should see default and kube-system at least, and maybe a few others depending on your provider. If you want to see all of the resources in a given namespace, you can run kubectl get all -n <name of namespace>, e.g. kubectl get all -n admin. Technically, this doesn’t get all of the resources in that namespace, since there are a ton of resources created behind the scenes to keep things running, but it gives you the most relevant ones.

It’s best to not work in the default namespace if possible. Create a new one instead:

kubectl create ns <pick-a-name>

Now you have a new namespace to dump all of your soon-to-be-created resources into!

A pleasant surprise is that kubectl comes with incredible tab completion support! It makes requests to the cluster in real-time, when you press tab, to show you your options. For instance, try running kubectl get all -n <tab><tab>; you’ll see a list of all namespaces in the cluster! Start typing a namespace and hit tab again, and it will complete that namespace for you. This works for all kinds of things, and you should make use of tab completion pretty much every time you use kubectl; it will save you a lot of time and frustration.

Conclusion

In this post, you installed and set up kubectl, the primary tool for working with K8s. You listed the namespaces and resources in the cluster, and you learned that tab completion support in kubectl is one of its killer features.

In the next post, we’ll talk about the most important resource in K8s–the sole reason for K8s to exist–the pod.