Is your feature request related to a problem?

I'm frustrated that the Helm chart only supports a single ingress for the entire cluster (cluster.ingress.opensearch), with no way to route traffic to specific node pools.
In production, master nodes should not receive client traffic - they need to focus on cluster state management. Both AWS and Elastic recommend this separation:

• AWS: "Master instances do not directly receive any traffic that you send to Amazon ES."
• Elastic: "Configure all master-eligible nodes to be dedicated master-eligible nodes which only have the master role."

Currently, I have to create separate Ingress resources outside the Helm chart to expose only data/coordinating nodes, which breaks GitOps workflows.

What solution would you like?

Add the ability to configure ingress per nodePool, or allow specifying target nodePools in the existing ingress configuration.

Option A: Per-nodePool ingress

cluster:
  nodePools:
    - component: data
      roles: ["data"]
      ingress:
        enabled: true
        className: "alb"
        hosts:
          - host: opensearch-data.example.com

Option B: Target nodePools in cluster ingress

cluster:
  ingress:
    opensearch:
      enabled: true
      targetNodePools: ["data", "coordinating"]
      hosts:
        - host: opensearch.example.com

What alternatives have you considered?

• Manually creating Ingress resources targeting nodePool-specific services (e.g., my-cluster-data). This works but requires managing resources outside the Helm chart.
• Using a service mesh to control traffic routing, but this adds unnecessary complexity for a simple routing requirement.

Do you have any additional context?

• The operator already creates separate Services per nodePool, so the backend infrastructure is already in place.
• This aligns with the recent addition of dedicated coordinator nodes (Enable coordinator nodes #1200), which are typically the preferred target for client traffic.