The Best Practices for building Kubernetes Operators say I should write a whole bunch of Operators to manage my application. How does inter-operator communication happen?
In other words, how should I build my Operator so that it can talk to other Operators?
They don't. Not directly, anyways. Communication on Kubernetes occurs purely through YAML files.
For example, if your application requires access to a database, you should install an operator for Postgresql, create a PostgreSQLCluster CR Object, and pull credentials from it once it's setup.
However, this isn't a practical solution in the long term, because Operators should be able to update automatically and without interaction. You are also not allowed to install older versions. To name names, the Crunchy Postgres Operator actually goes through many breaking changes with every update. If you were relying on them maintaining their CRD format, you made your architecture a brittle one.
A few exceptions do exist. Operators for products like Tekton Pipelines and Argo Pipelines are very stable and unlikely to change by design, and it's perfectly OK to depend on these.
Speaking purely towards the best practices, you are supposed to be able to migrate from older to newer versions of your CRD API using webhooks, though it isn't clear that any Operator implementations actually do this. Still, as of writing this post, there are no Operators on OperatorHub.io which rely on other Operators (Feb 16, 2021). Reader, you will be the first.
If you wanted to do so anyway, chances are the Operator you want to depend on is available on the Go package repository. You can just go get them and use their CRD API types natively in your code, which should make it very easy to keep up to date with the API.
Technically, the Operator you want to depend on could implement a REST API in their manager, and expose it as a service. I seriously doubt anybody will ever do this. It doesn't seem smart to poke holes into the Kubernetes design philosophy and open up attack vectors.