EFK centralized logging architecture

WHAT THIS TESTS This checks whether you can articulate a full centralized logging pipeline, the role of each component, and how data flows from container to dashboard.

A GOOD ANSWER COVERS The EFK stack has three roles. The collector, Fluentd or the lighter Fluent Bit, runs as a DaemonSet so exactly one agent sits on every node. It tails the container log files the runtime writes under /var/log/containers, parses each line, and enriches it with Kubernetes metadata like pod name, namespace, and labels by querying the API. It then forwards the structured records to the store. Elasticsearch is the storage and search engine: it indexes the logs into time-based indices, enabling full-text and field queries at scale, usually run as a StatefulSet with persistent volumes. Kibana is the visualization layer: it connects to Elasticsearch and gives engineers a UI to search logs, build dashboards, and define saved queries. Data flows node container stdout, to Fluentd DaemonSet, to Elasticsearch index, to Kibana view. Fluentd buffers in memory or on disk to absorb spikes and Elasticsearch downtime.

COMMON WRONG ANSWERS Saying you should run a logging sidecar in every pod by default is wrong for the common case; node-level DaemonSet collection is standard and far cheaper. Omitting metadata enrichment makes logs hard to correlate. Forgetting Elasticsearch needs persistence and index lifecycle management.

LIKELY FOLLOW-UPS When a sidecar collector IS justified. Fluentd versus Fluent Bit tradeoffs. How index lifecycle and retention are managed. The Loki/Promtail/Grafana alternative.

ONE CONCRETE EXAMPLE A pod logs a JSON error to stdout. The node's Fluentd reads it, tags it with namespace payments and pod checkout-7f, ships it to Elasticsearch where it lands in logstash-2026.06.24, and an engineer finds it in Kibana by filtering namespace payments.