2020-07-29T14:14:46.241Z [WARN]  core: leadership lost, stopping active operation
2020-07-29T14:14:46.241Z [INFO]  core: pre-seal teardown starting
2020-07-29T14:14:46.741Z [DEBUG] expiration: stop triggered
2020-07-29T14:14:46.741Z [DEBUG] expiration: finished stopping
2020-07-29T14:14:46.741Z [INFO]  rollback: stopping rollback manager
2020-07-29T14:14:46.741Z [INFO]  core: pre-seal teardown complete
2020-07-29T14:14:46.746Z [WARN]  core.cluster-listener: no TLS config found for ALPN: ALPN=[req_fw_sb-act_v1]
2020-07-29T14:14:46.747Z [DEBUG] core.cluster-listener: error handshaking cluster connection: error="unsupported protocol"
2020-07-29T14:14:46.749Z [WARN]  core.cluster-listener: no TLS config found for ALPN: ALPN=[req_fw_sb-act_v1]
2020-07-29T14:14:46.749Z [DEBUG] core.cluster-listener: error handshaking cluster connection: error="unsupported protocol"
2020-07-29T14:14:47.172Z [TRACE] core: found new active node information, refreshing
2020-07-29T14:14:47.178Z [DEBUG] core: parsing information for new active node: active_cluster_addr=https://vault-2.vault-internal:8201 active_redirect_addr=h
ttp://10.12.10.81:8200
2020-07-29T14:14:47.178Z [DEBUG] core: refreshing forwarding connection
2020-07-29T14:14:47.178Z [DEBUG] core: clearing forwarding clients
2020-07-29T14:14:47.178Z [DEBUG] core: done clearing forwarding clients
2020-07-29T14:14:47.178Z [DEBUG] core: done refreshing forwarding connection
2020-07-29T14:14:47.178Z [DEBUG] core.cluster-listener: creating rpc dialer: alpn=req_fw_sb-act_v1 host=fw-66e549bb-a050-79f9-e155-6dc9add22b3c
2020-07-29T14:14:47.183Z [DEBUG] core: forwarding: error sending echo request to active node: error="rpc error: code = Unavailable desc = all SubConns are in
TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing remote error: tls: internal error""
2020-07-29T14:14:48.183Z [DEBUG] core.cluster-listener: creating rpc dialer: alpn=req_fw_sb-act_v1 host=fw-66e549bb-a050-79f9-e155-6dc9add22b3c
2020-07-29T14:14:48.278Z [DEBUG] core.cluster-listener: performing client cert lookup

привет! подскажите пожалуйста по архитектуре консула. ходить за сервис дискавери или в kv не через локального агента, а напрямую в серверные агенты по dns имени сервиса consul - это не антипаттерн?
вот у меня есть поды в кубернетесе, как правильно интеграцию готовить? сайдкаром консул агента сажать в под, а основной контейнер пода на локалхост отправлять если что-то от консула нужно? или то что я всё это время напрямую к сервер агентам хожу через дефолтный сервис это не страшно?
так-то сейчас консул у меня по всей инфре на каждом хосте, но взаимодействие с консулом идёт только через api самих сервер агентов (сервер агенты понятное дело живут на трёх выделенных под них "консул серверах"). агенты на прочих хостах мной эксплуатируются ради хелсчеков, регистраций сервисов и, собственно, регистраций самих хостов - внутренний днс весь implicitly завязан на консул тоже, имена хостов  (a/ptr) и сервисов кроме как через консул никак нигде больше не резолвятся.
больше года на проекте такую архитектуру использую, ничего нигде не отваливалось, консулом очень доволен, но может всё-таки я что-то не так делаю?)

видимо я настолько наркоман, что прокомментировать такое никто не хочет))