Мы определяем наш микросервис внутри kubenetes Pods, нужно ли нам подключать Grpc-клиент к повторному подключению, если перезапуск сервисного модуля? Когда перезагружается модуль, имя хоста не изменяется, но мы не можем гарантировать, что IP-адрес останется прежним. Таким образом, клиент grpc все еще может обнаружить новый сервер для повторного подключения?Клиент-клиент GRPC повторно подключается внутри kubenetes
Когда TCP-соединение отключено (из-за остановки старого порта), канал gRPC попытается восстановить соединение с экспоненциальным отклонением. Каждая попытка повторного подключения подразумевает разрешение DNS-адреса, хотя он не может сразу обнаружить новый адрес из-за TTL (время жизни) старой записи DNS. Кроме того, я считаю, что некоторые реализации разрешают адрес, когда обнаружен сбой, а не перед попыткой.
Этот процесс происходит естественным образом, если ваше приложение ничего не делает, хотя оно может испытывать ошибки RPC до тех пор, пока соединение не будет восстановлено. Включение «ожидание готовности» в RPC уменьшит вероятность сбоя RPC в течение этого периода перехода, хотя такой RPC обычно подразумевает, что вы не заботитесь о задержке ответа.
Если DNS-адрес не был (в конечном итоге) реконструирован, это будет ошибкой, и вы должны указать проблему.
Необходимо балансировку нагрузки на стороне клиента, как описано here. Вы можете просмотреть конечные точки службы с помощью Kubernetes api. Я создал пакет для языка программирования Go, и он находится на github. Извините, но я еще не написал документацию. Базовая концепция - это получение конечных точек обслуживания в начале, чем конечные точки обслуживания для изменений.
Пожалуйста, укажите, что описано в вашей ссылке, так как ссылки только на них нахмурены. Ответ должен иметь возможность существовать, не полагаясь на внешние источники. –