Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Use actual etcd client for /healthz/etcd checks #65027
@liggitt: GitHub didn't allow me to request PR reviews from the following users: gyuho.
Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs.
On Tue, Jun 12, 2018 at 10:25 PM, k8s-ci-robot ***@***.***> wrote: [APPROVALNOTIFIER] This PR is *NOT APPROVED* This pull-request has been approved by: *hzxuzhonghu <#65027 (comment)>*, *liggitt <#65027#>* To fully approve this pull request, please assign additional approvers. We suggest the following additional approver: *sttts* Assign the PR to them by writing /assign @sttts in a comment when ready. The full list of commands accepted by this bot can be found here <https://go.k8s.io/bot-commands>. The pull request process is described here <https://git.k8s.io/community/contributors/guide/owners.md#the-code-review-process> Needs approval from an approver in each of these files: - *staging/src/k8s.io/apiextensions-apiserver/Godeps/OWNERS <https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiextensions-apiserver/Godeps/OWNERS>* - staging/src/k8s.io/apiserver/OWNERS <https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/OWNERS> [liggitt] - *staging/src/k8s.io/kube-aggregator/Godeps/OWNERS <https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/kube-aggregator/Godeps/OWNERS>* - staging/src/k8s.io/sample-apiserver/Godeps/OWNERS <https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/sample-apiserver/Godeps/OWNERS> [liggitt] Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#65027 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABG_pzGFk1lv_NXdcrPejXHxG4vDYjhrks5t8HgrgaJpZM4Uk9sH> .
[APPROVALNOTIFIER] This PR is APPROVED
The full list of commands accepted by this bot can be found here.
The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing
referenced this pull request
Jun 13, 2018
[MILESTONENOTIFIER] Milestone Pull Request Labels Incomplete
Action required: This pull request requires label changes. If the required changes are not made within 2 days, the pull request will be moved out of the v1.12 milestone.
kind: Must specify exactly one of
Jun 21, 2018
18 checks passed
not necessarily... it fixes stuck tcp connections, which we have observed happening in failover cases. open to further improvement here, but this is better than what we had
referenced this pull request
Jun 26, 2018
It does seem like a good idea to drop all watches if our etcd goes away, and a restart is an especially (excessively?) thorough way to accomplish that...
However! It doesn't seem great for apiserver to continuously fail liveness checks and crash-loop while etcd is down / split; it should be sufficient to just not be ready. So, maybe liveness shouldn't care about etcd until we observe a healthy etcd and become ready, at which point if we lose readiness because etcd goes away, we should also lose liveness and be restarted.
We can probably come up with something better / more principled than that: AFAIK, no one has payed any holistic attention to apiserver's liveness / readiness checks.