Владимир Грин

Мультиарендность Kubernetes предоставляет ряд деловых и технических преимуществ по сравнению с однопользовательскими кластерами. Однако мультитенантность также сопряжена с несколькими проблемами и болевыми точками, одна из которых связана с обработкой пользовательских определений ресурсов (CRD) Kubernetes.

В этом посте я объясню некоторые из самых больших головных болей, которые обычно возникают при работе с CRD в многопользовательской среде Kubernetes, а также способы минимизировать эти проблемы.

CRD и мультиарендность Kubernetes

Давайте сначала рассмотрим некоторые ключевые идеи, лежащие в основе пользовательских определений ресурсов (CRD), мультитенантных кластеров Kubernetes и того, как CRD обрабатываются в мультитенантной архитектуре.

Что такое CRD?

Пользовательский ресурс - это один из способов расширить встроенные объекты, предоставляемые Kubernetes API, а также представить свои собственные объекты API. Например, вы можете создать объект, который отслеживает данные о конкретных событиях в вашем конвейере CI / CD, определив его как настраиваемый ресурс, который затем можно использовать и управлять как собственные объекты Kubernetes, например используя такие команды, как kubectl create или kubectl apply.

Настраиваемое определение ресурса (CRD) позволяет вам определять свой настраиваемый тип объекта и указывать важные атрибуты, такие как имя объекта, группа, версии, вид, область действия и т. Д. Область действия CRD, например, определяет, можно ли получить доступ к объектам на уровень кластера или если они должны быть в пространстве имен. Сервер API Kubernetes использует CRD для создания конечных точек REST для управления этими настраиваемыми объектами. Кроме того, сервер API Kubernetes также обрабатывает жизненный цикл ресурсов, определенных в CRD, в то время как фактическая бизнес-логика для настраиваемого ресурса обрабатывается так называемым контроллером.

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

Что такое мультиарендность?

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

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

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

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

CRD в многопользовательских кластерах

Пользователи и рабочие нагрузки в многопользовательском кластере совместно используют компоненты и ресурсы всего кластера, такие как расширения сервера API, контроллеры и пользовательские определения ресурсов (CRD). Но решение двойной проблемы надлежащей изоляции арендаторов и справедливого распределения ресурсов может значительно ограничить или даже помешать арендаторам в полной мере использовать CRD. Во многих случаях арендаторам не разрешается добавлять или управлять своими собственными CRD и правилами RBAC, что может быть очень ограничивающим при установке новых диаграмм Helm или работе с более сложными приложениями.

Причина этого ограничения заключается в том, что в многопользовательских кластерах Kubernetes рекомендуется ограничивать доступ отдельных пользователей или рабочих нагрузок к ресурсам без пространства имен. Это ресурсы, область действия которых не ограничена конкретным пространством имен, а вместо этого доступны на уровне кластера. Вот почему одно из ограничений мультиарендности на основе пространств имен состоит в том, что арендаторы не могут управлять своими собственными CRD, которые по замыслу являются объектами всего кластера.

Хотя сами настраиваемые ресурсы могут быть пространствами имен, CRD для этих настраиваемых ресурсов является общекластерным. Хотя были попытки и взломы для создания CRD с пространством имен, до сих пор для этого нет жизнеспособной реализации.

Болевые точки использования CRD в многопользовательских кластерах

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

Проблемы изоляции и уязвимости безопасности

Из-за того, что CRD распространяется на весь кластер, они могут вызывать проблемы с надлежащей изоляцией клиентов. Допустим, ваша настройка позволяет арендаторам создавать и определять свои собственные CRD для реализации пользовательских API. Теперь вам нужно найти способ убедиться, что пользовательский ресурс одного пользователя не конфликтует с другими ресурсами, используемыми кем-то еще в кластере.

Более того, CRD потенциально могут создавать уязвимости безопасности в многопользовательском кластере. Фактически, уязвимость CVE-2019–11247 была раскрыта в прошлом году, ясно указывая на слабость системы безопасности, которая может поставить под угрозу мультитенантные кластеры таким образом, чтобы пользователи могли получать доступ и обновлять CRD глобально в кластере, когда доступ на основе ролей включен. Хотя эта проблема решена в новых версиях Kubernetes, она по-прежнему подчеркивает дополнительную проблему безопасного использования CRD в многопользовательской среде.

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

Доступность и ограничения

Как глобальные ресурсы, CRD могут вызывать проблемы во всем кластере, если они модифицированы или изменены несовместимым образом. Вот почему, как мы видели ранее, администраторы мультитенантных кластеров обычно ограничивают доступ арендаторов к объектам в их пространствах имен. Мы также уже узнали, что такая практика, в свою очередь, не позволяет арендаторам устанавливать или управлять своими собственными CRD, которые не являются ресурсами без пространства имен.

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

Дополнительные накладные расходы администратора

Использование мультитенантности уменьшает головную боль, связанную с управлением отдельными кластерами Kubernetes, но не снимает полностью бремя администрирования общего многопользовательского кластера. Фактически, использование CRD в многопользовательской среде добавляет некоторые дополнительные административные обязанности и проблемы.

Назначение ролей и разрешений RBAC, которые позволяют арендаторам в определенном пространстве имен для доступа к настраиваемым ресурсам, может постоянно становиться утомительным, поскольку в кластере устанавливается или создается больше CRD.

Кроме того, по мере роста количества CRD, добавляемых в кластер, возрастает вероятность того, что начнут возникать конфликты имен. Для внутренних пользовательских ресурсов этого можно избежать, добавив уникальные префиксы к именам ресурсов. Однако для сторонних CRD это может быть трудно отслеживать или применять в принудительном порядке (например, для разных версий cert-manager, которые используются арендаторами, могут потребоваться разные версии одних и тех же CRD).

Снижение боли, связанной с CRD в многопользовательских кластерах

Как и в случае с большинством вещей в Kubernetes, использование CRD в многопользовательской среде добавляет уникальный набор технических проблем. Но есть несколько подходов и инструментов, с помощью которых можно справиться с этими трудностями.

Не используйте CRD, если можете их избежать

Прежде всего, рассмотрите альтернативы CRD: один из способов минимизировать неудобства, связанные с CRD в многопользовательских кластерах Kubernetes, - это вообще избегать их. Экосистема Kubernetes предлагает ряд альтернативных вариантов, которые вы можете использовать, чтобы потенциально добиться того же с CRD. Даже официальная документация Kubernetes предоставляет сравнительную таблицу в качестве руководства для выбора между созданием агрегации Kubernetes API и автономным API вне Kubernetes. Эта страница документации также рекомендует использовать встроенные объекты Kubernetes, когда это возможно, и объясняет, почему, например, простые ConfigMaps могут решить множество проблем, которые некоторые люди могут захотеть решить с помощью CRD, хотя часто нет реальной необходимости в таком уровне сложности.

Итак, дважды подумайте, прежде чем даже создавать свои собственные CRD или устанавливать чужие CRD в свой кластер. Иногда простой ConfigMap может быть достаточно, и с ней, безусловно, будет намного проще работать в долгосрочной перспективе.

Рассмотрите отдельные кластеры или виртуальные кластеры

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

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

Не изобретайте колесо заново - используйте существующие решения

Используйте передовой опыт в качестве отправной точки: мы увидели, как некоторые из наиболее широко рекомендуемых передовых практик могут привести к нежелательным результатам, особенно при применении без предыстории и контекста. Но нельзя сказать, что передовой опыт не имеет никакой ценности. Лучшие практики и советы хорошо работают как отправные точки для улучшения вашей собственной реализации. В конце концов, не все варианты использования или настройки развертывания одинаковы.

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

Например, Лофт предлагает полный спектр решений для мультитенантных платформ Kubernetes. После установки в кластер Kubernetes Loft позволяет самостоятельно создавать пространства имен и виртуальные кластеры, эффективно решая самые серьезные проблемы использования CRD в многопользовательских кластерах.

Заключение

Обработка пользовательских определений ресурсов (CRD) может быть источником технических проблем в многопользовательских настройках Kubernetes. Подходы, которым мы обычно следуем при решении проблем многопользовательской настройки, также затрудняют использование CRD в таких средах.

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

Фото Каролина Грабовская из Pexels

Первоначально опубликовано на https://loft.sh.