chinmoysahu opened a new issue, #810:
URL: https://github.com/apache/solr-operator/issues/810
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](https://kubernetes.io/blog/2025/11/11/ingress-nginx-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:
```yaml
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):
```yaml
# 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
```
```yaml
# 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
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
