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.ObjectiveBy 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 ManifestOur 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: 80Let'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.yamlYou 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 PodOnce 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-serverThe output will look similar to this:NAME READY STATUS RESTARTS AGE nginx-server 1/1 Running 0 30sThe 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-serverThe 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-serverStep 3: Interacting with the Running ApplicationOur 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:80This 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:8080You 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-serverThis 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/bashThis 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 ProbesA 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: 20Here 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.yamlYou will see pod/nginx-server configured. Describe the Pod again to see the new probe definitions:kubectl describe pod nginx-serverNotice 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: CleanupTo 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.yamlThe 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.