В этой статье мы рассмотрим иерархический контроллер пространства имен Kubernetes, или сокращенно HNC.
HNC вышла из рабочей группы Kubernetes по мультитенантности.
Хотя он в настоящее время находится в стадии инкубации и еще не подходит для производства, он может предоставить некоторые полезные строительные блоки и парадигмы для создания легко управляемой многопользовательской архитектуры в кластере Kubernetes.
В этой части серии мы будем:
Создание иерархии пространств имен
Демонстрация возможности делегировать создание подпространства имен без роли кластера
Перемещение пространств имен из одной части иерархии в другую
Просмотр того, как роли и привязки RBAC распространяются через HNC
Прежде всего, позвольте мне рассказать вам историю ...
Фон
В параллельной вселенной, созданной разрывом в ткани пространственно-временного континуума, Kubernetes был изобретен в 1980-х годах для работы на Atari ST.
K8sST (наша вымышленная компания того времени) занималась бизнесом: в основном продавала Kubernetes ... на дискетах ... на самом деле поддон дискет ... по почте ... оплачивалась чеком.
Это была безумная бизнес-идея - глобальный Wi-Fi был естественным явлением в нашей параллельной вселенной с тех пор, как в юрский период на Землю упал метеор. Это было везде, бесплатно и очень быстро.
Тем не менее, венчурные капиталисты того времени, ну, скажем так, они много веселились и бросали деньги в K8sST, как будто завтра не наступило.
K8sST взял эти деньги венчурного капитала и тоже потратил их, как будто завтра не наступит. Они быстро выросли в крупную организацию с многочисленными подразделениями: снабжение, маркетинг, кадры, сбыт, финансы и так далее. У каждого подразделения была собственная инженерная функция, разделенная на несколько команд. Каждая команда по очереди заботилась об одном или нескольких продуктах или услугах.
Например, в отделе дистрибуции была команда управления заказами. Они несли ответственность за систему управления заказами (ключевой механизм рабочего процесса для управления заказами) и систему уведомлений о заказах (используемую для отправки электронных писем и текстовых сообщений клиентам относительно их заказа).
Каждый из этих продуктов состоял из ряда отдельных микросервисов. Например, Система уведомлений о заказах внутри содержала службу электронной почты, службу SMS и службу шаблонов.
На уровне платформы K8sST запускал свои сервисы на самом Kubernetes ... на огромном кластере Atari ST (не спрашивайте меня, как). Команда разработчиков платформы фактически сопоставила каждый продукт с пространством имен kubernetes. Затем им нужно было настроить RBAC, чтобы он отображал нужные разрешения для каждого пространства имен членам команды, которые за ним следили. Им также необходимо было настроить RBAC для центрального SRE отдела распространения и групп поддержки, чтобы у них были разрешения и в этих пространствах имен.
С большим количеством подразделений, с большим количеством команд, занимающихся растущим количеством продуктов, все становится сложнее:
RBAC - беспорядок
Сетевые политики повсюду
Команда разработчиков платформы устала от административной нагрузки, связанной с обработкой новых запросов пространства имен каждый раз, когда кто-то в них нуждается.
Жизнь тяжела!
Иерархический контроллер пространства имен Kubernetes (HNC)
Иерархический контроллер пространства имен предоставляет механизм для организации пространств имен kubernetes в иерархии, посредством чего дочерние пространства имен могут наследовать такие вещи, как роли / привязки RBAC и сетевые политики из своего родительского пространства имен.
Вы также можете делегировать возможность создавать подпространства имен роли, привязанной к пространству имен, без необходимости предоставлять роли кластера разрешения на создание пространств имен. По сути, «Вот ваше основное пространство имен. Если вам нужно больше, создайте их сами »- больше не нужно трудиться, проходя процесс утверждения.
HNC звучит именно так, как нужно команде разработчиков платформы K8sST, поэтому они берутся за дело.
Настройка
Для начала нам нужно установить HNC в кластере. Нам также необходимо установить удобный плагин kubectl-hns.
В этом эксперименте мы используем minikube на Mac.
Установите minikube, если у вас его еще нет, и запустите кластер:
brew install minikube
minikube start
Установите HNC на кластер:
HNC_VERSION=v0.5.1kubectl apply -f https://github.com/kubernetes-sigs/multi-tenancy/releases/download/hnc-${HNC_VERSION}/hnc-manager.yaml
В настоящее время не существует плагина kubectl-hns, скомпилированного для Mac, поэтому мы скомпилируем его сами:
go get sigs.k8s.io/multi-tenancy/incubator/hnc/internal/kubectlcd $GOPATH/src/sigs.k8s.io/multi-tenancy/incubator/hncgit fetch --all --tagsgit checkout hnc-${HNC_VERSION}go build -o /usr/local/bin/kubectl-hns ./cmd/kubectl/main.go
Наконец, убедитесь, что плагин kubectl-hns работает:
kubectl hns
На этом этапе вы должны увидеть:
Manipulates hierarchical namespaces provided by HNCUsage:kubectl-hns [command]Available Commands:config Manipulates the HNC configuration
create Creates a subnamespace under the given parent.
describe Displays information about the hierarchy configuration
help Help about any command
set Sets hierarchical properties of the given namespace
tree Display one or more hierarchy trees
...
Построение иерархии пространств имен
Иерархия пространств имен, которую мы пытаемся построить, выглядит так:
org
- distribution
- order-management
- order-notification-system
- order-management-system- marketing
- online-marketing
- email-marketing-system
- offline-marketing
- junkmail-system
Начнем с пространства имен org. Это наше корневое пространство имен для всей организации ...
kubectl create namespace org
… Добавить наши разделенные пространства имен…
kubectl create namespace distribution
kubectl create namespace marketing
… Начни собирать дерево…
kubectl hns set distribution --parent org
kubectl hns set marketing --parent org
… И просмотрите дерево…
kubectl hns tree org
…который дает…
org
├── distribution
└── marketing
Пространства имен самообслуживания
Здесь следует отметить одну вещь: в контексте HNC все пространства имен в нашем дереве пока являются полными пространствами имен. Таким образом, для их создания требуются разрешения на уровне кластера, что возвращает нас к процессу утверждения пространства имен. В данном случае это имеет смысл: распространение и маркетинг - это такие высокоуровневые пространства имен, но мы хотим, чтобы наши администраторы распространения и маркетинга могли самостоятельно обслуживать новые подпространства имен для своих команд.
Для этого нам нужны роль и привязка ролей к нашим пространствам имен. Начнем с пространства имен дистрибутива.
Роль…
Примечание: это разрешения роли, которую использует HNC, но ограниченная одним пространством имен. Я использовал эти разрешения в этой роли исключительно для того, чтобы выделить максимальные разрешения, которые вы можете распространять с помощью HNC. Все, что выходит за рамки этих разрешений, не может быть распространено.
cat <<EOF | kubectl apply -n distribution -f -
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: distribution
name: distribution-admin
rules:
- apiGroups:
- '*'
resources:
- '*'
verbs:
- create
- delete
- deletecollection
- get
- impersonate
- list
- patch
- update
- watch
- apiGroups:
- ""
resources:
- namespaces
verbs:
- get
- list
- patch
- update
- watch
- apiGroups:
- hnc.x-k8s.io
resources:
- hierarchies
verbs:
- create
- delete
- get
- list
- patch
- update
- watch
- apiGroups:
- hnc.x-k8s.io
resources:
- hierarchies/status
verbs:
- get
- patch
- update
EOF
… Привязка…
cat <<EOF | kubectl apply -n distribution -f -
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: distribution-admin
namespace: distribution
subjects:
- kind: User
name: distribution-admin
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: distribution-admin
apiGroup: rbac.authorization.k8s.io
EOF
… Наконец, пользователь.
# Generate certsopenssl genrsa -out distribution-admin.key 2048openssl req -new -key distribution-admin.key -out distribution-admin.csr -subj "/CN=distribution-admin/O=distribution-admin"openssl x509 -req -in distribution-admin.csr -CA ~/.minikube/ca.crt -CAkey ~/.minikube/ca.key -CAcreateserial -out distribution-admin.crt -days 500
# create the user and kubernetes contextkubectl config set-credentials distribution-admin --client-certificate=distribution-admin.crt --client-key=distribution-admin.keykubectl config set-context distribution-admin --cluster=minikube --user=distribution-admin
# switch context to the userkubectl config use-context distribution-admin
# verify you have access to the distribution namespacekubectl get pods -n distribution
Построй собственное дерево
Теперь, когда мы используем пользователя с правами администратора дистрибутива и имеем полные права доступа к пространству имен дистрибутива, мы продолжим построение дерева. Давайте добавим пространство имен для управления заказами под распространение
kubectl hns create order-management -n distribution
Здесь следует отметить, что роли и привязки из пространства имен распределения распространились на пространство имен управления порядком:
kubectl get role -n order-managementNAME AGE
distribution-admin 3m6s
На этом этапе наш администратор распределения может создать роль администратора управления заказами и делегировать разрешения для создания подпространств имен в этом пространстве имен. А пока мы просто воспользуемся ролью, распространяемой администратором дистрибутива, для построения остальной части нашего дерева.
kubectl hns create order-management-system -n order-management
kubectl hns create order-notification-system -n order-management
Теперь посмотрим на дерево:
kubectl hns tree distributiondistribution
└── order-management
├── order-management-system
└── order-notification-system
Примечание: как администратор распределения я могу видеть только ту часть дерева, за которую отвечаю. Если я пытаюсь просмотреть все дерево организации, я получаю сообщение об ошибке, так как у меня нет разрешений на другие пространства имен, а это именно то, что нам нужно.
kubectl hns tree org> Error reading namespace org: namespaces "org" is forbidden: User "distribution-admin" cannot get resource "namespaces" in API group "" in the namespace "org"
Очевидно, нам действительно нужно создать администратора по маркетингу для пространства имен маркетинга, чтобы делегировать ответственность за создание пространства имен, но пока мы просто вернемся к пользователю minikube и закончим наше дерево.
kubectl config use-context minikube
kubectl hns create online-marketing -n marketing
kubectl hns create email-marketing-system -n online-marketing
kubectl hns create offline-marketing -n marketing
kubectl hns create junkmail-system -n offline-marketing
И наше дерево готово:
kubectl hns tree orgorg
├── distribution
│ └── order-management
│ ├── order-management-system
│ └── order-notification-system
└── marketing
└── online-marketing
└── email-marketing-system
└── offline-marketing
└── junkmail-system
Встряхивая дерево
Какое-то время в K8sST дела обстоят золотом:
Подразделения и команды могут самостоятельно обслуживать пространства имен
У команды платформы меньше работы по управлению пространствами имен и RBAC, но они живут в безопасности, зная, что администраторы подразделения не могут создавать другие роли, превышающие их собственные привилегии.
Жизнь хороша!
Затем несколько ярких заметок: управление заказами и онлайн-маркетинг имеют много дублирования: службы шаблонов, службы электронной почты, службы SMS, приложения CMS. Они должны быть утилитарными, основным набором сервисов, которые будут использоваться в организации.
Во вновь созданном подразделении Core Services создается группа уведомлений. Они должны взять на себя систему уведомлений о заказах для группы управления заказами и систему электронного маркетинга от команды онлайн-маркетинга с целью их рационализации и устранения дублирования.
Дерево было таким:
org
├── distribution
│ └── order-management
│ ├── order-management-system
│ └── order-notification-system
└── marketing
└── online-marketing
└── email-marketing-system
└── offline-marketing
└── junkmail-system
Теперь это должно быть так:
org
├── distribution
│ └── order-management
│ ├── order-management-system
└── marketing
| └── offline-marketing
| └── junkmail-system
└── core-services
└── notifications
└── order-notification-system
└── email-marketing-system
Так как же нам встряхнуть дерево, чтобы достичь желаемого результата?
Прежде всего, давайте поместим наши новые пространства имен core-services и notifications в наше дерево.
# Create the core-service namespace
kubectl create namespace core-services# Make it as a child of the org
kubectl hns set core-services --parent org# Create the notifications subnamespace
kubectl hns create notifications -n core-services
Мы также дадим основным сервисам роль администратора.
cat <<EOF | kubectl apply -n core-services -f -
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: core-services
name: core-services-admin
rules:
- apiGroups:
- '*'
resources:
- '*'
verbs:
- create
- delete
- deletecollection
- get
- impersonate
- list
- patch
- update
- watch
- apiGroups:
- ""
resources:
- namespaces
verbs:
- get
- list
- patch
- update
- watch
- apiGroups:
- hnc.x-k8s.io
resources:
- hierarchies
verbs:
- create
- delete
- get
- list
- patch
- update
- watch
- apiGroups:
- hnc.x-k8s.io
resources:
- hierarchies/status
verbs:
- get
- patch
- update
EOF
… И привязка:
cat <<EOF | kubectl apply -n core-services -f -
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: core-services-admin
namespace: core-services
subjects:
- kind: User
name: core-services-admin
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: core-services-admin
apiGroup: rbac.authorization.k8s.io
EOF
Затем мы хотим переместить пространство имен системы уведомлений о заказах и пространство имен электронной почты в пространство имен уведомлений.
С полными пространствами имен это относительно просто. Мы просто поменяли бы родителя. Например, мы можем изменить родительский элемент пространства имен распространения на пространство имен маркетинга.
kubectl hns set distribution --parent marketing
Тогда наше дерево будет выглядеть так.
kubectl hns tree orgorg
├── core-services
│ └── notifications
└── marketing
├── distribution
└── order-management
│ ├── order-management-system
│ └── order-notification-system
└── online-marketing
│ └── email-marketing-system
└── offline-marketing
└── junkmail-system
Давай вернем это обратно.
kubectl hns set distribution --parent org
Перемещение подпространства имен
Однако на данный момент жизнь с подпространствами имен не так проста. В настоящее время вы не можете изменить или удалить родителя из подпространства имен в HNC, хотя я надеюсь, что эта функция будет поддерживаться в будущем.
Однако в качестве обходного пути вы можете изменить подпространство имен обратно на полное пространство имен, изменить его родителя и снова сделать его подпространством имен, когда закончите.
Давайте сделаем это сейчас для нашего пространства имен системы уведомлений о заказах.
Чтобы изменить подпространство имен обратно на полное пространство имен, нам нужно удалить из него аннотацию hnc.x-k8s.io/subnamespaceOf.
kubectl annotate namespace order-notification-system hnc.x-k8s.io/subnamespaceOf-
Теперь мы можем изменить родительский элемент нашего пространства имен ...
kubectl hns set order-notification-system --parent notifications
… И удалите привязку подпространства имен в родительском пространстве имен:
kubectl delete subnamespaceanchor order-notification-system -n order-management
Наконец, превратите пространство имен обратно в подпространство имен, повторно добавив аннотацию hnc.x-k8s.io/subnamespaceOf…
kubectl annotate namespace order-notification-system hnc.x-k8s.io/subnamespaceOf=notifications
… И создание нового якоря подпространства имен в новом родительском пространстве имен:
cat <<EOF | kubectl apply -n notifications -f -
apiVersion: hnc.x-k8s.io/v1alpha1
kind: SubnamespaceAnchor
metadata:
name: order-notification-system
EOF
Повторение для пространства имен email-marketing-system:
kubectl annotate namespace email-marketing-system hnc.x-k8s.io/subnamespaceOf-kubectl hns set email-marketing-system --parent notificationskubectl delete subnamespaceanchor email-marketing-system -n online-marketingkubectl annotate namespace email-marketing-system hnc.x-k8s.io/subnamespaceOf=notificationscat <<EOF | kubectl apply -n notifications -f -
apiVersion: hnc.x-k8s.io/v1alpha1
kind: SubnamespaceAnchor
metadata:
name: email-marketing-system
EOF
Наше новое дерево
Наше дерево теперь находится в желаемом состоянии:
kubectl hns tree orgorg
├── core-services
│ └── notifications
│ ├── email-marketing-system
│ └── order-notification-system
├── distribution
│ └── order-management
│ └── order-management-system
└── marketing
├── offline-marketing
│ └── junkmail-system
└── online-marketing
Мы также можем видеть, что HNC позаботился о миграции разрешений rbac, когда мы переместили пространство имен. Наша роль администратора основных служб теперь находится в пространствах имен, связанных с уведомлениями, но администратор распространения больше не имеет никаких разрешений.
kubectl get roles -n order-notification-systemNAME AGE
core-services-admin 6m50s
У команды платформы K8sST был хороший день. Даже довольно существенная реорганизация их не смутила - они были выполнены за полчаса, и они вернулись к более важной работе, такой как установка УВК на их кластеры Atari ST и обычное пятничное пиво после обеда.
Жизнь… все еще… хороша!
Подводя итоги
HNC действительно помог команде платформы K8sST организовать структуру пространств имен, чтобы она соответствовала структуре и рабочим границам их организации, и сделал потенциально сложные изменения относительно простыми.
Команды инженеров получили возможность самостоятельно обслуживать пространства имен, что сделало их более автономными, но в рамках ограничений, установленных HNC.
Наш кластер теперь выглядит как наша организация, что может быть хорошо, а может и нет.
Следующий
Во второй части мы рассмотрим, как распространить сетевые политики и другие ресурсы кубернетов в дочерние пространства имен.
Мы также увидим, как команда разработчиков платформы справляется с неизбежной кончиной K8sST и как они используют каскадные функции HNC, чтобы не отставать от темпов распада организации.
Источники
Для молодых HNC пока еще не так много возможностей, поэтому я почерпнул большую часть информации, которую использовал в этой статье, в основном из приведенных ниже ссылок - и изрядно проб и ошибок.
github.com
kubernetes.io
github.com
Перевод статьи с сайта: https://medium.com/
HNC вышла из рабочей группы Kubernetes по мультитенантности.
Хотя он в настоящее время находится в стадии инкубации и еще не подходит для производства, он может предоставить некоторые полезные строительные блоки и парадигмы для создания легко управляемой многопользовательской архитектуры в кластере Kubernetes.
В этой части серии мы будем:
Создание иерархии пространств имен
Демонстрация возможности делегировать создание подпространства имен без роли кластера
Перемещение пространств имен из одной части иерархии в другую
Просмотр того, как роли и привязки RBAC распространяются через HNC
Прежде всего, позвольте мне рассказать вам историю ...
Фон
В параллельной вселенной, созданной разрывом в ткани пространственно-временного континуума, Kubernetes был изобретен в 1980-х годах для работы на Atari ST.
K8sST (наша вымышленная компания того времени) занималась бизнесом: в основном продавала Kubernetes ... на дискетах ... на самом деле поддон дискет ... по почте ... оплачивалась чеком.
Это была безумная бизнес-идея - глобальный Wi-Fi был естественным явлением в нашей параллельной вселенной с тех пор, как в юрский период на Землю упал метеор. Это было везде, бесплатно и очень быстро.
Тем не менее, венчурные капиталисты того времени, ну, скажем так, они много веселились и бросали деньги в K8sST, как будто завтра не наступило.
K8sST взял эти деньги венчурного капитала и тоже потратил их, как будто завтра не наступит. Они быстро выросли в крупную организацию с многочисленными подразделениями: снабжение, маркетинг, кадры, сбыт, финансы и так далее. У каждого подразделения была собственная инженерная функция, разделенная на несколько команд. Каждая команда по очереди заботилась об одном или нескольких продуктах или услугах.
Например, в отделе дистрибуции была команда управления заказами. Они несли ответственность за систему управления заказами (ключевой механизм рабочего процесса для управления заказами) и систему уведомлений о заказах (используемую для отправки электронных писем и текстовых сообщений клиентам относительно их заказа).
Каждый из этих продуктов состоял из ряда отдельных микросервисов. Например, Система уведомлений о заказах внутри содержала службу электронной почты, службу SMS и службу шаблонов.
На уровне платформы K8sST запускал свои сервисы на самом Kubernetes ... на огромном кластере Atari ST (не спрашивайте меня, как). Команда разработчиков платформы фактически сопоставила каждый продукт с пространством имен kubernetes. Затем им нужно было настроить RBAC, чтобы он отображал нужные разрешения для каждого пространства имен членам команды, которые за ним следили. Им также необходимо было настроить RBAC для центрального SRE отдела распространения и групп поддержки, чтобы у них были разрешения и в этих пространствах имен.
С большим количеством подразделений, с большим количеством команд, занимающихся растущим количеством продуктов, все становится сложнее:
RBAC - беспорядок
Сетевые политики повсюду
Команда разработчиков платформы устала от административной нагрузки, связанной с обработкой новых запросов пространства имен каждый раз, когда кто-то в них нуждается.
Жизнь тяжела!
Иерархический контроллер пространства имен Kubernetes (HNC)
Иерархический контроллер пространства имен предоставляет механизм для организации пространств имен kubernetes в иерархии, посредством чего дочерние пространства имен могут наследовать такие вещи, как роли / привязки RBAC и сетевые политики из своего родительского пространства имен.
Вы также можете делегировать возможность создавать подпространства имен роли, привязанной к пространству имен, без необходимости предоставлять роли кластера разрешения на создание пространств имен. По сути, «Вот ваше основное пространство имен. Если вам нужно больше, создайте их сами »- больше не нужно трудиться, проходя процесс утверждения.
HNC звучит именно так, как нужно команде разработчиков платформы K8sST, поэтому они берутся за дело.
Настройка
Для начала нам нужно установить HNC в кластере. Нам также необходимо установить удобный плагин kubectl-hns.
В этом эксперименте мы используем minikube на Mac.
Установите minikube, если у вас его еще нет, и запустите кластер:
brew install minikube
minikube start
Установите HNC на кластер:
HNC_VERSION=v0.5.1kubectl apply -f https://github.com/kubernetes-sigs/multi-tenancy/releases/download/hnc-${HNC_VERSION}/hnc-manager.yaml
В настоящее время не существует плагина kubectl-hns, скомпилированного для Mac, поэтому мы скомпилируем его сами:
go get sigs.k8s.io/multi-tenancy/incubator/hnc/internal/kubectlcd $GOPATH/src/sigs.k8s.io/multi-tenancy/incubator/hncgit fetch --all --tagsgit checkout hnc-${HNC_VERSION}go build -o /usr/local/bin/kubectl-hns ./cmd/kubectl/main.go
Наконец, убедитесь, что плагин kubectl-hns работает:
kubectl hns
На этом этапе вы должны увидеть:
Manipulates hierarchical namespaces provided by HNCUsage:kubectl-hns [command]Available Commands:config Manipulates the HNC configuration
create Creates a subnamespace under the given parent.
describe Displays information about the hierarchy configuration
help Help about any command
set Sets hierarchical properties of the given namespace
tree Display one or more hierarchy trees
...
Построение иерархии пространств имен
Иерархия пространств имен, которую мы пытаемся построить, выглядит так:
org
- distribution
- order-management
- order-notification-system
- order-management-system- marketing
- online-marketing
- email-marketing-system
- offline-marketing
- junkmail-system
Начнем с пространства имен org. Это наше корневое пространство имен для всей организации ...
kubectl create namespace org
… Добавить наши разделенные пространства имен…
kubectl create namespace distribution
kubectl create namespace marketing
… Начни собирать дерево…
kubectl hns set distribution --parent org
kubectl hns set marketing --parent org
… И просмотрите дерево…
kubectl hns tree org
…который дает…
org
├── distribution
└── marketing
Пространства имен самообслуживания
Здесь следует отметить одну вещь: в контексте HNC все пространства имен в нашем дереве пока являются полными пространствами имен. Таким образом, для их создания требуются разрешения на уровне кластера, что возвращает нас к процессу утверждения пространства имен. В данном случае это имеет смысл: распространение и маркетинг - это такие высокоуровневые пространства имен, но мы хотим, чтобы наши администраторы распространения и маркетинга могли самостоятельно обслуживать новые подпространства имен для своих команд.
Для этого нам нужны роль и привязка ролей к нашим пространствам имен. Начнем с пространства имен дистрибутива.
Роль…
Примечание: это разрешения роли, которую использует HNC, но ограниченная одним пространством имен. Я использовал эти разрешения в этой роли исключительно для того, чтобы выделить максимальные разрешения, которые вы можете распространять с помощью HNC. Все, что выходит за рамки этих разрешений, не может быть распространено.
cat <<EOF | kubectl apply -n distribution -f -
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: distribution
name: distribution-admin
rules:
- apiGroups:
- '*'
resources:
- '*'
verbs:
- create
- delete
- deletecollection
- get
- impersonate
- list
- patch
- update
- watch
- apiGroups:
- ""
resources:
- namespaces
verbs:
- get
- list
- patch
- update
- watch
- apiGroups:
- hnc.x-k8s.io
resources:
- hierarchies
verbs:
- create
- delete
- get
- list
- patch
- update
- watch
- apiGroups:
- hnc.x-k8s.io
resources:
- hierarchies/status
verbs:
- get
- patch
- update
EOF
… Привязка…
cat <<EOF | kubectl apply -n distribution -f -
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: distribution-admin
namespace: distribution
subjects:
- kind: User
name: distribution-admin
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: distribution-admin
apiGroup: rbac.authorization.k8s.io
EOF
… Наконец, пользователь.
# Generate certsopenssl genrsa -out distribution-admin.key 2048openssl req -new -key distribution-admin.key -out distribution-admin.csr -subj "/CN=distribution-admin/O=distribution-admin"openssl x509 -req -in distribution-admin.csr -CA ~/.minikube/ca.crt -CAkey ~/.minikube/ca.key -CAcreateserial -out distribution-admin.crt -days 500
# create the user and kubernetes contextkubectl config set-credentials distribution-admin --client-certificate=distribution-admin.crt --client-key=distribution-admin.keykubectl config set-context distribution-admin --cluster=minikube --user=distribution-admin
# switch context to the userkubectl config use-context distribution-admin
# verify you have access to the distribution namespacekubectl get pods -n distribution
Построй собственное дерево
Теперь, когда мы используем пользователя с правами администратора дистрибутива и имеем полные права доступа к пространству имен дистрибутива, мы продолжим построение дерева. Давайте добавим пространство имен для управления заказами под распространение
kubectl hns create order-management -n distribution
Здесь следует отметить, что роли и привязки из пространства имен распределения распространились на пространство имен управления порядком:
kubectl get role -n order-managementNAME AGE
distribution-admin 3m6s
На этом этапе наш администратор распределения может создать роль администратора управления заказами и делегировать разрешения для создания подпространств имен в этом пространстве имен. А пока мы просто воспользуемся ролью, распространяемой администратором дистрибутива, для построения остальной части нашего дерева.
kubectl hns create order-management-system -n order-management
kubectl hns create order-notification-system -n order-management
Теперь посмотрим на дерево:
kubectl hns tree distributiondistribution
└── order-management
├── order-management-system
└── order-notification-system
Примечание: как администратор распределения я могу видеть только ту часть дерева, за которую отвечаю. Если я пытаюсь просмотреть все дерево организации, я получаю сообщение об ошибке, так как у меня нет разрешений на другие пространства имен, а это именно то, что нам нужно.
kubectl hns tree org> Error reading namespace org: namespaces "org" is forbidden: User "distribution-admin" cannot get resource "namespaces" in API group "" in the namespace "org"
Очевидно, нам действительно нужно создать администратора по маркетингу для пространства имен маркетинга, чтобы делегировать ответственность за создание пространства имен, но пока мы просто вернемся к пользователю minikube и закончим наше дерево.
kubectl config use-context minikube
kubectl hns create online-marketing -n marketing
kubectl hns create email-marketing-system -n online-marketing
kubectl hns create offline-marketing -n marketing
kubectl hns create junkmail-system -n offline-marketing
И наше дерево готово:
kubectl hns tree orgorg
├── distribution
│ └── order-management
│ ├── order-management-system
│ └── order-notification-system
└── marketing
└── online-marketing
└── email-marketing-system
└── offline-marketing
└── junkmail-system
Встряхивая дерево
Какое-то время в K8sST дела обстоят золотом:
Подразделения и команды могут самостоятельно обслуживать пространства имен
У команды платформы меньше работы по управлению пространствами имен и RBAC, но они живут в безопасности, зная, что администраторы подразделения не могут создавать другие роли, превышающие их собственные привилегии.
Жизнь хороша!
Затем несколько ярких заметок: управление заказами и онлайн-маркетинг имеют много дублирования: службы шаблонов, службы электронной почты, службы SMS, приложения CMS. Они должны быть утилитарными, основным набором сервисов, которые будут использоваться в организации.
Во вновь созданном подразделении Core Services создается группа уведомлений. Они должны взять на себя систему уведомлений о заказах для группы управления заказами и систему электронного маркетинга от команды онлайн-маркетинга с целью их рационализации и устранения дублирования.
Дерево было таким:
org
├── distribution
│ └── order-management
│ ├── order-management-system
│ └── order-notification-system
└── marketing
└── online-marketing
└── email-marketing-system
└── offline-marketing
└── junkmail-system
Теперь это должно быть так:
org
├── distribution
│ └── order-management
│ ├── order-management-system
└── marketing
| └── offline-marketing
| └── junkmail-system
└── core-services
└── notifications
└── order-notification-system
└── email-marketing-system
Так как же нам встряхнуть дерево, чтобы достичь желаемого результата?
Прежде всего, давайте поместим наши новые пространства имен core-services и notifications в наше дерево.
# Create the core-service namespace
kubectl create namespace core-services# Make it as a child of the org
kubectl hns set core-services --parent org# Create the notifications subnamespace
kubectl hns create notifications -n core-services
Мы также дадим основным сервисам роль администратора.
cat <<EOF | kubectl apply -n core-services -f -
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: core-services
name: core-services-admin
rules:
- apiGroups:
- '*'
resources:
- '*'
verbs:
- create
- delete
- deletecollection
- get
- impersonate
- list
- patch
- update
- watch
- apiGroups:
- ""
resources:
- namespaces
verbs:
- get
- list
- patch
- update
- watch
- apiGroups:
- hnc.x-k8s.io
resources:
- hierarchies
verbs:
- create
- delete
- get
- list
- patch
- update
- watch
- apiGroups:
- hnc.x-k8s.io
resources:
- hierarchies/status
verbs:
- get
- patch
- update
EOF
… И привязка:
cat <<EOF | kubectl apply -n core-services -f -
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: core-services-admin
namespace: core-services
subjects:
- kind: User
name: core-services-admin
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: core-services-admin
apiGroup: rbac.authorization.k8s.io
EOF
Затем мы хотим переместить пространство имен системы уведомлений о заказах и пространство имен электронной почты в пространство имен уведомлений.
С полными пространствами имен это относительно просто. Мы просто поменяли бы родителя. Например, мы можем изменить родительский элемент пространства имен распространения на пространство имен маркетинга.
kubectl hns set distribution --parent marketing
Тогда наше дерево будет выглядеть так.
kubectl hns tree orgorg
├── core-services
│ └── notifications
└── marketing
├── distribution
└── order-management
│ ├── order-management-system
│ └── order-notification-system
└── online-marketing
│ └── email-marketing-system
└── offline-marketing
└── junkmail-system
Давай вернем это обратно.
kubectl hns set distribution --parent org
Перемещение подпространства имен
Однако на данный момент жизнь с подпространствами имен не так проста. В настоящее время вы не можете изменить или удалить родителя из подпространства имен в HNC, хотя я надеюсь, что эта функция будет поддерживаться в будущем.
Однако в качестве обходного пути вы можете изменить подпространство имен обратно на полное пространство имен, изменить его родителя и снова сделать его подпространством имен, когда закончите.
Давайте сделаем это сейчас для нашего пространства имен системы уведомлений о заказах.
Чтобы изменить подпространство имен обратно на полное пространство имен, нам нужно удалить из него аннотацию hnc.x-k8s.io/subnamespaceOf.
kubectl annotate namespace order-notification-system hnc.x-k8s.io/subnamespaceOf-
Теперь мы можем изменить родительский элемент нашего пространства имен ...
kubectl hns set order-notification-system --parent notifications
… И удалите привязку подпространства имен в родительском пространстве имен:
kubectl delete subnamespaceanchor order-notification-system -n order-management
Наконец, превратите пространство имен обратно в подпространство имен, повторно добавив аннотацию hnc.x-k8s.io/subnamespaceOf…
kubectl annotate namespace order-notification-system hnc.x-k8s.io/subnamespaceOf=notifications
… И создание нового якоря подпространства имен в новом родительском пространстве имен:
cat <<EOF | kubectl apply -n notifications -f -
apiVersion: hnc.x-k8s.io/v1alpha1
kind: SubnamespaceAnchor
metadata:
name: order-notification-system
EOF
Повторение для пространства имен email-marketing-system:
kubectl annotate namespace email-marketing-system hnc.x-k8s.io/subnamespaceOf-kubectl hns set email-marketing-system --parent notificationskubectl delete subnamespaceanchor email-marketing-system -n online-marketingkubectl annotate namespace email-marketing-system hnc.x-k8s.io/subnamespaceOf=notificationscat <<EOF | kubectl apply -n notifications -f -
apiVersion: hnc.x-k8s.io/v1alpha1
kind: SubnamespaceAnchor
metadata:
name: email-marketing-system
EOF
Наше новое дерево
Наше дерево теперь находится в желаемом состоянии:
kubectl hns tree orgorg
├── core-services
│ └── notifications
│ ├── email-marketing-system
│ └── order-notification-system
├── distribution
│ └── order-management
│ └── order-management-system
└── marketing
├── offline-marketing
│ └── junkmail-system
└── online-marketing
Мы также можем видеть, что HNC позаботился о миграции разрешений rbac, когда мы переместили пространство имен. Наша роль администратора основных служб теперь находится в пространствах имен, связанных с уведомлениями, но администратор распространения больше не имеет никаких разрешений.
kubectl get roles -n order-notification-systemNAME AGE
core-services-admin 6m50s
У команды платформы K8sST был хороший день. Даже довольно существенная реорганизация их не смутила - они были выполнены за полчаса, и они вернулись к более важной работе, такой как установка УВК на их кластеры Atari ST и обычное пятничное пиво после обеда.
Жизнь… все еще… хороша!
Подводя итоги
HNC действительно помог команде платформы K8sST организовать структуру пространств имен, чтобы она соответствовала структуре и рабочим границам их организации, и сделал потенциально сложные изменения относительно простыми.
Команды инженеров получили возможность самостоятельно обслуживать пространства имен, что сделало их более автономными, но в рамках ограничений, установленных HNC.
Наш кластер теперь выглядит как наша организация, что может быть хорошо, а может и нет.
Следующий
Во второй части мы рассмотрим, как распространить сетевые политики и другие ресурсы кубернетов в дочерние пространства имен.
Мы также увидим, как команда разработчиков платформы справляется с неизбежной кончиной K8sST и как они используют каскадные функции HNC, чтобы не отставать от темпов распада организации.
Источники
Для молодых HNC пока еще не так много возможностей, поэтому я почерпнул большую часть информации, которую использовал в этой статье, в основном из приведенных ниже ссылок - и изрядно проб и ошибок.
multi-tenancy/incubator/hnc at master · kubernetes-retired/multi-tenancy
A working place for multi-tenancy related proposals and prototypes. - kubernetes-retired/multi-tenancy
github.com
Introducing Hierarchical Namespaces
Author: Adrian Ludwin (Google) Safely hosting large numbers of users on a single Kubernetes cluster has always been a troublesome task. One key reason for this is that different organizations use Kubernetes in different ways, and so no one tenancy model is likely to suit everyone. Instead...
Change the parent of a subnamespace · Issue #1045 · kubernetes-retired/multi-tenancy
Hi, I can envisage a scenario where changing the parent of a subnamespace would be really beneficial. Is this something that HNC is likely to support? Scenario: Large organisation, lots of teams, w...
github.com
Перевод статьи с сайта: https://medium.com/