25 новых проектов в песочнице CNCF: мегаобзор / forpes.ru

Главная
25 новых проектов в песочнице CNCF: мегаобзор

25 новых проектов в песочнице CNCF: мегаобзор

20.06.2024 06:21

Zhbert 1 3000 Источник

Cloud Native Computing Foundation (CNCF) — международная некоммерческая организация, основанная The Linux Foundation в 2015 году. Её основные цели — содействие развитию контейнерных технологий и координация технической отрасли вокруг них. В число учредителей входят такие компании, как Google, CoreOS, Mesosphere, Red Hat, Twitter, Huawei, Intel, RX-M, Cisco, IBM, Docker, Univa и VMware. На сегодняшний день CNCF поддерживают более 450 членов.

CNCF Sandbox (или песочница CNCF) — это место, куда попадают новые проекты на ранней стадии развития. Например, на момент написания статьи в ней заходятся 113 проектов, один из которых — werf, проект нашей компании, в декабре 2022 года ставший частью CNCF.

В этой статье мы посмотрим на другие проекты, попавшие в CNCF Sandbox за последний год — с января 2023 года.

Содержание

Clusternet
Copa
Easegress
Eraser
Headlamp
HwameiStor
Inspektor Gadget
K8sGPT
Kanister
KCL
kcp
Kepler
kpt
Krkn
Kuasar
Kube-burner
KubeClipper
KubeStellar
Logging Operator
Microcks
PipeCD
SlimToolkit
SOPS
Spiderpool
Xline
Заключение
P. S.

Clusternet

Clusternet — проект, который позволяет управлять кластерами Kubernetes «так же просто, как сходить в интернет». Система обеспечивает единство управления в различных окружениях, как если бы кластеры были развернуты локально. Она предоставляет API в стиле Kubernetes с генерацией kubeconfig. Это позволяет настроить привычный доступ к любому кластеру, подключенному к системе.

Технически она представляет собой расширение Kubernetes, которое устанавливают в родительский кластер, и агенты, устанавливаемые в дочерние кластеры. Управление дочерними кластерами происходит через запросы к API родительского кластера и является полностью прозрачным для пользователей.

Clusternet состоит из четырёх компонентов:

clusternet-agent:
- автоматически регистрирует кластер в родительском в качестве дочернего, также называемого ManagedCluster;
- пересылает информацию о состоянии дочернего кластера — версию Kubernetes, платформу, на которой работает кластер, статусы healthz/readyz/livez и так далее;
- настраивает соединение через веб-сокет, обеспечивающее двусторонние каналы связи поверх TCP с родительским кластером.
clusternet-scheduler:
- отвечает за планирование ресурсов для соответствующих дочерних кластеров на основе SchedulingStrategy.
clusternet-controller:
- утверждает запросы на регистрацию кластера и создание выделенных ресурсов, таких как пространства имён, учетные записи служб и RBAC-правила для каждого дочернего кластера;
- координирует и развёртывает приложения в нескольких кластерах с помощью единого API.
clusternet-hub:
- выполняет функции единого сборного API-сервера, который используется для предоставления shadow API, и служит сервером веб-сокетов, который поддерживает несколько активных соединений с дочерними кластерами;
- предоставляет API в стиле Kubernetes для перенаправления, проксирования или обновления запросов к каждому дочернему кластеру.

Из особенностей:

Поддерживаются платформы linux/amd64, linux/arm64, linux/ppc64le, linux/s390x, linux/386 и linux/arm.
Возможна установка в кластеры облачных провайдеров, таких как AWS, Google Cloud, Tencent Cloud, Alibaba Cloud и другие.
Поддерживается установка в K3s.
Родительский кластер также может зарегистрироваться в качестве дочернего для выполнения рабочих задач.

Подробнее ознакомиться с проектом можно в официальной документации. Для установки также есть отдельная инструкция с тремя версиями установки: как Helm-чарт, вручную или в K3s. Проект доступен на GitHub под лицензией Apache 2.0.

Copa

Copa — CLI-утилита для прямого исправления образов контейнеров с использованием отчётов сканеров уязвимостей. В качестве источника информации об уязвимостях используется популярный инструмент Trivy.

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

Copa предоставляет свой путь решения таких проблем:

Такой метод даёт следующие преимущества:

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

Механизм работы утилиты изображён на схеме:

Он состоит из нескольких шагов:

Анализируются необходимые пакеты обновлений из отчёта об уязвимостях для образа контейнера, созданного сканером Trivy.
Получаются и обрабатываются необходимые пакеты обновлений с помощью соответствующих пакетных менеджеров, таких как apt, apk и т. д.
Применяются полученные файлы обновления к образу контейнера с помощью buildkit.

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

Подробнее с утилитой можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.

Easegress

Easegress (ранее Ease Gateway) — это система облачной оркестрации трафика. Она позволяет повысить доступность и стабильность работы сервисов, а также улучшить производительность без изменений в коде проекта.

Система может выступать в роли шлюза для API и service mesh, осуществлять оркестрацию трафика и запросов API, настраивать canary-разработку и выступать в роли агрегатора API-запросов для нескольких API. В неё встроены механизмы для автоматической помощи веб-сайтам в оптимизации производительности, например в добавлении кэша, объединении запросов и уменьшении пропускной способности сети.

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

Основные особенности:

Высокая доступность. Встроенный механизм на основе консенсусного алгоритма Raft позволяет достичь доступность сервисов в районе 99,99%.
Оркестрация трафика. Простая настройка фильтров для трафика в различных пайплайнах.
Высокая производительность. Множество лёгких и функциональных возможностей ускоряет работу сервисов.
Наблюдаемость. Периодическая генерация содержательных отчётов в удобной для чтения форме.
Расширяемость. Есть возможность написать собственные фильтры под свои задачи.
Интеграция. Простые интерфейсы облегчают интеграцию с другими системами, такими как Kubernetes Ingress, EaseMesh Sidecar, Workflow и так далее.

Доступные функции:

Поддержка нескольких протоколов: HTTP/1.1, HTTP/2, HTTP/3(QUIC), MQTT.
Богатые правила маршрутизации: полные пути, префикс пути, регулярные выражения, методы, заголовки, IP-адреса клиента.
Устойчивость и отказоустойчивость:
- CircuitBreaker: временно блокирует возможные сбои.
- RateLimiter: ограничивает скорость входящих запросов.
- Retry: повторяет неудачные выполнения.
- TimeLimiter: ограничивает продолжительность выполнения.
Управление развёртыванием:
- Blue-green Strategy: переключает трафик одновременно.
- Canary Strategy: слегка планирует движение.
Управление API:
- Агрегация API: объединяет результаты нескольких API.
- Оркестрация API: организует потоки API.
Безопасность:
- IP-фильтр: ограничивает доступ к IP-адресам.
- Статический HTTPS: статические файлы сертификатов.
- API Signature: поддерживает проверку HMAC.
- JWT Verification: проверяет токен JWT.
- OAuth2: проверяет запросы OAuth/2.
- Let's Encrypt: автоматическое управление файлами сертификатов.
Управление фильтрами: упрощает разработку новых фильтров.
Service mesh:
- Mesh Master: control plane для управления жизненным циклом сетевых сервисов.
- Mesh Sidecar: data plane в качестве конечной точки для перехвата и маршрутизации трафика.
- Mesh Ingress Controller: специфичный входной контроллер для маршрутизации внешнего трафика к mesh-сервисам.
Интеграция:
- FaaS интегрируется с бессерверной платформой Knative.
- Service Discovery интегрируется с Eureka, Consul, Etcd и Zookeeper.
- Ingress Controller интегрируется с Kubernetes в качестве входного контроллера.
Высокая производительность и доступность:
- Адаптация: адаптирует запрос и ответ в цепочке обработки.
- Проверка: проверка заголовков, OAuth2, JWT и HMAC.
- Балансировка нагрузки: циклическая, случайная, взвешенная случайная, хэш IP-адресов, хэш заголовка и поддержка закреплённых сеансов.
- Кэш: для внутренних серверов.
- Сжатие: сжимает тело ответа.
- Горячее обновление: обновляет конфигурацию и исполняемые файлы Easegress в горячем режиме без потери соединений.

Подробнее ознакомиться с возможностями системы можно в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.

Eraser

Eraser помогает администраторам Kubernetes-кластеров удалять незапущенные образы на всех узлах кластера.

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

Eraser поддерживает два режима работы: ручной и автоматический. Для ручного запуска нужно указать перечень образов, которые нужно удалить. Автоматическая очистка производится по таймеру. По умолчанию автоматический процесс удаляет образы на основе результатов сканирования уязвимостей, используя в качестве сканера Trivy. Функцию проверки уязвимостей можно отключить, и тогда Eraser будет работать как обычный сборщик мусора.

На рисунке ниже представлена схема ручного запуска очистки:

А вот так выглядит работа по таймеру:

Сканирование с помощью Trivy позволяет удалять образы, у которых есть критические уязвимости. При этом следует помнить, что удалены будут только не работающие в данный момент образы.

Основное отличие Eraser от штатной очистки мусора в кластере Kubernetes состоит в том, что последняя запускается только при достижении заполненности свободного места в 85% и прекращается при достижении 80%. Eraser же можно гибко конфигурировать или использовать в полностью автоматическом режиме с учётом требований безопасности.

Headlamp

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

Особенности:

Независимый от поставщика универсальный пользовательский интерфейс Kubernetes.
Работает в кластере или локально, как десктопное приложение.
Поддерживает мультикластерную работу.
Расширяем через плагины.
Элементы управления пользовательского интерфейса учитывают RBAC-роли пользователей (удаление/обновление запрещено, если это не разрешено).
Чистый и современный интерфейс.
Отменяемые операции создания/обновления/удаления.
Логи, exec и редактор ресурсов с документацией.

Несколько скриншотов интерфейса:

HwameiStor

HwameiStor — гибкая локальная система хранения данных с отслеживанием состояния для облачных решений.

HwameiStor создаёт локальный пул ресурсов для централизованного управления всеми дисками, такими как HDD, SSD и NVMe. Он использует CSI-архитектуру для предоставления распределённых сервисов с локальными томами и обеспечивает возможность постоянного хранения данных для облаков или компонентов с отслеживанием состояния.

Это лёгкая и экономичная локальная система хранения с открытым исходным кодом, которая может заменить дорогостоящие хранилища наподобие SAN. Системная архитектура HwameiStor выглядит следующим образом:

С помощью шаблонов CAS пользователи могут добиться повышения производительности, экономической эффективности и упрощения управления хранилищем контейнеров. Его можно развернуть с помощью Helm-чартов или напрямую использовать независимую установку.

Основные особенности:

Автоматизированное обслуживание:
- диски можно автоматически обнаруживать, идентифицировать, управлять ими и выделять их под задачи;
- интеллектуальное планирование приложений и данных на основе affinity;
- автоматическое отслеживание состояния диска и заблаговременное предупреждение о возможных проблемах.
Используются межузловые реплики для синхронизации данных и обеспечения режима высокой доступности. При возникновении проблемы приложение будет автоматически переведено на узел данных высокой доступности, чтобы обеспечить непрерывность работы.
Объединение жёстких дисков, твердотельных накопителей и дисков NVMe для предоставления услуг передачи данных с малой задержкой и высокой пропускной способностью.
Динамическое расширение кластера в соответствии с требованиями приложения к сохранению данных.

Inspektor Gadget

Inspektor Gadget — набор «гаджетов» на основе eBPF для отладки приложений и ресурсов в Kubernetes.

Они могут управлять упаковкой, развёртыванием и выполнением в кластере eBPF-программ, в том числе основанных на инструментах BCC. При этом низкоуровневые примитивы ядра автоматически сопоставляются с ресурсами Kubernetes высокого уровня, что упрощает и ускоряет поиск необходимой информации.

Inspektor Gadget развёртывается на каждом узле как DaemonSet. Он использует встроенные в ядро вспомогательные eBPF-программы для мониторинга событий, в основном связанных с системными вызовами из программ пользовательского пространства в поде. Программы eBPF запускаются ядром и собирают данные журнала. Утилиты пользовательского пространства Inspektor Gadget извлекают данные журнала из кольцевых буферов и отображают их.

Набор содержит следующие «гаджеты»:

advise:
- network-policy — отслеживает сетевую активность в указанных пространствах имён и записывает сводную информацию о трафике TCP и UDP в файл. Затем этот файл можно использовать для создания сетевых политик Kubernetes.
- seccomp-profile — записывает системные вызовы, которые выполняются в указанном поде, а затем использует эту информацию для создания соответствующего профиля seccomp. Он может интегрироваться с Kubernetes Security Profile Operator, напрямую генерируя необходимый seccompprofile ресурс.
audit:
- seccomp — предоставляет поток событий с системными вызовами, фильтры seccomp которых создают журнал аудита.
profile:
- block-io — собирает информацию об использовании блочного устройства ввода-вывода (дискового ввода-вывода), создавая гистограмму распределения задержки ввода-вывода (времени), когда гаджет остановлен.
- cpu — анализирует производительность ЦП путем выборки стектрейсов.
- tcprtt — генерирует гистограмму распределения времени Round-Trip Time (RTT) TCP-соединений. Значения RTT, используемые для создания гистограммы, собираются из сглаженной информации RTT, уже предоставленной ядром Linux для сокетов TCP.
snapshot:
- process — собирает информацию о запущенных процессах.
- socket — собирает информацию о сокетах TCP и UDP.
top:
- block-io — используется для визуализации контейнеров, генерирующих наибольшее количество входных/выходных данных блочных устройств.
- ebpf — используется для визуализации использования и производительности программ eBPF.
- file — используется для визуализации операций чтения и записи по файлам с подробной информацией о контейнере.
- tcp — используется для визуализации активных TCP-соединений.
trace:
- bind — используется для потоковой передачи системных вызовов привязки сокетов.
- capabilities — позволяет увидеть, какие проверки безопасности запускаются приложениями, работающими в подах Kubernetes.
- dns — выводит информацию о DNS-запросах и ответах, отправленных и полученных различными подами.
- exec — передаёт поток событий создания новых процессов.
- fsslower — передаёт потоковые операции с файлами (открытие, чтение, запись и fsync), которые выполняются медленнее порогового значения.
- mount — используется для мониторинга mount и umount системных вызовов.
- oomkill — используется для отслеживания случаев, когда OOM Killer из-за нехватки памяти убивает процесс.
- open — передаёт события, которые связаны с файлами, открытыми внутри подов.
- signal — используется для отслеживания системных сигналов, полученных подами.
- sni — используется для отслеживания запросов указания имени сервера (SNI), отправляемых в рамках рукопожатий TLS.
- tcp — используется для мониторинга TCP-соединений, показывает события подключения, принятия и закрытия, связанные с TCP-соединениями.
- tcpconnect — отслеживает вызовы TCP-соединения.
- tcpdrop — отслеживает TCP-пакеты, дропнутые ядром.
- tcpretrans — отслеживает повторные передачи TCP ядром.
script — позволяет запускать сценарии, совместимые с bpftrace, в кластере Kubernetes.
traceloop — используется для отслеживания системных вызовов, исходящих от контейнеров.

После установки в кластер вызывать все составляющие набора можно с помощью kubectl:

$ kubectl gadget --help
Collection of gadgets for Kubernetes developers

Usage:
  kubectl-gadget [command]

Available Commands:
  advise      Recommend system configurations based on collected information
  audit       Audit a subsystem
  completion  Generate the autocompletion script for the specified shell
  deploy      Deploy Inspektor Gadget on the cluster
  help        Help about any command
  profile     Profile different subsystems
  prometheus  Expose metrics using prometheus
  run         Run a gadget (experimental)
  script      Run a bpftrace-compatible scripts
  snapshot    Take a snapshot of a subsystem and print it
  sync        Synchronize gadget information with server
  top         Gather, sort and periodically report events according to a given criteria
  trace       Trace and print system events
  traceloop   Get strace-like logs of a container from the past
  undeploy    Undeploy Inspektor Gadget from cluster
  version     Show version

...

K8sGPT

K8sGPT — это инструмент для сканирования кластеров Kubernetes, диагностики и устранения проблем на простом английском языке. Разработчики вложили в анализаторы проекта свой SRE-опыт и приправили его возможностями искусственного интеллекта — в нём присутствуют интеграции с OpenAI, Azure, Cohere, Amazon Bedrock, Google Gemini и локальными моделями.

Установить K8sGPT можно как локально, так и в виде оператора в кластере. Второй вариант идеально подходит для непрерывного мониторинга кластера и может интегрироваться с существующими системами, такими как Prometheus и Alertmanager.

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

podAnalyzer;
pvcAnalyzer;
rsAnalyzer;
serviceAnalyzer;
eventAnalyzer;
ingressAnalyzer;
statefulSetAnalyzer;
deploymentAnalyzer;
cronJobAnalyzer;
nodeAnalyzer;
mutatingWebhookAnalyzer;
validatingWebhookAnalyzer.

Опционально можно включить дополнительные:

hpaAnalyzer;
pdbAnalyzer;
networkPolicyAnalyzer;
gatewayClass;
gateway;
httproute.

Когда мы установили и настроили бэкенд (доступ к нейросети), можно проанализировать кластер одной командой. Например, если создать заведомо нерабочий под, K8sGPT выдаст следующее:

$ k8sgpt analyze
0 default/broken-pod(broken-pod)
- Error: Back-off pulling image "nginx:1.a.b.c"

Kanister

Kanister — это инструмент управления процессами защиты данных. Он предоставляет набор связанных API-интерфейсов для определения и управления операциями с данными, абстрагируя детали выполнения операций с данными в Kubernetes. Он расширяем, прост в установке, эксплуатации и масштабировании.

Основные особенности:

Ориентированность на Kubernetes. API-интерфейсы реализованы в виде Custom Resources, которые соответствуют декларативным моделям управления, безопасности и распространения Kubernetes.
Независимость от хранилища. Позволяет эффективно и безопасно передавать данные резервного копирования между сервисами кластера и сервисом объектного хранилища по нашему выбору.
Асинхронное и синхронное выполнение задач. Может запланировать выполнение операции с данными асинхронно в выделенных подах или синхронно через ExecStream-фреймворк Kubernetes.
Артефакты рабочего процесса, допускающие повторное использование. Kanister можно повторно использовать в нескольких рабочих процессах для защиты развёртываний в различных средах.
Расширяемые, атомарные функции работы с данными. Предоставляет набор простых в использовании функций работы с данными. Их можно добавить в свой проект, чтобы описать подробные этапы операций резервного копирования и восстановления, включая уменьшение количества реплик перед резервным копированием, работу со всеми смонтированными томами в поде и так далее.
Защита с помощью RBAC. Предотвращает несанкционированный доступ к рабочим процессам с помощью модели управления доступом на основе ролей Kubernetes.
Наблюдаемость. Предоставляет журналы, события и метрики популярным инструментам наблюдения, таким как Prometheus, Grafana и Loki, чтобы предоставить оперативную информацию о рабочих процессах защиты данных.

Kanister представляет собой оператор Kubernetes, определяет свои ресурсы и взаимодействует с ними. Он состоит из трёх основных компонентов: контроллера и пользовательских ресурсов ActionSet и Blueprint. Схема ниже иллюстрирует их взаимосвязь и то, как они сочетаются друг с другом:

Все операции являются декларативными и требуют создания ActionSet. Как только ActionSet обнаруживается контроллером Kanister, он проверяет среду на наличие Blueprint, указанного в ActionSet (наряду с другой необходимой конфигурацией). Если все требования удовлетворены, он будет использовать обнаруженный Blueprint для выполнения действия (например, резервного копирования), указанного в ActionSet. Наконец, исходный ActionSet будет обновлен контроллером с учетом статуса и других метаданных, созданных при выполнении действия.

KCL

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

Этот язык можно использовать для:

создания низкоуровневых статических конфигураций, таких как JSON, YAML и так далее, или интеграции их с существующими данными;
уменьшения количества шаблонов в данных конфигурации с помощью моделирования схем;
определения схем с ограничениями правил для конфигураций и их автоматических проверок;
организации, упрощения, унификации и управления большими конфигурациями без побочных эффектов с помощью схем градиентной автоматизации и GitOps;
управления большими конфигурациями с возможностью масштабирования для различных сред с помощью изолированных блоков конфигурации;
изменения или проверки ресурсов Kubernetes с помощью плагинов облачных инструментов;
использования в качестве языка программирования для разработки платформ доставки современных приложений с помощью KusionStack.

Основные особенности:

Создан на основе языков высокого уровня, таких как Python и Golang, и включает в себя возможности функционального языка с низким уровнем побочных эффектов.
Имеет независимый синтаксис, семантику, среду выполнения и дизайн системных модулей, основанный на спецификациях.
Имеет готовые модули и типы конфигурации, ориентированные на схемы, а также модульную абстракцию.
Позволяет создавать конфигурации с типами, логикой и политикой на основе Config, Schema, Lambda, Rule.
Стабильность конфигурации достигается за счёт статической системы типов, ограничений и правил.
Обеспечивает высокую масштабируемость с помощью механизма автоматического слияния изолированных блоков конфигурации.
Имеет градиентную схему автоматизации CRUD API, SDK для различных языков программирования и плагинов.
Обеспечивает высокую производительность во время компиляции и выполнения с использованием Rust & C и LLVM, а также поддержку компиляции в собственный код и WASM.
Имеет встроенную поддержку OpenAPI, Kubernetes CRD, Kubernetes Resource Model (KRM).
Удобен для разработки с использованием богатых инструментов (Format, Lint, Test, Vet, Doc, инструменты управления пакетами и так далее) и нескольких расширений для IDE.
Прост в обслуживании и управлении.
Имеет поддержку Go, Python и Java.
Широко используется в продакшене при проектирования платформ и автоматизации в Ant Group.

kcp

kcp — горизонтально масштабируемый control plane для API-интерфейсов наподобие Kubernetes API. Он реализует полностью изолированные рабочие области, каждая из которых действует как отдельный кластер со своим URL-адресом, набором API (например, различными CRD), собственным RBAC, но столь же быстр и прост, как пространство имен.

kcp не заменяет Kubernetes, а дополняет его в качестве бэкенда для размещения API-интерфейсов в качестве SaaS. Это гибкая основа для создания платформ. Он распределяет рабочие области по экземплярам kcp, называемым шардами, аналогично тому, как поды планируются по узлам.

Основные возможности:

Control plane для множества независимых изолированных «кластеров», известных как рабочие области.
Предоставление возможности централизованно поставлять API с помощью мультитенантных операторов.
Простое использование API для пользователей в их рабочих областях.
Расширенные стратегии развёртывания для таких сценариев, как affinity/anti-affinity, geographic replication, репликация между облаками и так далее.

Kepler

Kepler — экспортёр Prometheus. Он использует eBPF для проверки счётчиков производительности ЦП и точек трассировки ядра Linux. Эти данные и статистику из cgroup и sysfs затем можно передать в модели машинного обучения для оценки энергопотребления подов.

Схема работы Kepler:

Kepler экспортирует в Prometheus различные метрики контейнера, основные из которых связаны с потреблением энергии. Все метрики, специфичные для Kepler Exporter, имеют префикс kepler.

После установки в кластер нужно подключить метрики, экспортируемые Kepler'ом, к дашборду Grafana:

Краткий обзор метрик, которые может отдавать Kepler:

kepler_container_joules_total — представляет собой совокупное энергопотребление сокета ЦП, DRAM-памяти, графического процессора и других компонентов хоста для данного контейнера. Каждый компонент имеет отдельные показатели.
kepler_container_core_joules_total — измеряет общее потребление энергии ядрами ЦП, которые использовал определённый контейнер. Как правило, когда система имеет доступ к метрикам RAPL, эта метрика будет отражать пропорциональное энергопотребление контейнера, которое представляет собой энергию, потребляемую всеми ядрами ЦП в сокете. Однако этот показатель зависит от модели процессора и может быть недоступен на некоторых процессорах сервера.
kepler_container_dram_joules_total — описывает общий объём энергии, затрачиваемой контейнером в DRAM.
kepler_container_uncore_joules_total — измеряет совокупную энергию, потребляемую определёнными неядерными компонентами, которыми обычно являются кэш последнего уровня, встроенный графический процессор и контроллер памяти.
kepler_container_package_joules_total — измеряет совокупную энергию, потребляемую сокетом ЦП, включая все ядра и неядерные компоненты, например кэш последнего уровня, встроенный графический процессор и контроллер памяти.
kepler_container_other_joules_total — измеряет совокупное потребление энергии другими компонентами хоста, помимо ЦП и DRAM.
kepler_container_gpu_joules_total — измеряет общее энергопотребление графических процессоров, использованных определённым контейнером. В настоящее время Kepler поддерживает только графические процессоры NVIDIA, но в будущем этот показатель будет отражать и другие ускорители.
kepler_container_energy_stat — содержит несколько метрик контейнера, помеченных метриками cgrouр.
kepler_container_bpf_cpu_time_us_total — измеряет общее время ЦП, используемое контейнером, с использованием трассировки BPF.
kepler_container_cpu_cycles_total — измеряет общее количество циклов ЦП, используемых контейнером, с помощью аппаратных счётчиков.
kepler_container_cpu_instructions_total — измеряет общее количество инструкций процессора, используемых контейнером, с помощью аппаратных счётчиков.
kepler_container_cache_miss_total — измеряет общее количество случаев отсутствия кэша, произошедших для данного контейнера, с помощью аппаратных счётчиков.
kepler_container_cgroupfs_cpu_usage_us_total — измеряет общее время ЦП, используемое контейнером при чтении из статистики cgroups.
kepler_container_cgroupfs_memory_usage_bytes_total — измеряет общий объём памяти в байтах, используемый контейнером, считывающим данные cgroups stat.
kepler_container_cgroupfs_system_cpu_usage_us_total — измеряет общее время процессора в пространстве ядра, используемое контейнером, считывающим данные cgroups stat.
kepler_container_cgroupfs_user_cpu_usage_us_total — измеряет общее время ЦП в пользовательском пространстве, используемое контейнером, считывающим данные cgroups stat.
kepler_container_bpf_net_tx_irq_total — измеряет общее количество переданных пакетов на сетевые карты контейнера с использованием трассировки BPF.
kepler_container_bpf_net_rx_irq_total — измеряет общее количество пакетов, полученных от сетевых карт контейнера, с использованием трассировки BPF.
kepler_container_bpf_block_irq_total — измеряет блок ввода-вывода, вызванный из контейнера, с использованием трассировки BPF.
kepler_node_info — показывает метаданные узла, такие как архитектура ЦП узла.
kepler_node_platform_joules_total — представляет общее потребление энергии хостом.
kepler_node_energy_stat — содержит несколько метрик от узлов, помеченных метриками cgroup.
kepler_node_accelerator_intel_qat — измеряет использование ускорителя Intel QAT на определённом узле, если он есть.

Ещё к ним можно отнести метрики, аналогичные метрикам контейнера, но в данном случае это совокупность всех контейнеров, работающих на узле и в операционной системе:

kepler_node_core_joules_total;
kepler_node_uncore_joules_total;
kepler_node_dram_joules_total;
kepler_node_package_joules_total;
kepler_node_other_host_comComponents_joules_total;
kepler_node_gpu_joules_total.

kpt

kpt — это набор инструментов, который обеспечивает создание, автоматизацию и доставку конфигурации WYSIWYG. Это упрощает управление платформами Kubernetes и инфраструктурой на основе KRM (например, Config Connector, Crossplane) в масштабе за счёт манипулирования декларативной конфигурацией как данными (Configuration as Data).

Configuration as Data — это подход к управлению конфигурацией, который:

делает данные конфигурации источником истины, хранящимся отдельно от живого состояния;
использует единую сериализуемую модель данных для представления конфигурации;
отделяет код, который воздействует на конфигурацию, от данных и пакетов / пакетов данных;
абстрагирует структуру и хранилище файла конфигурации от операций, которые воздействуют на данные конфигурации — клиентам, манипулирующим данными конфигурации, не нужно напрямую взаимодействовать с хранилищем (Git, образы контейнеров).

Большинство пользователей Kubernetes управляют своими ресурсами с помощью либо традиционных императивных графических интерфейсов пользователя, инструментов командной строки (kubectl) и средств автоматизации (например, с помощью операторов), которые работают непосредственно с API-интерфейсами Kubernetes, либо инструментов декларативной настройки, таких как Helm, Terraform, cdk8s или один из десятков других инструментов.

kpt обеспечивает WYSIWYG-управление конфигурацией аналогично тому, как текущее состояние можно изменить с помощью традиционных императивных инструментов, тем самым устраняя эту дихотомию:

kpt состоит из нескольких компонентов:

kpt CLI — поддерживает операции с пакетами и функциями, а также развёртывание посредством прямого использования или GitOps. Ведёт мониторинг развёрнутых ресурсов и обеспечивает их сокращение, агрегирование статуса и наблюдаемость, а также улучшенный предварительный просмотр.
Function SDKs — предоставляет SDK для упрощения процесса создания функций на Go, Typescript и Starlark (встроенном языке, подобном Python).
Function catalog — каталог готовых, проверенных функций.
Package orchestrator — обеспечивает интерфейс WYSIWYG. Предоставляет control plane для создания, изменения, обновления и удаления пакетов, а также оценки функций данных пакета. Позволяет выполнять операции с упакованными ресурсами, аналогичные операциям непосредственно с активным состоянием через API Kubernetes.
Config Sync: предоставляет эталонную реализацию GitOps для завершения процесса управления WYSIWYG и обеспечения сквозной разработки новых функций.
Backstage UI plugin: экспериментальный пользовательский интерфейс в виде плагина Backstage, чтобы продемонстрировать возможности WYSIWYG:

Krkn

Krkn aka Kraken — инструмент тестирования и устойчивости для Kubernetes с упором на повышение производительности в условиях сбоя.

После запуска с указанием через kubeconfig конкретного кластера Kubernetes, в зависимости от конфигурации, kraken внедряет определённые хаосные сценарии. Затем он общается с Cerberus, чтобы получить отчёт о годности, который отражает общее состояние кластера. Далее он извлекает метрики из кластерного Prometheus, получает профиль метрик с запросами PromQL и долгосрочно сохраняет их в настроенном Elasticsearch, оценивает выражения PromQL, указанные в профиле оповещений, и агрегирует всё, чтобы установить статус Pass или Fail:

Основные особенности:

В большинстве сценариев предусмотрены встроенные проверки того, восстановился ли целевой компонент после сбоя по истечении указанного периода времени. Но могут быть случаи, когда другие компоненты могут оказать на него влияние из-за собственных сбоев. Поэтому важно убедиться, что система (или приложение) в целом здорова после внедрения хаоса.
Помимо проверки состояния восстановления и работоспособности кластера, не менее важно оценить показатели производительности, такие как задержка, скачки использования ресурсов, пропускная способность и так далее. Для этого Kraken оценивает выражения PromQL из кластерного Prometheus и выводит результат в зависимости от уровня серьёзности, выбранного для каждого запроса.
Общий успех или неудача основаны на восстановлении конкретного компонента в течение определённого периода времени, отчёте, который отслеживает работоспособность всего кластера, и оценке метрик из кластерного Prometheus.

Доступны следующие сценарии тестирования:

Сценарии подов:
- Нарушают работу Kubernetes и приложений, развёрнутых как поды:
  - Помогают понять доступность приложения, время инициализации и состояние восстановления.
Контейнерные сценарии:
- Нарушают работу Kubernetes и приложений, развёрнутых как контейнеры, работающие как часть подов, используя указанный сигнал уничтожения для имитации сбоев:
  - Помогают понять влияние и время восстановления, когда программа или процесс, работающий в контейнерах, прерывается — зависает, приостанавливается, завершается и так далее, с использованием различных сигналов завершения, например SIGHUP, SIGTERM, SIGKILL и так далее.
Сценарии узлов:
- Нарушают работу узлов как части инфраструктуры кластера, обращаясь к облачному API. На данный момент поддерживаемыми платформами являются AWS, Azure, GCP, OpenStack и bare metal. К возможным сбоям относятся:
  - удаление узла;
  - форк-бомба внутри узла;
  - остановка узла;
  - сбой kubelet, работающего на узле.
Отключения зон:
- Создают сбой в зонах доступности в целевом регионе публичного облака, где работает кластер Kubernetes, путём настройки сетевого ACL зоны для имитации сбоя. Это останавливает как входящий, так и исходящий трафик со всех узлов в определённую зону на указанный период времени и затем восстанавливает подключения, которые были затронуты:
  - Помогают понять влияние как на Kubernetes, так и на приложения и службы, работающие на рабочих узлах в этой зоне.
  - В настоящее время настроены только для облачной платформы AWS: можно указать один VPC и несколько подсетей внутри VPC.
Сбои в работе приложений:
- Сценарий блокировки трафика (входящего/исходящего) приложения, соответствующего меткам, на указанный период времени, чтобы понять поведение служб, которые зависят от неё во время простоя:
  - Помогают понять, как зависимые службы реагируют на недоступность.
Отключения электроэнергии:
- Этот сценарий имитирует отключение электроэнергии путём отключения всего кластера на заданный период времени, затем перезапускает все узлы по истечении указанного времени и проверяет работоспособность кластера:
  - Существуют различные варианты использования в среде клиентов. Например, при отключении некоторых кластеров в тех случаях, когда приложениям не требуется запускаться в определённое время в целях экономии затрат.
  - Узлы останавливаются параллельно, чтобы имитировать отключение электроэнергии, то есть выдергивание вилки из розетки.
Ресурсные сценарии:
- Загружают ЦП, память и ввод-вывод на целевых узлах:
  - Помогают понять, зарезервированы ли у компонентов приложения и системы ресурсы, чтобы избежать сбоев из-за несанкционированных приложений или снижения производительности.
Искажения времени:
- Управляют системным временем и датой конкретных модулей/узлов:
  - Проверяют планирование объектов, чтобы они продолжали работать.
  - Убеждаются, что время сбрасывается правильно.
Сбои пространства имён:
- Удаляют пространства имён на указанный период времени:
  - Помогают понять влияние на другие компоненты и тестируют время восстановления компонентов в целевом пространстве имён.
Постоянное заполнение дисков:
- Заполняет постоянные тома (до заданного процента), используемые подом в течение указанного периода времени:
  - Помогает понять, как ведёт себя приложение, когда оно больше не может записывать данные на диск.
Сетевой хаос:
- Поддерживаемые сценарии включают в себя:
  - задержку сети;
  - потерю пакетов;
  - колеблющийся интерфейс;
  - ошибки DNS;
  - повреждение пакетов;
  - ограничение пропускной способности.

Kuasar

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

Kuasar состоит из двух основных модулей:

Kuasar-sandboxer — реализует Sandbox API, отвечает за жизненный цикл песочницы и управление распределением ресурсов.
Kuasar-task — реализует Task API, отвечает на запросы среды выполнения контейнера высокого уровня, а затем управляет жизненным циклом и распределением ресурсов пользовательских контейнеров.

Песочница — это метод, используемый для отделения контейнерных процессов друг от друга и от самой операционной системы. Kuasar поддерживает различные типы песочниц, что позволяет пользователям выбирать наиболее подходящую для каждого приложения в соответствии с требованиями приложения:

Провайдер	Песочница	Статус
MicroVM	Cloud Hypervisor	Поддерживается
	QEMU	Поддерживается
	Firecracker	Запланировано в 2024 г.
	StratoVirt	Поддерживается
Wasm	WasmEdge	Поддерживается
	Wasmtime	Поддерживается
	Wasmer	Запланировано в 2024 г.
App Kernel	gVisor	Запланировано в 2024 г.
	Quark	Поддерживается
runC	runC	Поддерживается

Основные преимущества Kuasar:

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

Kube-burner

Kube-burner — это инструмент, написанный на Golang, который можно использовать для нагрузки на кластеры Kubernetes путём создания, удаления и исправления ресурсов с заданной скоростью. Действия, выполняемые этим инструментом, легко настраиваются.

Запустить тестирование кластера можно одной командой init, указав ей нужные флаги:

uuid — идентификатор бенчмарка. Это произвольная строка, которая используется в тесте для разных целей. Например, можно пометить объекты, созданные kube-burner. По умолчанию он генерируется автоматически.
config — путь или URL-адрес допустимого файла конфигурации.
configmap — в случае отсутствия флага --config kube-burner сможет получить свою конфигурацию из заданного файла configMap.
namespace — имя пространства имён, в котором находится configMap.
log-level — уровень ведения журнала.
prometheus-url — эндпоинт Prometheus, необходимый для сбора метрик.
metrics-profile — путь к допустимому файлу профиля метрик.
metrics-endpoint — путь к допустимому файлу эндпоинта метрик.
token — Bearer-токен Prometheus.
username — имя пользователя Prometheus для базовой аутентификации.
password — пароль Prometheus для базовой аутентификации.
skip-tls-verify — пропустить проверку TLS для Prometheus.
step — размер шага Prometheus.
timeout — глобальное время ожидания теста Kube-burner.
kubeconfig — путь к файлу kubeconfig.
kube-context — имя используемого контекста kubeconfig.
user-metadata — путь к файлу YAML, который содержит пользовательские метаданные, подлежащие индексации.

В итоге запустить бенчмарк кластера можно следующим образом:

kube-burner init -c cfg.yml -u https://prometheus-k8s-openshift-monitoring.apps.rsevilla.stress.mycluster.example.com -t ${token} --uuid 67f9ec6d-6a9e-46b6-a3bb-065cde988790

Результат тестирования:

KubeClipper

KubeClipper — это лёгкий веб-сервис, который предоставляет удобный графический интерфейс веб-консоли, API и инструмент CLI для управления жизненным циклом кластера Kubernetes. Он позволяет быстро развёртывать кластеры K8s в любом месте (облако, гипервизор, bare metal) и обеспечивает возможности постоянного управления жизненным циклом (установка, удаление, обновление, резервное копирование и восстановление, масштабирование кластера, удалённый доступ, управление плагинами, магазин приложений).

Компоненты KubeClipper:

kc-server — сбор информации, сообщаемой kc-agent, распределение операций внешнего интерфейса назначенному агенту, суммирование результатов выполнения и так далее.
kc-agent — разворачивается на управляемом узле и взаимодействует с kc-server через очередь сообщений, отвечает за передачу информации об узле, а также за обработку и выполнение задач.
kcctl — инструмент командной строки, позволяет быстро и эффективно развёртывать кластеры KubeClipper и управлять ими, а также заменять большинство операций со страницами интерфейса.

Установить KubeClipper можно с помощью его же утилиты kcctl, указав ей логин, пароль или SSH-ключ от машины, на которую будет произведена установка. По окончании установки можно будет войти в веб-интерфейс:

Несколько скриншотов интерфейса:

Logging operator

Logging operator — решает проблемы, связанные с ведением журналов в средах Kubernetes. Инструмент автоматизирует развёртывание и настройку конвейера журналирования Kubernetes.

Основные особенности:

Развёртывает и настраивает сборщик журналов (в настоящее время — Fluent Bit DaemonSet) на каждом узле для сбора журналов контейнеров и приложений из файловой системы узла.
Fluent Bit запрашивает API Kubernetes и дополняет журналы метаданными о подах, а также передаёт журналы и метаданные в инстанс средства пересылки журналов.
Экземпляр пересылки журналов получает, фильтрует и преобразует входящие журналы и передаёт их на один или несколько приёмников. Поддерживаются Fluentd и syslog-ng в качестве переадресаторов журналов.
Журналы всегда передаются по аутентифицированным и зашифрованным каналам.

Основные характеристики:

Изоляция пространств имён.
Собственные селекторы меток Kubernetes.
Безопасная связь (TLS).
Проверка конфигураций.
Поддержка нескольких потоков (несколько журналов для разных преобразований).
Поддержка нескольких выходных данных (хранение одних и тех же журналов в нескольких хранилищах: S3, GCS, ES, Loki и других).
Поддержка нескольких систем журналирования (множественное развёртывание Fluentd, Fluent Bit в одном кластере).
Поддержка syslog-ng и Fluentd в качестве центрального компонента маршрутизации журналов.

В системе можно настроить гибкие правила маршрутизации журналов:

Microcks

Microcks — инструмент Kubernetes для тестирования API. Он поддерживает следующие инструменты редактирования и форматы экспорта/импорта:

Microcks может сопоставлять несколько артефактов (один первичный и несколько вторичных) с одним определением макета API. В primary будут представлены метаданные служб и операций, а secondary лишь обогащают существующие операции новыми неконфликтующими запросами/ответами и образцами событий:

Установка с вторичным артефактом может позволить протестировать собственные макеты на соответствие OpenAPI Specification (OAS):

Импортируется сертификат OpenAPI (OAS) в качестве основного артефакта.
Импортируется коллекция Postman в качестве вторичного артефакта (этот артефакт будет добавлять только макеты/примеры к основному артефакту/спецификации).
Запускается тест на собственных эндпоинтах Microcks.

Управлять Microcks можно через веб-интерфейс:

После импорта новых источников можно запускать тестирование нажатием кнопок:

Результаты тестирования каждого ресурса можно просмотреть подробнее с детальной статистикой по запросам, ответам и прочим параметрам:

Установить Microcks в кластер можно в качестве оператора и с использованием Helm-чарта. Также есть возможность развернуть его локально в Docker Compose.

PipeCD

PipeCD — платформа непрерывной доставки в стиле GitOps, обеспечивающая согласованное развёртывание и эксплуатацию любых приложений.

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

Основные особенности:

Простое, унифицированное и удобное в использовании, но мощное определение пайплайна для построения развёртывания.
Один и тот же интерфейс развёртывания для приложений любой платформы, включая Kubernetes, Terraform, GCP Cloud Run, AWS Lambda, AWS ECS.
Никаких изменений CRD или манифеста приложений не требуется — необходимо только определение пайплайна вместе с манифестами приложения.
Никакие учётные данные для развёртывания не предоставляются и не требуются за пределами кластера приложений.
Встроенный анализ развёртывания как часть пайплайна развёртывания на основе метрик, журналов и отправленных запросов.
Легко взаимодействовать с любым CI — CI тестирует и создаёт артефакты, PipeCD берёт на себя всё остальное.
Аналитические данные показывают такие показатели, как время выполнения, частота развёртывания, MTTR и частота неудачных попыток, для измерения эффективности доставки.
Разработан для управления тысячами кросс-платформенных приложений в мультиоблачной среде в масштабах компании, но также хорошо подходит для небольших проектов.

Возможности системы:

Видимость:
- Пользовательский интерфейс пайплайна развёртывания показывает, что происходит.
- Отдельный просмотрщик журналов для каждого отдельного развёртывания.
- Визуализация состояния приложения в реальном времени.
- Уведомления о развёртывании в Slack и другие средства коммуникации.
- Статистика показывает эффективность доставки.

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

Безопасность:
- Поддержка единого входа и контроля доступа на основе ролей.
- Учётные данные не предоставляются за пределами кластера и не сохраняются в control plane.
- Выполняются только исходящие запросы, что даёт возможность работать внутри сети с ограниченным доступом.
- Встроенное управление секретами.

Поддержка нескольких типов приложений в мультиоблаке, включая Kubernetes, Terraform, Cloud Run, AWS Lambda, Amazon ECS.
Поддержка нескольких поставщиков анализа, включая Prometheus, Datadog, Stackdriver и других.
Простота в эксплуатации мультикластера и мультиарендности за счёт разделения control plane и пайплайнов обработки.

SlimToolkit

SlimToolkit — инструмент для исследования, оптимизации и дебага контейнеров. Он упрощает и улучшает процесс создания, настройки и использования контейнеров, делая их лучше, меньше и безопаснее.

Для использования не нужно ничего менять в контейнерах, утилита всё сделает сама с использованием нескольких команд: xray, lint, build, debug, run, images, merge, registry, vulnerability. Её можно использовать с основанными на Node.js, Python, Ruby, Java, Go, Rust, Elixir и PHP приложениями, которые запускаются в контейнерах на базе Ubuntu, Debian, CentOS, Alpine и даже Distroless.

Примеры уменьшения контейнеров на разных языках:

Node.js:
- from ubuntu:14.04 — 432 MБ => 14 MБ (уменьшено в 30,85 раза)
- from debian:jessie — 406 MБ => 25,1 MБ (уменьшено в 16,21 раза)
- from node:alpine — 66,7 MБ => 34,7 MБ (уменьшено в 1,92 раза)
- from node:distroless — 72,7 MБ => 39,7 MБ (уменьшено в 1,83 раза)
Python:
- from ubuntu:14.04 — 438 MБ => 16,8 MБ (уменьшено в 25,99 раза)
- from python:2.7-alpine — 84,3 MБ => 23,1 MБ (уменьшено в 3,65 раза)
- from python:2.7.15 — 916 MБ => 27,5 MБ (уменьшено в 33,29 раза)
- from centos:7 — 647 MБ => 23 MБ (уменьшено в 28,57 раза)
- from centos/python-27-centos7 — 700 MБ => 24 MБ (уменьшено в 29,01 раза)
- from python2.7:distroless — 60,7 MБ => 18,3 MБ (уменьшено в 3,32 раза)
Go:
- from golang:latest — 700 MB => 1,56 MБ (уменьшено в 448,76 раза)
- from ubuntu:14.04 — 531 MБ => 1,87 MБ (уменьшено в 284,10 раза)
- from golang:alpine — 258 MБ => 1,56 MБ (уменьшено в 165,61 раза)
- from centos:7 — 615 MБ => 1,87 MБ (уменьшено в 329,14 раза)

Описание команд:

xray — выполняет статический анализ целевого образа контейнера (включая реверс-инжиниринг Dockerfile для образа).
lint — анализирует инструкции контейнера в Dockerfile.
build — анализирует, профилирует и оптимизирует образ контейнера, создавая поддерживаемые профили безопасности. Это самая популярная команда.
debug — отладка работающего целевого контейнера. Эта команда полезна для устранения неполадок при запуске контейнеров, созданных из минимальных/минифицированных или обычных образов.
registry — выполнение операций с реджистри (pull, push, copy, server).
profile — выполняет базовый анализ образа контейнера и динамический анализ контейнера, но не создает оптимизированный образ.
run — запускает один или несколько контейнеров.
merge — объединяет два образа контейнера.
images — получает информацию об образах контейнеров.
vulnerability — выполняет операции, связанные с уязвимостями.
version — показывает информацию о версии.
appbom — показывает спецификацию приложения (состав/зависимости приложения).
update — обновление Slim до последней версии.
help — отображает справку.

Пример использования: slim build my/sample-app.

SOPS

SOPS: Secrets OPerationS — редактор зашифрованных файлов, который поддерживает форматы YAML, JSON, ENV, INI и BINARY и шифрует с помощью AWS KMS, GCP KMS, Azure Key Vault, Age и PGP.

Примеры использования:

Создаёт новый файл с ключом данных, зашифрованным KMS и PGP:

$ sops edit --kms "arn:aws:kms:us-west-2:927034868273:key/fe86dd69-4132-404c-ab86-4269956b4500" --pgp C9CAB0AF1165060DB58D6D6B2653B624D620786D /path/to/new/file.yaml

Шифрование существующего файла:

$ export SOPS_KMS_ARN="arn:aws:kms:us-west-2:927034868273:key/fe86dd69-4132-404c-ab86-4269956b4500"
$ export SOPS_PGP_FP="C9CAB0AF1165060DB58D6D6B2653B624D620786D"
$ sops encrypt /path/to/existing/file.yaml > /path/to/new/encrypted/file.yaml

Расшифровать можно с помощью ключа -d – $ sops decrypt /path/to/new/encrypted/file.yaml.

Вместо перенаправления вывода -e или -d можно заменить исходный файл после его шифрования или расшифровки:

# file.yaml is in cleartext
$ sops encrypt -i /path/to/existing/file.yaml
# file.yaml is now encrypted
$ sops decrypt -i /path/to/existing/file.yaml
# file.yaml is back in cleartext

Основной вариант использования SOPS — шифрование файлов конфигурации YAML и JSON, но он также имеет возможность управлять двоичными файлами. При шифровании двоичного файла SOPS считывает данные в виде байтов, шифрует их, сохраняет зашифрованный код Base64 и записывает результат в формате JSON:

$ dd if=/dev/urandom of=/tmp/somerandom bs=1024
count=512
512+0 records in
512+0 records out
524288 bytes (524 kB) copied, 0.0466158 s, 11.2 MB/s

$ sha512sum /tmp/somerandom
9589bb20280e9d381f7a192000498c994e921b3cdb11d2ef5a986578dc2239a340b25ef30691bac72bdb14028270828dad7e8bd31e274af9828c40d216e60cbe /tmp/somerandom

$ sops encrypt -i /tmp/somerandom
please wait while a data encryption key is being generated and stored securely

$ sops decrypt -i /tmp/somerandom

$ sha512sum /tmp/somerandom
9589bb20280e9d381f7a192000498c994e921b3cdb11d2ef5a986578dc2239a340b25ef30691bac72bdb14028270828dad7e8bd31e274af9828c40d216e60cbe /tmp/somerandom

SOPS может извлечь определённую часть документа YAML или JSON, если указать путь в --extract флаге командной строки. Это полезно для извлечения определённых значений, например ключей, без необходимости использования дополнительного синтаксического анализатора:

$ sops decrypt --extract '["app2"]["key"]' ~/git/svc/sops/example.yaml
-----BEGIN RSA PRIVATE KEY-----
MIIBPAIBAAJBAPTMNIyHuZtpLYc7VsHQtwOkWYobkUblmHWRmbXzlAX6K8tMf3Wf
ImcbNkqAKnELzFAPSBeEMhrBN0PyOC9lYlMCAwEAAQJBALXD4sjuBn1E7Y9aGiMz
bJEBuZJ4wbhYxomVoQKfaCu+kH80uLFZKoSz85/ySauWE8LgZcMLIBoiXNhDKfQL
vHECIQD6tCG9NMFWor69kgbX8vK5Y+QL+kRq+9HK6yZ9a+hsLQIhAPn4Ie6HGTjw
fHSTXWZpGSan7NwTkIu4U5q2SlLjcZh/AiEA78NYRRBwGwAYNUqzutGBqyXKUl4u
Erb0xAEyVV7e8J0CIQC8VBY8f8yg+Y7Kxbw4zDYGyb3KkXL10YorpeuZR4LuQQIg
bKGPkMM4w5blyE1tqGN0T7sJwEx+EUOgacRNqM2ljVA=
-----END RSA PRIVATE KEY-----

SOPS можно использовать с Git для расшифровки файлов при отображении различий между версиями. Это очень удобно для просмотра изменений или визуализации истории: *.yaml diff=sopsdiffer.

Spiderpool

Spiderpool — это сетевое решение RDMA для Kubernetes. Он расширяет возможности macvlan CNI, ipvlan CNI, SR-IOV CNI, удовлетворяет различные сетевые потребности и поддерживает работу на bare metal, виртуальных машинах и в общедоступных облачных средах. Spiderpool обеспечивает исключительную производительность сети, особенно принося пользу сетевым приложениям с интенсивным вводом-выводом и малой задержкой, таким как хранилище, промежуточное программное обеспечение и искусственный интеллект.

Преимущества Spiderpool:

macvlan, ipvlan и SR-IOV имеют решающее значение для поддержки ускорения сети RDMA. RDMA значительно повышает производительность приложений искусственного интеллекта, чувствительных к задержке, и сетевых приложений с интенсивным вводом-выводом, превосходя по сетевой производительности решения оверлейных сетей.
В отличие от решений CNI, основанных на виртуальных интерфейсах, underlay-сети исключают пересылку уровня 3 на хосте, избегая накладных расходов на инкапсуляцию туннеля. Это приводит к превосходной производительности с высокой пропускной способностью, низкой задержкой и снижением использования ЦП для пересылки по сети.
Беспрепятственное соединение с underlay-сетями VLAN уровня 2 обеспечивает связь как на уровне 2, так и на уровне 3 для приложений. Он поддерживает многоадресную и широковещательную связь, позволяя при этом контролировать пакеты с помощью межсетевых экранов.
Пакеты данных содержат фактические IP-адреса подов, что обеспечивает прямую связь между ними на основе их IP-адресов. Такое подключение к мультиоблачным сетям повышает гибкость и простоту использования.
Underlay CNI может создавать виртуальные интерфейсы с помощью различных родительских сетевых интерфейсов на хосте, чем обеспечивает изолированные подсети для приложений с высокими сетевыми нагрузками, таких как хранилище и наблюдаемость.

Основные особенности:

Упрощает процесс установки и уменьшает количество запущенных подов, беря на себя установку компонентов.
Предоставляет эксклюзивные и общие пулы IP-адресов, поддерживая различные настройки привязки. Поддерживается назначение статических IP-адресов для приложений с сохранением состояния, таких как MySQL, Redis и KuberVirt, а также возможно использовать фиксированные диапазоны IP-адресов для приложений без сохранения состояния. Spiderpool автоматизирует управление пулами эксклюзивных IP-адресов, обеспечивая восстановление IP-адресов во избежание утечки. Кроме того, он обеспечивает замечательную производительность IPAM .
IPAM Spiderpool может быть доступен для любого основного CNI, поддерживающего сторонний плагин IPAM, включая не только macvlan CNI, ipvlan CNI и SR-IOV CNI, но также Calico и Weave в качестве использования статического IP.
Позволяет использовать сценарии, в которых поды могут иметь несколько underlay-интерфейсов CNI или комбинацию оверлейных и underlay-интерфейсов. Обеспечивается правильная IP-адресация для каждого интерфейса CNI. Spiderpool эффективно управляет политикой маршрутизации для поддержания согласованных путей данных, устраняя проблемы с потерей пакетов.
Устанавливает бесшовное соединение между подами и хост-машинами, обеспечивая бесперебойную проверку работоспособности подов. Позволяет подам получать доступ к сервисам через kube-proxy или замену kube-proxy на основе eBPF. Кроме того, поддерживает расширенные функции, такие как обнаружение конфликтов IP и проверка доступности шлюза.
Замена kube-proxy на основе eBPF значительно ускоряет доступ к сервисам, а технология короткого замыкания сокетов повышает эффективность связи локальных подов внутри одного узла. По сравнению с методом kube-proxy улучшение производительности составляет до 25% по задержке сети и до 50% по пропускной способности сети .
Предлагает решения RDMA на основе технологий RoCE и InfiniBand. Под может использовать устройство RDMA в совместном или эксклюзивном режиме, и оно подходит для рабочих нагрузок ИИ.
Поддерживает среды только с IPv4, IPv6 и двойным стеком.

Где рекомендуется применять Spiderpool:

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

Xline

Xline — распределённое KV-хранилище (Key-Value) для управления метаданными. Xline позволяет управлять индексами, разрешениями и конфигурациями в нескольких кластерах. Он совместим с интерфейсом ETCD, поэтому существующие пользователи ETCD могут легко переключиться на Xline и получить высокопроизводительное управление метаданными в нескольких кластерах.

Основные характеристики:

Облачный, совместимый с экосистемой Kubernetes.
Поддержка геораспределённого развёртывания.
Поддерживает богатый набор интерфейсов «ключ — значение» (KV), полностью совместимых с API etcd.
Обеспечивает высокую производительность и высокую согласованность в глобальной сетевой среде, используя протокол CURP в качестве основного протокола консенсуса.

Результаты сравнения производительности xline при двух разных рабочих нагрузках (один — с одним ключом, другой — с пространством ключей 100 КБ) с etcd:

Заключение

Мы кратко рассмотрели новые проекты, добавленные в CNCF Sandbox за последний год. Некоторые из них были добавлены совсем недавно, некоторые — в самом начале прошлого года. Проекты развиваются по сей день. Пожелаем им удачи на пути роста и достижения всех поставленных целей.

P. S.

Читайте также в нашем блоге:

Комментарии (1)

jurikolo
22.06.2024 20:40
#26963022
Надо попробовать headlamp, а то за LENS стали денежку просить. Тут как-никак проект, поддерживаемый CNCF.