[Перевод] Что такое модель claims в Kubernetes: гибкость и эффективность управления ресурсами
Примечание переводчика: статья посвящена модели claims в Kubernetes, которая помогает управлять ресурсами, разделяя желаемое состояние пользователя и доступные ресурсы. Автор разбирает ключевые паттерны, такие как разделение ролей между поставщиками и потребителями ресурсов, возможность предварительного заказа и динамического выделения ресурсов, а также повторное и совместное использование ресурсов. Дальше идет текст оригинала.
В предыдущей статье я упоминал, что Kubernetes использует модель запросов (claims) для управления ресурсами. Claims помогают представить разницу между тем, что пользователь хочет (желаемое состояние), и тем, что доступно в системе (наблюдаемое состояние). Например, поды и PersistentVolumeClaims — это запрашиваемые ресурсы, а узлы и PersistentVolumes — это ресурсы, доступные в текущей инфраструктуре.
Gateway API и Crossplane — сравнительные новички в экосистеме Kubernetes — также используют эту модель.
API-интерфейсы шлюза Kubernetes для различных пользовательских ролей
Claims в Crossplane помогают разделить зоны ответственности
Примечание переводчика по некоторым сущностям схемы:
Составной ресурс (Composite Resource) в Crossplane — это специальный ресурс, который объединяет несколько связанных облачных ресурсов в одну высокоуровневую сущность. Например, если мы говорим о составном ресурсе «база данных», то он будет включать в себя такие элементы, как сервер базы данных, хранилище данных и сетевые настройки.
Claim в данном случае — это запрос на создание экземпляра составного ресурса.
Состав (Composition) определяет реализацию составного ресурса с использованием низкоуровневых managed-ресурсов, то есть описывает, какие конкретные облачные ресурсы нужно создать и как их настроить. Например, состав для «базы данных» может указывать, что нужно создать экземпляр БД в облаке, настроить группу безопасности и выделить определённый объём хранилища.
Что такое модель запросов, какова её цель и как она работает
Claim — это запрос пользователя на определённый ресурс, в котором указаны минимальные требования. Это не полное описание того, что нужно, а лишь часть того, что пользователь хочет получить. Этот запрос может быть удовлетворён ресурсом, который соответствует указанным требованиям.
Claim больше похож на future или promise, а не на директиву, которую конкретный контроллер обязан незамедлительно выполнить. Этим он отличается от унифицированных аллокаторов вроде токен-бакетов, семафоров или системы предложений (когда пользователь выбирает из списка доступных ресурсов).
Обычно в Kubernetes ресурсы выражают желаемое состояние для некоторой сущности или поведения. Например, в спецификации пода указывается, какие образы контейнеров запускать вместе, как их запускать и сколько процессора и оперативной памяти им требуется. Подструктура status пода возвращает рантайм-информацию, например, о причинах сбоя в работе, о которых сообщает рантайм контейнера или kubelet. В API управляющего слоя нет отдельного представления для самого контейнера, хотя у kubelet и рантайма контейнера они имеются.
Однако существует отдельное представление узла, на котором работает под. Зачем это нужно? Узел — пример сразу нескольких паттернов:
Ресурс, который производится одним агентом в системе — провайдером инфраструктуры — и потребляется другим — подами.
Заказ и использование могут быть разделены во времени, то есть узел может быть подготовлен заранее.
Ресурс можно переиспользовать.
Общий ресурс, который может использоваться сразу несколькими подами.
PersistentVolumes являются примером первых двух паттернов, но не последних, поскольку они не используются повторно и не являются общими.
Разделение поставщика и потребителя
Основная цель первого паттерна — облегчить разделение ролей. Запросчик ресурса не обязан иметь разрешение на предоставление этого ресурса и не должен понимать все критерии, необходимые для его предоставления. Некоторые критерии могут быть заранее заданы администратором, как, например, в случае со StorageClass. Система также может выбирать между несколькими доступными ресурсами и ограничивать доступ к некоторым ресурсам для некоторых пользователей:
API PersistentVolume для различных пользовательских ролей
Даже системные компоненты могут разделять зоны ответственности. В Kubernetes поды по умолчанию назначаются на узлы с помощью встроенного планировщика, но их также можно назначить напрямую на определённый узел в обход планировщика или воспользоваться кастомным планировщиком. Kubelet’у не важно, как именно был назначен под, а планировщику не важно, как были созданы поды и узлы.
Разделение заказа и использования
Основная цель второго паттерна — обеспечить возможность заблаговременной инициализации и настройки в случаях, когда существует большая задержка или некоторые действия приходится выполнять вручную (например, приобретать и настраивать аппаратное обеспечение). Запрос сопоставляется с подходящим существующим ресурсом и привязывается к нему. Именно так PersistentVolumeClaims привязываются к PersistentVolumes.
Также возможен динамический заказ. Например, неудовлетворённый claim может запускать автозаказ узлов и динамическое выделение томов.
Повторное использование
Ресурсы, заказ которых занимает длительное время, имеет смысл переиспользовать, когда это возможно. Это справедливо для узлов Kubernetes — поды могут запускаться, работать и завершаться, а затем заменяться новыми подами. kubelet и рантайм контейнера обеспечивают изолированный от хоста запуск каждого контейнера и очистку системных ресурсов после завершения его работы.
Совместное использование/перераспределение
Claim’ы также могут использоваться для перераспределения общих ресурсов, таких как узлы. На один узел можно назначить несколько подов, или же они могут быть привязаны к одному узлу из-за ограничений. Любопытный факт: мы использовали термин claim для запросов к общим пулам ресурсов в Omega.
Отличать желаемое состояние от наблюдаемого
Это не так важно для основных сценариев использования Kubernetes, но является основной мотивацией для случая, который в одной из прошлых статей я использовал для иллюстрации того, что такое claim’ы, — заказа облачной инфраструктуры с помощью Kubernetes. Claim будет представлять желаемое состояние, выраженное пользователем, а соответствующий инфраструктурный ресурс будет смоделирован в явном виде с полной и точной информацией о реальном состоянии. Это упростит и сделает более прозрачной работу с дрейфом, импортом, удалением, ссылками на неуправляемые ресурсы и, возможно, другими случаями.
Заключение
Claim’ы обеспечивают бóльшую гибкость при заказе ресурсов по сравнению с подходами, когда ресурсы выделяются непосредственно, вроде каталогов шаблонов. Большая гибкость особенно наблюдается в случае, когда ресурсы используются совместно.
Приходилось ли вам поддерживать какой-либо из описанных выше сценариев при внедрении самообслуживания для выделения ресурсов? Используете ли вы подобную модель предоставления ресурсов в своих системах? Использовали ли вы другой термин для описания модели, например promise или matching rules?
Если эта статья показалась вам интересной, возможно, вас заинтересуют другие посты из цикла «Инфраструктура как код» и «Декларативная конфигурация», а также из серии «Kubernetes».
P. S.
Читайте также в нашем блоге:
