Sign up for a live Kubernetes or DevSecOps demo

Click here


Learn how to get started with Kubernetes including how to monitor and manage your clusters, view your Kubernetes logs, and how to improve your Kubernetes security

Cluster-Level Logging Architecture

The bad news about cluster-level logging in Kubernetes is that Kubernetes has no native cluster-level logging. The good news is that there are a few proven methods that can be applied cluster-wide to provide the same effective result of all the logs being collected in a standardized way and sent to a central location.

The most widely-used methods are:

  • Configure an agent on every node
  • Include a sidecar that attaches to every pod
  • Configure every application individually to ship its own logs

Node Logging Agent

Installing a running agent on every node, preferably as a DaemonSet in Kubernetes, but it could be at the Operating System level.

Benefits are that it requires no changes to the Kubernetes cluster and can be extended to capture other system logs. But the downfall is that it requires a container to run with elevated privileges to access the files that some environments will not be friendly too.


This actually has two options for deployment; the first being the sidecar simply diverts all the log traffic to a custom stdout file that is watched by a custom node logging agent and then shipped off. Or, the sidecar can ship traffic directly to the central logging repository.

While this option requires no changes to the individual container images, it does require changes to the deployment specification for every application that is deployed. This is a great option if you can not run containers with elevated privileges, or only want to send different applications to different logs repositories. But that flexibility comes with many more moving parts to configure than the node-agent option that needs to be watched.

Application Customized

Configuring the applications directly has the same benefits as the sidecar option listed above, and can potentially provide even more valuable information as the application development team can tailor what messages are being generated. The biggest downfall revolves around the fact it is upstream in the application lifecycle and, therefore, needs involvement from the development teams to ensure it is implemented. This leads to additional cross-team coordination and can increase timelines when changes are required, due to the nature of a larger group being involved in all related activities.