kubernetes: apiserver errors should include reason
/kind feature
What happened: Spend too much time figuring out that my apiserver didn’t start because the etcd DNS name couldn’t be resolved. I got the following error:
Error: error waiting for etcd connection: timed out waiting for the condition
And even --v=10 didn’t provide any more context. This was very misleading and made me assume the issue is on application level.
What you expected to happen: I expected the apiserver error to tell me that DNS resolution wasn’t working.
How to reproduce it (as minimally and precisely as possible):
I used the bootkube manifest but just starting the apiserver with --etcd-servers pointing to a nonexisting name.
About this issue
- Original URL
- State: open
- Created 7 years ago
- Reactions: 1
- Comments: 18 (10 by maintainers)
I’ve opened a PR for this. Could use a review
I’m commenting here only to give my +1 to the underlying issue, that the error message emitted by the apiserver is not sufficient to begin debugging related problems.
I’m seeing the same error message, my experimental configuration is quite different, but it would be more pleasing if the apiserver told me clearly why it cannot talk to an etcd cluster, where it thinks that etcd cluster is, and so on.
Okay, I’ll add another issue to the 784 issues already open. 😆 👍