Sponsored by
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.
👋 👋 A big thank you to today's sponsor HUBSPOT
A CRM so smart, it updates itself.
HubSpot's CRM is so smart, it now updates itself. Calls get logged and summarized the moment they end. New leads get researched and a first outreach drafted, automatically. Deals move forward on their own, with next steps flagged before you have to ask.
Even the one repetitive task you've been meaning to fix can now run itself, no code required. Customers using it are already seeing the difference.
This isn't the CRM you have to work hard to figure out. It's the one already working before you log in.
👀 Remote Jobs
Biti is hiring a DevOps Engineer
Remote Location: Worldwide
Somnia is hiring a Senior Infrastructure Engineer
Remote Location: Worldwide
📚 Resources
If you’re not a subscriber, here’s what you missed last week.
To receive all the full articles and support TechOps Examples, consider subscribing:
🧠 USE CASE
Kubernetes Sidecar Container Architecture Explained
While sidecar containers are widely talked about in the Kubernetes world, I’ve seen many engineers confuse them with init containers. Both run inside the same pod, but their purpose and behavior are not the same.
Sidecars run alongside your app container and stay alive throughout the pod lifecycle. They share volumes and network with the app and are designed to offload operational work. Real cases I’ve implemented:
A log shipper like Fluent Bit reading app logs from a shared volume and pushing to Loki.
An Envoy proxy sidecar that adds mTLS, retries, and metrics in a service mesh setup.
A backup sidecar that syncs files to S3 every few minutes while the app keeps writing to disk.
The key here is that sidecars are not startup helpers. They are co runners. They support the app at runtime by handling things the app shouldn’t be bothered with.
Kubernetes Sidecar Architecture
To explain the sidecar pattern in depth, I’ve picked service mesh as the example. It’s one of the most real world, high impact use cases where sidecars shine. In a service mesh, the sidecar is usually a network proxy like Envoy, injected into every pod. It works closely with a control plane that handles service discovery, certificates, routing rules, and identity mappings. Here's how it flows in practice.
It starts with namespaces. You typically split responsibilities across two namespaces:
One for application pods with sidecars injected
One for the service mesh control plane
This separation makes security and lifecycle management easier. Your workloads stay isolated, while the control plane operates independently, watching and updating all sidecars.
Inside the app namespace, each pod has two containers.
The app container runs your actual microservice
The sidecar container is the proxy, injected automatically by the mesh
Both containers share:
A network namespace (they communicate over localhost)
A volume mount (used for sharing mTLS certs and tokens)
This setup ensures the sidecar can transparently handle all traffic without changing the app.
The control plane in the mesh namespace drives the system.
Register workloads and track them using a Workload Registry
Issue and rotate certs through a Certificate Issuer
Manage service identity and policy using an Identity Store
The control plane constantly watches for pod events and pushes updates to each sidecar. No manual restarts. No app changes. Everything flows from control to proxy.
Traffic never flows directly between apps.
When service A calls service B:
Service A’s app container sends traffic to localhost
Its sidecar encrypts the traffic with mTLS and forwards it
Service B’s sidecar receives it, decrypts it, verifies identity
Finally, it passes it to B’s app container over localhost
This ensures full encryption, observability, and access control for every call.
Secrets and identity are handled without app logic.
Sidecars receive mTLS material or tokens from the control plane and write them to a shared volume. App containers simply read from that volume (no fetching, no refresh logic, no direct API calls to secret managers). This model enforces least privilege and removes secrets management from app code entirely. With just two namespaces, a shared volume, and a local proxy, Kubernetes sidecar architecture turns each pod into a secure, observable, policy aware unit.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Looking to promote your company, product, service, or event to 50,000+ DevOps and Cloud Professionals? Let's work together.
