Fetch logs from all pods in a Kubernetes namespace

Collecting logs from a busy Kubernetes namespace usually means running kubectl logs pod by pod, then chasing down namespace events separately to understand what actually happened. This blueprint turns that manual scramble into a single, repeatable Kestra flow: it lists every pod in a target namespace, pulls each pod's logs for a chosen time window, and gathers the namespace events alongside them. The result is a consistent, auditable snapshot of cluster activity for debugging incidents, building observability routines, and capturing evidence before pods are recycled.

How it works

1. get_pods (io.kestra.plugin.kubernetes.kubectl.Get) connects to the cluster API server and lists all pods in the namespace from inputs.namespace, using fetchType: FETCH to return pod metadata as flow outputs.
2. extract_pod_names (io.kestra.plugin.core.output.OutputValues) parses that metadata with a jq expression to build a clean array of pod names.
3. fetch_logs_per_pod (io.kestra.plugin.core.flow.ForEach) iterates over the pod list with a concurrencyLimit of 5, running the fetch_logs shell task per pod. Each kubectl logs call uses --since={{ inputs.since }}, --all-containers=true, and --ignore-errors=true so multi-container pods are covered without failing the run.
4. fetch_events (io.kestra.plugin.scripts.shell.Commands) runs kubectl get events for the namespace, sorted by .lastTimestamp, for the full activity picture.

Shell tasks run in the bitnami/kubectl container via pluginDefaults, with the client certificate, client key, and CA cert injected as inputFiles so authentication is consistent across every task.

What you get

• Logs from every pod in a namespace gathered in one execution.
• A configurable lookback window (10m, 30m, 1h, 24h, and so on).
• Namespace events sorted chronologically for root-cause context.
• Parallel log collection capped at 5 concurrent pods to protect the API server.
• A stored, replayable record of cluster state at the moment of capture.

Who it's for

• Platform and DevOps engineers triaging namespace incidents.
• SREs assembling observability and on-call routines.
• Support teams capturing evidence before pods are rescheduled.

Why orchestrate this with Kestra

kubectl is great for one-off commands but has no scheduler, no retries, and no history. With Kestra you can attach event triggers and schedules, get automatic retries on transient API failures, and keep full execution lineage of every log capture in one place. The declarative YAML makes the whole routine version-controlled and reviewable, something a loose shell script or a bare cron entry cannot offer.

Prerequisites

• A reachable Kubernetes API server and a namespace to inspect.
• The io.kestra.plugin.kubernetes and io.kestra.plugin.scripts plugins (bundled in Kestra).
• Docker available for the bitnami/kubectl container image.

Secrets

Configure these secrets in your Kestra instance:

• masterUrl: the Kubernetes API server URL.
• client.crt: client certificate for API authentication.
• client.key: client private key for API authentication.
• ca.crt: cluster certificate authority certificate.

Quick start

1. Add the masterUrl, client.crt, client.key, and ca.crt secrets to your Kestra instance.
2. Import this flow into the system namespace.
3. Execute it, setting the namespace and since inputs (defaults: kestra and 1h).
4. Review the captured pod logs and namespace events in the execution outputs.

How to extend

• Add a Schedule trigger to capture logs on a fixed cadence.
• Push collected logs to object storage, Elasticsearch, or a SIEM for retention.
• Add a Slack or email notification when error patterns appear in the logs.
• Filter pods by label selector to scope collection to a single workload.

Links

• Kubernetes plugin docs
• Kubernetes orchestration with Kestra