How to Set Up Internal Service Communication in Kubernetes

Last updated: December 1, 2025

Overview

When services need to communicate within a Kubernetes cluster on Qovery, the approach depends on whether they are in the same namespace (same Qovery environment) or in different namespaces (different Qovery environments).


Same Namespace (Same Qovery Environment)

When services are deployed in the same Qovery environment, they share the same Kubernetes namespace. Communication is straightforward.

How to configure:

  1. Use the built-in variable QOVERY_<SERVICE_NAME>_HOST_INTERNAL which is automatically available for each service

  2. Reference this variable directly in your calling service's environment variables

Example:
If service-a needs to call service-b (both in the same environment):

  • Create an alias variable in service-a: SERVICE_B_HOST = {{QOVERY_SERVICE_B_HOST_INTERNAL}}

  • Your application can then connect to SERVICE_B_HOST on the appropriate port

DNS format (for reference):
<service-name> or <service-name>.<namespace>.svc.cluster.local


Cross Namespace (Different Qovery Environments)

When services are in different Qovery environments, they are deployed in different Kubernetes namespaces. You need to use the fully qualified domain name (FQDN).

DNS format:
<service-name>.<namespace>.svc.cluster.local

How to configure:

  1. Retrieve the service name: Get the value from QOVERY_<SERVICE_NAME>_HOST_INTERNAL on the target service

  2. Retrieve the namespace: Get the value from QOVERY_KUBERNETES_NAMESPACE_NAME on the target service's environment

  3. Create the connection string: In the calling service, create an environment variable combining both values

Example:
If service-a (in env-frontend) needs to call service-b (in env-backend):

  • On service-b, note the values of QOVERY_SERVICE_B_HOST_INTERNAL (e.g., app-z1234567) and QOVERY_KUBERNETES_NAMESPACE_NAME (e.g., z5678-env-backend)

  • In service-a, create a variable: SERVICE_B_HOST = app-z1234567.z5678-env-backend.svc.cluster.local


Important Notes

  • Port configuration: Ensure you're using the internal port configured on your target service (not the external/public port).

  • Testing connectivity: You can verify TCP connectivity using netcat:

  nc -zv <service-host> <port>
  • Same cluster only: This method only works for services deployed on the same Kubernetes cluster.

Important: If your services enforce HTTPS, you'll need to modify your application logic to handle internal traffic differently, as there is no SSL termination for internal Kubernetes communication.