Strategie logowania w Kubernetes

In Kubernetes, applications run inside containers which are often ephemeral. This means containers can start, stop, or crash at any time. How do you know what's happening?

Logs are your application's voice! They provide crucial insights into how your applications are performing, what errors are occurring, and help you troubleshoot issues effectively.

By default, Kubernetes captures any output that your application sends to stdout (standard output) and stderr (standard error) within its container.

• stdout: Typically used for general informational messages.
• stderr: Reserved for warnings and error messages.

These streams are then handled by the container runtime (like containerd or CRI-O) and made available.

For a single container, you can easily view its logs using the kubectl logs command. This is great for quick debugging of a running or recently crashed pod.

First, let's create a simple Pod that generates logs:

apiVersion: v1
kind: Pod
metadata:
  name: my-logger-pod
spec:
  containers:
  - name: logger-container
    image: busybox
    command: ["sh", "-c", "while true; do echo 'Hello from CoddyKit!'; sleep 5; done"]

After applying this YAML (kubectl apply -f your-pod.yaml), you can view its logs:

While kubectl logs is handy, it has limitations. If a Pod is deleted, crashes, or is rescheduled to another node, its logs are gone! This is because kubectl logs fetches directly from the container runtime on the node where the Pod is running.

For production environments, relying solely on kubectl logs is not sustainable. You need a way to store and access logs even after a Pod is gone.

To overcome the ephemeral nature of container logs, we need centralized logging. This means collecting logs from all your Kubernetes Pods and storing them in a dedicated, persistent system outside the cluster.

Why centralize?

• Persistence: Logs are saved even if Pods disappear.
• Searchability: Easily search across all application logs.
• Analysis: Identify trends, errors, and performance issues.
• Monitoring: Create alerts based on log patterns.

One of the most common and robust strategies for centralized logging in Kubernetes is using a node-level logging agent. This involves running a small agent container on every node in your cluster.

• The agent collects logs from all containers on its node.
• It then forwards these logs to a centralized logging backend.
• These agents often run as a Kubernetes DaemonSet, ensuring one instance per node.

Another pattern, less common for general cluster-wide logging but useful for specific cases, is the sidecar logging container.

Here, a dedicated logging agent runs as a separate container within the same Pod as your application container. The application writes logs to a shared volume, and the sidecar container picks them up and forwards them.

This is useful when an application writes logs to a file instead of stdout/stderr, or requires specific log processing.

Several powerful open-source tools are widely used for centralized logging in Kubernetes:

• Fluentd/Fluent Bit: Lightweight and efficient log collectors, often used as node-level agents.
• Elasticsearch: A distributed search and analytics engine for storing and indexing logs.
• Kibana: A data visualization and exploration tool for Elasticsearch, used to view and analyze logs.

Combined, these are often referred to as the EFK stack (Elasticsearch, Fluentd, Kibana).

You've learned about different ways to handle logs in Kubernetes. Let's test your understanding.

Well done! You've explored the foundations of logging in Kubernetes.

• We saw that logs are vital for monitoring and troubleshooting.
• Kubernetes captures stdout and stderr by default.
• kubectl logs is useful for immediate debugging but lacks persistence.
• Centralized logging is crucial for production, using node-level agents (like Fluentd) or sidecar patterns to aggregate logs.
• Tools like the EFK stack help store, index, and visualize these aggregated logs.

Next, we'll dive into monitoring tools!