I noticed that when I start multiple alphas, my application (conencting via Dgo) only puts load on a single alpha. Having ready the very useful explanation at Load balancing and scaling long-lived connections in Kubernetes I understand this is due to the long-lived connections used by gRPC/HTTP2, i.e. my app connects to a random alpha pod and will continue to use that one pod for all queries.
It seems that a headless service would fix this, as gRPC can natively connect to all pods of a headless service simultaneously, maintain/update the connection pool, and distribute requests across these connections.
There is a headless alpha service by default in your Helm charts, but this is for internal connections only I think. I would therefore like to make the default (9080) service optionally headless also. Alternative is to use a service mesh like LinkerD, but that comes with other considerations and overheads.
Please let me know if this is a sensible choice and I can submit a PR to your Helm repo to make this option templated. I suspect this would also help the liveloader tool as that uses gRPC?
By default, a Kubernetes LoadBalancer service doesn’t do gRPC load balancing. You’ll need to use a different proxy for this (e.g., Envoy, Nginx, Traefik) that supports gRPC load balancing.
@dmai My app runs inside the k8s cluster also, does it make sense to route this traffic through an ingress proxy to DGraph? Seeing the arguments here client side load balancing is more appropriate to my set up I think, especially because performance is critical.