docs(core-concepts): write the service discovery page

[whg517]

Summary

Third batch of stage 2. One page, both language trees — it was a one-line placeholder.

Independent of #38 and #39: all three branch off main and touch different files. Any merge order works.

Two mechanisms share this heading, and the page separates them rather than blurring them together:

• Exposing a product — ListenerClass, Listener
• Finding one product from another — discovery ConfigMaps

Sources: operator-go's pkg/apis/listeners/v1alpha1 and pkg/listener for the listener half; zookeeper-operator's cluster_extension.go and common/discovery.go plus hdfs-operator's ClusterConfigSpec for the discovery half.

The listener half

Documents the three built-in classes and — prominently — that external-unstable is NodePort, not a LoadBalancer with a changing address:

Class	Service type	Address stability
cluster-internal	ClusterIP	Stable, cluster-only
external-unstable	NodePort	Tied to the node the pod runs on
external-stable	LoadBalancer	Survives rescheduling

ServiceTypeFor's own comment records that two operators in this project drew opposite conclusions from an earlier wording, so the page states the mapping plainly instead of leaving it to be inferred from the name.

Also covers:

• An unrecognised or empty class falls back to ClusterIP by design — a typo should not produce an accidental public address
• The preferredAddressType rule (HostnameConservative uses an IP only for NodePort)
• Why publishNotReadyAddresses defaults to true — a quorum cannot form if members cannot find each other before they report ready
• The CSI volume (listeners.kubedoop.dev StorageClass, class / listenerName annotations) through which a pod learns its own published address

The discovery half

Documents the actual keys ZooKeeper publishes (ZOOKEEPER, ZOOKEEPER_HOSTS, ZOOKEEPER_PORT, ZOOKEEPER_CHROOT), that a cluster always emits a ConfigMap at the root znode and adds a <cluster>-nodeport variant when the listener class is external-unstable, how a consumer references it by ConfigMap name rather than hostname (so ZooKeeper can move without editing the HDFS resource), and why a ZookeeperZnode is the right way to give each product its own subtree.

Testing

• npm run verify exits 0 — 52 files linted with 0 errors, both locales built
• Page renders in both locales (spot-checked external-unstable in the build output)
• Relative links resolve — onBrokenLinks: 'throw' would have failed the build otherwise
• en/zh trees still mirror 1:1

Remaining stage 2 placeholders

7 left: kubernetes, kubebuilder, develop-guideline, spark-k8s-operator, faq, release-notes, and database (blocked — see #38).

faq and release-notes cannot be derived from source: one needs real user questions, the other needs release history. Those need maintainer input rather than research.

🤖 Generated with Claude Code