That makes sense to me. Perhaps we could add a constructor to KubernetesApiServiceDiscovery that you can provide your own org.apache.pekko.discovery.kubernetes.Settings-like object to instead of relying on the one from the system - would that work in your case?

Yeah that would work, I was only thinking of podNamespace and overloading it to a separate method, but having Settings will give us ability to configure the other options as well

Nice! Would you be up for the challenge of contributing this improvement?

Yes sure

I cannot make changes to the constructor, It has to abide by the ServiceDiscovery constructor for 'DynamicAccess'.

would it be possible to have two constructors, one like the original for 'DynamicAccess' and one that takes a custom Settings?

I tried with defining 'apply' method in the companion object but it doesn't work.

I think this will do, given the lookup is in the same Kubernetes cluster

I tried with defining 'apply' method in the companion object but it doesn't work.

Perhaps if you add this to the class instead of creating an apply method?

  def this(system: ActorSystem) = {
    this(Settings(system))(system)
  }

Yup that worked