You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 17, 2025. It is now read-only.
Copy file name to clipboardExpand all lines: docs/user-guide/concepts.md
+69-2
Original file line number
Diff line number
Diff line change
@@ -13,6 +13,7 @@ namespaces are, and _why_ they behave the way they do.
13
13
*[Basic concepts](#basic)
14
14
*[Parents, children, trees and forests](#basic-trees)
15
15
*[Full namespaces and subnamespaces](#basic-subns)
16
+
*[Hierarchical resource quotas (HRQs)](#hrq)
16
17
*[Policy inheritance and object propagation](#basic-propagation)
17
18
*[Tree labels and non-propagated policies](#basic-labels)
18
19
*[Exceptions and propagation control](#basic-exceptions)
@@ -87,6 +88,8 @@ namespaces:
87
88
as isolation units for their own services. However, namespace creation is a
88
89
privileged cluster-level operation, and you typically want to control this
89
90
privilege very closely.
91
+
* You might want to give some amount of resources to a team (similar to `ResourceQuota`), and they can
92
+
distribute those resources between their subnamespaces.
90
93
* Finally, you might want to avoid having to find unique names for every
91
94
namespace in the cluster.
92
95
@@ -218,6 +221,70 @@ probably not a great idea.
218
221
You can create a subnamespace from the command line via `kubectl hns create child
219
222
-n parent`.
220
223
224
+
<aname="hrq">
225
+
226
+
### Hierarchical resource quotas (HRQs)
227
+
228
+
***Hierarchical resource quotas are beta in HNC v1.1***
229
+
230
+
***HRQs are not included by default, to use it install the hrq.yaml file in the [releases -> Assets](https://github.com/kubernetes-sigs/hierarchical-namespaces/releases)***
231
+
232
+
When you want to give some amount of resources to `team-a`, and want them to be able to
233
+
flexibly use resources in any of their subnamespaces, you create a `HierarchicalResourceQuota`
234
+
in namespace `team-a`. The sum of all resources from all the subnamespaces of the
235
+
members wont be over the amount of resources that is configured in
236
+
`HierarchicalResourceQuota` of namespace `team-a`. All of the reasources of `team-a` are
237
+
equally shared between the applications in their subnamespaces, which is very efficient.
238
+
239
+
In addition, you can let an org or team's admin create their own hierarchical
240
+
quotas without violating the overall HRQ for their org or team. For example,
241
+
if you start with the following structure:
242
+
```
243
+
company-a
244
+
├── organization-a
245
+
│ ├── org-a-team-1
246
+
│ ├── org-a-team-2
247
+
│ ...
248
+
├── organization-b
249
+
│ ├── org-b-team-1
250
+
│ ├── org-b-team-2
251
+
│ ...
252
+
...
253
+
```
254
+
Instead of each team asking from the `cluster-admin` to modify their `ResourceQuota`,
255
+
you can insert an additional "policy" namespace above each level to hold
256
+
the policy objects (like hierarchical quota) that the sub-admin _cannot_
257
+
change, while giving them permission to create their own quotas in the
258
+
lower level namespaces, like this:
259
+
```
260
+
company-a-policy
261
+
└── company-a
262
+
```
263
+
And put the resources HRQ in the `company-a-policy` namespace. This will restrict
264
+
whole `company-a` to the amount of resources that they are paying for. Then `company-a`
265
+
can do similar HRQ with their organizations:
266
+
```
267
+
company-a-policy (has HRQ)
268
+
└── company-a
269
+
├── org-a-policy (has HRQ)
270
+
│ └── organization-a
271
+
├── org-b-policy (has HRQ)
272
+
│ └── organization-b
273
+
...
274
+
```
275
+
Lower-level quotas cannot override more restrictive quotas from ancestor namespaces;
276
+
the most restrictive quota always wins.
277
+
This way each individual can fairly and securely distribute their resources across
278
+
their members.
279
+
280
+
To implement hierarchical quotas, HNC automatically creates `ResourceQuota` objects in each
281
+
affected namespace. This is a part of the internal implementation and shouldn't be modified or
282
+
inspected. Use the `kubectl hns hrq` command to inspect hierarchical quotas,
283
+
or look at the `HierarchicalResourceQuota` object in the ancestor
284
+
namespaces.
285
+
286
+
Note: Decimal point values cannot be specified in HRQ (you can't do `cpu: 1.5` but you can do `cpu: "1.5"` or `cpu: 1500m`). See [#292](https://github.com/kubernetes-sigs/hierarchical-namespaces/issues/292)
287
+
221
288
<aname="basic-propagation">
222
289
223
290
### Policy inheritance and object propagation
@@ -327,7 +394,7 @@ HNC typically propagates _all_ objects of a [specified type](how-to.md#admin-res
327
394
from ancestor namespaces to descendant namespaces. However, sometimes this is
328
395
too restrictive, and you need to create ***exceptions*** to certain policies. For example:
329
396
330
-
* A ResourceQuota was propagated to many children, but one child namespace now
397
+
* A `ResourceQuota` was propagated to many children, but one child namespace now
331
398
has higher requirements than the rest. Rather than getting rid of the quota in
332
399
the parent namespace, or raising the limit for everyone, you can stop the
333
400
quota in the parent from being propagated to that _one_ child namespace,
@@ -345,7 +412,7 @@ an object can also control how it is propagated to descendant namespaces.
345
412
If you modify an exception - for example, by removing it - this could cause
346
413
the object to be propagated to descendants from which it had previously been
347
414
excluded. This could cause you to accidentally overwrite objects that were
348
-
intended to be exceptions from higher-level policies, like the ResourceQuota
415
+
intended to be exceptions from higher-level policies, like the `ResourceQuota`
349
416
in the example above. To prevent this, if modifying an exception would cause
350
417
HNC to overwrite another object, HNC’s admission controllers will prevent you
351
418
from modifying the object, and will identify the objects that would have been
*[Select namespaces based on their hierarchies](#use-select)
14
15
*[Delete a subnamespace](#use-subns-delete)
15
16
*[Organize full namespaces into a hierarchy](#use-full)
@@ -186,6 +187,21 @@ permissions. To understand why an object is not being propagated to a namespace,
186
187
use `kubectl hns describe <ns>`, where `<ns>` is either the source (ancestor) or
187
188
destination (descendant) namespace.
188
189
190
+
<aname="use-hrq"/>
191
+
192
+
### Limit Resources over parent namespaces
193
+
194
+
***Hierarchical resource quotas are beta in HNC v1.1***
195
+
196
+
***HRQs are not included by default, to use it install the hrq.yaml file in the [releases -> Assets](https://github.com/kubernetes-sigs/hierarchical-namespaces/releases)***
197
+
198
+
HNC has an object called `HierarchicalResourceQuota` which is a drop-in replacement for `ResourceQuota`
199
+
but across all the namespaces in a hierarchy. It allows you to distribute your resources between
200
+
teams, and those teams can distribute their resources between their subteams.
201
+
[Learn how it works](concepts.md#hierarchical-resource-quota) or see an [quickstart example](quickstart.md#hrq)
202
+
203
+
Note: Decimal point values cannot be specified in HRQ (you can't do `cpu: 1.5` but you can do `cpu: "1.5"` or `cpu: 1500m`). See [#292](https://github.com/kubernetes-sigs/hierarchical-namespaces/issues/292)
***Hierarchical resource quotas are beta in HNC v1.1***
467
+
468
+
***HRQs are not included by default, to use it install the hrq.yaml file in the [releases -> Assets](https://github.com/kubernetes-sigs/hierarchical-namespaces/releases)***
469
+
470
+
_Will demonstrate: Create and delete [HierarchicalResourceQuota](concepts.md#hierarchical-resource-quota)._
471
+
472
+
Let's assume you own _acme-org_ from the previous example:
473
+
```
474
+
acme-org
475
+
├── [s] team-a
476
+
└── [s] team-b
477
+
```
478
+
479
+
You can create a `HierarchicalResourceQuota` in namespace `acme-org`, and the sum of
480
+
all subnamespaces resource usage can't go over what is configured in the HRQ.
481
+
482
+
We will demonstrate how it works using services, but you could also limit `cpu`,
483
+
`memory`or any other `ResourceQuota` field.
484
+
485
+
Creating the HRQ:
486
+
```bash
487
+
kubectl apply -f - << EOF
488
+
kind: HierarchicalResourceQuota
489
+
apiVersion: hnc.x-k8s.io/v1alpha2
490
+
metadata:
491
+
name: acme-org-hrq
492
+
namespace: acme-org
493
+
spec:
494
+
hard:
495
+
services: 1
496
+
EOF
497
+
```
498
+
499
+
Lets create Service in namespace `team-a`:
500
+
```bash
501
+
kubectl create service clusterip team-a-svc --clusterip=None -n team-a
502
+
```
503
+
504
+
And when we try to create Service in namespace `team-b`:
505
+
```bash
506
+
kubectl create service clusterip team-b-svc --clusterip=None -n team-b
507
+
```
508
+
We get an error:
509
+
```
510
+
Error from server (Forbidden):
511
+
error when creating "STDIN":
512
+
admission webhood "resourcesquotasstatus.hnc.x-k8s.io" denied the request:
513
+
exceeded hierarchical quota in namespace "acme-org":
0 commit comments