Use context: kubectl config use-context k8s-c1-H
In Namespace project-tiger
create a Pod named tigers-reunite
of image httpd:2.4.41-alpine
with labels pod=container
and container=pod
. Find out on which node the Pod is scheduled. Ssh into that node and find the containerd container belonging to that Pod.
Using command crictl
:
- Write the ID of the container and the
info.runtimeType
into/opt/course/17/pod-container.txt
- Write the logs of the container into
/opt/course/17/pod-container.log
Capturing Container Information and Logs in Kubernetes
Kubernetes provides powerful tools for managing and inspecting containers running within Pods. In this guide, we’ll walk through the process of creating a Pod, identifying its associated container, capturing runtime details, and retrieving logs directly from the container. These steps are crucial for debugging and monitoring your applications in a Kubernetes environment.
Step 1: Creating the Pod
First, we’ll create a new Pod in the project-tiger
namespace. This Pod will run an HTTPD server using the httpd:2.4.41-alpine
image and will have specific labels applied:
1 2 3 4 5 |
kubectl -n project-tiger run tigers-reunite \ --image=httpd:2.4.41-alpine \ --labels "pod=container,container=pod" |
This command creates a Pod named tigers-reunite
with the specified image and labels, which you can use later for querying or organizing resources.
Step 2: Identifying the Node Where the Pod is Running
Next, we need to determine which node the Pod is scheduled on. You can do this by running the following command:
1 2 3 |
kubectl -n project-tiger get pod -o wide |
For a more targeted approach, you can also use the following command to get just the node name:
1 2 3 |
kubectl -n project-tiger get pod tigers-reunite -o jsonpath="{.spec.nodeName}" |
This will return the name of the node where the Pod is running, which is essential for the next steps.
Step 3: Accessing the Node and Inspecting the Container
Now that we know the node where the Pod is running, we’ll SSH into that node to inspect the container:
1 2 3 |
ssh cluster1-node2 |
Once logged in, find the container ID associated with the tigers-reunite
Pod:
1 2 3 |
crictl ps | grep tigers-reunite |
This command will output details about the running container, including its ID, which we’ll use for further inspection. For example:
1 2 3 |
b01edbe6f89ed 54b0995a63052 5 seconds ago Running tigers-reunite ... |
Next, inspect the container to determine the runtime type:
1 2 3 |
crictl inspect b01edbe6f89ed | grep runtimeType |
The output should look something like this:
1 2 3 |
"runtimeType": "io.containerd.runc.v2", |
Step 4: Capturing Container Information
Now that we have the container ID and runtime type, let’s store this information in a file on the main terminal:
1 2 3 4 |
# /opt/course/17/pod-container.txt b01edbe6f89ed io.containerd.runc.v2 |
This file records the container ID and its runtime type for future reference.
Step 5: Retrieving Container Logs
Finally, let’s capture the logs from the container and save them into a log file. You can do this by running the following command:
1 2 3 |
ssh cluster1-node2 'crictl logs b01edbe6f89ed' &> /opt/course/17/pod-container.log |
This command redirects both standard output and standard error to a log file. The log file might look something like this:
1 2 3 4 5 6 |
# /opt/course/17/pod-container.log AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 10.44.0.37. Set the 'ServerName' directive globally to suppress this message [Mon Sep 13 13:32:18.555280 2021] [mpm_event:notice] [pid 1:tid 139929534545224] AH00489: Apache/2.4.41 (Unix) configured -- resuming normal operations [Mon Sep 13 13:32:18.555610 2021] [core:notice] [pid 1:tid 139929534545224] AH00094: Command line: 'httpd -D FOREGROUND' |
These logs provide valuable insights into the operation of your container, helping you debug and monitor the HTTPD server.
Conclusion
In this guide, we’ve demonstrated how to create a Kubernetes Pod, identify and inspect its container, and retrieve logs directly from the container. These skills are essential for effective troubleshooting and monitoring in Kubernetes, ensuring that your applications run smoothly in your cluster.