Kraken — P2P-powered Docker реестр, ориентированный на масштабируемость и доступность

Kraken — это Docker реестр с P2P архитектурой, который фокусируется на масштабируемости и доступности. Он предназначен для управления образами Docker, репликации и распространения в гибридной облачной среде. Благодаря поддержке подключаемых бэкэндов, Kraken легко интегрируется в существующие настройки Docker реестра в качестве слоя распространения.

Kraken используется в Uber с начала 2018 года. В самом загруженном кластере Kraken распространяет более миллиона больших двоичных объектов (blobs) в день, включая 100 тысяч объектов размером более 1 ГБ. При пиковой нагрузке Kraken может распространять 20 тысяч объектов размером от 100 МБ до 1 ГБ менее чем за 30 секунд.

Визуализация работы небольшого кластера Kraken:

Содержание

• Особенности
• Дизайн
• Архитектура
• Тестирование производительности
• Использование
• Сравнение с другими проектами
• Ограничения
• Вклад в проект
• Контакты

Особенности

Вот некоторые особенности Kraken:

• Высокая масштабируемость. Kraken способен распространять образы Docker со скоростью более 50% от максимального предела скорости загрузки на каждом хосте. Размер кластера и размер образа не оказывают существенного влияния на скорость загрузки.
• Поддерживает по крайней мере 15 тысяч хостов на кластер.
• Поддерживает произвольно большие blobs/layers. Обычно мы ограничиваем максимальный размер 20 ГБ для лучшей производительности.
• Высокая доступность. Ни один компонент не является единственной точкой отказа.
• Безопасность. Поддерживает аутентификацию отправителя и защиту целостности данных через TLS.
• Настраиваемые параметры хранения. Вместо управления данными, Kraken подключается к надёжным вариантам хранения blob, таким как S3, GCS, ECR, HDFS или другой реестр. Интерфейс хранилища прост, и новые варианты легко добавить.
• Беспроигрышная кросс-кластерная репликация. Kraken поддерживает асинхронную репликацию на основе правил между кластерами.
• Минимальные зависимости. Помимо настраиваемого хранилища, Kraken имеет только необязательную зависимость от DNS.

Дизайн

Основная идея Kraken заключается в том, чтобы иметь небольшое количество выделенных хостов, которые распространяют контент в сети агентов, работающих на каждом хосте в кластере.

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

Такой граф имеет высокую связность и небольшой диаметр. В результате даже при наличии одного сеялки и тысяч пиров, присоединяющихся одновременно, все участники могут достичь минимум 80% максимальной скорости загрузки/выгрузки в теории (60% с текущей реализацией), и производительность не сильно ухудшается по мере увеличения размера blob и размера кластера. Для получения более подробной информации см. технический доклад команды на KubeCon + CloudNativeCon.

Архитектура

• Агент
  • Развёртывается на каждом хосте
  • Реализует интерфейс Docker реестра
  • Объявляет доступный контент трекеру
  • Подключается к пирам, возвращаемым трекером, для загрузки контента
• Источник
  • Выделенные сеялки
  • Хранит blobs в виде файлов на диске, поддерживаемых настраиваемым хранилищем (например, S3, GCS, ECR)
  • Формирует самовосстанавливающееся хэш-кольцо для распределения нагрузки
• Трекер
  • Отслеживает, какие пиры имеют какой контент (как текущий, так и завершённый)
  • Предоставляет упорядоченные списки пиров для подключения к любому данному blob
• Прокси
  • Реализует Docker Репликация в мультикластерной конфигурации: рассмотрите возможность настройки ещё одного реестра Docker в качестве бэкенда Kraken.

Теоретически, Kraken должен распределять большие двоичные объекты (blob) любого размера без существенного снижения производительности. Однако в Uber мы устанавливаем ограничение в 20 ГБ и не можем рекомендовать использование сверхбольших blob-объектов (например, размером более 100 ГБ) в продакшене. Пиры устанавливают ограничения на соединения для каждого большого двоичного объекта, и новые пиры могут испытывать нехватку соединений, если другие пиры не станут сидерами относительно скоро. Если вы хотите распространять сверхбольшие большие двоичные объекты, мы рекомендуем сначала разбить их на фрагменты размером менее 10 ГБ.

Contributing

Пожалуйста, ознакомьтесь с нашим руководством (docs/CONTRIBUTING.md).

Contact

Чтобы связаться с нами, присоединяйтесь к нашему каналу Slack (https://join.slack.com/t/uber-container-tools/shared_invite/enQtNTIxODAwMDEzNjM1LWIwYzIxNmUwOGY3MmVmM2MxYTczOTQ4ZDU0YjAxMTA0NDgyNzdlZTA4ZWVkZGNlMDUzZDA1ZTJiZTQ4ZDY0YTM).