Practice: Deploying and Inspecting Pods

You will create, deploy, inspect, and manage a Pod in your local Kubernetes cluster, applying concepts for effective Pod management. You will work directly with kubectl and YAML manifests to solidify your understanding of the Pod lifecycle and its operational management.

Objective

By the end of this practice, you will be able to:

• Write a basic Pod manifest for a single-container application.
• Deploy the Pod to your cluster using kubectl.
• Inspect the Pod's status, events, and logs.
• Access the application running inside the Pod from your local machine.
• Modify the manifest to include health probes.
• Clean up the resources you created.

Before you begin, ensure you have a running local Kubernetes cluster and kubectl is configured to interact with it, as detailed in Chapter 1.

Step 1: Writing and Deploying a Pod Manifest

Our first task is to create a Pod that runs a simple NGINX web server. This requires defining a manifest file that specifies the desired state.

Create a new file named nginx-pod.yaml and add the following content:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-server
  labels:
    app: nginx
spec:
  containers:
  - name: web-server
    image: nginx:1.25
    ports:
    - containerPort: 80

Let's briefly examine the fields in this manifest:

• apiVersion: v1: Specifies the API version for the Pod object, which is part of the core API group.
• kind: Pod: Declares that we are defining a Pod object.
• metadata: Contains data that helps uniquely identify the object, including its name and descriptive labels.
• spec: Defines the desired state for the Pod.
• containers: A list of one or more containers to run within the Pod.
  • name: A name for the container within the Pod.
  • image: The container image to pull from a registry.
  • ports: A list of network ports to expose from the container. containerPort: 80 informs Kubernetes that the NGINX container is listening on port 80.

Now, apply this manifest to your cluster using kubectl:

kubectl apply -f nginx-pod.yaml

You should see a confirmation message: pod/nginx-server created. This command instructs Kubernetes to read the manifest and create the object, striving to match the cluster's state with the state you have declared.

Step 2: Inspecting the Pod

Once the manifest is applied, the Kubernetes control plane works to schedule and run the Pod. We can observe this process using several kubectl commands.

First, check the Pod's status. It may take a few moments to transition from Pending or ContainerCreating to Running as the image is pulled.

kubectl get pod nginx-server

The output will look similar to this:

NAME           READY   STATUS    RESTARTS   AGE
nginx-server   1/1     Running   0          30s

The STATUS column shows that the Pod is running, and the READY column indicates that 1/1 containers within the Pod are ready to serve traffic.

For a more detailed view, use the describe command. This is an indispensable tool for troubleshooting.

kubectl describe pod nginx-server

The output is verbose but provides a wealth of information. Pay attention to these sections:

• IP: The internal IP address assigned to the Pod within the cluster's network.
• Containers: Details about the container's state, image ID, and port mappings.
• Events: A chronological log of actions the scheduler and kubelet have taken regarding this Pod. If a Pod fails to start, the reason is almost always found here.

...
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  1m    default-scheduler  Successfully assigned default/nginx-server to minikube
  Normal  Pulling    1m    kubelet            Pulling image "nginx:1.25"
  Normal  Pulled     50s   kubelet            Successfully pulled image "nginx:1.25" in 10s
  Normal  Created    50s   kubelet            Created container web-server
  Normal  Started    50s   kubelet            Started container web-server

Step 3: Interacting with the Running Application

Our NGINX container is running inside the Pod, but it is only accessible within the cluster's private network. To interact with it from our local machine, we can use kubectl port-forward. This command creates a secure tunnel between your local machine and the Pod.

Open a new terminal window and run the following command:

kubectl port-forward pod/nginx-server 8080:80

This command forwards traffic from your local port 8080 to the Pod's container port 80. The command will remain active as long as the tunnel is open.

Now, you can access the NGINX welcome page. Use a web browser to navigate to http://localhost:8080 or use curl in another terminal:

curl http://localhost:8080

You should see the standard NGINX HTML response, confirming your application is running and accessible.

You can also view the logs generated by the container. Go back to your first terminal (where port-forwarding is not running) and execute:

kubectl logs nginx-server

This will show the NGINX access logs, including the request you just made with curl. For an interactive shell inside the container, use exec:

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

This gives you a root shell inside the web-server container. From here, you can inspect the filesystem and running processes. Type exit to return to your local shell.

Step 4: Adding Liveness and Readiness Probes

A running application is not always a healthy one. Let's modify our manifest to include health probes, allowing Kubernetes to automatically manage the Pod's health.

Update nginx-pod.yaml with the following livenessProbe and readinessProbe:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-server
  labels:
    app: nginx
spec:
  containers:
  - name: web-server
    image: nginx:1.25
    ports:
    - containerPort: 80
    readinessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 20

Here is what we added:

• readinessProbe: The kubelet will send an HTTP GET request to / on port 80. If it receives a success code, the Pod is marked as Ready. Kubernetes will not send traffic to a Pod until its readiness probe succeeds.
• livenessProbe: If this probe fails, the kubelet will kill the container and restart it according to the Pod's restart policy. This helps recover from deadlocked applications.

Save the file and re-apply it. Kubernetes is smart enough to update the existing object with the new configuration.

kubectl apply -f nginx-pod.yaml

You will see pod/nginx-server configured. Describe the Pod again to see the new probe definitions:

kubectl describe pod nginx-server

Notice the new Liveness and Readiness sections in the container's description. The Pod's status also reflects the readiness state in kubectl get pod.

Step 5: Cleanup

To conclude the practice, we will delete the Pod from the cluster. You can do this imperatively by name or declaratively using the same file you used for creation. Using the file is often preferred as it ensures you delete exactly what you defined.

kubectl delete -f nginx-pod.yaml

The output pod "nginx-server" deleted confirms the resource has been removed. You can verify this by running kubectl get pods. This completes our hands-on tour of creating and inspecting a fundamental Kubernetes object.