Reachable Services
When the transparent proxy is enabled, Kuma automatically configures each data plane proxy to connect with every other data plane proxy in the same mesh. This setup ensures broad service-to-service communication but can create issues in large meshes:
- Increased Memory Usage: The configuration for each data plane proxy can consume significant memory as the mesh grows.
- Slower Propagation: Even small configuration changes for one service must be propagated to all data planes, which can be slow and resource-intensive.
- Excessive Traffic: Frequent updates generate additional traffic between the control plane and data plane proxies, especially when services are added or changed often.
In real-world scenarios, services typically need access to only a few others, not all services in the mesh. To optimize this, Kuma provides the Reachable Services feature, allowing you to define which services each proxy can connect to. This helps prevent the performance issues mentioned earlier.
Here’s how to configure reachable services:
Use the kuma.io/transparent-proxying-reachable-services annotation to list the services your Pod connects to, separated by commas. For example:
apiVersion: apps/v1
kind: Pod
metadata:
name: demo-client
annotations:
kuma.io/transparent-proxying-reachable-services: "redis_kuma-demo_svc_6379,elastic_kuma-demo_svc_9200"
...
You can update your pods manually or with kubectl:
kubectl annotate pods example-app \
"kuma.io/transparent-proxying-reachable-services=redis_kuma-demo_svc_6379,elastic_kuma-demo_svc_9200"
This configuration ensures that example-app only connects to redis_kuma-demo_svc_6379 and elastic_kuma-demo_svc_9200, reducing the overhead associated with managing connections to all services in the mesh.
Marking a service as not reaching any other service
If you want to indicate that a service should not reach any other service, do not set the annotation to an empty string. An empty value is treated as if no reachable services are configured, meaning the service can access all other services in the mesh.
Instead, use a non-existing service name, such as _noservice_, in the annotation. For example:
apiVersion: apps/v1
kind: Pod
metadata:
name: isolated-service
annotations:
kuma.io/transparent-proxying-reachable-services: "_noservice_"
...
This ensures that the service does not have access to any other services in the mesh while avoiding unintended behavior caused by an empty annotation.