Когда мы говорим про увеличение поверхности атаки при прямом роутинге, речь не о том, что трафик не доедет до compute вовсе, а о том, что при централизованном border мы можем применять жёсткие политики до входа в underlay. Если эти же правила размазать по сотням compute-нод, сложнее гарантировать их синхронность и полноту, а так же контролировать изменения. Ну и сам факт того, что compute нода будет обязана тратить ресурсы на обработку внешнего трафика, при централизованном же есть гарантия, что по underlay перемещается уже сколько то отфильтрованный и причесанный по полосе трафик.
По поводу одного ядра и ACL. Ядро выделить-то можно, только пограничная обработка не ограничивается ACL, и тут мы снова утыкаемся в те же грабли, что и выше. Есть ещё нюанс с изоляцией: если внешний трафик валится напрямую на compute, сложнее гарантировать, что всплеск внешней нагрузки не повлияет на производительность виртуальных машин
Ну, на самом деле тут получится составить большой список, но, если обобщить, то можно выделить следующие пункты:
Вопрос безопасности прежде всего. Если выносить внешние маршруты на компьюты, это кратно увеличивает поверхность потенциальной атаки, а так же сложность управления политиками. Ну и часть инфраструктуры, которая не попала в данную работу по разным причинам
Разделение функций. Вместо хостов, которые неплохо делают и то, и то, акцент был сделан на узких специализациях и соответствующих оптимизациях. Сложно сказать, был бы какой-то выигрыш, если в тч на бордерах находились широкопрофильные компьюты, но за это часть ресурсов на всех компьютах всех зон было бы "отъедено" на разного рода уникальные для бордеров детали. При быстрой прикидке как будто бы нет
Ну и если говорить про точку отказа, то тут тоже не так все однозначно. Самое минимальное - это то, что когда речь идет о бордерах, то речь не об одном единственном серваке, а отказоустойчивом кластере с несколькими зонами. Если даже с целой зоной что-то случается - вторая зона подхватывает (как минимум такая схема позволяет обновлять инфраструктуру "невидимо" для клиентов)
Когда мы говорим про увеличение поверхности атаки при прямом роутинге, речь не о том, что трафик не доедет до compute вовсе, а о том, что при централизованном border мы можем применять жёсткие политики до входа в underlay. Если эти же правила размазать по сотням compute-нод, сложнее гарантировать их синхронность и полноту, а так же контролировать изменения. Ну и сам факт того, что compute нода будет обязана тратить ресурсы на обработку внешнего трафика, при централизованном же есть гарантия, что по underlay перемещается уже сколько то отфильтрованный и причесанный по полосе трафик.
По поводу одного ядра и ACL. Ядро выделить-то можно, только пограничная обработка не ограничивается ACL, и тут мы снова утыкаемся в те же грабли, что и выше. Есть ещё нюанс с изоляцией: если внешний трафик валится напрямую на compute, сложнее гарантировать, что всплеск внешней нагрузки не повлияет на производительность виртуальных машин
Ну, на самом деле тут получится составить большой список, но, если обобщить, то можно выделить следующие пункты:
Вопрос безопасности прежде всего. Если выносить внешние маршруты на компьюты, это кратно увеличивает поверхность потенциальной атаки, а так же сложность управления политиками. Ну и часть инфраструктуры, которая не попала в данную работу по разным причинам
Разделение функций. Вместо хостов, которые неплохо делают и то, и то, акцент был сделан на узких специализациях и соответствующих оптимизациях. Сложно сказать, был бы какой-то выигрыш, если в тч на бордерах находились широкопрофильные компьюты, но за это часть ресурсов на всех компьютах всех зон было бы "отъедено" на разного рода уникальные для бордеров детали. При быстрой прикидке как будто бы нет
Ну и если говорить про точку отказа, то тут тоже не так все однозначно. Самое минимальное - это то, что когда речь идет о бордерах, то речь не об одном единственном серваке, а отказоустойчивом кластере с несколькими зонами. Если даже с целой зоной что-то случается - вторая зона подхватывает (как минимум такая схема позволяет обновлять инфраструктуру "невидимо" для клиентов)