Skip to main content
In this article, we review a lab exercise on multi-container pods. The lab demonstrates how to identify container counts in pods, create multi-container pods using specified images, and add a sidecar container to forward logs to Elasticsearch. This step-by-step guide will help you understand these concepts and implement them in your Kubernetes environment.

Identifying Containers in the Red Pod

To determine the number of containers in the red pod, you have two options:
  1. Check the “READY” column in the pod listing—the numbers indicate total containers versus how many are ready.
  2. Use the describe command to inspect the pod details. In the output, look for the “Containers:” section. For example, the following YAML snippet shows three container entries named apple, wine, and searle:
Both methods confirm that the red pod contains three containers.

Identifying Containers in the Blue Pod

Next, determine the container names in the blue pod. Examining its details reveals two containers, named teal and navy. Below is an excerpt of the pod details:
This confirms that the blue pod runs two containers: teal and navy.

Creating a Multi-Container Pod (Yellow Pod)

The next task is to create a multi-container pod named yellow that includes two containers. Follow these specifications:
  • Container 1: Named lemon, uses the busybox image with a sleep command (sleep 1000) to prevent a CrashLoopBackOff state.
  • Container 2: Named gold, uses the redis image.
An image from the lab instructions illustrates these details:
The image shows a task to create a multi-container pod with two containers using specified images, with instructions to handle a crashloopbackoff error.

Step 1: Generate the Base Pod Definition

Run the following command using dry run to generate a YAML definition for the pod:
The command produces a YAML definition similar to this:

Step 2: Update the YAML

Rename the first container from yellow to lemon and add the sleep command. Then, include a second container named gold with the redis image. The updated YAML should look like this:
Save this file (e.g., as yellow.yaml) and apply the configuration:

Verifying the Yellow Pod

After the pod is created, verify the status with:
You should see the yellow pod with two containers: lemon (busybox) running with sleep 1000 and gold (redis).

Exploring the Elastic Stack Logging Setup

This section covers the deployment of a simple application and a logging stack within the elastic-stack namespace. The deployment includes:
  • app pod (running the event simulator)
  • elastic-search pod
  • kibana pod
Wait until all pods are in the running state:
Expected output:

Inspecting the Kibana UI

Once the pods are up and running, open the Kibana UI using the link provided above your terminal. Kibana serves as the dashboard for viewing the logs gathered by Elasticsearch. Elasticsearch collects log data—such as metrics and application logs—and Kibana visualizes them. To view logs from Kibana, run:

Investigating the Application Pod

Next, examine the app pod to verify its container configuration and image details. The app pod runs a single container with an event simulator that sends log messages to /log/app.log. An excerpt from its description is shown below:
The event simulator writes its logs to /log/app.log. To view the log entries directly within the pod, execute:
Inspect the log entries to identify any user issues. For example, the logs indicate that USER5 experienced login problems due to the account being locked after multiple failed attempts:
Thus, the problematic user is USER5.

Adding a Sidecar Container for Log Shipping to Elasticsearch

To forward logs from the app pod to Elasticsearch, a sidecar container must be added. This container, named sidecar, utilizes a custom Fluent Bit image (configured similarly to Filebeat) to read logs from a shared volume and forward them to Elasticsearch.

Editing the App Pod Definition

The current definition of the app pod includes only the event simulator container. To implement log forwarding, modify the pod definition to include both the event simulator and the sidecar container, ensuring that they share the same volume. Below is an example YAML snippet with the updated configuration:
In this configuration:
  • The sidecar container mounts log-volume at /var/log/event-simulator/ (where Filebeat expects the logs).
  • The app container writes logs to /log.

Updating the Pod

Since Kubernetes does not permit the modification of container sets on a live pod, you must force replace the existing pod with the updated YAML. If you try to edit the pod interactively, you might see an error similar to:
Editing an existing pod to add or remove containers is not allowed. Instead, update the configuration file and force replace the pod.
To apply the changes, use the force replace command:
The output should confirm the replacement:
Finally, verify the pod status:

Verifying Logs in Kibana

After updating the app pod with the sidecar container, open the Kibana UI to confirm that logs are flowing into the Discover section. Follow these steps:
  1. Create an index pattern in Kibana (for example, filebeat-*).
  2. Configure the time filter as needed.
  3. Navigate to the Discover section to view the log entries.
The following image shows the Kibana interface for creating an index pattern:
The image shows a Kibana interface for creating an index pattern, with a successful match for one index named "filebeat-6.4.2-2022.04.17".
Once the index pattern is established, view the logs in the Discover section:
The image shows a log management interface displaying event logs with timestamps, sources, messages, and other metadata related to user activities on a system.
This confirms that logs from the app pod are successfully forwarded to Elasticsearch and visualized in Kibana.
This concludes the guide on setting up multi-container pods and integrating a sidecar container for log shipping to Elasticsearch. Happy learning!

Watch Video