CRD в Kubernetes: мощный импульс для и без того мощной платформы

Kubernetes зарекомендовал себя как де-факто инструмент оркестровки контейнеров. Он помогает вам управлять приложениями в кластере с разнообразной инфраструктурой и машинами. С Kubernetes вы можете определить, как ваше приложение должно работать и взаимодействовать с другими приложениями или реальным миром. Kubernetes позволяет увеличивать и уменьшать масштаб приложения в зависимости от ваших потребностей. Вы также можете более эффективно развертывать обновления, перенаправляя часть вашего трафика на новую версию, чтобы проверить, готова ли она к выпуску. Kubernetes подключаемый, настраиваемый и расширяемый. Пользователи Kubernetes могут расширить возможности K8s, используя API своих поставщиков. Kubernetes предоставляет пользователям множество функций, но что, если разработчикам нужен пользовательский объект или ресурс, основанный на их конкретных требованиях? Именно здесь в разговор вступает CRD (настраиваемое определение ресурса). CRD — это последняя функция, представленная как часть Kubernetes 1.7, которая помогает пользователям добавлять свои собственные настраиваемые объекты в кластер Kubernetes и использовать их как любые другие собственные объекты K8s, такие как Deployment и Pod.

Что такое CRD и зачем он нужен?

Ресурс на сервере API Kubernetes хранит коллекцию объектов API определенного типа. Пользовательский ресурс позволяет пользователям создавать свои собственные объекты API. Пользовательские ресурсы определяются с помощью определения пользовательского ресурса. Таким образом, пользователи могут расширить возможности Kubernetes за пределы своих ограничений по умолчанию. После создания CRD сервер API Kubernetes создает RESTful-путь к каждой версии, указанной в CRD. Путь может быть доступен всему кластеру или конкретному проекту в зависимости от области, определенной в файле CRD. Пользовательский ресурс, определенный CRD, затем сохраняется в кластере etcd. Сервер API Kubernetes заботится о жизненном цикле и репликации ресурсов. Пользовательские ресурсы действуют аналогично собственным ресурсам, и при удалении проекта все пользовательские ресурсы и собственные ресурсы удаляются.

Хотя пользовательские ресурсы невероятно полезны, их не следует использовать повсеместно. Вы должны использовать файлы конфигурации, если у вас уже есть хорошо документированный файл конфигурации или если вы предпочитаете, чтобы Pod использовал конфигурации через файл, а не через API Kubernetes. Файлы конфигурации также следует использовать, когда вам нужно выполнять последовательные обновления каждый раз, когда файл обновляется. Вы должны полагаться на пользовательские ресурсы, если вам нужно использовать клиентские библиотеки Kubernetes или интерфейсы командной строки для создания и обновления ресурсов. Пользовательские ресурсы также идеальны, если вы хотите абстрагировать набор ресурсов. Помимо этого, используйте пользовательские ресурсы, если вы хотите использовать поля Kubernetes API, такие как.spec и.metadata, или если вам нужны полностью декларативные API.

Давайте посмотрим, как создать CRD и, следовательно, создать пользовательские ресурсы.

Создание пользовательского определения ресурса

Чтобы создать CRD, вам необходимо иметь Kubernetes 1.7 или выше и установить инструмент kubectl. CRD создается с использованием файла YAML, который содержит все необходимые вам спецификации объекта CRD. Файл YAML состоит из нескольких полей. Вот некоторые важные поля:

• metadata.name: это имя CRD, которое вы создаете.
• spec.group: Имя группы, к которой принадлежит объект CRD.
• spec.versions: это поле содержит различные версии пользовательских ресурсов, которые будут созданы с использованием CRD в контексте. Версии можно включать и отключать с помощью флага «served».
• spec.names: Это поле используется для определения того, как вы можете описать пользовательские ресурсы. Вы можете определить формы множественного, единственного и краткого имени, которые можно использовать для управления пользовательскими ресурсами через kubectl.
• spec.names.kind: это поле определяет «вид» пользовательских ресурсов, которые могут быть созданы с помощью CRD. Развертывание, CronJob и CronTab — вот некоторые из видов, которые вы можете определить в CRD.
• spec.scope: поле определяет, какой будет область действия пользовательских ресурсов. Он может быть установлен как «кластеризованный» или «пространство имен». Однако по умолчанию для него установлено значение «namespaced».

После создания CRD через kubectl создается URL-адрес конечной точки, который можно использовать для создания настраиваемых объектов и управления ими. Создание этой конечной точки может занять несколько секунд. Чтобы проверить, был ли создан ресурс, вы можете либо проверить информацию об обнаружении вашего сервера API, либо проверить, чтобы условие «Установлено» стало «истинным».

Создание пользовательского ресурса

После создания пользовательского определения ресурса вы можете приступить к созданию настраиваемых ресурсов на его основе. Пользовательские ресурсы могут иметь любое количество настраиваемых полей. Поля также могут содержать произвольные данные в зависимости от того, проверяются ли они проверками, установленными вами в CRD. Пользовательские объекты относятся к типу, определенному в CRD. После сохранения пользовательского объекта YAML вы можете создать его с помощью команды kubectl. Kubectl также можно использовать для управления всеми объектами определенного «вида». При использовании kubectl регистр символов в именах ресурсов не учитывается. Кроме того, вы можете получить доступ к пользовательским ресурсам, используя формы единственного, множественного числа и краткие имена в зависимости от того, что вы определили в CRD.

Удаление пользовательского определения ресурса

Чтобы удалить CRD в Kubernetes, вы можете использовать kubectl delete так же, как вы будете использовать его для нативного ресурса. Когда вы удаляете CRD, сервер удаляет конечную точку RESTful, созданную с помощью CRD. При удалении CRD все пользовательские ресурсы, созданные с его помощью, также удаляются и не могут быть восстановлены. Если вы начнете с нуля и создадите CRD с тем же именем, что и тот, который вы удалили ранее, вы не сможете получить все пользовательские ресурсы, созданные ранее.

Как получить полностью декларативный API

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

CRD: делаем Kubernetes еще мощнее

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