Feature request: add support for multiple Ingress definitions

[myk0la-b]

Feature request

What would you like to be added?
I’d like the Portainer Helm chart to support defining multiple Kubernetes Ingress resources, so operators can, for example, have both HTTP (port 8000) and HTTPS (port 9443) Ingresses—or multiple host-based Ingresses—without having to deploy the chart twice.

Why is this needed?
Currently the chart’s values.yaml only allows a single .ingress block. In environments where you need separate listeners, SSL redirect rules, path mappings, or distinct hostnames, maintaining two separate releases of the chart is cumbersome and error-prone.

Proposed Values API
Extend values.yaml from:

ingress:
  enabled: false
  annotations: { … }
  hosts:
    - host: chart-example.local
      paths:
        - path: /
          pathType: Prefix

to something like:

ingresses:
  - name: portainer-http
    enabled: true
    annotations:
      kubernetes.io/ingress.class: alb
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":8000}]'
      alb.ingress.kubernetes.io/backend-protocol: HTTP
    hosts:
      - host: portainer.example.com
        paths:
          - path: /
            pathType: Prefix

  - name: portainer-https
    enabled: true
    annotations:
      kubernetes.io/ingress.class: alb
      alb.ingress.kubernetes.io/certificate-arn: <YOUR_CERT_ARN>
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":9443}]'
      alb.ingress.kubernetes.io/backend-protocol: HTTPS
      alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS-1-2-2017-01
    hosts:
      - host: portainer.example.com
        paths:
          - path: /
            pathType: Prefix

Acceptance criteria

• Values schema supports a top-level ingresses array

• Each entry renders its own Ingress resource named {{ .Release.Name }}-{{ .Values.ingresses[i].name }}

• Backward-compatibility: if ingresses is unset but ingress is present, chart behaves as it does today

Additional context
This would allow a single Helm release to manage multiple ALB listeners (or other controllers) cleanly, without duplicating values or releases.

[blackoutnet]

+1

[MarkhamLee]

+1 on this. Anyone who is deploying this primarily to manage edge devices/environments will need two separate ingresses, so not being able to define two in the chart makes things a bit cumbersome to manage.