Ничего не сказано про maglev и dsr режим(в native и geneve), да и в целом geneve. Про egressgateway ни сслова. Про Bandwidth и возможность настройки bbr, bug tcp на конкретные поды.
Ну и про то, что egress gateway и dbs policy это не ha решения, так что фичи очень огранченные тоже ни слова. В обсервабилити можно было затронуть service map, что тоже у мало у кого есть. Не затронув что и сервис меш, и ингресс гейтвей очень сырые, например что два ингресс не поставишь на одну ноду используя енвой нативный у силиума
Буду немного токсичным, по верхам совсем прошлись.
Если уже про фичи говорить, то это очень крутые фичи, которые не у всех есть.
Так и метрики по snmp - это тоже о том, что происходило n времени назад. Выже не собираете снмп в реальном времени? А скорее циклом за н времени, с подсчетом того, что происходило между этими циклами. В логи в этом плане более стихийны и моментальны, и могут показать что происходит быстрее, при условии, что данные визуализирубися/подсчитываются достаточно "быстро"
Thanks for this article. I like you app. And i have one question. Why did not you use clickhouse for metadata too and ise it postgres? I think one database is batter than two?) I see that similar apps like a signoz and qryn store all metadata to clickhouse too
Все это круто. Классно. Но, насколько я понимаю, смотря вот сюда, ваша система еще использует consul, arangodb, redis, postgres, rabbitmq. Не удивлюсь, если подумываете использовать кафку. Понимаю, что критиковать не строить, но выглядит конструкция, конечно, монструозно. У меня в аналогии сразу всплывает sentry, где количество субд и очередей довольно много, и поддерживать это сложно. А еще сложнее разобраться как оно все работает под капотом. Не думали отказаться от каких-то частей в пользу чего-то одного? Например как делает signoz и qryn?
Наверное, такую систему, как и в случае с сентри, проще брать облачную.
согласен насчет л2. Но автор ответил на этот вопрос. А вы пробовали на ноде, например с CNI калико, которая установила пиринг по БГП со свичом/роутером поднять MetalLB спикера и подружить с темже свичем? (Необходимы костыли, пару из которых описаны здесь)
на балансер повесить wildcard, а с него балансить на ingress nodes. Т.е. в этом случае автоматизация — добавить новые ingress nodes в ротацию. Но это любым ансиблом можно сделать. Если про первый вариант мной описаный. Если про второй — то это вообще не продовая вещь. там много костылей.
Это с оператором. А можно «внекуба», например поднять кластер haproxy, а тот уже будет балансировать на игнресс ноды, а те в свою очередь через ингресс балансировать на поды. Если для нужд хватает 80/443 портов. И будет очень даже отказоусточиво, да.
А можно даже заанонсить Service, и балансировать на них через haproxy (а дальше магия куба, но это тот еще костыль). Но в этом случае нужно отслеживать, чтобы при деплое не поменялся IP у сервиса или сообщать об этом haproxy, ну и фичи теряешь LB. Хотя можно поставить externalTrafficPolicy=Local и Affinity… крч много вариантов
я про BGP и имел ввиду, моя оплошность. Помню ваше выступление на highload и вы описывали плоскую сеть без ротинга как примещуство. А получается, чтобы добиться гибкости маршрутизации в такой схеме, приходится добавлять статику, PBR, красить роуты на нодах. И это, ИМХО конечно, сложнее обслуживать чем динамику, где бгп за тебя анонсит маршруты соседям и дальше магия сетевиков (главное чтобы сеть не офигела от количества маршрутов которые бедет генерить куб). Я не критикую вас. Так мысли в слух. И понять для себя как лучше
Ничего не сказано про maglev и dsr режим(в native и geneve), да и в целом geneve. Про egressgateway ни сслова. Про Bandwidth и возможность настройки bbr, bug tcp на конкретные поды.
Ну и про то, что egress gateway и dbs policy это не ha решения, так что фичи очень огранченные тоже ни слова. В обсервабилити можно было затронуть service map, что тоже у мало у кого есть. Не затронув что и сервис меш, и ингресс гейтвей очень сырые, например что два ингресс не поставишь на одну ноду используя енвой нативный у силиума
Буду немного токсичным, по верхам совсем прошлись.
Если уже про фичи говорить, то это очень крутые фичи, которые не у всех есть.
Ну разве что в kubectl logs podName -f иль тип того, я хз ))
Так и метрики по snmp - это тоже о том, что происходило n времени назад. Выже не собираете снмп в реальном времени? А скорее циклом за н времени, с подсчетом того, что происходило между этими циклами. В логи в этом плане более стихийны и моментальны, и могут показать что происходит быстрее, при условии, что данные визуализирубися/подсчитываются достаточно "быстро"
Спасибо Максим, мне нравится такие статьи читать)
Зы: По informers как они работают, нравится такая статья
Да, это древняя 'фишечка' пром оператора https://github.com/prometheus-operator/prometheus-operator/issues/3298
And i really like it https://uptrace.dev/get/opentelemetry-js-web.html
Thanks for this article. I like you app. And i have one question. Why did not you use clickhouse for metadata too and ise it postgres? I think one database is batter than two?) I see that similar apps like a signoz and qryn store all metadata to clickhouse too
Понятно.
Не знаю, нужно оно или нет. Тут вам виднее). Вы лучше знаете своего клиента.
Все это круто. Классно. Но, насколько я понимаю, смотря вот сюда, ваша система еще использует consul, arangodb, redis, postgres, rabbitmq. Не удивлюсь, если подумываете использовать кафку. Понимаю, что критиковать не строить, но выглядит конструкция, конечно, монструозно. У меня в аналогии сразу всплывает sentry, где количество субд и очередей довольно много, и поддерживать это сложно. А еще сложнее разобраться как оно все работает под капотом. Не думали отказаться от каких-то частей в пользу чего-то одного? Например как делает signoz и qryn?
Наверное, такую систему, как и в случае с сентри, проще брать облачную.
так первый коммит coroot тоже был сделал почти год назад)) специально глянул - 1го февраля)
но я понял мысль
+1 прочитав статью, первое что подумал - почему бы не взять coroot и не изобретать костыль?
Спасибо, мне приятно, что понравилась статья). Данным исследованием занимались 2 инженера.
А можно даже заанонсить Service, и балансировать на них через haproxy (а дальше магия куба, но это тот еще костыль). Но в этом случае нужно отслеживать, чтобы при деплое не поменялся IP у сервиса или сообщать об этом haproxy, ну и фичи теряешь LB. Хотя можно поставить externalTrafficPolicy=Local и Affinity… крч много вариантов
А режим l3 не решает таких проблем?