У нас же есть схожий механизм - сабсеттинг. Только нет «динамического» изменения размера, но суть схожа. Клиенты получают только пачку бэкендов, а не весь список, который может состоять из сотен инстансов.
Есть официальная документация тут от самого gRPC-go
Работает это по следующему принципу: при настройке Istio к каждому поду в кластере добавляется init контейнер, который формирует и сохраняет под собой файлик xds_bootstrap. В нем содержится информация о том, где находится Istio и некоторые доп поля для подключения. Далее для gRPC необходимо прописать путь до этого bootstrap файла и при создании подключения добавить схему Resolver: xds:///. Ориентируясь на полученную информацию, gRPC сделает коннект к Istio и скачает нужную информацию. Плюс он получит Service Config, в котором можно настроить некоторые механизмы балансировщиков. Об этом можно подробнее почитать в документации Istio
В некоторых случаях - да, это хорошая и простая альтернатива, если вы работаете с небольшой инсталляцией Но если у вас разрастется кластер, то каждый под на таком решении будет создавать трафик на Kubernetes API, что может привести к излишней нагрузки на нем
Да, я это не упомянул в статье, так как когда я начинал её писать, я использовал 1.57 версию. Ей, кстати, недавно патч выпустили. Судя по всему, её ещё поддерживают, поэтому ей ещё можно пользоваться.
С версии gRPC 1.58 чуть поменяли интерфейсы работы updateSubConnState и самих SubConn. Теперь там регистрируется подписка на события, а не обрабатывается в общем коллбэке. Кажется, что так удобнее, поскольку нет необходимости проверять, что полученное обновление соответствует тем SubConn, которые зарегистрированы используемым Balancer. Плюс удаление SubConn теперь вызывается не через cc.RemoveSubConn, а через метод самого SubConn - Shutdown.
Я пока написал только первую часть. И она уже получилась достаточно громоздкой :) Про Balancer нужно написать ещё столько же. Если она будет востребована, то я выпущу вторую, где как раз расскажу про то, какие фичи можно сделать на Balancer :)
Все так)
Я думал, речь про aperture.
Привет)
У нас же есть схожий механизм - сабсеттинг. Только нет «динамического» изменения размера, но суть схожа. Клиенты получают только пачку бэкендов, а не весь список, который может состоять из сотен инстансов.
Есть официальная документация тут от самого gRPC-go
Работает это по следующему принципу: при настройке Istio к каждому поду в кластере добавляется init контейнер, который формирует и сохраняет под собой файлик xds_bootstrap. В нем содержится информация о том, где находится Istio и некоторые доп поля для подключения. Далее для gRPC необходимо прописать путь до этого bootstrap файла и при создании подключения добавить схему Resolver: xds:///. Ориентируясь на полученную информацию, gRPC сделает коннект к Istio и скачает нужную информацию. Плюс он получит Service Config, в котором можно настроить некоторые механизмы балансировщиков. Об этом можно подробнее почитать в документации Istio
В некоторых случаях - да, это хорошая и простая альтернатива, если вы работаете с небольшой инсталляцией
Но если у вас разрастется кластер, то каждый под на таком решении будет создавать трафик на Kubernetes API, что может привести к излишней нагрузки на нем
Да, я это не упомянул в статье, так как когда я начинал её писать, я использовал 1.57 версию. Ей, кстати, недавно патч выпустили. Судя по всему, её ещё поддерживают, поэтому ей ещё можно пользоваться.
С версии gRPC 1.58 чуть поменяли интерфейсы работы updateSubConnState и самих SubConn. Теперь там регистрируется подписка на события, а не обрабатывается в общем коллбэке. Кажется, что так удобнее, поскольку нет необходимости проверять, что полученное обновление соответствует тем SubConn, которые зарегистрированы используемым Balancer. Плюс удаление SubConn теперь вызывается не через cc.RemoveSubConn, а через метод самого SubConn - Shutdown.
Я пока написал только первую часть. И она уже получилась достаточно громоздкой :) Про Balancer нужно написать ещё столько же. Если она будет востребована, то я выпущу вторую, где как раз расскажу про то, какие фичи можно сделать на Balancer :)
Круто)
В gRPC под капотом есть реализация xDS, которая из коробки может законнектиться к Istio. Можете заглянуть туда в поисках полезных систем.
Привет)
У нас нет требований по IDE для разработчиков, поэтому все используют те IDE, которые им нравятся) Из популярных - VSCode и VIM