Connecting two applications inside your cluster

What this is

How to get two of your own applications talking to each other inside the same cluster. For example, a web front end that needs to call an API service you are also running.

Before you start

You need two applications deployed and running in your cluster. See Deploying your first application, and do it twice.

Confirm both pods are actually running before you try to connect them, because a connection failure and a stopped pod look identical from the outside. See Reading logs and events to debug your app.

Why not just use the public endpoint

If your application already has a public endpoint, you could point one service at the other's public address. It works, and you should not do it.

Traffic leaves the cluster, crosses the public internet and comes back in. That adds latency, exposes internal traffic that had no reason to be public, and breaks if the public address changes. Internal connections stay inside the cluster.

How it works

Services inside a cluster reach each other through the cluster's internal networking rather than through public addresses. You do not hardcode an IP address, because pod addresses change every time a pod is replaced, which happens routinely.

Instead you declare the connection on the container specification. Add the network entry there and your service becomes reachable by its service name inside the cluster.

Step 1. Deploy your first application, for example an API service.

Step 2. Deploy your second application, for example a web front end.

Step 3. On the container specification, add the network entry that maps the service you want to reach.

Step 4. In your application configuration, refer to the other service by its service name rather than by an IP address.

Step 5. Deploy and test the call from one application to the other.

Screenshot needed: container specification showing the network and service mapping entry.

Content pending: the exact service mapping configuration, including the precise field to set and a worked example of the entry, is being confirmed from the ByteDC platform team's own end to end test of two communicating applications. This page is written from that test rather than from theory, so the specific configuration block is added once the test findings are documented.

What you should see when it works

Your front end can call your API service by name from inside the cluster. The call does not leave the cluster, and it keeps working after either pod is replaced or the deployment is scaled, because you referred to a service name rather than an address.

Common problems

The connection is refused. Confirm the target application is running and listening on the port you are calling. Check the target's own logs, because an application that has not finished starting up refuses connections in exactly this way.

It works and then stops working. This is the signature of a hardcoded IP address. Pod addresses change when pods are replaced, so refer to the service by name.

The name does not resolve. Confirm the network entry is present on the container specification, and confirm both applications are in the same namespace. Cross namespace access is not something you can arrange yourself on a shared plan, because the namespace boundary is the tenant isolation boundary.

I want to connect to a service in a different cluster. That is a different problem to this guide. Raise it with ByteDC rather than working around it, because the shared plans isolate by namespace.