SysbeeTech / kubedeploy

Kubedeploy
https://kubedeploy.app/
Apache License 2.0
5 stars 2 forks source link

Allow multiple ingress objects #23

Closed criskurtin closed 9 months ago

criskurtin commented 10 months ago

Currently only single ingress object can be defined without using the extraObjects field and defining raw manifests. ingress field should be an array instead, in order to natively support defining multiple ingresses.

Expected Behavior

ingress:
  - enabled: true
    className: "haproxy-public"
    hosts:
      - host: api.example.com
        paths:
          - path: /
    tls:
      - secretName: api
        hosts:
          - api.example.com
  - enabled: true
    hosts:
      - host: api-internal.example.com
        paths:
          - path: /
    tls:
      - secretName: api-internal
        hosts:
          - api-internal.example.com

Result of this configuration should be two ingress manifests.

Current Behavior

Currently, the ingress field does not support specifying an array of objects. Only single ingress object can be specified instead:

ingress:
  enabled: true
  hosts:
    - host: api-internal.example.com
      paths:
        - path: /
  tls:
    - secretName: api-internal
      hosts:
        - api-internal.example.com

Possible Solution

ingress.yaml template should iterate through specified array elements and use the already implemented templating logic to generate individual ingress manifests. Sort of a combination between extra-objects.yaml with range function and the existing ingress.yaml template.

Context

This would be useful if multiple ingresses should be defined. For example, most of the service endpoints might only be available to the internal network (using the haproxy default ingress controller), while the endpoints prefixed with /public might need to be exposed through the haproxy-public ingress controller. At the moment, the solution is a bit clumsy and requires specifying one of the above as a raw manifest.

Your Environment

btoic commented 9 months ago

Unfortunatly, changing the existing ingress value to accept list of Ingress objects will not be possible as this would brake the backwards compatibility promisse between major chart versions.

I've added the extraIngress configuration option in related PR #24 that will be included in 1.2.0 version. Full feature documentation is available in values.yaml and on website https://kubedeploy.app/start/values/extraingress.html

If you wish to do some early testing, the release candidate version that will include all the 1.2.0 milestone features is available in pre-release repository:

helm repo add sysbee-release https://charts.sysbee.io/release/sysbee
helm repo update

Feel free to re-open this issue if you encounter any errors with extraIngress config