Enhance Log Retrieval Behavior for Multi-Container Pods

[tanweersalah]

🔍 Current Behavior

Our existing log tool fetches logs from a Kubernetes pod container using:

{
  "name": "string",
  "namespace": "string",
  "container_name": "",
  "tail_lines": 10
}

Current Logic:

• If container_name is specified → return logs for that specific container.
• If container_name is NOT specified → return logs for the pod’s default container only.

Output format:

{
  "logs": {
    "current_container": "string",
    "previously_terminated_container": "string"
  }
}

---

🚩 Problem

In multi-container pods (sidecars, init containers, service meshes, etc.), returning logs from only the default container can:

• Hide important information from other containers
• Make debugging more difficult
• Create ambiguity about which container logs are being returned
• Force multiple API calls to retrieve full pod logs

---

✅ Proposed Behavior Change

If container_name is not provided, the API should:

Return logs from all containers inside the pod, structured by container name.

If container_name is provided, behavior remains unchanged.

This maintains backward compatibility while improving usability.

---

🛠 Proposed Implementation Approach

We can wrap the current functionality:

Step 1: Describe the Pod

Use Kubernetes API to retrieve the pod definition:

• Extract all container names:

  • spec.containers
  • (Optional) spec.initContainers

Step 2: Iterate Through Containers

For each container:

• Call existing log retrieval logic
• Append results in a structured format

---

📦 Proposed Response Structure

Instead of returning a single container log object, return:

{
  "logs": {
    "app": {
      "current": "log content...",
      "previous": "previous log content..."
    },
    "sidecar": {
      "current": "log content...",
      "previous": null
    }
  }
}

---

🎯 Benefits

• ✅ More intuitive behavior
• ✅ Better debugging experience
• ✅ Reduces API round-trips
• ✅ Backward compatible (explicit container still works)
• ✅ Scales naturally with multi-container pods

---

⚖️ Considerations

1. Performance

   • Large pods with many containers may increase response size.
   • Mitigation: keep tail_lines enforced per container.

2. Response Size

   • Could add optional flag:

     "all_containers": true

     for explicit behavior (if team prefers safer rollout).

---

Another strategy :

• Introduce new boolean field:

  "include_all_containers": true

• Keep current default unchanged

---

🧠 Summary

Enhancing the log tool to return logs from all containers when no container is specified aligns better with real-world Kubernetes usage patterns, especially for multi-container pods.

The change is technically straightforward:

• Describe pod
• Iterate containers
• Aggregate results in structured response

This significantly improves debugging experience with minimal implementation risk.

[github-actions]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs.
Thank you for your contributions.