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
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.
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 thatcontroller.ingressClassResource.enabled
is only evaluated to determine whether or not to create theIngressClass
, not whether or not to attach thecontroller.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 anIngressClass
, and attach the controllerValue to the controller:For all other controllers that you want to run with the same
IngressClass
, simply setcontroller.ingressClassResource.enabled: false
, to prevent Helm from trying (and failing) to create theIngressClass
again.