Хм, рейтлимитер влияет на время повторного попадания реквеста в очередь. Но, если дергать объекты за которыми следит контроллер - объект ставится в очередь сразу. Конечно, при условии что изменения в отслеживаемых объектах не заблокированны предикатами.
Предикаты не могут повлиять на рейтлимитер, они только ограничивают, фильтруют события которые могут дойти до контроллера.
Не очень понял что имеется в виду под конфигом. Если это CR или конфигмапа - то самый прямой путь это повесить Watch на этот объект. Тогда любые изменения на них будут отправлять событие в очередь контроллеру на реконсиляцию. Сюда же можно повесить предикат, чтобы не все события вызывали реконсиляцию, например, тот же GenerationChangedPredicate, только надо помнить что для разных объектов generation может меняться по немного разным правилам.
Правда, если кластер большой, то может быть желание не вотчить конфигмапы, поскольку их может быть тьма и это забьет кэш оператора. Тогда очень многое зависит от самой структуры оператора, что он делает и какие у него объекты есть. Как вариант, создать дополнительную, легковесную CR на которую и повесить вотч. А чтобы они не засоряли кластер автоматически удалять после срабатывания реконсайла. Это, конечно, добавляет лишний шаг для пользователя - нужно обновить конфигмапу, а потом еще и CR создать, но позволяет не вотчить миллионы часто меняющихся конфигмап.
Чтобы сбросить backoff у рейтлимитера нужно вызвать у него Forget для соответствующего события. Правда, для этого нужно следить за объектом. Но зачем тогда сбрасывать backoff, если можно просто поставить вотч на этот объект для исходного контроллера?
Там, на самом деле, отсутствуют и другие элементы. Просто выводится содержимое только одного бакета. А во втором выводе, после роста мапы, бакетов становится уже несколько. Собственно, распределение элементов по бакетам после роста мапы - процесс случайный и просто так получилось что новый элемент попал в новый бакет, который просто не вывели. Если позапускать код несколько раз - то можно поймать его и в этом бакете.
Повлияет, конечно. На саму асинхронную обработку, так или иначе, действительно расходуются ресурсы. Но я бы не сказал что это проблема асинхронной обработки, это скорее проблема выбора инструмента и(или) подхода к разработке. Если есть задача в которой необходимо утилизировать 100% CPU, ну, кажется стоит обратить внимание на более низкоуровневые языки. И самостоятельно управлять потоками, памятью и прочим.
Асинхронная обработка в го, скорее (но не только), позволяет, так сказать, выполнять операции которые можно не делать прямо сейчас в отложенном режиме.
Да, согласен, немного не корректно получилось. Наверное, стоило явно писать "эвакуация данных" когда это подразумевалось, а то местами выглядит будто эвакуация мапы.
По росту - да, в go он асинхронный. Из-за этого могут возникать ситуации когда при попытке доступа к данным часть бакетов уже переехала, а часть нет. Но, благодаря этому не происходит просадок во время роста большой мапы.
Хм, рейтлимитер влияет на время повторного попадания реквеста в очередь. Но, если дергать объекты за которыми следит контроллер - объект ставится в очередь сразу. Конечно, при условии что изменения в отслеживаемых объектах не заблокированны предикатами.
Предикаты не могут повлиять на рейтлимитер, они только ограничивают, фильтруют события которые могут дойти до контроллера.
Не очень понял что имеется в виду под конфигом. Если это CR или конфигмапа - то самый прямой путь это повесить Watch на этот объект. Тогда любые изменения на них будут отправлять событие в очередь контроллеру на реконсиляцию. Сюда же можно повесить предикат, чтобы не все события вызывали реконсиляцию, например, тот же GenerationChangedPredicate, только надо помнить что для разных объектов generation может меняться по немного разным правилам.
Правда, если кластер большой, то может быть желание не вотчить конфигмапы, поскольку их может быть тьма и это забьет кэш оператора. Тогда очень многое зависит от самой структуры оператора, что он делает и какие у него объекты есть. Как вариант, создать дополнительную, легковесную CR на которую и повесить вотч. А чтобы они не засоряли кластер автоматически удалять после срабатывания реконсайла. Это, конечно, добавляет лишний шаг для пользователя - нужно обновить конфигмапу, а потом еще и CR создать, но позволяет не вотчить миллионы часто меняющихся конфигмап.
Чтобы сбросить backoff у рейтлимитера нужно вызвать у него Forget для соответствующего события. Правда, для этого нужно следить за объектом. Но зачем тогда сбрасывать backoff, если можно просто поставить вотч на этот объект для исходного контроллера?
Хотя, я вполне мог и неправильно понять вопрос.
Спасибо, поправил
Там, на самом деле, отсутствуют и другие элементы. Просто выводится содержимое только одного бакета. А во втором выводе, после роста мапы, бакетов становится уже несколько. Собственно, распределение элементов по бакетам после роста мапы - процесс случайный и просто так получилось что новый элемент попал в новый бакет, который просто не вывели. Если позапускать код несколько раз - то можно поймать его и в этом бакете.
О, спасибо, совсем забыл добавить, даже в самом тексте ведь обещал. Собственно, добавил в статью код ф-ции и небольшое описание к нему.
Согласен, добавил небольшой блок с уточнением.
Повлияет, конечно. На саму асинхронную обработку, так или иначе, действительно расходуются ресурсы. Но я бы не сказал что это проблема асинхронной обработки, это скорее проблема выбора инструмента и(или) подхода к разработке. Если есть задача в которой необходимо утилизировать 100% CPU, ну, кажется стоит обратить внимание на более низкоуровневые языки. И самостоятельно управлять потоками, памятью и прочим.
Асинхронная обработка в го, скорее (но не только), позволяет, так сказать, выполнять операции которые можно не делать прямо сейчас в отложенном режиме.
Да, согласен, немного не корректно получилось. Наверное, стоило явно писать "эвакуация данных" когда это подразумевалось, а то местами выглядит будто эвакуация мапы.
По росту - да, в go он асинхронный. Из-за этого могут возникать ситуации когда при попытке доступа к данным часть бакетов уже переехала, а часть нет. Но, благодаря этому не происходит просадок во время роста большой мапы.