Могут ли несколько команд использовать один и тот же кластер Kubernetes?
Можно ли безопасно запускать ненадежные рабочие нагрузки от ненадежных пользователей?
Поддерживает ли Kubernetes мультиарендность?
В этой статье рассмотрим проблемы запуска кластера с несколькими арендаторами.
Мультиарендность можно разделить на:
Мягкая мультиарендность. Когда вы доверяете своим арендаторам. Например, когда вы делите кластер с командами из одной компании.
Жесткая мультиарендность. Когда вы не доверяете арендаторам.
Также вы можете миксовать оба типа.
Фундаментом для совместного использования кластера арендаторами является пространство имен.
Пространства имен группируют ресурсы логически. То есть они не предлагают никаких механизмов безопасности и не гарантируют, что все ресурсы развернуты на одном узле.
Поды в пространстве имен по-прежнему могут взаимодействовать со всеми другими подами в кластере, делать запросы к API и использовать столько ресурсов, сколько захотят.
Из коробки любой пользователь может получить доступ к любому пространству имен.
Как изменить это?
С помощью RBAC вы можете ограничить действия пользователей и приложений с пространством имен и внутри него.
Чаще всего предоставляются определенные разрешения ограниченным пользователям.
С помощью Quotas и LimitRanges вы можете ограничить ресурсы, а также память, ЦП и т.д., которые может использовать определенное пространство имен.
Это отличная идея, если вы хотите ограничить действия арендатора, у которого есть свое пространство имен.
По умолчанию все поды могут взаимодействовать с любыми подами в Kubernetes.
Это не очень хорошо для мультитенантности, но вы можете исправить это с помощью сетевых политик — NetworkPolicies.
Сетевые политики похожи на правила брандмауэра и позволяют разделять исходящий и входящий трафик.
Отлично, теперь пространство имен безопасно?
Не спешите.
Пока что RBAC, NetworkPolicies, Quotas и т. д., дали вам только фундамент для мультиарендности, но этого недостаточно.
Kubernetes имеет несколько общих компонентов.
Хороший пример — контроллер Ingress. Обычно он разворачивается один раз на каждый кластер.
Если вы отправляете Ingress-манифест тем же путем, перезаписывается и работает только один.
Лучше развернуть контроллер для каждого пространства имен.
Еще одна интересная задача — CoreDNS.
Что делать, если один из арендаторов злоупотребляет DNS?
Остальная часть кластера тоже пострадает.
Вы можете ограничить запросы с помощью дополнительного плагина https://github.com/coredns/policy.
Та же проблема относится и к серверу Kubernetes API.
Kubernetes не знает об арендаторе, и если API получает слишком много запросов, то он будет блокировать их для всех.
Я не знаю, есть ли обходной путь для этого!
Предполагаю, что вам удастся разобраться с общими ресурсами, но есть еще проблема с kubelet и рабочими нагрузками.
Как объясняет Филипп Богартс в этой статье, арендатор может взять на себя управление узлами в кластере, просто злоупотребляя проверками на живучесть.
Исправление не тривиальное.
Вы можете использовать линтер как часть CI/CD-процесса или использовать контроллеры допуска для проверки безопасности ресурсов, отправленных в кластер.
Вот библиотека или правила для Open Policy Agent.
У вас также есть контейнеры, которые предлагают более слабый механизм изоляции, чем виртуальные машины.
В этом видео Льюис Денхэм-Пэрри показывает, как избавиться от контейнера.
Как это исправить?
Вы можете использовать контейнерную песочницу, такую как gVisor, легкие виртуальные машины в качестве контейнеров (Kata containers, firecracker + containerd) или полные виртуальные машины (virtlet как CRI).
Надеюсь, вы поняли, что сложность в том, трудно установить жесткие границы для отдельных сетей, рабочих нагрузок и контроллеров в Kubernetes.
Вот почему не рекомендуется предоставлять жесткую мультитенантность в Kubernetes.
Если вам нужна жесткая мультитенантность, советуем вместо этого использовать несколько кластеров или инструмент «Cluster-as-a-Service».
Если вы можете позволить себе более слабую модель с несколькими арендаторами в обмен на простоту и удобство, вы можете выкатить свои RBAC, Quotas и другие правила.
Но есть несколько инструментов, которые возьмут на себя эти проблемы:
А чтобы еще больше узнать о том, как разработчикам можно использовать Kubernetes в работе, вы можете прийти на наш курс «Kubernetes: Мега», который стартует 19 июня. Он рассчитан на специалистов, которые уже имеют опыт работы с ним. В курсе мы заглянем под капот Kubernetes: изучим тонкости установки и конфигурации production-ready кластера («the-not-so-easy-way»), механизмы обеспечения стабильности и безопасности, отказоустойчивости приложений и масштабирование, разберем стратегические задачи, касающиеся инфраструктуры.
