Комментарии 5
Про client-side throttling и его qps/burst из всеми любимого client-go надо просто знать, если что-то б.м. масштабное крутишь в кубах.
Ну и для подстраховки же есть --eviction-rate-limit и --eviction-rate-burst у Updater-а.
4й вывод и вся статья явно не про "опенсорс - крутая штука". Без доступа к коду - т.е. с вендорской "коробкой", пошли бы к вендору и он бы ковырял. За деньги, возможно, управился бы быстрее чем самостоятельное ковыряние кода, а может быть и нет, тут как с встретить динозавра.
А вот про то, что в опенсорсе нужно быть 100% готовым ковырять кодец, это правильный вывод без сомнения.
Без доступа к коду - т.е. с вендорской "коробкой", пошли бы к вендору и он бы ковырял.
только если ты убер-мега-гига важный клиент, а иначе - "ваш звонок очень важен для нас, оставайтесь на линии"
За деньги, возможно, управился бы быстрее чем самостоятельное ковыряние кода, а может быть и нет, тут как с встретить динозавра.
ага, увидимся через месяц и без какой либо гарантии. Помню я критический баг то ли в sharepoint то ли ms exchange, а мы тогда была microsoft gold partner. В итоге года пол мурыжили, ничем толком не помогли
4й вывод и вся статья явно не про "опенсорс - крутая штука". Без доступа к коду - т.е. с вендорской "коробкой", пошли бы к вендору и он бы ковырял. За деньги, возможно, управился бы быстрее чем самостоятельное ковыряние кода
И что, правда находились вендоры, которые ковыряют быстрее? По моему опыту, в разы медленнее. Что Suse, что Fujitsu, что CrowdStrike, что PaloAlto -- часто годами не могут решить проблемы. Быстро решают только тогда, когда проблема очевидна и клиент что-то проворонил в документации. И неважно, сколько денег ты им платишь. Они в принципе не умеют решать быстро.
Как Vertical Pod Autoscaler пошёл вразнос и уронил наш кластер