Cluster Access

Introduction

Kubernetes is a container orchestration system. It manages how containerized applications are scheduled, run, exposed, and recovered across a cluster.

To interact with a Kubernetes cluster, you typically use kubectl. Before deploying applications, you need a running cluster and a working client configuration that points to it correctly.

In this lab, you will go through the fundamental steps of setting up your access to a Kubernetes cluster. You will use Minikube, a tool that runs a single-node Kubernetes cluster locally, which is perfect for learning and development.

You will learn how to:

1. Start a local Kubernetes cluster.
2. Verify your kubectl context to ensure you are targeting the correct cluster.
3. Retrieve essential cluster information.
4. List the nodes in the cluster to verify their status.

Start the Cluster

In this step, you will start a local Kubernetes cluster using Minikube. Minikube creates a virtual machine or a container on your local machine and deploys a simple cluster inside it. This allows you to practice Kubernetes commands without needing a cloud provider.

At this stage, it helps to separate three ideas clearly. A cluster is the whole Kubernetes environment. A node is a machine inside that cluster. The control plane is the part that accepts API requests and decides what should happen. Minikube packages these pieces into a local learning environment so you can focus on Kubernetes concepts before dealing with cloud infrastructure.

First, ensure you are in the project directory:

cd ~/project

Now, start the Minikube cluster. We will specify the docker driver to run the cluster within a Docker container, which is compatible with this lab environment.

minikube start --driver=docker

This process may take a few minutes as it downloads the necessary Kubernetes images and starts the control plane. You will see output indicating that Minikube is pulling images, starting the container, and configuring the cluster.

Once the command finishes, you can check the status of Minikube to ensure it is running correctly:

minikube status

You should see output indicating that the host, kubelet, and apiserver are "Running".

Verify Context

In this step, you will verify that the kubectl command-line tool is configured to communicate with your new Minikube cluster.

Kubernetes uses a configuration file (usually located at ~/.kube/config) to store cluster access information. This file can contain details for multiple clusters. The "context" determines which cluster kubectl sends commands to. When you started Minikube in the previous step, it automatically updated your configuration and set the context to minikube.

This idea matters because kubectl is just a client. It does not "contain" the cluster. It reads connection details, certificates, and the currently selected context, then sends requests to the Kubernetes API server. In real work, engineers often switch between development, staging, and production clusters, so checking the current context is a safety habit, not a formality.

To verify the current context, run the following command:

kubectl config current-context

The output should be:

minikube

If you want to see the full configuration details, including the cluster server URL and user certificates (safely hidden), you can view the config:

kubectl config view

This confirms that any subsequent kubectl commands you run will be executed against your local Minikube cluster.

Check Cluster Info

In this step, you will retrieve basic information about the cluster to verify connectivity and see where the Kubernetes control plane is running.

The cluster-info command is a simple way to check if kubectl can successfully talk to the API server.

Kubernetes is an API-driven system. Almost every action, from creating a Pod to scaling a Deployment, becomes an API request to the control plane. That is why "Can my client reach the API server?" is one of the first health checks in any cluster investigation.

Run the following command:

kubectl cluster-info

You should see output similar to this:

Kubernetes control plane is running at https://127.0.0.1:32769
CoreDNS is running at https://127.0.0.1:32769/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

The IP addresses and ports may vary, but the key takeaway is that the "Kubernetes control plane is running". This confirms that your client (kubectl) is successfully connected to the server (the cluster).

List Nodes

In this step, you will inspect the nodes in your cluster. A node is a worker machine (virtual or physical) in Kubernetes. Since we are using Minikube, we expect to see a single node that acts as both the control plane and the worker.

In larger clusters, these roles are often separated. Control-plane nodes focus on orchestration, while worker nodes run application workloads. Minikube collapses them into one node to keep the learning environment simple, but the command output still introduces the same concepts you will see in production.

To list all nodes in the cluster, use the get nodes command:

kubectl get nodes

You will see output similar to the following:

NAME       STATUS   ROLES           AGE     VERSION
minikube   Ready    control-plane   5m20s   v1.26.1

Let's break down the columns:

• NAME: The name of the node (in this case, minikube).
• STATUS: The status should be Ready, indicating the node is healthy and ready to accept workloads.
• ROLES: Shows the role of the node (e.g., control-plane).
• AGE: How long the node has been running.
• VERSION: The Kubernetes version installed on the node.

If the status is NotReady, it usually means the node is still starting up or there is a networking issue. Since your status is Ready, your cluster is fully operational.

Summary

In this lab, you have successfully configured your environment to access a Kubernetes cluster. You have:

1. Started a local Kubernetes cluster using Minikube.
2. Verified that your kubectl context is correctly set to target the local cluster.
3. Retrieved cluster information to confirm connectivity with the API server.
4. Listed the nodes to ensure the cluster infrastructure is ready and healthy.

These are the foundational steps required before deploying any applications to Kubernetes. You now have a working local environment to continue your Kubernetes learning journey.