Service-to-Service communication

This topic tells you about service-to-service communication for web and server workloads.

Calling web workloads within a cluster

When a web workload type is created, a Knative service is deployed to the cluster. To access your application, you need the URL for the route created by the Knative Service.

Obtain the URL by running one of these commands:

• To use the tanzu apps command run:

  tanzu apps workload get WORKLOAD-NAME --namespace DEVELOPER-NAMESPACE
  

• To use the kubectl get command run:

  kubectl get ksvc WORKLOAD-NAME -n YOUR-DEVELOPER-NAMESPACE -ojsonpath="{status.address.url}"
  

Note

When calling a Knative service, both the service name and namespace are required. This behavior is distinct from server type workloads, which do not rely on the namespace name to establish service-to-service communication between applications within the same namespace.

Example of service-to-service communication for web and server workloads

You have three applications deployed to the namespace called dev-namespace:

• A server type workload named server-workload
• A web type workload named web-workload
• A pod running the busybox image with curl that is named busybox

Open a shell to the running container of the busybox pod and send requests to the server and web workloads using curl. Specify the namespace for both, as follows:

kubectl exec busybox -n dev-namespace -- curl server-workload.dev-namespace.svc.cluster.local -v
kubectl exec busybox -n dev-namespace -- curl web-workload.dev-namespace.svc.cluster.local -v

You can alternatively reference a web service as workload-name.namespace or web-workload.dev-namespace in this example. You can also reference a server workload that exists in the same namespace as workload-name or server-workload.