This lesson's interactive features are locked, please to keep using them

Namespace and Routing Review

Namespaces are used to separate resources into logical groups. They also impact how internal DNS works.

At Boot.dev, we have all of our production backend services in a namespace, let's pretend it's called "backend". Each time I use kubectl to work with the backend services, I have to specify the namespace:

kubectl -n backend get pods

Internal Routing

Kubernetes makes it really easy for pods to communicate with each other. It does this by automatically creating DNS entries for each service. The format is:

<service-name>.<namespace>.svc.cluster.local

In reality, the .svc.cluster.local isn't needed in most scenarios. If you just use http://<service-name>.<namespace> for the api->crawler communication, it will work. When working in the same namespace, you can even just use http://<service-name>. That wouldn't work for us in our scenario just because the crawler is in its own separate namespace.

Internal Is Better Than External

Unless a service really needs to be made available to the outside world, it's better to keep it internal to the cluster. Internal communications are great because:

It's faster (assuming nodes are close to each other physically)
No public DNS is required
Communication is inherently more secure because it runs on an internal network (usually don't even need HTTPS)

The architecture of SynergyChat is a good example of this. We expose a single JSON API to the outside world, and if the pod that serves those HTTP requests doesn't have all the info it needs locally, it makes internal HTTP requests to other services.