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
This functionality is currently only supported on {op-system-first} 8.x worker nodes. On {op-system-base-full} 7.x worker nodes the Tuned `[bootloader]` plug-in is currently not supported.
97
+
This functionality is currently only supported on {op-system-first} 8.x worker nodes. On {op-system-base-full} 7.x worker nodes the TuneD `[bootloader]` plug-in is currently not supported.
Copy file name to clipboardExpand all lines: modules/custom-tuning-specification.adoc
+11-11Lines changed: 11 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,9 +6,9 @@
6
6
[id="custom-tuning-specification_{context}"]
7
7
= Custom tuning specification
8
8
9
-
The custom resource (CR) for the Operator has two major sections. The first section, `profile:`, is a list of Tuned profiles and their names. The second, `recommend:`, defines the profile selection logic.
9
+
The custom resource (CR) for the Operator has two major sections. The first section, `profile:`, is a list of TuneD profiles and their names. The second, `recommend:`, defines the profile selection logic.
10
10
11
-
Multiple custom tuning specifications can co-exist as multiple CRs in the Operator's namespace. The existence of new CRs or the deletion of old CRs is detected by the Operator. All existing custom tuning specifications are merged and appropriate objects for the containerized Tuned daemons are updated.
11
+
Multiple custom tuning specifications can co-exist as multiple CRs in the Operator's namespace. The existence of new CRs or the deletion of old CRs is detected by the Operator. All existing custom tuning specifications are merged and appropriate objects for the containerized TuneD daemons are updated.
12
12
13
13
*Management state*
14
14
@@ -20,26 +20,26 @@ The Operator Management state is set by adjusting the default Tuned CR. By defau
20
20
21
21
*Profile data*
22
22
23
-
The `profile:` section lists Tuned profiles and their names.
23
+
The `profile:` section lists TuneD profiles and their names.
24
24
25
25
[source,yaml]
26
26
----
27
27
profile:
28
28
- name: tuned_profile_1
29
29
data: |
30
-
# Tuned profile specification
30
+
# TuneD profile specification
31
31
[main]
32
32
summary=Description of tuned_profile_1 profile
33
33
34
34
[sysctl]
35
35
net.ipv4.ip_forward=1
36
-
# ... other sysctl's or other Tuned daemon plugins supported by the containerized Tuned
36
+
# ... other sysctl's or other TuneD daemon plugins supported by the containerized TuneD
37
37
38
38
# ...
39
39
40
40
- name: tuned_profile_n
41
41
data: |
42
-
# Tuned profile specification
42
+
# TuneD profile specification
43
43
[main]
44
44
summary=Description of tuned_profile_n profile
45
45
@@ -74,7 +74,7 @@ The individual items of the list:
74
74
<3> If omitted, profile match is assumed unless a profile with a higher priority matches first or `machineConfigLabels` is set.
75
75
<4> An optional list.
76
76
<5> Profile ordering priority. Lower numbers mean higher priority (`0` is the highest priority).
77
-
<6> A Tuned profile to apply on a match. For example `tuned_profile_1`.
77
+
<6> A TuneD profile to apply on a match. For example `tuned_profile_1`.
78
78
79
79
`<match>` is an optional list recursively defined as follows:
80
80
@@ -98,7 +98,7 @@ The list items `match` and `machineConfigLabels` are connected by the logical OR
98
98
99
99
[IMPORTANT]
100
100
====
101
-
When using machine config pool based matching, it is advised to group nodes with the same hardware configuration into the same machine config pool. Not following this practice might result in Tuned operands calculating conflicting kernel parameters for two or more nodes sharing the same machine config pool.
101
+
When using machine config pool based matching, it is advised to group nodes with the same hardware configuration into the same machine config pool. Not following this practice might result in TuneD operands calculating conflicting kernel parameters for two or more nodes sharing the same machine config pool.
102
102
====
103
103
104
104
.Example: node or pod label based matching
@@ -121,10 +121,10 @@ When using machine config pool based matching, it is advised to group nodes with
121
121
profile: openshift-node
122
122
----
123
123
124
-
The CR above is translated for the containerized Tuned daemon into its `recommend.conf` file based on the profile priorities. The profile with the
125
-
highest priority (`10`) is `openshift-control-plane-es` and, therefore, it is considered first. The containerized Tuned daemon running on a given node looks to see if there is a pod running on the same node with the `tuned.openshift.io/elasticsearch` label set. If not, the entire `<match>` section evaluates as `false`. If there is such a pod with the label, in order for the `<match>` section to evaluate to `true`, the node label also needs to be `node-role.kubernetes.io/master` or `node-role.kubernetes.io/infra`.
124
+
The CR above is translated for the containerized TuneD daemon into its `recommend.conf` file based on the profile priorities. The profile with the
125
+
highest priority (`10`) is `openshift-control-plane-es` and, therefore, it is considered first. The containerized TuneD daemon running on a given node looks to see if there is a pod running on the same node with the `tuned.openshift.io/elasticsearch` label set. If not, the entire `<match>` section evaluates as `false`. If there is such a pod with the label, in order for the `<match>` section to evaluate to `true`, the node label also needs to be `node-role.kubernetes.io/master` or `node-role.kubernetes.io/infra`.
126
126
127
-
If the labels for the profile with priority `10` matched, `openshift-control-plane-es` profile is applied and no other profile is considered. If the node/pod label combination did not match, the second highest priority profile (`openshift-control-plane`) is considered. This profile is applied if the containerized Tuned pod runs on a node with labels `node-role.kubernetes.io/master` or `node-role.kubernetes.io/infra`.
127
+
If the labels for the profile with priority `10` matched, `openshift-control-plane-es` profile is applied and no other profile is considered. If the node/pod label combination did not match, the second highest priority profile (`openshift-control-plane`) is considered. This profile is applied if the containerized TuneD pod runs on a node with labels `node-role.kubernetes.io/master` or `node-role.kubernetes.io/infra`.
128
128
129
129
Finally, the profile `openshift-node` has the lowest priority of `30`. It lacks the `<match>` section and, therefore, will always match. It acts as a profile catch-all to set `openshift-node` profile, if no other profile with higher priority matches on a given node.
Copy file name to clipboardExpand all lines: modules/node-tuning-operator.adoc
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,11 +22,11 @@ ifdef::operators[]
22
22
[discrete]
23
23
== Purpose
24
24
endif::operators[]
25
-
The Node Tuning Operator helps you manage node-level tuning by orchestrating the Tuned daemon. The majority of high-performance applications require some level of kernel tuning. The Node Tuning Operator provides a unified management interface to users of node-level sysctls and more flexibility to add custom tuning specified by user needs.
25
+
The Node Tuning Operator helps you manage node-level tuning by orchestrating the TuneD daemon. The majority of high-performance applications require some level of kernel tuning. The Node Tuning Operator provides a unified management interface to users of node-level sysctls and more flexibility to add custom tuning specified by user needs.
26
26
27
-
The Operator manages the containerized Tuned daemon for {product-title} as a Kubernetes daemon set. It ensures the custom tuning specification is passed to all containerized Tuned daemons running in the cluster in the format that the daemons understand. The daemons run on all nodes in the cluster, one per node.
27
+
The Operator manages the containerized TuneD daemon for {product-title} as a Kubernetes daemon set. It ensures the custom tuning specification is passed to all containerized TuneD daemons running in the cluster in the format that the daemons understand. The daemons run on all nodes in the cluster, one per node.
28
28
29
-
Node-level settings applied by the containerized Tuned daemon are rolled back on an event that triggers a profile change or when the containerized Tuned daemon is terminated gracefully by receiving and handling a termination signal.
29
+
Node-level settings applied by the containerized TuneD daemon are rolled back on an event that triggers a profile change or when the containerized TuneD daemon is terminated gracefully by receiving and handling a termination signal.
30
30
31
31
The Node Tuning Operator is part of a standard {product-title} installation in version 4.1 and later.
0 commit comments