Как создать CDN с Kubernetes

Интернет позволил людям обмениваться идеями и информацией по всему миру так быстро, что теперь любые задержки могут быть крайне неприятными, особенно когда дело касается общих документов или видеопотоков. Согласитесь, необходимость смотреть на «буферизацию» анимаций разочаровывает.

При наличии конкурирующих вариантов такое ухудшение UX вызывает желание искать альтернативы, и не один бизнес терял клиентов таким образом.

Основная причина долгого ожидания — большое расстояние от серверов до пользователей. Если ваша инфраструктура расположена в одной части мира и обслуживает глобальную клиентскую базу, у пользователей из другой части мира будет задержка при использовании вашего сервиса.

Развёртывание серверов ближе к пользователям может уменьшить время ожидания, но управление глобальной инфраструктурой требует больших капиталовложений и инвестиций.

Поставщики CDN — сети доставки контента

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

Поставщики CDN минимизируют задержку при подключении пользователей, кешируя статический контент в точках присутствия (PoP) по всему миру. PoP состоят из нескольких пограничных серверов и предоставляют кешированное содержимое пользователям. Если запрошенный ресурс не найден, пограничный сервер получает ресурс либо с исходного (вашего) сервера, либо с соседних пограничных серверов. Это улучшает UX для географически распределённых пользователей и сокращает задержку.

Проблемы сторонних CDN

• При использовании сторонних CDN для предоставления своих услуг, вы отказываетесь от некоторого контроля над своей инфраструктурой. Вы становитесь зависимыми от третьего лица и не можете гарантировать, что пользователи получают наилучший опыт использования приложения.
• Ещё более важным фактором является угроза безопасности данных. Ошибки в системе поставщика CDN, такие как эта, могут иметь серьёзные последствия для безопасности и конфиденциальности пользователей.
• Вы, вероятно, не единственный их клиент, и в конце концов, сторонний CDN — это бизнес. Они будут приоритизировать свою прибыль над качеством вашего обслуживания.
• Наконец, самая важная проблема с использованием поставщика CDN — понимание того, что они получают данные о вашем бизнесе. Поставщик CDN может определить местонахождение ваших клиентов, время использования вашего сервиса и типы устройств, получающих к нему доступ. Подобные данные могут быть очень ценны для конкурентов, а разглашение информации третьим лицам может и вовсе лишить вас клиентов.

По этим и другим причинам многие ведущие сервисы, такие как Netflix и LinkedIn, решили справиться с проблемой доставки контента самостоятельно.

Вы можете сделать так же, и для этого вам понадобится kubeCDN.

kubeCDN

Автономная сеть доставки контента, основанная на Kubernetes. Это самостоятельное решение, где вы поддерживаете полный контроль над своей инфраструктурой.

kubeCDN заменяет сторонние сервисы доставки контента и восстанавливает контроль над потоком данных с ваших серверов на устройства пользователей.

Дизайн и архитектура

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

ExternalDNS применяется для автоматического создания DNS-записей при развёртывании новых служб.

Вот каким образом Terraform используется в kubeCDN:

В то время как Terraform служит для развёртывания необходимой инфраструктуры kubeCDN, Route53 используется для маршрутизации пользовательского трафика в определённые регионы.

Пример

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

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

Пользователь из Сан-Франциско направляется в кластер us-east-2, а не в кластер us-east-1, поскольку у первого задержка меньше. Существуют и другие варианты, доступные на Route53. Их можно использовать с kubeCDN для удовлетворения различных требований приложений. Более подробно смотрите здесь.

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

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

Решение некоторых проблем

Решение некоторых сложных задач может потребовать разработку обходных путей. Две такие проблемы описаны ниже.

Terraform Code Refactor

kubeCDN использует код Terraform для развёртывания кластеров EKS в регионе. Он основан на репозитории, созданном HashiCorp.

Хотя хранилище очень чёткое, с подробными инструкциями, оно не способно к развёртыванию в нескольких регионах. Целевая область жёстко запрограммирована и требует репликации репозитория для каждой желаемой области. Это утомительный ручной процесс, который уязвим к человеческим ошибкам. Это также приведёт к случайной структуре управления, что затруднит мониторинг инфраструктуры и оптимизацию затрат.

Решение проблемы — рефакторинг кода Terraform. Структура ниже будет лучше организовывать инфраструктурную часть проекта на этом этапе.

main.tf здесь указывает на все нужные регионы. Развёртывание региона определяется с использованием следующего фрагмента:

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

Это позволяет легко определять новые регионы в одном конфигурационном файле и управлять ими.

Внешние проблемы DNS

ExternalDNS динамически настраивает DNS-записи через ресурсы Kubernetes, поэтому веб-сервер можно обнаружить с помощью общедоступных DNS-серверов.

Сервис можно использовать с kubeCDN. Он автоматически создаст DNS-записи для различных регионов. После этого нужно настроить Route53 для использования политики маршрутизации, обеспечивающей минимальную задержку.

Пример

Установим две A-записи для вашего домена — по одной для каждого развёрнутого региона. В сочетании с Route53 это направит пользователей в регионы AWS с минимальной задержкой.

Одна из записей указывает на инфраструктуру Восточного побережья, а другая — на инфраструктуру Западного побережья.

Включите ExternalDNS в kubeCDN, настройте службу тестирования видео на использование ExternalDNS и установите запись DNS при развёртывании.

Вы заметите, что ExternalDNS перезаписывает A-записи для одного и того же доменного имени, даже если IP-адрес другой. Похоже, что это временное ограничение поставщика AWS. Учитывая, что ExternalDNS является новым инструментом и всё ещё инкубируется как проект, можно заняться этим вопросом вручную.

Ещё одно ограничение AWS в ExternalDNS — невозможность установить маршрутизацию на основе задержки на Route53 — описано здесь. Эта проблема решается путём ручной настройки.

Указанные здесь проблемы характерны для провайдера AWS на ExternalDNS. Однако те же проблемы могут не существовать для других облачных провайдеров на ExternalDNS или в его будущих версиях.

Расширение kubeCDN

Рассмотрим идеи по расширению проекта и его возможностей.

Поддержка нескольких облаков

На данный момент kubeCDN основан исключительно на AWS. В основном это связано с тем, что AWS предоставляет сотрудникам Insight кредиты на проекты. Использование только одного облачного провайдера может быть критичным в случае сбоя. Чтобы обеспечить необходимое переключение в таких сценариях, нужно добавить поддержку нескольких облачных провайдеров, например GCP и Azure.

Для добавления поддержки потребуется одно из следующих действий:

• Включите управляемые услуги Kubernetes от всех облачных провайдеров. Это упростит развёртывание.
• Используйте пользовательское развёртывание Kubernetes. Оно будет связано с:использованием kops для установки пользовательского кластера Kubernetes;использованием инфраструктуры от выбранного поставщика.

Это позволит кластерам быть едиными для всех облачных провайдеров и обеспечит повышенную гибкость для уникальных сценариев развёртывания.

В дополнение к этому, kops-интеграция позволит командам использовать kubeCDN с локальным оборудованием. Это устранит все сторонние зависимости. Вариант с kops кажется самым подходящим для долгосрочного проекта, но его внедрение — непростое дело и требует обширной разработки.

Региональное автомасштабирование

Глобальное масштабирование инфраструктуры значительно улучшает UX. Но круглосуточный её запуск во многих частях мира может и не потребоваться. Иногда с точки зрения прибыли лучше, чтобы у незначительного количества пользователей была задержка.

Такая оптимизация стоимости инфраструктуры может быть очень выгодной, но чтобы понять, так это или нет, потребуется мониторинг выбранной метрики. Когда этот показатель достигает заданного порогового значения в регионе, инфраструктура может быть демонтирована. Если же наблюдается всплеск пользователей из определённого региона, аналогичные пороговые значения могут использоваться для автоматического ускорения инфраструктуры в предварительно утверждённой области. Ближе к месту, где идентифицирован всплеск пользователей.

Список предопределённых регионов

Текущая версия kubeCDN упростила развёртывание кластеров EKS в новых регионах. Тем не менее, чтобы добиться этого, есть способы получше, чем текущий метод репликации трёх строк кода для каждого региона.

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

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

Выводы

Текущая версия kubeCDN упрощает георепликацию кластеров Kubernetes и позволяет легко масштабировать приложение. Будучи самостоятельно размещённым, kubeCDN учитывает уникальные требования инфраструктуры и обеспечивает максимальную гибкость для управления ей.

Однако существуют возможности для улучшения, которые сделали бы kubeCDN более надёжным инструментом, а создание federation-v2 может кардинально изменить функции и особенности kubeCDN в будущем.