Ничто из перечисленного не является идеальным решением.Я пойду, почему.
Безопасность
Пространства имен - это самая простая граница для управления разрешениями RBAC.В общем случае вы захотите использовать предварительно подготовленные роли кластера администратора и редактора, чтобы ограничить доступ пользователей к использованию пространств имен.Это означает, что люди и службы, которые совместно используют пространства имен, также делятся видимостью секретов.Таким образом, пространство имен становится радиусом взрыва для компрометации секретов.
Чтобы уменьшить взрывной радиус раскрытия секретов, вы можете либо связать роль уровня управления микро-ресурсами (что неоправданно затратно, без дополнительной автоматизации и инструментов), либо разделить службы по пространствам имен, чтобы только тесно связанные службы совместно использовали пространство имен.
Изоляция
Изоляция ресурсов Kubernetes относительно плоха между пространствами имен.Нет способа принудительно развернуть пространство имен в другом пуле узлов, чем другое пространство имен без пользовательских контроллеров доступа.Таким образом, изоляция ресурсов фактически является обязательной, что является одновременно небезопасным и неосуществимым.
Благодаря этому фактически является более безопасным и лучше изолированным, чтобы иметь разные среды (dev, staging, prod) в отдельных кластерах K8s.все вместе.Но это, очевидно, дороже и больше накладных расходов на управление.Так что это экономически выгодно только тогда, когда у вас есть много услуг и достаточно ресурсов, чтобы оправдать дополнительные накладные расходы.
Следствием плохой изоляции ресурсов является то, что ваши рабочие и промежуточные рабочие нагрузки могут эффективно выполнять DOS для ваших рабочих нагрузок, просто используя общие ресурсы.Процессор / память / диск являются очевидными виновниками.Это может быть выполнено с помощью пользовательских контроллеров доступа.Но более коварной проблемой является совместное использование входных прокси-серверов, балансировщика нагрузки и сетей, которые сложнее изолировать между пространствами имен.
Еще одним следствием плохой изоляции является то, что службы разработки с плохой безопасностью могут быть скомпрометированы, обеспечивая горизонтальный доступ к службам prod.На самом деле, никто не развертывает приложения dev как готовые к работе и безопасные.Так что без жесткой изоляции ваша безопасность тоже подвергается риску.
Квоты
Квоты управляются на уровне пространства имен.Поэтому, если вы хотите изолировать квоту по среде и команде, вы не можете использовать пространства имен для обоих.И если вы хотите иметь квоту на проект, вам потребуется проект для каждого пространства имен.Единственный способ справиться со всеми тремя - это использовать несколько кластеров, несколько пространств имен и несколько пулов узлов с настраиваемым применением развертывания / принятия, что создает временную иерархию или матрицу.
Иерархия пространств имен
Пространства имен плоские.Если вы используете их для env, вы не можете использовать их для контроля доступа на уровне организации или команды.Если вы используете их для контроля доступа на уровне команды, ваши инженеры могут использовать их для границ абстракции уровня компонента / проекта / системы.Вы можете выбрать только один, или хаос будет неуправляемым.
Заключение
К сожалению, абстракция пространства имен используется в 3 или 4 случаях использования в сообществе Kubernetes, и это не совсем идеально.для любого из них.Таким образом, либо вы выбираете неидеальный вариант использования для оптимизации, либо вы управляете несколькими кластерами и пишете множество пользовательских средств автоматизации для обработки всех вариантов использования.