Skip to content

Commit 647ebad

Browse files
authored
chore: Move the resource requests fragment into a partial (#976)
1 parent ccc31fc commit 647ebad

3 files changed

Lines changed: 50 additions & 50 deletions

File tree

‎modules/concepts/pages/resources.adoc‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -71,7 +71,7 @@ It can not use more CPU resources than `500m` (which is half of a physical or vi
7171

7272
=== CPU and memory
7373

74-
include::stackable_resource_requests.adoc[]
74+
include::partial$stackable_resource_requests.adoc[]
7575

7676
=== Storage
7777

Lines changed: 1 addition & 49 deletions
Original file line numberDiff line numberDiff line change
@@ -1,49 +1 @@
1-
// This is meant to be inlined using the "include" directive in other pages.
2-
// WARNING: do not add headers here as they can break the structure of pages
3-
// that include this file.
4-
Stackable operators handle resource requests in a slightly different manner than Kubernetes.
5-
Resource requests are defined on xref:concepts:stacklet.adoc#roles[role] or xref:concepts:stacklet.adoc#role-groups[role group] level.
6-
On a role level this means that by default, all workers will use the same resource requests and limits.
7-
This can be further specified on role group level (which takes priority to the role level) to apply different resources.
8-
9-
This is an example on how to specify CPU and memory resources using the Stackable https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/[Custom Resources{external-link-icon}^]:
10-
11-
[source, yaml]
12-
----
13-
---
14-
apiVersion: example.stackable.tech/v1alpha1
15-
kind: ExampleCluster
16-
metadata:
17-
name: example
18-
spec:
19-
workers: # role-level
20-
config:
21-
resources:
22-
cpu:
23-
min: 300m
24-
max: 600m
25-
memory:
26-
limit: 3Gi
27-
roleGroups: # role-group-level
28-
resources-from-role: # role-group 1
29-
replicas: 1
30-
resources-from-role-group: # role-group 2
31-
replicas: 1
32-
config:
33-
resources:
34-
cpu:
35-
min: 400m
36-
max: 800m
37-
memory:
38-
limit: 4Gi
39-
----
40-
41-
In this case, the role group `resources-from-role` will inherit the resources specified on the role level, resulting in a maximum of `3Gi` memory and `600m` CPU resources.
42-
43-
The role group `resources-from-role-group` has a maximum of `4Gi` memory and `800m` CPU resources (which overrides the role CPU resources).
44-
45-
IMPORTANT: For Java products the actual used heap memory is lower than the specified memory limit due to other processes in the Container requiring memory to run as well.
46-
Currently, 80% of the specified memory limit is passed to the JVM.
47-
48-
For memory, only a limit can be specified, which will be set as memory request and limit in the container.
49-
This is to always guarantee a container the full amount memory during Kubernetes scheduling.
1+
include::partial$stackable_resource_requests.adoc[]
Lines changed: 48 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,48 @@
1+
// WARNING: do not add headers here as they can break the structure of pages
2+
// that include this file.
3+
Stackable operators handle resource requests in a slightly different manner than Kubernetes.
4+
Resource requests are defined on xref:concepts:stacklet.adoc#roles[role] or xref:concepts:stacklet.adoc#role-groups[role group] level.
5+
On a role level this means that by default, all workers will use the same resource requests and limits.
6+
This can be further specified on role group level (which takes priority to the role level) to apply different resources.
7+
8+
This is an example on how to specify CPU and memory resources using the Stackable https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/[Custom Resources{external-link-icon}^]:
9+
10+
[source, yaml]
11+
----
12+
---
13+
apiVersion: example.stackable.tech/v1alpha1
14+
kind: ExampleCluster
15+
metadata:
16+
name: example
17+
spec:
18+
workers: # role-level
19+
config:
20+
resources:
21+
cpu:
22+
min: 300m
23+
max: 600m
24+
memory:
25+
limit: 3Gi
26+
roleGroups: # role-group-level
27+
resources-from-role: # role-group 1
28+
replicas: 1
29+
resources-from-role-group: # role-group 2
30+
replicas: 1
31+
config:
32+
resources:
33+
cpu:
34+
min: 400m
35+
max: 800m
36+
memory:
37+
limit: 4Gi
38+
----
39+
40+
In this case, the role group `resources-from-role` will inherit the resources specified on the role level, resulting in a maximum of `3Gi` memory and `600m` CPU resources.
41+
42+
The role group `resources-from-role-group` has a maximum of `4Gi` memory and `800m` CPU resources (which overrides the role CPU resources).
43+
44+
IMPORTANT: For Java products the actual used heap memory is lower than the specified memory limit due to other processes in the Container requiring memory to run as well.
45+
Currently, 80% of the specified memory limit is passed to the JVM.
46+
47+
For memory, only a limit can be specified, which will be set as memory request and limit in the container.
48+
This is to always guarantee a container the full amount memory during Kubernetes scheduling.

0 commit comments

Comments
 (0)