You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 28, 2020. It is now read-only.
When etcd starts, it has a bootstrap phase that talks to other peers:
Start -> bootstrapping -> running/serving
If "bootstrap" phase failed, it is the same as dead because no data is available, no quorum information is known.
However, if we start etcd in a Kubernetes Pod, even if it starts running, it doesn't mean etcd is running. It is important for the operator to know the status of the etcd member in this phase. We can only proceed with this member after it's "ready".
There is a field in Kubernetes to decouple readiness and endpoints called
Only affect self hosted
Another use case of this: On self hosted etcd, etcd pods restart could lead to pod endpoints removed from service. This is dangerous and unnecessary. Because etcd pod should restart and recover. It shouldn't remove such endpoints unless pod is deleted.
For example, say we have 3 members of etcd cluster, three of them died. In such case, the etcd service will have no endpoints and self hosted kubernetes cluster won't be able to recover itself. However, if service can tolerate such unready pods and don't remove the endpoints, etcd pods will restart and recover itself.
hongchaodeng
changed the title
Use "tolerante-unready-endpoints" to check etcd pod readiness
Use "tolerate-unready-endpoints" to check etcd pod readiness
Apr 25, 2017
Some real world experience:
Due to some issue on the node, e.g. node pressure or network partition, etcd pod was restarted and endpoint gets removed.
This could be better tolerated.
ref:
When etcd starts, it has a bootstrap phase that talks to other peers:
Start -> bootstrapping -> running/serving
If "bootstrap" phase failed, it is the same as dead because no data is available, no quorum information is known.
However, if we start etcd in a Kubernetes Pod, even if it starts running, it doesn't mean etcd is running. It is important for the operator to know the status of the etcd member in this phase. We can only proceed with this member after it's "ready".
There is a field in Kubernetes to decouple readiness and endpoints called
Making use of this will help us differentiate the "bootstrapping" phase.
The text was updated successfully, but these errors were encountered: