Why Centralized logging (EFK stack) in Kubernetes? - Purpose & Use Cases

The Big Idea

What if you could see all your system problems in one place, instantly?

The Scenario

Imagine you run many small shops in different parts of a city. Each shop keeps its own paper logbook to track sales and issues. When you want to see how all shops are doing, you have to visit each one, read their messy notes, and try to piece together the story.

The Problem

This manual way is slow and frustrating. You waste hours traveling and reading different handwriting. You might miss important problems because some notes are lost or unclear. It's hard to find patterns or spot urgent issues quickly.

The Solution

The EFK stack (Elasticsearch, Fluentd, Kibana) collects all logs from every shop into one clean, searchable place. Fluentd gathers logs from all sources, Elasticsearch stores and indexes them, and Kibana shows them in easy-to-understand dashboards. Now you can see everything at once, find problems fast, and make smart decisions.

Before vs After

✗ Before

ssh shop1; cat logs.txt
ssh shop2; cat logs.txt

✓ After

kubectl logs -l app=shop
# View all logs centrally in Kibana dashboard

What It Enables

With centralized logging, you can instantly monitor all your systems together and react to issues before they become big problems.

Real Life Example

A company running hundreds of Kubernetes pods uses EFK to spot a sudden spike in error messages across pods, helping them fix a bug before customers notice.

Key Takeaways

Manual log checking is slow and error-prone.

EFK stack centralizes logs for easy searching and visualization.

This helps teams quickly find and fix issues across many systems.

Practice

1. What is the main purpose of the EFK stack in Kubernetes?

easy

A. To collect, store, and visualize logs from all pods centrally

B. To manage Kubernetes cluster networking

C. To automate deployment of applications

D. To monitor CPU and memory usage only

Solution

1. Step 1: Understand EFK components

   The EFK stack consists of Fluentd (log collector), Elasticsearch (log storage), and Kibana (log viewer).

2. Step 2: Identify the main goal

   Its main goal is to centralize logs from all Kubernetes pods for easier troubleshooting and monitoring.

3. Final Answer:

   To collect, store, and visualize logs from all pods centrally -> Option A

4. Quick Check:

   EFK = Centralized logging [OK]

Hint: EFK means Fluentd, Elasticsearch, Kibana for logs [OK]

Common Mistakes:

• Confusing EFK with monitoring CPU/memory
• Thinking EFK manages networking
• Assuming EFK automates deployments

2. Which Kubernetes resource is typically used to deploy Fluentd as a log collector in the EFK stack?

easy

A. ServiceAccount

B. DaemonSet

C. Deployment

D. ConfigMap

Solution

1. Step 1: Understand Fluentd deployment needs

   Fluentd must run on every node to collect logs from all pods on that node.

2. Step 2: Choose correct Kubernetes resource

   DaemonSet ensures one pod per node, perfect for log collectors like Fluentd.

3. Final Answer:

   DaemonSet -> Option B

4. Quick Check:

   Fluentd runs as DaemonSet [OK]

Hint: DaemonSet runs pods on all nodes [OK]

Common Mistakes:

• Using Deployment which may not run on all nodes
• Confusing ConfigMap with deployment type
• Thinking ServiceAccount deploys pods

3. Given this Fluentd config snippet in Kubernetes:

match ** {
  @type elasticsearch
  host elasticsearch.logging.svc.cluster.local
  port 9200
}

What is the main effect of this configuration?

medium

A. Fluentd sends all logs to Elasticsearch service at port 9200

B. Fluentd collects logs only from pods named elasticsearch

C. Fluentd stores logs locally on each node

D. Fluentd forwards logs to Kibana directly

Solution

1. Step 1: Analyze Fluentd match directive

   The match ** means all logs are matched and processed by this output plugin.

2. Step 2: Understand output plugin settings

   @type elasticsearch with host and port means logs are sent to Elasticsearch service at that address.

3. Final Answer:

   Fluentd sends all logs to Elasticsearch service at port 9200 -> Option A

4. Quick Check:

   match ** + elasticsearch output = send all logs to ES [OK]

Hint: match ** means all logs sent to Elasticsearch [OK]

Common Mistakes:

• Thinking logs go directly to Kibana
• Assuming logs are stored locally
• Confusing match pattern with pod names

4. You deployed the EFK stack but Kibana shows no logs. Which of these is the most likely cause?

medium

A. Kibana is configured to use wrong Elasticsearch URL

B. Elasticsearch service port is set to 8080 instead of 9200

C. All of the above

D. Fluentd DaemonSet is not running on nodes

Solution

1. Step 1: Check Fluentd status

   If Fluentd pods are not running, logs won't be collected or sent.

2. Step 2: Verify Elasticsearch connectivity

   Wrong port on Elasticsearch service means Fluentd can't send logs properly.

3. Step 3: Confirm Kibana configuration

   If Kibana points to wrong Elasticsearch URL, it can't display logs.

4. Final Answer:

   All of the above -> Option C

5. Quick Check:

   Any broken link in EFK stops logs [OK]

Hint: Check Fluentd, Elasticsearch port, Kibana URL [OK]

Common Mistakes:

• Checking only one component
• Ignoring service port mismatch
• Assuming Kibana auto-fixes URLs

5. You want to filter out logs from Kubernetes system namespaces (like kube-system and default) before sending to Elasticsearch in Fluentd. Which configuration snippet achieves this?

hard

A. filter ** {
@type grep

key kubernetes.namespace_name
pattern ^kube-system$

}

B. filter ** {
@type record_transformer
remove_keys kubernetes.namespace_name
}

C. filter ** {
@type grep

key kubernetes.namespace_name
pattern ^kube-system$

}

D. filter ** {
@type grep

key kubernetes.namespace_name
pattern ^(kube-system|default)$

}

Solution

1. Step 1: Understand filtering with Fluentd grep plugin

   The grep plugin can exclude logs matching certain patterns using blocks.

2. Step 2: Identify namespaces to exclude

   We want to exclude system namespaces like kube-system and default, so pattern must match both.

3. Step 3: Compare options

   filter ** {
     @type grep
     
       key kubernetes.namespace_name
       pattern ^(kube-system|default)$
     
   }

   excludes both kube-system and default namespaces correctly; others exclude only one or do wrong action.

4. Final Answer:

   filter ** { @type grep key kubernetes.namespace_name pattern ^(kube-system|default)$ } -> Option D

5. Quick Check:

   Exclude system namespaces with grep exclude pattern [OK]

Hint: Use grep exclude with regex for system namespaces [OK]

Common Mistakes:

• Excluding only one namespace
• Using include instead of exclude
• Removing keys instead of filtering logs