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.

Somehow, it’s free - Sign up to get The Ultimate Claude Code Guide + 200 Free Engineering resources.

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

In Kubernetes, traffic flow is rarely a single hop from client to Pod. A request moving from outside the cluster to a running container passes through several layers, each solving a different piece of the routing problem, and each capable of failing independently of the others.

I've seen teams spend an entire on call rotation chasing a "service unreachable" error that turned out to be a LoadBalancer forwarding correctly into a NodePort that was never actually listening, or a Service selector that silently stopped matching any Pods after a label change. These are not exotic failures. They come from treating "the Service is up" as one fact, when it is really several independent layers that all have to agree.

Let us walk through exactly how each of those layers moves a request.

Internal service discovery in Kubernetes enables Pods within the same cluster to communicate using stable DNS names instead of dynamic Pod IPs.

When a Service is created, Kubernetes assigns it a virtual IP (ClusterIP) and registers it with CoreDNS for name resolution.

Each time a Pod calls another service, the DNS name resolves to this virtual IP. The Service then forwards the request to one of the Pods that match its selector. This creates a consistent routing layer that hides Pod restarts or rescheduling across nodes.

In this setup, applications interact with other services using simple hostnames rather than managing IPs manually. The Service object maintains the endpoint list and handles load balancing automatically within the cluster.

Works well for most internal communications but comes with a few trade offs:

Applications inside Kubernetes often need to talk to resources that are not part of the cluster, such as managed databases, third-party APIs, or external services maintained by other teams. External service discovery handles this outbound communication.

When a Pod makes an outbound request, Kubernetes can map a DNS name to an external IP or hostname using ExternalName Services. These act as lightweight aliases, redirecting traffic to the actual external system.

For example, a service named payments can point to payments.example.com, and applications inside the cluster can connect using http://payments.

For direct connections, Pods can also reach external IPs through standard egress routes or dedicated gateways. In production environments, network policies or egress controllers are often applied to control outbound access and enforce security rules.

This model is essential for hybrid setups, but it introduces specific considerations:

Always verify how your cluster connects to external systems. Small network or DNS misconfigurations often surface as service discovery failures.

With this basic understanding, let us now move into the real world service discovery patterns used in most production environments.

A NodePort Service in Kubernetes allocates a static TCP or UDP port on every node in the cluster, usually within the range 30000 to 32767. This port acts as an external entry point that forwards traffic to the Pods backing the Service.

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