Craig Shea:
I think, according to what I read, that the service used to use an unsecured port (i.e. only the --port parameter). But it has since changed. I already submitted feedback about this lab that it needs some serious updating since the days of k8s 1.16-1.18. I’m glad I was able to help!!
Bukola:
Thanks @Craig Shea I have gone through your thread, so you are saying your lab also was not marked as correct after you did all of these?
Bukola:
Because I also used my scheduler which was not marked as correct in the next question and it worked . Of course because the scheduler pod was actually running
Bukola:
But my curiosity is that the answer file gets marked correctly and I cant still spot the difference between my manifest and the answer file
Craig Shea:
@Bukola So after going through my steps, question 3 will not be detected as correct, so I’m forced to skip past the question. However, as you also saw, it is possible to schedule a pod using that scheduler, and so question 4 is detected as correct. I think the short answer here is that the lab was originally written against an earlier version of k8s. I had taken that lab a few months ago, and the provided answer was the correct solution at the time. What’s different here, is that since this lab was originally written, k8s has switched to using TLS for all scheduler communications–whereas before, this communication was in plaintext over HTTP. That, I think, is where the ultimate failing is at with the lab’s answer. When not using a secure port (--secure-port), the scheduler won’t start. (There may be some option you can pass to override that behavior, but since that’s insecure, I wanted to find a solution that also used TLS protected communications between the kube-api and the scheduler.)
Bukola:
Yes @Craig Shea I noticed in the answerfile it uses http , I was initially using https , but when it was failing i changed it to http and the pod then came up
Bukola:
but I also needed to add --secure-port=0 and --port=10257 else it wont come up and it fails with some liveliness probe failure
Bukola:
I think I found it , I found the missing item hahahahaha . I just compared my answer with the answerfile now and noticed that answerfile has this --scheduler-name=my-scheduler in the command section , which i think explains why it doesnt mark it for me as correct . Am going to try it now and revert
Bukola:
yay , that was it . 
Interesting!!!
Bukola:
@Craig Shea So it is marked for me as correct now after I added the scheduler name to the command
Craig Shea:
@Bukola Interesting, because I did add that parameter, otherwise, other “bad” things happen 
I’ll have to go back and try. 
Glad you got it to work!!
Craig Shea:
Hmm, I think question 3 is not being marked as correct for me is because I left --leader-elect=true and added --lock-object-namespace=kube-system --lock-object-name=my-scheduler, because in a highly available cluster scenario (e.g. more than one master node), you’d want your custom scheduler to be highly available, too, and distributed on other master nodes–but only one should be “active” at a time.
Craig Shea:
Going to try removing those and see if it works…
Craig Shea:
Nope–that wasn’t it. No matter what I do, my scheduler is running and can schedule pods, but question 3 will not be marked as correct.
Craig Shea:
Even switching to use only HTTP (vs. HTTPS) did not change the result. Question 3 does not ever pass for me.
Craig Shea:
I wonder–@Bukola, what version of kube-scheduler are you using? The answer file uses v1.16. But the version deployed on my cluster is v1.19. I wonder if the test is looking for a specific version of the kube-scheduler…guess I’ll try changing the image version…
Craig Shea:
Nope…that wasn’t it either. Oh well. For me, question 3 never passes…but the scheduler is working, as you and I have both observed.
Bukola:
okay let me share my manifest here and you can compare
Craig Shea:
DUH…I know what the problem is…the name of the pod comes up as my-scheduler-controlplane…
Craig Shea:
Definitely…you can see it in my original YAML.