TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

Upgrade your AI knowledge with The CODE! Dive into a newsletter trusted by 300,000+ readers for its comprehensive, 5-minute snapshot of everything happening in AI. We navigate through hundreds of sources to bring you the latest AI trends, tools, and resources—so you can stay ahead, absolutely free.

Powered by: Jobsurface.com

Browse 607 Worldwide Jobs Here →

Looking to promote your company, product, service, or event to 49,000+ Cloud Native Professionals? Let's work together. Advertise With Us

Monitoring a Kubernetes cluster is different from monitoring a traditional server. In a traditional setup, you know which processes run on which machine, and you instrument each one directly. In Kubernetes, pods move between nodes, containers restart, and the cluster topology changes constantly. A monitoring approach that works for static infrastructure breaks down quickly in this environment.

Understanding how Kubernetes handles supporting concerns like logging is the right starting point, because the same architectural pattern (the sidecar) shows up across logging, monitoring agents, proxies, and certificate rotation. Once you understand sidecars, the rest of the monitoring stack becomes much easier to reason about.

A Kubernetes pod can run more than one container. The primary container handles the core business logic. A sidecar container runs alongside it in the same pod, sharing the same network namespace, the same localhost, and access to the same volumes. The sidecar handles peripheral concerns so the application container does not have to.

The sidecar pattern is useful because it keeps concerns separated at the container level. The application team owns the application container. The platform team can inject a logging or monitoring sidecar without modifying the application image. The two containers share filesystem access through a volume but are otherwise independent, they can be updated, scaled, and restarted separately.

Service mesh proxies like Envoy in Istio run as sidecars intercepting all network traffic in and out of the application container. Log shippers like Fluentd or Fluent Bit run as sidecars reading application log files from a shared volume and forwarding them to a central logging backend. Monitoring agents can run the same way.

Kubernetes does not have a built-in centralised logging system. Each container writes logs to stdout and stderr, and the kubelet on each node captures those streams and writes them to files under /var/log/containers on the node's filesystem. If you want those logs to survive pod restarts, be searchable across nodes, or flow into a central system like Elasticsearch or Loki, you need to set that up yourself.

There are two common approaches. The first uses a logging agent running as a DaemonSet (one pod per node) that reads from /var/log/containers and ships everything to a central backend. Fluent Bit is the standard choice here because of its low memory footprint. This approach works well for applications that write structured logs to stdout. The second approach uses the sidecar pattern for applications that write logs to files rather than stdout, or that produce multiple distinct log streams that need to be routed separately.

In the sidecar logging model, the application container and the log containers share a volume. The application writes log data to the shared volume. Each sidecar log container reads from a specific log stream or file and forwards it independently. This gives you per stream control, you can route one log stream to an audit system and another to a general purpose logging backend, without changing the application container at all.

The trade off is resource overhead: each sidecar consumes CPU and memory, and in a cluster with many pods this adds up.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)