Question about Ingress: Is there anything that connects an Ingress controller an . . .

Kubernetes-Slack Discussions
#1

ReynO:
Question about Ingress: Is there anything that connects an Ingress controller and Ingress resources?
What happens if I just deploy an Ingress resource without the controller? Or vice versa?

#2

Anurag Kumar:
Hey @ReynO
If you’ll deploy ingress resource without the controller then nothing will happen in the cluster. It’s the controller who does the job of say creating a loadbalancer in the cloud for routing traffic to the backend services.

If you’ll install the controller and don’t deploy any resources then also nothing will happen. In this case, a ingress controller being a controller keeps looking for new ingress resources that are being created in the cluster. If no ingress resource is getting created then there’s not any object on which the controller can act. Ideally the current state is equal to the desired state so the controller will be running idle waiting for new ingress resource.

#3

ReynO:
Thanks :+1: Couple more questions:

• If I were to deploy my own ingress controller manually, is there any extra configuration to add so that it is able to listen to any ingress resources being created?
• Also, if I were to lets say accidentally create 2 ingress resources that both have the same path to a particular service, will the controller throw an error when traffic is being redirected to backend services since there are duplicate rules?
• Along with that train of thought, what if I created 2 ingress controllers and multiple ingress resources? How does each controller know which resource to act on?

#4

Alistair Mackay:

  1. You’ll normally deploy an ingress controller form a helm chart. There are many configuration options, so installing from raw manifests really isn’t practical.
  2. Not sure - haven’t tried it. If the controller is smart enough, it should notice this when the resource is being created and cause kubectl to fail and print an error. Go to the lab where you have to create the wear/watch ingress. Get it up and running so that you can browse the sites, then make a copy of the ingress yaml, change the name property, and deploy that. See what happens.
  3. By using ingressClassName in the resource to select the controller to use. Again, in the lab, if you examine the ingress controller pod’s yaml, you’ll see it has a corresponding argument in the pod of --ingress-class-name. That tells the controller what ingressClassName to look for when resources are created.
#5

Anurag Kumar:
> If I were to deploy my own ingress controller manually, is there any extra configuration to add so that it is able to listen to any ingress resources being created?
No by default when you install any ingress controller then you don’t have to do anything on your end. Most often ingress controller will create a loadbalancer under the hood and you’ll have to take the loadbalancer IP and create say an A record in your DNS provider.
> • Also, if I were to lets say accidentally create 2 ingress resources that both have the same path to a particular service, will the controller throw an error when traffic is being redirected to backend services since there are duplicate rules?
I think it doesn’t matter, it’s the loadbalancer who’s responsible for spilling the traffic. So once the loadbalancer gets the request it will send it to the backend service. If there are two resource with different names then also the traffic is going to the backend service and that’s what matters.
> • Along with that train of thought, what if I created 2 ingress controllers and multiple ingress resources? How does each controller know which resource to act on?
>
As mentioned above, you use ingressClassName under spec to choose which ingress should handle the logic part.
In ingress-nginx we define something like this.

spec:
  ingressClassName: "nginx"