Skip to main content
In this lesson Bob adds Kibana to the cluster so the team can browse logs with a web UI instead of inspecting raw search output. This page walks through the Deployment and Service manifests, how to reach Kibana from a laptop, and how to create an index pattern and run simple queries to verify end-to-end logging. Why Kibana?
  • Provides a web UI for exploring logs stored in Elasticsearch.
  • Lets you create index patterns, run ad-hoc queries, and build visualizations and dashboards.
A quick example of an Elasticsearch hit (conceptual):

Deploying Kibana

The Kibana Deployment is straightforward: it creates a Deployment named kibana in the elastic-stack namespace, with one replica and the pod label app: kibana. The container exposes port 5601, the default Kibana web UI port. Deployment (excerpt):
Apply the manifest into the same elastic-stack namespace where Elasticsearch and Fluentd are running:
Initially the pod will be ContainerCreating while Kubernetes pulls the Kibana image. After a short time it should become Running:

Exposing Kibana: NodePort Service

A running pod is reachable inside the cluster, but to open the UI in a laptop browser we create a Service. A NodePort Service opens a port on each node and forwards traffic to the pod’s port 5601. The Service selects the same app: kibana label so it routes to the Kibana pod. Inside the cluster the service listens on 5601 and maps a NodePort (example: 30601) on each node.
An illustration titled "A Door Number on the Node." It shows a stylized node character on a platform labeled 5601, a nearby door icon labeled 30601, and a search window on the left.
Apply the Service manifest and confirm the NodePort mapping:
Probe the NodePort from your workstation (replace node01 with your node’s address):
A 200 OK indicates Kibana is answering. Open http://node01:30601 in your browser to load the Kibana UI.
Exposing Kibana via a NodePort makes the UI reachable from the node network. If your nodes are publicly accessible, secure Kibana with authentication, network policies, or an ingress that enforces TLS and access control.

Quick reference: Kubernetes objects deployed

For more details see the Kubernetes documentation: Services.

Creating an index pattern in Kibana

When you open Kibana and go to Discover, Kibana asks which index pattern to use. Fluentd in this setup creates daily indices named like fluentd-YYYY.MM.DD. To match today’s index and future indices, use a wildcard index pattern such as fluentd-*. Enter fluentd-* to match current and future daily indices.
A dark-themed screenshot titled "The Wildcard" showing a "Create index pattern" dialog with the pattern "fluentd-*" and a success message listing indices like fluentd-2026.10.12 and fluentd-2026.10.13. To the right is a circular user avatar labeled "Bob."
Kibana will then ask which field to use as the timestamp. Select the appropriate timestamp field (for example @timestamp) and create the index pattern. Kibana reads the index mappings and displays discovered fields.

Exploring logs in Discover

With the index pattern created, Discover shows a bar chart of events over time and lists log lines (newest first). These logs originate in app pods, are collected by Fluentd, stored in Elasticsearch, and surfaced in Kibana.
A dark-themed analytics dashboard titled "Discover Comes Alive" showing a search bar, bar chart and recent user activity log entries. To the right is a simple data flow diagram showing logs flowing through Fluentd into Elasticsearch.
To filter for a specific user Bob switches the search mode to KQL (Kibana Query Language) and runs a simple query:
After applying the filter the chart updates and only log lines that mention USER1 remain. KQL is an easy-to-use query language for interactive log exploration. Example filtered output in Discover (conceptual):
From these searches you can build visualizations (for example, counts by user) and pin them to dashboards. The key verification here is that the entire path — app → Fluentd → Elasticsearch → Kibana — is working and searchable in a browser.
Kibana queries data in Elasticsearch. If Elasticsearch is unavailable or resource-starved, Discover won’t always show an explicit error; it may simply return no results and flatten charts. Add monitoring and alerts for Elasticsearch cluster health and resource usage to ensure reliable log visibility.

Next steps

  • Add monitoring and alerts for Elasticsearch (cluster health, disk, CPU, memory).
  • Consider using an authenticated, encrypted ingress instead of a NodePort for production access.
  • Build visualizations and dashboards in Kibana to surface important operational metrics and log-derived KPIs.
Useful links and references

Watch Video

Practice Lab