Yes this causes overhead; every microservice will have a public API of sorts that will need to be documented and communicated, and any other service consuming it will need to eventually be updated to keep up with changes. If this overhead is not something your organization can afford, you should not be doing a microservices architecture.
Except is is. Microservice doesn't mean distributed setup. For the first problem, yes service running in multiple pods causes issues, but even monolith could face the same issue. Statefulset based microservices not only exists, but is a pretty common setup. Also I would even call multiple container on the same pod as microservice, which basically solves all of the problem.
There are many ways to solve second problem. Some folks create different API version. I prefer different deployment.
Last is a problem for monolith. I know of big companies where compile time is in order of an hour for monolith, even for small change.
- distributed systems problems - think consistency and ACID
- increased refactoring complexity - you now have to change the api three times instead of 1 to deploy the change with 0 downtime
- requirements for more generic CI/CD pipelines - you will develop many microservices, it's important to do it fast
it's not "just" a network rpc, even technically