Add optional Gateway API support for SolrCloud external addressability

[chinmoysahu]

Today, the Solr Operator supports solrAddressability.external.method=Ingress and ExternalDNS to make SolrCloud instances externally addressable. When method=Ingress and hideNodes=false, the operator:

• Creates a common Service for the SolrCloud
• Creates a per-node Service for each pod (when needed)
• Generates an Ingress with:
  • One host pointing to the common Service
  • Additional hosts (one per node) pointing to the corresponding node Services
• Keeps the Ingress rules in sync as SolrCloud nodes are added/removed

With the retirement of the community ingress-nginx controller and the CNCF push towards Gateway API, it would be helpful if the Solr Operator could optionally use Gateway API resources instead of an Ingress, while preserving the existing addressability setup.

---

Proposal (high level)

• Extend SolrCloud.spec.solrAddressability.external.method to support a new value, e.g. Gateway, alongside the existing Ingress / ExternalDNS.

• Add a new configuration block for Gateway settings, for example:

  spec:
    solrAddressability:
      external:
        method: Gateway
        domainName: <domain-prefix>.example.com
        hideNodes: false
        nodePortOverride: 443
        gateway:
          gatewayRef:
            name: shared-gateway
            namespace: infra
            sectionName: https

• When method=Gateway:

  • The operator continues to create the same common and per-node Services as it does for method=Ingress.
  • Instead of an Ingress, the operator creates Gateway API HTTPRoute resources:
    • One HTTPRoute for the “cluster” hostname (ex. <>-common) -> common Service
    • If hideNodes=false, one HTTPRoute per node hostname -> corresponding node Service
  • These HTTPRoute resources are kept in sync with the SolrCloud’s replica count and lifecycle, similar to how the Ingress is today.

• The operator assumes the referenced Gateway already exists and is managed by the platform/infra team. It only manages the child HTTPRoute objects.

Example generated resources (conceptual):

# Cluster entrypoint route
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: solr-cloud-common
namespace: solr
spec:
parentRefs:
  - name: shared-gateway
    namespace: infra
    sectionName: https
hostnames:
  - solr-cloud.example.com
rules:
  - backendRefs:
      - name: solr-cloud-common
        port: 80

# Per-node route (when hideNodes=false)
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: solr-cloud-node-0
namespace: solr
spec:
parentRefs:
  - name: shared-gateway
    namespace: infra
    sectionName: https
hostnames:
  - solr-cloud-node-0.example.com
rules:
  - backendRefs:
      - name: solr-cloud-node-0
        port: 443

---

Questions for maintainers

• Does the above API shape for external.method=Gateway and gateway.gatewayRef align with how you’d like to model Gateway support?
• For hideNodes=false, would you prefer:
  • (a) One HTTPRoute per node hostname, or
  • (b) A single HTTPRoute with multiple hostnames and rules?
• Would you consider an initial implementation that targets HTTPRoute only (HTTPS on a shared Gateway), with TCPRoute / advanced features as follow-ups?

Motivation

I’m running SolrCloud in Kubernetes with the Solr Operator and currently rely on an nginx-based Ingress for external access. As the Kubernetes community moves toward the Gateway API model for ingress across platforms, having first-class Gateway API support in the Solr Operator would make that transition much smoother and more future-proof.

I am interested in contributing to a potential implementation. If the general direction of this proposal is acceptable, I would be happy to help with a draft pull request