Филипп Федоров

S3 — не самое быстрое хранилище и подходит не для всех задач. Но это отличный вариант, если нужно организовать надежное и масштабируемое пространство для данных большого объема. По этой причине S3 часто используют в качестве хранилища для приложений, развернутых в Kubernetes. Меня зовут Филипп Федоров, я DevOps-инженер в Selectel. В своей обзорной статье хочу разобрать, какие есть решения для работы с объектным хранилищем из K8s. Соберу тестовый стенд из кластера Managed Kubernetes и покажу, как установить и настроить нужные компоненты через Terraform. Начинаем! Знакомство с CSI: что это и когда использовать CSI полезен для администраторов и разработчиков, которые стремятся автоматизировать и упростить управление хранилищами данных в облачных и локальных средах. Это особенно актуально для крупных проектов с высокими требованиями к масштабируемости и надежности, где необходимо использовать разнообразные системы хранения без создания уникальных решений. CSI позволяет легко добавлять или менять хранилища данных по мере развития инфраструктуры. Кроме того, CSI-драйверы развиваются независимо от ядра Kubernetes и работают в пользовательском пространстве. Это значит, что они не требуют изменений в коде K8s для добавления новых функций или исправлений. Такой подход снижает риски безопасности, так как уязвимости в CSI-драйверах напрямую не влияют на Kubernetes. А еще это позволяет быстро реагировать на изменения в требованиях к хранению данных, развивать и обновлять драйверы отдельно от основного кода K8s. Из чего состоит CSI CSI можно разделить на компоненты, которые разрабатывают Kubernetes и сторонние поставщики хранилищ. Компоненты от Kubernetes Driver registrar — регистрирует CSI-драйверы в kubelet. External provisioner — обрабатывает запросы на создание и удаление томов. External attacher — управляет монтированием и размонтированием томов. Компоненты от сторонних поставщиков CSI Identity — проверяет и возвращает информацию о плагине. CSI Controller — управляет жизненным циклом томов. CSI Node — управляет монтированием и размонтированием томов на узлах. Но как работает CSI на практике? Подготовим инфраструктуру и протестируем подключение к S3 из Kubernetes. Подготовка инфраструктуры Первым делом нужно создать сервисного пользователя в панели управления Selectel. И установить роли «Администратор аккаунта» и «Администратор пользователей». О том, как это сделать, мы подробно рассказали в документации. Этот этап нужен для инициализации Terraform-провайдера Selectel, в который далее передадим логин и пароль. Чтобы не писать самостоятельно большие портянки с кодом Terraform, воспользуемся кодом из публичного репозитория GitHub. Клонируем его и вносим некоторые коррективы. Далее пошагово опишу, что нужно будет сделать. 1. Клонируйте репозиторий к себе и перейдите в созданную папку: 2. В main.tf закомментируйте все модули и ресурсы, кроме project-with-user, mks и s3-credentials. 3. Если нужно, измените имя проекта, пользователя, регион и требуемую конфигурацию для системной группы нод. 4. В качестве версии Managed Kubernetes укажите доступную версию. По завершении должен получиться главный файл main.tf следущего вида: 5. Немного модифицируем код Terraform, чтобы мы могли устанавливать компоненты (по сути, Helm-чарты), используя Terraform-провайдер Helm. Добавим в файл providers.tf инициализацию helm-tf-провайдера: На мой взгляд это очень удобно для тестирования, ведь мы можем описывать все в одном месте в коде Terraform. 6. Далее проверим конфигурацию — для этого выполним пару Terraform-команд. Инициализируем конфигурацию и проверим, какие изменения Terraform планирует внести в инфраструктуру: В конце вывода команды terraform plan вы должны увидеть, что будет создано n ресурсов: 7. Теперь применим конфигурацию и подтвердим изменения: В результате Terraform развернет все необходимое для тестового стенда: проект, сервисного пользователя, S3-контейнер, S3-ключ, кластер и ноды MKs и сеть для MKs. Для выполнения команды kubectl и, например, доступа к кластеру через Lens, понадобится kube_config файл, который можно получать через панель управления. По готовности можно перейти дальше и начать уже знакомиться с CSI-драйверами для S3. Как и отмечал ранее, рекомендую устанавливать чарты с помощью terraform provider helm — так вы получите описание проекта в одном месте. Но никто не запрещает устанавливать Helm-чарты через сам Helm. Обзор сtrox/csi-s3 GitHub-репозиторий → Неофициальный Helm-чарт → Особенности 1. Инструмент поддерживает различные S3-совместимые хранилища. 2. Ctrox/csi-s3 позволяет монтировать S3-контейнеры в виде файловой системы. Это хорошо, если нужно обеспечить прямой доступ к данным в хранилище с подов в Kubernetes, например, для обработки или анализа данных в реальном времени. Без предварительного скачивания и локального хранения этих данных. 3. Поддерживает «маунтеры»: rclone, s3fs, goofys и s3backer. Вы можете выбрать наиболее подходящий инструмент. rclone — универсальный инструмент для синхронизации и монтирования различных облачных хранилищ. s3fs — позволяет монтировать S3-хранилища как файловую систему, используя FUSE. goofys — оптимизирован для высокопроизводительного чтения данных из S3. Далее будем тестировать этот вариант. s3backer (experimental*) — позволяет использовать S3 как блочное устройство. 4. Ctrox/csi-s3 редко обновляется. Крайние апдейты были около двух лет назад.5. Нет официального Helm-чарта, но можно использовать компонент от Cloudve. Установка 1. Добавим ресурс helm_release и опишем переменную values. Достаточно в main.tf вписать следующий код Terraform: Важно: данные для подключения к S3 можно получить из вывода модуля s3-creds. Но помните, что они хранятся в стейте и никак не защищены. 2. Далее применим код Terraform и дождемся, пока все запустится: 3. Также понадобится подправить cluster-role с именем external-attacher-runner и добавить в него api-group. Выполним команду kubectl: Тестирование Для тестирования будем использовать утилиту fio в поде. К контейнеру с ней смонтируем PVC по пути /mnt. Вот пример создания PVC и пода с запуском fio: Результаты тестирования можно посмотреть в логах пода: Результаты Преобразуем вывод команды fio в таблицу, в которой укажем следующие параметры. Пропускная способность (BW, Bandwidth) — скорость передачи данных, измеряемая в MiB/s (мебибайтах в секунду) или MB/s (мегабайтах в секунду). Указывает, сколько данных можно передать за определенный промежуток времени. Средняя задержка (clat) — среднее время задержки (latency) для выполнения операций ввода-вывода, измеряемое в микросекундах (мкс) или наносекундах (нс). Чем ниже значение, тем быстрее система обрабатывает запросы. Пиковая задержка (max clat) — максимальное время задержки, зарегистрированное во время теста. Пиковое значение показывает наихудший случай времени ожидания для операции ввода-вывода. BS-size (размер блока) — размер блока данных, используемый в тесте ввода-вывода. Например, 4k (килобайты) или 2M (мегабайты). Различные размеры блоков могут влиять на производительность системы в зависимости от конфигурации и типов рабочих нагрузок. #ОперацияПропускная способность (BW)Средняя задержка (clat)Пиковая задержка (max clat)BS-sizectrox/csi-s3 (Goofys)Чтение355 MiB/s (372 MB/s)10,24 мкс300,555 мс4kctrox/csi-s3 (Goofys)Запись44,1 MiB/s (46,3 MB/s)87,78 мкс121,541 мс4k Первое тестирование ctrox/csi-s3 с маунтером Goofys показало хорошие результаты для чтения. CSI достигла скорости 355 MiB/s (372 MB/s) и 10,24 мкс avg clat. Однако запись оказалась медленнее: 44,1 MiB/s (46,3 MB/s) и 87,78 мкс avg clat. Обзор yandex-cloud/k8s-csi-s3 GitHub-репозиторий → Официальный Helm-чарт → Особенности GeeseFS — высокопроизводительный файловый монтировщик через FUSE для S3-совместимых хранилищ. И все особенности завязаны на нем. Производительность. GeeseFS быстрее традиционных монтировщиков вроде s3fs. Все это — благодаря оптимизированному коду, который минимизирует количество операций чтения и записи. Подробнее о тестах производительности читайте в репозитории на GitHub. Частичное изменение и дозапись объектов. Вы можете хранить в контейнере данные, например логи, в виде единого файла, периодически дописывая информацию. Также упрощается работа с большими файлами. Остальные особенности хорошо описаны в документации. Установка Важно: перед установкой необходимо удалить все, что связано с ctrox. 1. Клонируем репозиторий и при описании helm_release укажем локальное расположение Helm-чарта: 2. Применим код Terraform и проверим, что поды успешно запустились: Если все поды успешно запустились, можем переходить к тестированию. Тестирование Выполним тест с запуском пода c fio. Применим манифест: Вытащим из логов контейнера необходимые значения и зафиксируем их в таблице: Результаты #ОперацияПропускная способность (BW)Средняя задержка (clat)Пиковая задержка (max clat)BS-sizeyandex-csi-s3 (GeeseFS)Чтение446 MiB/s (468 MB/s)8,04 мкс16,91 мс4kyandex-csi-s3 (GeeseFS)Запись24,7 MiB/s (25,9 MB/s)157,36 мкс8,982 мс4k GeeseFs показал себя лучше в чтении, где скорость достигла 446 MiB/s (468 MB/s) и 8,04 мкс avg clat. Однако запись оказалась в 2 раза медленней: 24,7 MiB/s (25,9 MB/s) и 157,36 мкс avg clat. Выводы и заключение Давайте объединим результаты операций чтения/записи маунтерами Goofys и GeeseFS и сделаем общие выводы. #ОперацияПропускная способность (BW)Средняя задержка (clat)Пиковая задержка (max clat)BS-sizectrox/csi-s3 (Goofys)Чтение355 MiB/s (372 MB/s)10,24 мкс300,555 мс4kctrox/csi-s3 (Goofys)Запись44,1 MiB/s (46.3 MB/s)87,78 мкс121,541 мс4kyandex-csi-s3 (GeeseFS)Чтение446 MiB/s (468 MB/s)8,04 мкс16,91 мс4kyandex-csi-s3 (GeeseFS)Запись24.7 MiB/s (25.9 MB/s)157,36 мкс8,982 мс4k Общий анализ Пропускная способность (BW) Чтение. GeeseFS показал лучшую пропускную способность по сравнению с Goofys. Показатель GeeseFS достиг 446 MiB/s (468 MB/s), в то время как для Goofys он же составляет 355 MiB/s (372 MB/s). Запись. Снова GeeseFS показал лучшие результаты с пропускной способностью: 24,7 MiB/s (25.9 MB/s) против 44,1 MiB/s (46,3 MB/s). Это указывает на лучшую оптимизацию чтения у GeeseFS. Средняя задержка (clat) Чтение. GeeseFS показал более низкую среднюю задержку (8,04 мкс) по сравнению с Goofys (10,24 мкс), что свидетельствует о более быстрой обработке запросов чтения. Запись. Goofys показал лучшую производительность с задержкой 87,78 мкс против 157,36 мкс у GeeseFS. Это может быть связано с оптимизацией записи у Goofys. Пиковая задержка (max clat): Чтение. GeeseFS демонстрировал более стабильную производительность с пиковым значением 16.91 мс против 300.555 мс у Goofys. Запись. Пиковое значение задержки составило 8.982 мс у GeeseFS по сравнению с 121.541 мс у Goofys.