DEV Community

Cover image for How Resources Discover Each Other in Kubernetes and AWS
Faizan Firdousi
Faizan Firdousi

Posted on

How Resources Discover Each Other in Kubernetes and AWS

One thing I got to know while working with AWS and learning Kubernetes is that, while building systems at scale, one of the biggest problems is that resources can’t reliably talk to each other using their private IP addresses, even when they are in the same network, whether it’s a VPC or a Kubernetes cluster. Why?

Because IP addresses are unstable in nature. You restart an EC2 instance, and the IP address changes. A pod dies, a new pod starts, and its IP address changes. So the resource you were trying to access using an IP address can become unavailable anytime, and that’s why IP addresses are generally avoided for this purpose.

The solution to that is using service discovery and DNS resolvers.

In Kubernetes, CoreDNS is the internal DNS server, meaning it acts as a nameserver for the cluster and runs as pods inside the cluster itself.

What CoreDNS Does

Suppose you create:

kind: Service
metadata:
  name: backend
Enter fullscreen mode Exit fullscreen mode

Kubernetes automatically tells CoreDNS:

backend.default.svc.cluster.local -> 10.96.0.25
Enter fullscreen mode Exit fullscreen mode

Now any pod can do:

curl http://backend
Enter fullscreen mode Exit fullscreen mode

CoreDNS resolves the name.

Route 53 Resolver in AWS

And if we talk about VPCs in AWS, internal resources are resolved using the Route 53 Resolver, not normal public Route 53 hosting, but a different thing.

It resolves AWS internal hostnames:

ip-10-0-1-15.ec2.internal
Enter fullscreen mode Exit fullscreen mode

Private hosted zones:

db.internal.company
Enter fullscreen mode Exit fullscreen mode

Internal load balancers:

internal-api-alb.amazonaws.com
Enter fullscreen mode Exit fullscreen mode

Every EC2 instance gets access to an internal DNS resolver.

Stay tuned.

Meanwhile, I am going deep into how Services work in Kubernetes.

Top comments (0)