Interacting with Pods

Introduction

In this lab, you will learn the essential techniques for interacting with running pods. These are core debugging skills in Kubernetes because workloads are often distributed and not directly visible the way local processes are.

We will cover three powerful debugging skills:

• Logs: Reading the diary of your application to see what it's saying.
• Exec: Teleporting inside the container to look around and run commands.
• Port Forwarding: Creating a secret tunnel to access your application from your local computer.

These skills are fundamental for any DevOps engineer or developer. By the end of this lab, you will feel confident investigating running Pods.

View Logs

In this step, you will learn how to inspect the logs of a running Pod. Think of logs as the "voice" of your application. If something goes wrong, the logs are usually the first place to look for clues.

Under the hood, kubectl logs usually reads what the main container process wrote to standard output and standard error. This is why many containerized applications are designed to log to the terminal instead of writing to local files. In Kubernetes, terminal output is easier for the platform to collect and expose consistently.

The environment is starting a Pod named my-nginx for you in the background. First, wait until the Pod has been created:

until kubectl get pod my-nginx > /dev/null 2>&1; do sleep 2; done

Then wait until its container is ready:

kubectl wait --for=condition=ready pod/my-nginx --timeout=300s

Now verify that it is running:

kubectl get pods

You should see my-nginx with the status Running. If it is not ready yet, wait a moment and try again.

Once the pod is running, use the kubectl logs command to read what the container has printed to the standard output:

kubectl logs my-nginx

Since Nginx is a stable web server, it might be quiet and show little output initially, or simply a message saying it is ready for connections.

To watch the logs in real-time (like watching a live TV feed), you can add the -f (follow) flag:

kubectl logs -f my-nginx

You will see the cursor hanging, waiting for new messages. This is great for watching traffic come in live. Press Ctrl+C to stop following the logs and return to your terminal prompt.

Exec into Container

In this step, you will go beyond reading logs and run commands inside the Pod. You might need to check if a configuration file exists, verify that a tool is installed, or test network connectivity from inside the Pod.

You can do this using the kubectl exec command. It allows you to execute a command inside a running container. We commonly use it to open an interactive shell, effectively "teleporting" us inside.

This is an important distinction: kubectl exec does not "move" you into another machine the way SSH does. It asks the kubelet on the node to start a new process inside an already running container. That is why you see the container's filesystem and environment, not your local terminal's environment.

Run the following command to open a bash shell inside the my-nginx pod:

kubectl exec -it my-nginx -- /bin/bash

Let's understand the flags:

• -i (Interactive): Keeps the input open so you can type things.
• -t (TTY): allocates a pseudo-terminal so it looks like a normal command prompt.
• --: Tells kubectl "everything after this point is a command for the container, not for kubectl".

Your command prompt should change to something like root@my-nginx:/#. You are now inside the specific container in the Kubernetes cluster!

Try listing the files in the directory to confirm you are in a new environment:

ls -F

You are seeing the files inside the Nginx container, completely separate from your LabEx workspace files.

Inspect Environment

In this step, you will inspect the environment inside the container. A common debugging task is to check what Operating System (OS) the container is running. This helps you know which commands (like apt or apk) are available.

This also introduces a common container lesson: the container image determines the user space tools and files you have available. Two Pods might both be "Linux" but still differ greatly because one image is Debian-based, another is Alpine-based, and another contains almost no shell tools at all.

While your prompt is still root@my-nginx:/#, run this command to read the OS release file:

cat /etc/os-release

You will see output identifying the Linux distribution, likely "Debian GNU/Linux". This is because the official Nginx image is built on top of Debian.

When you are done exploring, you need to exit the container and return to your main terminal. Type:

exit

Your prompt will return to labex:~/project.

To confirm you completed this investigation, create a file named os_version.txt and write the name of the OS you found (e.g., "Debian") into it.

echo "Debian" > ~/project/os_version.txt

Port Forwarding

In this step, you will access the Nginx Pod through port forwarding. By default, Pods are isolated. They are like houses in a gated community—they can talk to each other, but outsiders (like you at your local terminal) can't easily reach them.

To access the web server running in my-nginx from your local machine, we can create a "secret tunnel" using Port Forwarding.

Port forwarding is a debugging convenience, not the normal production way to publish applications. It creates a temporary tunnel from your current workstation to one Pod. This is perfect for inspection and quick tests because it avoids creating a full Service or changing external network policy.

Run the following command to forward your local port 8080 to the Pod's port 80:

kubectl port-forward my-nginx 8080:80 &

Note the & at the end! This tells Linux to run this process in the background. If you didn't check this, the command would hang your terminal, and you wouldn't be able to type anything else until you stopped it.

You should see a message saying Forwarding from 127.0.0.1:8080 -> 80.

Now, you can access the Nginx web page through this tunnel using curl:

curl localhost:8080

You should see the HTML code for the "Welcome to nginx!" page. Success! You have reached into the cluster and pulled data out through the tunnel.

Summary

In this lab, you practiced the three essential skills for debugging kubernetes applications:

• Logs: checking the output of your application with kubectl logs.
• Exec: entering the container environment with kubectl exec to inspect files and run commands.
• Port Forwarding: accessing internal services locally with kubectl port-forward.

These tools are your stethoscope and X-ray machine. Whenever you encounter a problem in Kubernetes, these are the first tools you will reach for to diagnose the issue.