Hide Forgot
The kube-scheduler was never secure, but we noticed during the rebase. It should be secured.
Ravi, you might send this over to Stephan if he is the one doing the work for it
https://github.com/openshift/cluster-kube-scheduler-operator/pull/77
Let's ignore that /healthz is running on both secure and insecure ports. The important things is that the secure port is an option now and only the /healthz endpoint is on the insecure port. I would move to VERIFIED, but back to ON_QA in case there are any other questions.
Thanks for explaining, I do see it is listening on both 10251 & 10259. $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.1.0-0.nightly-2019-04-25-002910 True False 21h Cluster version is 4.1.0-0.nightly-2019-04-25-002910 # netstat -lnptu | grep -e PID -e 10250 -e 10251 -e 10259 Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp6 0 0 :::10250 :::* LISTEN 1017/hyperkube tcp6 0 0 :::10251 :::* LISTEN 24711/hyperkube tcp6 0 0 :::10259 :::* LISTEN 24711/hyperkube # ps alxwww | grep -e PID -e 1017 -e 24711 -e 10259 F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 4 0 1017 1 20 0 2000220 204948 - Ssl ? 85:33 /usr/bin/hyperkube kubelet --config=/etc/kubernetes/kubelet.conf --bootstrap-kubeconfig=/etc/kubernetes/kubeconfig --rotate-certificates --kubeconfig=/var/lib/kubelet/kubeconfig --container-runtime=remote --container-runtime-endpoint=/var/run/crio/crio.sock --allow-privileged --node-labels=node-role.kubernetes.io/master,node.openshift.io/os_version=4.1,node.openshift.io/os_id=rhcos --minimum-container-ttl-duration=6m0s --client-ca-file=/etc/kubernetes/ca.crt --cloud-provider=aws --volume-plugin-dir=/etc/kubernetes/kubelet-plugins/volume/exec --anonymous-auth=false --register-with-taints=node-role.kubernetes.io/master=:NoSchedule 4 0 24711 24698 20 0 1074216 120120 - Ssl ? 15:50 hyperkube kube-scheduler --config=/etc/kubernetes/static-pod-resources/configmaps/config/config.yaml --cert-dir=/var/run/kubernetes --port=0 --authentication-kubeconfig=/etc/kubernetes/static-pod-resources/configmaps/scheduler-kubeconfig/kubeconfig --authorization-kubeconfig=/etc/kubernetes/static-pod-resources/configmaps/scheduler-kubeconfig/kubeconfig --feature-gates=ExperimentalCriticalPodAnnotation=true,LocalStorageCapacityIsolation=false,RotateKubeletServerCertificate=true,SupportPodPidsLimit=true -v=2 --tls-cert-file=/etc/kubernetes/static-pod-resources/secrets/serving-cert/tls.crt --tls-private-key-file=/etc/kubernetes/static-pod-resources/secrets/serving-cert/tls.key
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:0758