Hi Friends,
I am learning Kubernetes, wishing to attempt the CKA exams soon.
While studying Ingress in the Networking part, a doubt came up.
We are creating Ingress resources in one namespace. THe Ingress Controller resides in another namespace. Did not find anything linking these two in the Ingress resource spec. But as sson as the resource is created it starts working provided the Ingress controller is configured. One of my friends told me it is handled internally by CRD. Kindly share any relevant documentation or notes on the same.
Sorry if its a dumb question
Thanks and Regards
Jayakrishnan
It’s certainly not a dumb question; the way this works requires looking carefully at some non-obvious concepts. There are two labs in our CKA course on Ingress resources and how they work; the first lab concentrates on creating Ingress resources, and the second lab covers how the nginx Ingress Controller works.
The short version is that the Ingress Controller (IC) watches for new Ingress resources using what’s called an admission controller. So when you create an ingress somewhere on your cluster, the admission controller will kick in and process the ingress; this will tell the ingress controller what on the network it needs to watch for (which hosts, which paths) and where to redirect that traffic via the services specified in the ingress.
Hi
Thank you very much rob for the quick response. Understood the point. Have not been able to complete the second lab yet especially with this doubt in mind. So does that mean we need not have multiple ingress controllers of the same type.
But wont it be a problem when we are separating different envs like dev, stag,prod etc using namespaces?
Regards
Jayakrishnan
Think of the IC as an extension of the controlplane. You only need one IC for the whole cluster, generally speaking. But if you wish, you can partition the cluster to have different ICs control different namespaces, since the admission controller is configurable. If you have a local cluster where you have the ingress-nginx IC installed, you can see the default configuration as follows:
k get validatingwebhookconfigurations ingress-nginx-admission -o yaml
There’s a fair amount of configuration in the resource, so I won’t show all of it. But here’s the relevant section:
name: validate.nginx.ingress.kubernetes.io
namespaceSelector: {}
objectSelector: {}
rules:
- apiGroups:
- networking.k8s.io
apiVersions:
- v1
operations:
- CREATE
- UPDATE
resources:
- ingresses
scope: '*'
As configured, it’s grabbing all ingress resources in the cluster. For your use case, you’d need to to have multiple validatingwebhookconfigurations resources, configured to partition the namespaces as you would require. You’d need to get deep into the documentation as to how to configure the resource, but it looks do-able. I suspect that the ingress-nginx docs might have info on how to do this, but I haven’t checked, so YMMV.
Here’s a comment on a relevant issue from the ingress-nginx issue queue. You want to do something like this on each of your validatingwebhookconfigurations to partition your namespaces. NOT FOR THE FAINT OF HEART, I’d guess 
Hi
Thank you very much Rob, will come back with more. 
Regards
Jayakrishnan
Hi
Sorry for coming back again.
I was trying the second lab on CKA course for Ingress. The ingress controller yaml has to be corrected. In the controller yaml file there is a yaml for creating service for the deployment also. As part of the excercie the service name is wrong. Until I corrected that(after checking the solution, hint) the pod for the deployment was failing with error( Back-off restarting failed container controller in pod ingress-nginx-controller-cc9f46d74-k4zvw_ingress-nginx(e67ce1fd-9cfe-4e8c-a7ab-5ac4044ac495)) Once I corrected ie made the service name(changed to same name as that of the deployment) the po started.
I am a bit confused on this, does that mean the service name has to be same as that of the deployment name
Thanks and Regards
Jayakrishnan
I don’t think the service name needs to match the deployment; the deployment doesn’t need to know the service, since the dependency runs the other way: from the port for the nodePort, and from the loadbalancer to the LoadBalancer service if that’s used. The key thing missing in that file is the namespace of the deployment, which is essential.
Hi,
Ok, . But in the question it is mentioned that the Service name has to be ingress-nginx-controller. When I tried with a different name intentionally, the pod for the ingress-nginx-controller fails to start with the following error
Once I corrected the service name and redeployed the service and deleted the pod, a new pod was deployed and it started working as shown below
Events:
Type Reason Age From Message
Normal Scheduled 32s default-scheduler Successfully assigned ingress-nginx/ingress-nginx-controller-cc9f46d74-wxvcv to controlplane
Normal Pulled 31s kubelet Container image “registry.k8s.io/ingress-nginx/controller:v1.1.2@sha256:28b11ce69e57843de44e3db6413e98d09de0f6688e33d4bd384002a44f78405c” already present on machine
Normal Created 31s kubelet Created container controller
Normal Started 30s kubelet Started container controller
Normal RELOAD 29s nginx-ingress-controller NGINX reload triggered due to a change in configuration
controlplane ~ ➜ k -n ingress-nginx get pods
NAME READY STATUS RESTARTS AGE
ingress-nginx-admission-create-mmz4f 0/1 Completed 0 26m
ingress-nginx-controller-cc9f46d74-wxvcv 1/1 Running 0 39s
Sorry for the long mail
Thanks and Regards
Jayakrishnan
Hi Rob,
Sorry the text were not bolded intentionally
Regards
Jayakrishnan
I don’t see why that would be; there’s no setting for it and the liveness and readiness probes do not rely on it. So I’m not sure why that happens.
Hi Rob,
Ok, that could be something unrelated then specific to the lab setup.
Thanks and Regards
Jayakrishnan