Navigate through the Cluster

Now you have a Kubernetes Cluster running and kubectl installed. Let's find out what we can do here and how to navigate through the cluster.

Now we’ll run our first kubectl commands to interact with the cluster, specifically, with its API Server. The API Server is the central component of the Kubernetes Control Plane and is responsible for handling requests from kubectl and other components.

You can run the following command to get a list of all available kubectl commands:

kubectl --help

You should see a list of commands and options that you can use to interact with your Kubernetes Cluster. Some of the most commonly used commands are:

kubectl get          # List resources
kubectl describe     # Show detailed information about a resource
kubectl create       # Create a resource from a manifest file
kubectl apply        # Apply a manifest file to create or update a resource
kubectl delete       # Delete a resource

Most of the commands will require a resource type as an argument, such as node, pod, deployment, or service. You can find a list of all available resource types by running:

kubectl api-resources

The first thing we will do today is to list the nodes in our Kubernetes Cluster. Nodes are the machines that run the Kubernetes components and your applications. You can list the nodes by running:

kubectl get nodes

If everything is ok, you should see a list of nodes in your cluster. If you are using Minikube, you will see a single node named minikube.

❯ kubectl get nodes
NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   15m   v1.33.1

You can also get a more detailed view of the nodes by running:

kubectl describe node minikube

If you see that your nodes are in the Ready state, the fun can begin and we can proceed with our tour. Now that we know what machines (nodes) are in our cluster, let’s look at how Kubernetes organizes the resources that run on those nodes, using namespaces.

Namespaces

Kubernetes uses namespaces to organize resources within a cluster. Namespaces allow you to logically separate resources, which can be useful if you have multiple teams and/or applications running in the same cluster (which is hopefully the case in your production environment). By default, Kubernetes has a few built-in namespaces, such as default, kube-system, and kube-public.

By default, you will work in the default namespace (as your kubectl configuration will point to it). In real-world scenarios, avoid using the default namespace for your applications and create dedicated namespaces for your applications or teams. This will help you to manage resources and access control more effectively. Avoid deploying applications to the kube-system namespace, which is reserved for system components. Throughout our labs, we will create and use dedicated namespaces for our applications.

How to define objects in Kubernetes

Kubernetes is configured using objects that are typically defined in YAML or JSON format. As long as you have these manifests only stored on your local machine and don't apply them to the cluster, they are just files and nothing happens. Once you apply them to the cluster, Kubernetes will store them in its database and will do its best to ensure that the desired state of the cluster matches the state defined in the manifests.

There are multiple ways to create objects in Kubernetes. You can use imperative commands to create objects directly from the command line, or you can use declarative manifests that define the desired state of the object.

The first object we’ll create is a Namespace that we’ll use throughout this lab. You can create a Namespace using the following command:

kubectl create namespace learning-tracker

This command will create a new Namespace called learning-tracker. You can verify that the Namespace was created by running:

kubectl get namespaces

You should see the newly created Namespace in the list of namespaces.

From now on, we will use the learning-tracker Namespace for all our resources in this lab. You can switch to this Namespace by running:

kubectl config set-context --current --namespace=learning-tracker

This command will set the current context to the learning-tracker Namespace. But what exactly is a context in Kubernetes? Did you already wonder how you got authenticated to the cluster and how kubectl knows which cluster to connect to? In the next section, we'll shed some light on this topic.

Contexts and the kubeconfig

In large environments, you will often have multiple clusters and multiple users. Kubernetes uses contexts to manage these configurations. These configurations are stored in a file called kubeconfig, which is located at ~/.kube/config by default. The kubeconfig file contains information about clusters, users, and contexts.

A context defines a cluster, a user, and a namespace. This tells kubectl which cluster to talk to, who you are, and which namespace to use by default. When you run kubectl commands, it uses the current context to determine which cluster to connect to and which user to authenticate as. You can view the current context by running:

kubectl config current-context

You can also view the contents of your kubeconfig file by running:

kubectl config view

As already mentioned, you can switch the current context to a different namespace by running:

kubectl config set-context --current --namespace=learning-tracker

This command will set the current context to the learning-tracker Namespace, so that all subsequent kubectl commands will operate in this Namespace by default.

In our minikube setup, the kubeconfig file is automatically configured to use the minikube context, which points to the Minikube cluster and the default namespace. By switching to the learning-tracker namespace, we can now create and manage resources in this Namespace without having to specify it in every command.

In the next section, we will create our first Pod in the learning-tracker Namespace and explore how to work with it.