> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Loki in Kubernetes

> How to deploy Loki, Grafana Alloy as a DaemonSet, and Grafana via Helm to collect, index, and visualize Kubernetes pod logs.

Picture a large apartment complex: many floors, and many units on each floor. People move in and out all the time. To collect everyone's mail reliably, you don't run up and down the stairs yourself — you station one concierge on every floor.

![An illustration titled "One concierge per floor" showing a three‑story building with a concierge avatar standing on each floor. Each floor has rows of room or apartment panels with small status icons (mail and highlights).](https://mintcdn.com/kodekloud-c4ac6d9a/dEcIUoAxuol-3ZBK/images/Grafana-Loki/Grafana-Loki-on-Kubernetes/Loki-in-Kubernetes/one-concierge-per-floor.jpg?fit=max\&auto=format\&n=dEcIUoAxuol-3ZBK\&q=85\&s=3b7ef47e934af0bd3f26deccdb2b323a)

Each concierge handles the units on their floor. When a new floor opens, it simply gets its own concierge. Kubernetes works the same way: each node is like a floor, and the pods running on it are the units. Pods are ephemeral — they start, stop, and are rescheduled across nodes — and every one of them writes logs. Collecting logs from every pod across all nodes manually would be a losing battle, especially in a cluster that autos-scales.

![A slide diagram titled "A cluster is like that complex" showing three dashed boxes labeled node-1, node-2, and node-3, each containing colored circular icons and short lines representing components or services. It visually illustrates a cluster made up of multiple nodes.](https://mintcdn.com/kodekloud-c4ac6d9a/dEcIUoAxuol-3ZBK/images/Grafana-Loki/Grafana-Loki-on-Kubernetes/Loki-in-Kubernetes/cluster-three-nodes-diagram.jpg?fit=max\&auto=format\&n=dEcIUoAxuol-3ZBK\&q=85\&s=f009af605ab471b77942f1e2c85dc358)

To solve this, we ask Kubernetes to run one log-collection agent on every node using a DaemonSet. A DaemonSet is a Kubernetes controller that ensures exactly one copy of a pod runs on each node. When a new node joins the cluster, the DaemonSet’s pod gets scheduled there automatically — just like placing a concierge on every floor so no mailbox goes unchecked.

DaemonSets are the canonical way to run node-local agents (logging, monitoring, networking) because they guarantee one pod per node and follow node lifecycle events automatically.

![A diagram titled "A DaemonSet: One agent per node" showing a Kubernetes DaemonSet deploying an "Alloy agent" onto each of four nodes (node-1 to node-4). Each node box contains colored circles representing workloads/pods.](https://mintcdn.com/kodekloud-c4ac6d9a/dEcIUoAxuol-3ZBK/images/Grafana-Loki/Grafana-Loki-on-Kubernetes/Loki-in-Kubernetes/kubernetes-daemonset-alloy-agent-nodes.jpg?fit=max\&auto=format\&n=dEcIUoAxuol-3ZBK\&q=85\&s=c71157299cfcc1006c06f55fbd08af60)

Key pieces of the logging stack we’ll deploy in Kubernetes:

* Loki — the log storage and indexer (server component).
* Grafana Alloy — the node-local log collector, deployed as a DaemonSet so one agent runs on every node and collects logs from all pods on that node.
* Grafana — the visualization and query UI for logs.

To make this clearer, here’s a quick comparison table:

| Component | Purpose | Typical Deployment |
| - | - | - |
| Loki | Stores and indexes logs for efficient querying | Helm chart (server) |
| Grafana Alloy | Collects logs from node-local files or the Kubernetes API | DaemonSet via Helm |
| Grafana | Web UI for exploring logs and dashboards | Helm chart (frontend) |

These components work because the kubelet (the node agent that manages pods) writes pod logs to disk in a predictable location. For example:

```bash theme={null}
/var/log/pods/
default_web-7f9c…/web/0.log
default_api-2b41…/api/0.log
```

Grafana Alloy reads logs from those files (or via the Kubernetes API) and forwards them to Loki for indexing and storage.

Deploying Loki, Alloy, and Grafana by hand means writing lots of YAML and managing many objects. Helm, the Kubernetes package manager, packages charts with sane defaults and reduces manual configuration. Our plan for this article/tutorial is:

* Deploy Loki with its official Helm chart.
* Deploy Grafana Alloy as a DaemonSet via its Helm chart so it collects logs on every node.
* Deploy Grafana with its Helm chart to visualize and query logs.

This architecture results in three Helm releases that work together. While there are older all-in-one bundles, using one Helm chart per component follows current best practices and scales better for production environments.

![An infographic diagram titled “The plan: Three Helm releases” showing three Helm package icons labeled release for loki, alloy, and grafana inside a dashed Kubernetes cluster outline. Below them are daemonset/node icons and a small monitoring graph representing the deployment topology.](https://mintcdn.com/kodekloud-c4ac6d9a/dEcIUoAxuol-3ZBK/images/Grafana-Loki/Grafana-Loki-on-Kubernetes/Loki-in-Kubernetes/helm-releases-loki-alloy-grafana-topology.jpg?fit=max\&auto=format\&n=dEcIUoAxuol-3ZBK\&q=85\&s=4c54deaa404770b68ad0cb032940f58d)

Next steps

* When you’re ready, follow the component-specific Helm charts to deploy each release in sequence: Loki → Alloy (DaemonSet) → Grafana.
* After installation, verify that the Alloy DaemonSet has a pod on every node and that Loki is receiving logs.

Resources and references

* [Kubernetes Concepts: DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)
* [Loki Documentation](https://grafana.com/docs/loki/latest/)
* [Grafana Alloy docs](https://grafana.com/docs/grafana-cloud/agents/)
* [Helm Documentation](https://helm.sh/docs/)

Be mindful of log retention, access control, and sensitive data in logs. Configure Loki retention policies and secure Grafana access before sending production logs.

> **[Watch Video](https://learn.kodekloud.com/user/courses/grafana-loki/module/595f27e5-031e-46ea-bffc-ee1a15f73837/lesson/9b2f4e21-c668-4e36-b015-b8802c13bc08)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.