Будівництво пайплайну для кількох архітектур контейнерів за допомогою Argo та Kaniko на Kubernetes - javascript.org.ua

текст перекладу
Автор: Йоссі Коен
Головний інженер із розробки програмного забезпечення, спеціалізується на хмарній інфраструктурі, DevOps і спостережуваності на основі Cloud Native Infra. Створює масштабовані рішення з акцентом на оркестрацію контейнерів та автоматизацію.

Створено за допомогою claud ai

Вступ

У світі хмарних додатків, що постійно розвивається, підтримка кількох архітектур процесорів стає все важливішою. Завдяки зростаючому впровадженню ARM-інстансів у хмарних провайдерів, таких як AWS, організації можуть досягти значної економії (приблизно 15%) шляхом оптимізації своїх робочих навантажень для архітектури ARM64. У цьому пості я поділюся тим, як ми реалізували складний процес створення контейнерних образів для кількох архітектур за допомогою ArgoWorkflows, Kaniko та Buildah, що працюють повністю на Kubernetes.

Майбутнє хмарних обчислень полягає в оптимізації як для продуктивності, так і для вартості. Підтримка кількох архітектур більше не є варіантом — це необхідність для сучасної хмарної інфраструктури.

Завдання

Міграція з нашого попереднього налаштування принесла кілька викликів:

Потреба в ефективному створенні контейнерів для кількох архітектур (ARM64 та AMD64)
Обробка кількох образів для кожного репозиторію в підтримуваному вигляді
Масштабування з ростом кількості наших сервісів
Забезпечення надійної спостережуваності та обробки помилок
Мета — перехід на 100% ARM64 для оптимізації вартості (ціль економії 15%)

Архітектура рішення

Наше рішення реалізує підхід з двоступеневим процесом.

Ось загальний огляд:

Безпека та масштабованість — це не функції, які додаються до конвеєра, а основні принципи, на яких ви будуєте все з самого початку.

Компоненти процесу

GitHub Trigger Pipeline

GitHub WebHook до Argo EventSource->Sensor->Argo-Workflow

Процес побудови та пушу

HTTP WebHook до Argo EventSource->Sensor->Argo-Workflow

Структура Workflow DAG

Нижче показана базова структура процесу Build-push.
Ми бачимо, що arm64 і amd64 обробляються паралельно, і весь процес паралельний до схожих процесів за потребою і масштабується за запитами.

Процес Build-Push

Деталі реалізації

1. Налаштування метаданих

Конфігурація процесу зберігається в централізованому репозиторії (build-push) в папці repository-meta-data.
Кожен репозиторій має свій файл метаданих (metadata-multi.yaml) з такою структурою:

Примітка: Я видалив розділ PostProcess, який займається обробкою поведінки gitops CD.

Безпека

Безпека є критичним аспектом нашого процесу побудови контейнерів.
текст перекладу
Ми впроваджуємо специфічні контексти безпеки для Buildah та Kaniko, ретельно балансуючи вимоги безпеки та функціональні потреби.

У побудові контейнерів безпека — це не обмеження, а можливість для команд рухатись швидко та з упевненістю.

Контекст безпеки для Buildah

securityContext:  
 allowPrivilegeEscalation: false  
 readOnlyRootFilesystem: false  
 runAsUser: 65533  
 runAsGroup: 10001  
 capabilities:  
 drop:  
 - ALL

Ця конфігурація реалізує кілька кращих практик безпеки:

Запобігання ескалації привілеїв

allowPrivilegeEscalation: false запобігає процесу отримати більше привілеїв, ніж у його батьківського процесу
Зберігає принцип мінімальних привілеїв

Виконання від імені користувача, що не має прав root

runAsUser: 65533 гарантує, що контейнер буде запущений від користувача, який не має прав root
runAsGroup: 10001 налаштовує групу, яка не має прав root
Мінімізує потенційний вплив витоків контейнера

Мінімальні можливості

За замовчуванням скидаються всі можливості
Забезпечує максимальну безпеку для процесу побудови

Контекст безпеки для Kaniko

securityContext:  
allowPrivilegeEscalation: false  
runAsNonRoot: false  
capabilities:  
drop:  
 - ALL  
add:  
 - CHOWN  
 - FOWNER  
 - DAC_OVERRIDE  
 - SETUID  
 - SETGID

Kaniko потребує специфічних можливостей для своєї роботи:

Управління можливостями

Спочатку скидаються ВСІ можливості для чистого початку, потім вибірково додаються тільки необхідні можливості:

CHOWN: Зміна власності файлів
FOWNER: Оминання перевірок власності
DACOVERRIDE_: Оминання перевірок прав доступу до файлів (читання/запис/виконання)
SETUID/SETGID: Зміна ідентифікаторів користувача/групи

Виконання від root

Хоча runAsNonRoot: false необхідно для певних операцій
Компенсується скиданням непотрібних можливостей
Строгий контроль над ескалацією привілеїв

Структури Pod у Kubernetes

Pod для побудови образу (Kaniko)

Структура Pod для Kaniko

Приклад використання Kaniko

Pod для індексу образів (Buildah)

Структура Pod для Buildah

Процес побудови для кількох архітектур

Процес побудови складається з таких кроків:

1. Ініціалізація тригера

GitHub webhook тригерить процес
ArgoEvents обробляє webhook
Метадані отримуються та перевіряються

2. Ініціалізація процесу побудови

Для кожного образу тригеряться окремі процеси побудови
Побудова для кожної архітектури виконується паралельно
Ресурси виділяються в залежності від потреб архітектури

3. Побудова образу (Kaniko)

Завантажує вихідний код
Створює образи для кожної архітектури
Тегує образи архітектурно-специфічними тегами

4. Створення індексу образу (Buildah)
Створення маніфесту через buildah, що містить посилання на специфічні образи архітектур.

echo $TOKEN | buildah login --username AWS --password-stdin ".dkr.ecr.us-east-1.amazonaws.com"  
buildah manifest create "${image_index}"  
buildah manifest add "${image_index}" "${image_index}-arm64"  
buildah manifest add "${image_index}" "${image_index}-amd64"  
buildah manifest push "${image_index}"

Спостережуваність і обробка помилок

Наш процес включає всебічну спостережуваність:

Сповіщення в Slack про статус побудови
Логи побудови експортуються в OpenSearch
Спостережуваність на основі eBPF для системних інсайтів
Автоматичні повтори за допомогою механізму повтору Argo-Workflows
Внутрішнє виявлення сервісів Kubernetes для міжсервісної комунікації

Результати та переваги

Ця реалізація принесла кілька ключових переваг:

Оптимізація витрат

Підтримка побудови для ARM64 дозволяє досягти економії в ~15% на інфраструктурних витратах
Ефективне використання ресурсів завдяки паралельній обробці

2. Легкість підтримки

Підхід, орієнтований на метадані, спрощує налаштування
Централізовані конфігурації зменшують навантаження
Чітке розмежування між процесами
текст перекладу

Масштабованість
Ефективно обробляє кілька образів на репозиторій
Паралельна обробка побудови для кожної архітектури
Масштабованість, властива Kubernetes

Майбутні покращення

Ми розглядаємо кілька вдосконалень:

Оптимізація побудови

Покращення кешування шарів
Перевикористання артефактів побудови
Метрики продуктивності пайплайнів

Покращення безпеки

Інтеграція сканування вразливостей
Перевірка підписів
Удосконалення RBAC

Висновок

Комбінуючи ArgoWorkflows, Kaniko та Buildah, ми створили надійний, масштабований пайплайн для побудови контейнерних образів для кількох архітектур. Підхід, орієнтований на метадані, надає гнучкість, зберігаючи простоту, а можливості паралельної обробки забезпечують ефективне використання ресурсів.

Це рішення дозволило нам ефективно підтримувати архітектуру ARM64, що призвело до значних заощаджень на витратах при збереженні чистого, зручного для підтримки та масштабованого процесу побудови.

Чи впроваджували ви побудови для кількох архітектур у вашій організації? З якими труднощами ви стикалися? Поділіться своїм досвідом у коментарях нижче.

Перекладено з: Building a Multi-Architecture Container Pipeline with Argo and Kaniko on Kubernetes