apiserver errors should include reason

[discordianfish]

/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.

[discordianfish]

@kubernetes/sig-cluster-ops

[zhangxiaoyu-zidif]

/area apiserver

[xiangpengzhao]

maybe
/sig api-machinery
also.

[mml]

/assign @jpbetz cc @mml

[k8s-ci-robot]

@mml: GitHub didn't allow me to assign the following users: jpbetz, cc.

Note that only kubernetes members can be assigned.

In response to this:

/assign @jpbetz cc @mml

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[Cryptophobia]

@discordianfish : How did you ultimately fix this issue? We are getting the same message when deploying with kops and we think its a DNS issue but we keep getting this error in the kube-apiserver.log file.

[discordianfish]

@Cryptophobia It's been a "special" setup, but in general you can verify whether it's a DNS issue by using nslookup or dig.

[Cryptophobia]

@discordianfish : It turns out instanceGroups are very important for configuring DNS Route53 and etcd during cluster configuration with kops. If those instanceGroups are not defined correctly (particularly when there are even number of master or multiple groups of masters into one availability zone in a single region), etcd servers will not start and master nodes will not check in. This is definitely something that is not very well documented in the kops documentation.

[discordianfish]

@Cryptophobia Ah, you should fill an issue with kops then. This issue here is mostly about saving time by pointing you into the right direction.

[Cryptophobia]

Okay, I'll add another issue to the 784 issues already open. 😆 👍

[ntfrnzn]

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.

[Cryptophobia]

Agreed. Better error messages and more error details going up to the api layer errors so we know what kubernetes apiserver is actually trying to.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[discordianfish]

/remove-lifecycle stale

[Cryptophobia]

/lifecycle frozen

[Cryptophobia]

This would be a really nice feature. I wish I knew more Go so I could help out.

[jordy25519]

I've opened a PR for this. Could use a review

[nikhita]

I've opened a PR for this.

@Holygits thanks!!

I'll remove the help-wanted label on this. :)

/remove-help

[aaronchall]

Will this issue ever be addressed?