@sftim, the change is okay, though, the semantics seem a bit off to me. Can you clarify what upon this API vs `build an Operator to interface with [what API]?

Maybe it's easier to remove the example? It looks like I saved some unfinished work here, and I don't remember what point I wanted to make.

Here is the current version:
You can use a headless Service to interface with other service discovery mechanisms, without being tied to Kubernetes’ implementation. For example, you could implement a custom [Operator]( be built upon this API.

• I think the original idea is suggesting that the custom Operator handles: load balancing, proxying, DNS configuration for this service, but I may have misinterpreted the concept.

I re-rewrote the text to clarify a bit.

If that's not helping, what do people think about chopping out the example instead?

hello @sftim .
I reread the section. A few nits and suggestions.

• hyphenate load-balancing or not?
• What does this phrase mean, without being tied to Kubernetes' implementation.? Implementation of what?
• line 454, Is it reasonable to double quote, "A record"? Also, link to https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#a-records
• Should Services be bold, if so, be consistent
• bold kube-proxy?
• I think line 436 could be broken down and made into a list:

  Limitations of Headless Services:

  • a cluster IP is not allocated
  • kube-proxy is not in use
  • Kubernetes does not perform load balancing
• line 443, should it be Endpoints Controller instead of endpoints controller?

Whilst that's legitimate feedback, I'd like to get this 3-line change done now and have another PR take care of bigger fixes.

Okay -- your intention is to just clean up the reference to Operators.