skip to Main Content

Is it possible to run multiple IngressController in the same Namespace with the same IngressClass?

I have multiple IngressController with different LoadBalancer IP Addresses and would like to continue with this setup.

I upgraded the first IngressController to the latest version.
Updating the second/third/.. IngressController fails because of:

rendered manifests contain a resource that already exists. Unable to continue with update: IngressClass "nginx" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "nginx-ingress-lb-02": current value is "nginx-ingress-lb-01"

Any idea how to fix this?

2

Answers


  1. The issue you mention here is mainly with Helm, preventing you from overwriting some resources – your IngressClass – that belongs to another helm deployment.

    One way to work around this may be to use helm "–dry-run" option. Once you have the list of objects written into a file: remove the IngressClass, then apply that file.

    Another way may be to patch the chart deploying your controller. As a contributor to the Traefik helm chart, I know that we would install IngressClasses named after the Traefik deployment we operate. The chart you’re using, for Nginx, apparently does not implement support for that scenario. Which doesn’t mean it shouldn’t work.

    Now, answering your first question, is it possible to run multiple IngressController in the same Namespace with the same IngressClass: yes.

    You may have several Ingress Controllers, one that watches for Ingresses in namespace A, another in namespace B, both ingresses referencing the same class. Deploying those ingresses into the same namespace is possible – although implementing NetworkPolicies, isolating your controllers into their own namespace would help in distinguishing who’s who.

    Login or Signup to reply.
  2. An options that works for me, when deploying multiple ingress controllers with Helm, is setting controller.ingressClassResource.enabled: false in every Helm deployment, except the first.

    The comments in the default values.yaml aren’t entirely clear on this, but after studying the chart I found that controller.ingressClassResource.enabled is only evaluated to determine whether or not to create the IngressClass, not whether or not to attach the controller.ingressClassResource.controllerValue to the controller. (This is true at least for helm-chart-4.0.13).

    So, the first Helm deployment, if you don’t override any of the default controller.ingressClassResource settings, the following values will be used to create an IngressClass, and attach the controllerValue to the controller:

    controller:
      ingressClassResource:
        name: nginx
        enabled: true
        default: false
        controllerValue: "k8s.io/ingress-nginx"
    

    For all other controllers that you want to run with the same IngressClass, simply set controller.ingressClassResource.enabled: false, to prevent Helm from trying (and failing) to create the IngressClass again.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search