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.

The AI tool you tried last quarter waited for a prompt, hallucinated a number, then asked if you'd like a summary.

Viktor opened a PR at 2am, rebased it against main, ran your test suite, and posted a note in #eng: "Two flaky tests in payments service, both pre-existing. Recommended merging after fixing them." Then drafted the customer reply for the support ticket the bug created.

That's 619K autonomous actions per day across 20,000+ teams. Not chat replies. Real work shipped to GitHub, Stripe, Linear, Notion, and 3,000+ other tools, from inside Slack and Microsoft Teams.

You don't supervise him any more than you supervise a senior engineer.

SOC 2 certified. Your data never trains models.

"It's what you probably originally thought AI was going to be when you first heard of it in sci-fi movies." Tyler, CEO.

Get Started for Free

Powered by: Jobsurface.com

Browse 665 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

Pods in a Kubernetes cluster communicate with each other constantly.

None of these callers hardcode IP addresses, because pod IPs are ephemeral, they change every time a pod restarts or gets rescheduled.

Kubernetes solves this with an internal DNS system that assigns stable, predictable hostnames to Services, so callers can use names instead of IPs and keep working regardless of what happens to individual pods underneath.

Knowing exactly how that DNS system works, what names it creates, and when it does and does not create records for pods directly, saves a significant amount of debugging time when services cannot reach each other.

When you create a Service in Kubernetes, the cluster DNS system automatically creates a DNS record for it.

The record maps the Service name to its ClusterIP, the stable virtual IP that Kubernetes assigns to the Service. That ClusterIP does not belong to any individual pod. It belongs to the Service itself, and kube-proxy on each node routes traffic arriving at that IP to one of the healthy pods behind it.

The DNS record points to the Service's ClusterIP, not to any of the backing pods. If a pod restarts and gets a new IP, the Service record does not change. The Service itself is stable, and the DNS record reflects that stability. This is the whole point of the Service abstraction, it decouples callers from the lifecycle of individual pods.

When a pod calls another service in the same namespace, the shortest form of the DNS name works: just the Service name itself. A pod in the default namespace calling the web Service can use http://<service_name> and the cluster DNS resolves it to the Service's ClusterIP.

This works because each pod's /etc/resolv.conf is pre configured by the kubelet with a set of DNS search domains, including default.svc.cluster.local for pods in the default namespace. When a pod queries the name web, the DNS resolver appends the search domain and queries web.default.svc.cluster.local, which the cluster DNS answers with the Service's ClusterIP. The pod never sees this expansion, it just gets back an IP.

Pods in different namespaces cannot resolve each other's services by short name alone. The search domains configured in a pod's /etc/resolv.conf only include that pod's own namespace. A pod in the default namespace with the search domain default.svc.cluster.local will not find a service in the other namespace when looking up web, because it will try to resolve web.default.svc.cluster.local, which does not exist in the other namespace.

To reach a service in another namespace, the caller must include the namespace in the name.

Kubernetes DNS supports three levels of specificity for cross namespace resolution, all of which resolve to the same ClusterIP.

The fully qualified domain name web.other.svc.cluster.local is always unambiguous and works from any namespace in the cluster. The shorter forms web.other and web.other.svc also work in practice because the DNS resolver appends svc.cluster.local via search domain expansion.

Using the full FQDN in configuration files is the safer choice, it makes the target namespace explicit and avoids any edge cases with search domain ordering.

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