As an idea: why not using a central configuration storage (like etcd, redis,..) to synchronize the workers with the gRPC-API, this kind of logic need to be managed by the application itself, in details:

1. when a new worker-pod starts, it register itself on the configuration service
2. when the application gRPC-API requires to establish a new connection, it looks on on the configuration service and the application chooses one: it is up to you to decide which kind of strategy you want to use there, round-robin, random, stickiness,...etc
3. when a worker-pod is then shutted-down, the entry of that destination is removed from the configuration service. To avoid ghost entries, it is probably better in place a custom monitoring tool or that gRPC-API takes the responsibility to check the validity of the destination before start a new connection

This should do the trick that you are looking for.

Maybe this is not possible for your use case, but have you thought about having a service in front of the worker, so instead of subscribing to both workers, you subscribe to one of the two?

If you need to subscribe to both workers, one thing you can do is to use the k8s API client and watch the pod resource with a selector that selects your worker pod (by name, or some other label), and subscribe to it if a new one pops up. That'll probably require you to setup a cluster role and a cluster role binding for the listener pods so they can watch pod resources. This scheme will also allow you to unsubscribe from workers when they die.