Hello,
Apologies for this this is not the correct place to put support questions about specific exam questions. Let me know if there is a better avenue and I will address these there.
In the Ultimate CKA Mock Exam series: mock exam#2 question#7
(from cluster4-controlplane; curl http://kodekloud-pink.app; get a response)
I believe there is an issue with this question. I started a new lab and then went straight to Q7 and followed the solution. It does not work the way intended.
(see pics below for actual output)
ssh into cluster4-controlplane
create the ingress (as is)
run the curl command = expected output
modify the svc (UDP → TCP)
run the curl command != expected output (still 503 error)
change the ingress port 5000 → 80 != expected output (get 200 response)
For my understanding, I want to learn what the intention was to troubleshoot this issue.
In my usual method to TS a connectivity issue that involves a svc & ingress, is to:
validate on the pod the application is accessible
(curl telnet://localhost:5000)
validate on the controlplane the application is accessible through svc
(curl telnet://:5000)
validate on controlplane that application is accessible through the ingress
(curl http(s)://:<port, if applicable>)
The issue I have with the setup of this question, how would/could you validate the pod actually has an application on TCP5000, if the pod does not support netstat, ps, or the pod definition does not even declare the spec.container.port [I know this is purely only for documentation purposes and does not actually expose the port from the image].
At this point, I would assume the information given is the problem and the point of the TS is to figure out which port on the pod is viable and expose that all the way to the ingress.
This question mainly tests the Networking skills required to troubleshoot an application failing to be accessible to users outside the cluster. Which involves, dealing with Services, Ingress, and CoreDNS which handles DNS resolution in Kubernets clusters (this comes into the picture, as we are using Ingress).
I guess you missed the config in pink-pod-cka16-trb Pod, which is in fact exposed on port 80/TCP(screenshot attached). Since it’s exposed on TCP, we can not route the traffic to the Pod via a service on UDP protocol. So, we fix one error there.
Next, as we asked to make the application available via ingress to external users, we create the Ingress resource. As Ingress uses hostnames, and CoreDNS is the component in Kubernetes which handles the DNS resolution, we need to confirm if the coreDNS Deployment is working without any errors. When we inspect the CoreDNS deployments, we see the Deployment has Zero Pods running.
We try to scale the coreDNS Deployment to two, as we have two nodes. after observing for couple of minutes, we can confirm the coreDNS is working. As a result, the curl http://kodekloud-pink.app returns the Welcome page and the question a success.
@Santosh_KodeKloud
I get the point of the UDP → TCP change is needed in the svc side but, there are still a bunch of issues with how to solve this issue.
TL;DR since there is nothing telling me I cannot change things, I can put everything on port 80 and the exam verification gives me a positive [falsely].
The issues stem from a few factors:
no way to verify if the TCP5000 is a false flag or not
If I cannot validate that TCP500 is legit and there is no statement along the lines it is working and cannot be changed, I have to assume this is a false flag.
I can get the controlplane to respond to curl -vv http://kodekloud-pink.app without having any coreDNS pods running
if you change the svc to TCP and change the port on the ingress to 80, then you get a response
suggestions:
re-phrase the TCP5000 part of the question
“The URL is exposed externally to users over TCP/5000”
(this implies the URL path is exposed on that port and you should not expect the end pod to answer on that port) [especially since there is no netstat or anything within the image to verify]
additional note/rule
“the ingress cannot be modified”
(this ensures the user that port TCP/5000 is legit and something will eventually answer on that)
specify the actual response expected
“should get 200 and ‘YOU ARE CORRECT’”
(this will ensure the solution is correct and the above bug mentioned could be left)[assuming without coreDNS working the response is actually coming from a different source]
hopefully this makes sense to ensure the point of the exercise is actually achieved. It is a DNS & svc/network issue, not just a svc/network issue.
