Finding an optimum solution can often be a moving target as a project evolves but I can share some points to be aware of. As you suggest, if your services are all inside Kubernetes and have a ClusterIP then they will be automatically load-balanced. 'Headless' services or external services, from outside the cluster, would not. So if you have those then you could consider ribbon for doing the load-balancing inside the services. There is an implementation that uses kubernetes for discovery if you decide against eureka. Ribbon has the advantage of working with hystrix so you could then do rate-limiting in addition to load-balancing.

There are also more sophisticated options available within the kubernetes ecosystem. You can have services of type LoadBalancer or use Ingress but these tend to be used for external exposure whereas I think your question is more about service-to-service communication. Another way of addressing these concerns would be to use a service mesh and Istio is gaining a lot of attention in the Kubernetes space. You could use it to address service-to-service load-balancing and rate-limiting and also provide a gateway/s.

Using a kubernetes-native approach or mesh would have the advantage of doing this in a language-neutral way. If you needed ribbon/hystrix in your services and then wanted to add a python-based service you'd have to think about how to get consistent behaviour.

I'd suggest that you be sure to consider what you and your team finds easiest to work with. There are a lot of options and nuances and it is good to be aware of them but you may find that you don't need anything fancy.