Kubernetes - это все участники HA etcd, отвечающие на запрос чтения?

Для кластера HA kubernetes я не нахожу подтверждения, все ли участники etcd отвечают на запрос чтения от apiserver или прямого клиентского доступа, или только главный член etcd выполняет операции чтения / записи?

Доступ для записи хорошо описан, это делает только главный член etcd. Но для кластера K8S с 3 (или более) etcd работает только главный член etcd?

В документации etcd говорится: ‹< Увеличение размера кластера может повысить отказоустойчивость и обеспечить лучшую производительность чтения. Поскольку клиенты могут читать из любого члена, увеличение количества членов увеличивает общую пропускную способность чтения.

Уменьшение размера кластера может улучшить производительность записи кластера за счет снижения устойчивости. Записи в кластер реплицируются на большинство членов кластера, прежде чем они будут считаться зафиксированными. Уменьшение размера кластера приводит к уменьшению большинства, и каждая запись выполняется быстрее. >>

https://coreos.com/etcd/docs/latest/v2/runtime-configuration.html

Верно ли это в контексте реализации K8S в зависимости от типа клиента (apiserver, calico и т. Д.)?


person acra    schedule 24.11.2018    source источник


Ответы (1)


Да, чтения обслуживаются любым членом etcd в кластере HA Kubernetes

person Jordan Liggitt    schedule 24.11.2018
comment
Большое спасибо за быстрое подтверждение @jordan - person acra; 25.11.2018
comment
Я имею в виду, требуется ли консенсус для любого запроса к K8S etcd? - person acra; 25.11.2018
comment
Выполняемые чтения являются чтениями кворума, что гарантирует, что отвечающий сервер etcd по-прежнему является членом функционального кластера и имеет актуальные данные по согласованию с лидером. - person Jordan Liggitt; 25.11.2018
comment
а? Я так понял, что в ведущий приходят только пишут, напрямую управляют чтением? - person acra; 27.11.2018
comment
Насколько я понимаю: coreos.com/etcd/docs/latest/v2 /runtime-configuration.html - person acra; 27.11.2018
comment
‹< Увеличение размера кластера может повысить отказоустойчивость и обеспечить лучшую производительность чтения. Поскольку клиенты могут читать из любого члена, увеличение количества членов увеличивает общую пропускную способность чтения. Уменьшение размера кластера может улучшить производительность записи кластера за счет снижения устойчивости. Записи в кластер реплицируются на большинство членов кластера, прежде чем они будут считаться зафиксированными. Уменьшение размера кластера приводит к уменьшению большинства, и каждая запись выполняется быстрее. ›› - person acra; 27.11.2018