[WalBeh]

Summary of changes

In-cluster clients don't need a cloud load balancer, but loadbalancer (the default) always requests one, and traefik needs externalDNS plus Traefik CRDs. clusterip serves the data Service as a plain ClusterIP. Exposure switches reuse the in-place Service patch, so the #851 NLB cleanup still applies. Resume only waits for an LB address with loadbalancer, otherwise a clusterip cluster would never resume. Suspend keeps a clusterip Service: it costs nothing, and recreating it would change the ClusterIP that in-cluster clients may have cached.

Checklist

• Link to issue this PR refers to: Feature request: ClusterIP-only exposure without LoadBalancer or ingress resources #918
• Relevant changes are reflected in CHANGES.rst
• Added or changed code is covered by tests
• Documentation has been updated if necessary
• Changed code does not contain any breaking changes (or this is a major version change)

[WalBeh]

Known gaps, not addressed here:

• loadbalancer → clusterip: the external-IP webhook ignores the address going away, so webhook consumers keep the old LB address (same as loadbalancer → traefik today).
• With grandCentral.exposure unset, a clusterip cluster still gets a public nginx Ingress for grand-central. Cloud-only; a follow-up makes that mapping explicit.
• Resume with clusterip is covered by a unit test only: test-mode get_host needs an LB address, so the e2e tests can't connect to a ClusterIP cluster.

[itenev]

Thanks for explicitly documenting the ClusterIP test-harness limitation above. Our review of commit38d0f3191403d3f6ceb280abc09daae4ced0ca7f confirms the distinction: TESTING=True falls through to the LoadBalancer-address lookup, while normal in-cluster operation uses discovery DNS. We therefore regard this as a known test-coverage limitation, not a production defect. Would you prefer to track support for ClusterIP connectivity in the external e2e harness as a separate follow-up? Our planned EKS verification will run the operator in-cluster and cover ClusterIP connectivity and suspend/resume; those live checks have not run yet.

[WalBeh]

Yes, a separate follow-up. Production connections don't depend on the exposure: get_host always returns the headless crate-discovery-<name> service, and #920 has a unit test for that. A harness test would mainly guard the test-mode branch. Our e2e suite runs the operator in the pytest process outside the test cluster, so it can only reach CrateDB through a public LB address; a ClusterIP test needs a port-forward or a test-only LB service. Tracked in #923. The full integration suite passed on the current head. Your in-cluster EKS run is the more useful check; please post the results here when you have them.

[tomach]

LGTM! 👍