Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 Благодаря сети Интернет мы можем обмениваться информацией по всем миру. Главное сегодня - это скорость, ведь нередко бизнес теряет клиентов именно по причине задержек. А их сложно избежать, когда ваша инфраструктура находится в одной части мира, а обслуживает глобальную клиентскую базу, куда входят пользователи со всех концов света.

2 Первое желание - развернуть серверы ближе к пользователям, но создание такой глобальной инфраструктуры и управление ей потребует много затрат. Один из вариантов решения проблемы -сторонние поставщики сети доставки контента. К примеру, у нас есть такиеCDN-поставщики, как Akamai, CloudFlare и Fastly, позволяющие компаниям создавать инфраструктуру в одном регионе, а потом масштабировать услуги для глобальной аудитории.

3 Но, к сожалению, когда речь идёт о сторонних CDN,всё не так уж и гладко: - вы теряете часть контроля над своей инфраструктурой; - снижается уровень безопасности данных; собственно говоря, те же сторонние поставщики CDN получают данные о вашем бизнесе, например, информацию о местонахождении ваших клиентов и т. п. А эти данные могут быть очень ценны для ваших конкурентов; - сторонний CDN - это тоже бизнес, не забывайте об этом. Следовательно, поставщики тоже стремятся получить максимальную прибыль, сопоставляя её с качеством обслуживания (вы же не один клиент, в конце концов).

4 Как же самостоятельно справиться с проблемой доставки контента, как это сделали такие сервисы, как Netflix и LinkedIn?

5 Один из вариантов -kubeCDN.

6 <h2>Описание, дизайн и архитектура kubeCDN</h2>

7 kubeCDN- автономная сеть доставки контента, которая основана на Kubernetes. Это самостоятельное решение, позволяющее поддерживать полный контроль над своей инфраструктурой. При этом kubeCDN заменяет сторонние сервисы доставки контента, а также даёт возможность восстанавливать контроль над потоком данных с ваших серверов.

8 Данная сеть использует для развёртывания EKS и прочих компонентов инфраструктуры AWS в нужном регионе такой инструмент, какTerraform. Для маршрутизации пользовательского трафика между регионами применяетсяRoute53- облачная DNS от AWS. Для автоматического создания DNS-записей в процессе развёртывания новых служб задействуетсяExternalDNS.

9 <h2>Рассмотрим пример</h2>

10 Представьте, что наш видеосервер располагается в 2-х регионах AWS: us-east-1 и us-west-2. Мы настраиваем для своего домена размещённую зону на Route53 и устанавливаем А-записи для каждого региона, где развернуты кластеры, применяя политику маршрутизации, что необходимо для направления пользователей в регион, где задержка минимальна.

11 Ниже показано, каким образом Route53 маршрутизирует пользовательский трафик с кластерами, которые настроены в 2-х регионах:

12 Таким образом, пользователь из Сан-Франциско направляется не в кластер us-east-1, а в кластер us-east-2, так как у второго меньше задержка.

13 Кроме того, kubeCDN даёт возможность без проблем масштабировать сервисы и приложения по всему миру, делая это за считанные минуты. Допустим, чтобы развернуть инфраструктуру для демонстрационного примера выше, было потрачено всего 15 минут времени. И это существенно меньше, чем при ручном развёртывании через консоль AWS.

14 Кроме простоты масштабирования, kubeCDN оптимизирует затраты на инфраструктуру, к примеру, благодаря тому, что сеть разбивает регионы в периоды невысокой активности пользователей. И этот уровень оптимизации затрат иногда имеет решающее значение для повышения прибыли.

15 <h2>Terraform Code Refactor</h2>

16 В целях развёртывания кластеров EKS в регионе kubeCDN применяет код Terraform, основанный на репозитории, который созданHashiCorp. Это хранилище имеет подробные инструкции, но не очень-то способно к развёртыванию в нескольких регионах. Дело в том, что целевая область жёстко запрограммирована, требуя для каждой желаемой области репликации репозитория. А это, как известно процесс ручной и утомительный, к тому же, весьма уязвимый к человеческим ошибкам. Не говоря уже о получении нечёткой структуры управления, затрудняющей мониторинг инфраструктуры и усложняющей оптимизацию расходов.

17 Проблема решается путёмрефакторинга кода Terraform. Давайте посмотрим на структуру ниже, которая лучше организовывает инфраструктурную часть проекта на данном этапе:

18 ├── terraform (Dir containing all infrastructure code) ├── cluster (EKS cluster components) │ ├── main.tf │ ├── outputs.tf │ ├── rbac.yaml │ └── variables.tf ├── main.tf (Main .tf file where regions are specified) └── variables.tf (Some files have been removed for brevity)Здесь main.tf указывает на все нужные регионы. А развёртывание региона определяется с применением следующего фрагмента:

19 module "<name-for-region-deployment>" { source = "cluster" region = "<AWS-region>" }В результате мы получаем возможность не только легко определять новые регионы в одном конфигурационном файле, но и управлять ими.

20 Источник - "<a>How to build your own CDN with Kubernetes</a>".