Current situation
Currently, the outcome of the check-apiserver-connectivity command is mainly succeeded or failed:
$ kubectl aks check-apiserver-connectivity --node aks-agentpool-27170680-vmss000000
Running...
Connectivity check: succeeded
$ echo $?
0
$ kubectl aks check-apiserver-connectivity --node aks-agentpool-27170680-vmss000000
Running...
Connectivity check: failed with returned value X: <stderr>
$ echo $?
X
However, in case of failure, the stderr could not be enough to understand what is the issue.
Impact
Output could not provide enough details to the user to understand where to start investigation.
Ideal future situation
When there's a failure, the outcome of check-apiserver-connectivity should be enough to understand, at least, when there is a problem with the DNS and when the API sever is actually unreachable.
Implementation options
Before proceeding with this implementation, find a way to simulate an issue on the DNS and verify what is the stderr of the command we are using to verify connectivity (currently kubectl --kubeconfig /var/lib/kubelet/kubeconfig version).
Current situation
Currently, the outcome of the
check-apiserver-connectivitycommand is mainlysucceededorfailed:However, in case of failure, the
stderrcould not be enough to understand what is the issue.Impact
Output could not provide enough details to the user to understand where to start investigation.
Ideal future situation
When there's a failure, the outcome of
check-apiserver-connectivityshould be enough to understand, at least, when there is a problem with the DNS and when the API sever is actually unreachable.Implementation options
Before proceeding with this implementation, find a way to simulate an issue on the DNS and verify what is the
stderrof the command we are using to verify connectivity (currentlykubectl --kubeconfig /var/lib/kubelet/kubeconfig version).