kubeCDN и Terraform

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

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

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

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

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

Описание, дизайн и архитектура kubeCDN

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

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

Рассмотрим пример

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

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

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

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

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

Terraform Code Refactor

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

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

├── 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 указывает на все нужные регионы. А развёртывание региона определяется с применением следующего фрагмента:

module "<name-for-region-deployment>" {
    source = "cluster"
    region = "<AWS-region>"
}

В результате мы получаем возможность не только легко определять новые регионы в одном конфигурационном файле, но и управлять ими.

Источник — «How to build your own CDN with Kubernetes».