Новый Kubernetes, OpenEBS и Dapr

Сегодня в выпуске три интересные фичи нового кубера, краткий обзор OpenEBS и разбор рантайма Dapr. Приятного чтения!

Kubernetes 1.26 после релиза

Очередная версия Kubernetes была представлена в декабре 2022 года. Всего 37 изменений, из которых 11 были помечены как стабильные, 10 — бета и 16 — альфа. Также было удалены или помечены как deprecated ещё 12 функций. Все эти изменения были детально описаны в блоге проекта. 

Авторы отмечают несколько основных изменений, таких как использование нового реестра образов контейнеров registry.k8s.io, необходимость задействовать containerd версий 1.6.0 и выше, а также значительную работу по улучшению интерфейса CSI. Мы же хотим заострить внимание на трёх второстепенных изменениях, которые позволяют строить предположения о будущем Kubernetes.

Validating Admission Policies — контроль доступа без необходимости задействовать вебхуки. Оно не может их полностью заменить, но предлагает альтернативу с использованием языка CEL (Common Expression Language). Это изначально более быстрый вариант, чем JS, созданный с искусственными ограничениями. CEL не является полным по Тьюрингу, лишён мутаций и оценивается за линейное время. Внедрение его в Kubernetes говорит о готовности использовать CEL на практике и даёт разработчикам понять, что в будущем на него стоит обратить особое внимание.

Dynamic Resource Allocation — даст доступ подам к нестандартным ресурсам. Исторически сложилось, что ресурсы в Kubernetes — это CPU, RAM и Storage. Но иногда требуется пробросить внутрь подов специальные устройства, например, аппаратные ускорители нейросетей, FPGA или криптографические микроконтроллеры. Именно такая функциональность была включена в качестве альфа-версии. Разработано специальное API с новыми типами ресурсов и объектами. Отличный шаг в сторону обширного мира Edge computing.

Host network support for Windows pods — уравняет контейнеры Linux и Windows в плане доступа к сетевому namespace узла. До выхода 1.26 параметр hostNetwork=true в свойствах Windows-пода не срабатывал, как с Linux-подом, и не давал доступ к сетевым ресурсам узла. Kubernetes пошёл навстречу и обновил kubelet для добавления такой возможности. Вместе с другой фичей Support for Windows privileged containers это демонстрирует серьёзные намерения по поддержке контейнеров с Windows.

Хранилище OpenEBS

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

Это бесплатное ПО, предоставляемое по лицензии Apache License 2.0. Исходный код открыт и доступен на GitHub. Почти 8к звёздочек и 950 форков говорят сами за себя.

Это контейнеризованное хранилище, так называемый CAS. Оно универсально тем, что заработает на любой инфраструктуре, где есть Kubernetes — от Bare Metal серверов и SAN до облаков, таких как AWS и GKE.

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

• LocalPV оптимален для Cassandra, обеспечивает минимальную задержку;
• ZFS based cStor для монолитных БД (MySQL, PostgreSQL);
• Mayastor для максимальной производительности, особенно при использовании NVMe/NVMe-oF.
• Jiva пригодится, когда нужна синхронная репликация, но есть только один диск и нет необходимости в снапшотах.

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

Рантайм Dapr

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

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

Код приложения может взаимодействовать с Dapr вполне стандартными средствами — HTTP API или gRPC API. Поддерживаются языки Go, Node.js, Python, .NET, Java, JavaScript и для них предоставляются пакеты SDK. А дальше в игру вступают возможности рантайма. Стоит сказать, что используются абстракции, но они специально сделаны максимально простыми в виде блоков. 

Каждый блок отвечает за свою часть работы:

• state-management — управляет данными о состоянии;
• service-invocation — контролирует вызовы между службами;
• publish-subscribe — заведует обменом сообщениями между службами внутри приложения;
• bindings — помогает организовать обмен информацией со службами за пределами приложения;
• observability — всё, относящееся к мониторингу и измерениям;
• secrets-management — управляет доступом к внешним хранилищам секретов;
• actors — независимая единица вычислений и состояния, упрощает построение параллельных систем.

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

Митапы

Вакансии