Centralized Logging for Minikube Environment

[ozgen]

We currently have a Spring Boot application deployed in the default namespace within a Minikube cluster. For better observability and debugging, we need centralized logging to collect, store, and visualize logs from all pods.

---

Task Overview

We aim to set up a centralized logging solution within Minikube using Kubernetes manifests stored in the k8s/logging/ directory.

---

Steps

• Create a k8s/logging/ directory to store all Kubernetes manifests related to logging setup.

• Move the Spring Boot application to its own namespace (app) and create a dedicated logging namespace. Namespace definitions should be included as separate YAML files under k8s/logging/.

• Choose a logging stack:

  • Option A: EFK (Elasticsearch, Fluent Bit or Fluentd, Kibana)
  • Option B: Grafana Loki, Promtail, Grafana

• Define YAML manifests under k8s/logging/ for:

  • Elasticsearch or Loki
  • Fluent Bit or Promtail
  • Kibana or Grafana
  • ConfigMaps, Services, PersistentVolumes, and other necessary resources

• Ensure log collection is configured for all namespaces, especially the app namespace.

• Expose Kibana or Grafana, kubectl port-forward.

---

Suggested Directory Structure

k8s/
└── logging/
    ├── logging-namespace.yaml
    ├── elasticsearch-deployment.yaml
    ├── fluentbit-configmap.yaml
    ├── fluentbit-daemonset.yaml
    ├── kibana-deployment.yaml
    └── grafana-loki-setup yaml files (if using Loki)

---

Notes

• Fluent Bit is recommended over Fluentd for Minikube due to its lightweight nature.
• Keep resource requests and log retention policies conservative to avoid overloading the Minikube environment.

[SelahattinSert]

Which logging stack option is more recommended by you, option A or option B? @ozgen

[ozgen]

Which logging stack option is more recommended by you, option A or option B? @ozgen

both of them can be used its up to you that's why I let you choose @SelahattinSert