openshift-docs/modules/advanced-node-tuning-hosted-cluster.adoc

// Module included in the following assemblies:
//
// * scalability_and_performance/using-node-tuning-operator.adoc
// * hosted_control_planes/hcp-managing.adoc

:_mod-docs-content-type: PROCEDURE
[id="advanced-node-tuning-hosted-cluster_{context}"]
= Advanced node tuning for hosted clusters by setting kernel boot parameters

For more advanced tuning in {hcp}, which requires setting kernel boot parameters, you can also use the Node Tuning Operator. The following example shows how you can create a node pool with huge pages reserved.

.Procedure

. Create a `ConfigMap` object that contains a `Tuned` object manifest for creating 10 huge pages that are 2 MB in size. Save this `ConfigMap` manifest in a file named `tuned-hugepages.yaml`:
+
[source,yaml]
----
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: tuned-hugepages
      namespace: clusters
    data:
      tuning: |
        apiVersion: tuned.openshift.io/v1
        kind: Tuned
        metadata:
          name: hugepages
          namespace: openshift-cluster-node-tuning-operator
        spec:
          profile:
          - data: |
              [main]
              summary=Boot time configuration for hugepages
              include=openshift-node
              [bootloader]
              cmdline_openshift_node_hugepages=hugepagesz=2M hugepages=50
            name: openshift-node-hugepages
          recommend:
          - priority: 20
            profile: openshift-node-hugepages
----
+
[NOTE]
====
The `.spec.recommend.match` field is intentionally left blank. In this case, this `Tuned` object is applied to all nodes in the node pool where this `ConfigMap` object is referenced. Group nodes with the same hardware configuration into the same node pool. Otherwise, TuneD operands can calculate conflicting kernel parameters for two or more nodes that share the same node pool.
====

. Create the `ConfigMap` object in the management cluster:
+
[source,terminal]
----
$ oc --kubeconfig="<management_cluster_kubeconfig>" create -f tuned-hugepages.yaml <1>
----
<1> Replace `<management_cluster_kubeconfig>` with the name of your management cluster `kubeconfig` file.

. Create a `NodePool` manifest YAML file, customize the upgrade type of the `NodePool`, and reference the `ConfigMap` object that you created in the `spec.tuningConfig` section. Create the `NodePool` manifest and save it in a file named `hugepages-nodepool.yaml` by using the `hcp` CLI:
+
[source,terminal]
----
$ hcp create nodepool aws \
  --cluster-name <hosted_cluster_name> \// <1>
  --name <nodepool_name> \// <2>
  --node-count <nodepool_replicas> \// <3>
  --instance-type <instance_type> \// <4>
  --render > hugepages-nodepool.yaml
----
<1> Replace `<hosted_cluster_name>` with the name of your hosted cluster.
<2> Replace `<nodepool_name>` with the name of your node pool.
<3> Replace `<nodepool_replicas>` with the number of your node pool replicas, for example, `2`.
<4> Replace `<instance_type>` with the instance type, for example, `m5.2xlarge`.
+
[NOTE]
====
The `--render` flag in the `hcp create` command does not render the secrets. To render the secrets, you must use both the `--render` and the `--render-sensitive` flags in the `hcp create` command.
====

. In the `hugepages-nodepool.yaml` file, set `.spec.management.upgradeType` to `InPlace`, and set `.spec.tuningConfig` to reference the `tuned-hugepages` `ConfigMap` object that you created.
+
[source,yaml]
----
    apiVersion: hypershift.openshift.io/v1alpha1
    kind: NodePool
    metadata:
      name: hugepages-nodepool
      namespace: clusters
      ...
    spec:
      management:
        ...
        upgradeType: InPlace
      ...
      tuningConfig:
      - name: tuned-hugepages
----
+
[NOTE]
====
To avoid the unnecessary re-creation of nodes when you apply the new `MachineConfig` objects, set `.spec.management.upgradeType` to `InPlace`. If you use the `Replace` upgrade type, nodes are fully deleted and new nodes can replace them when you apply the new kernel boot parameters that the TuneD operand calculated.
====

. Create the `NodePool` in the management cluster:
+
[source,terminal]
----
$ oc --kubeconfig="<management_cluster_kubeconfig>" create -f hugepages-nodepool.yaml
----

.Verification

After the nodes are available, the containerized TuneD daemon calculates the required kernel boot parameters based on the applied TuneD profile. After the nodes are ready and reboot once to apply the generated `MachineConfig` object, you can verify that the TuneD profile is applied and that the kernel boot parameters are set.

. List the `Tuned` objects in the hosted cluster:
+
[source,terminal]
----
$ oc --kubeconfig="<hosted_cluster_kubeconfig>" get tuned.tuned.openshift.io \
  -n openshift-cluster-node-tuning-operator
----
+
.Example output
[source,terminal]
----
NAME                 AGE
default              123m
hugepages-8dfb1fed   1m23s
rendered             123m
----

. List the `Profile` objects in the hosted cluster:
+
[source,terminal]
----
$ oc --kubeconfig="<hosted_cluster_kubeconfig>" get profile.tuned.openshift.io \
  -n openshift-cluster-node-tuning-operator
----
+
.Example output
[source,terminal]
----
NAME                           TUNED                      APPLIED   DEGRADED   AGE
nodepool-1-worker-1            openshift-node             True      False      132m
nodepool-1-worker-2            openshift-node             True      False      131m
hugepages-nodepool-worker-1    openshift-node-hugepages   True      False      4m8s
hugepages-nodepool-worker-2    openshift-node-hugepages   True      False      3m57s
----
+
Both of the worker nodes in the new `NodePool` have the `openshift-node-hugepages` profile applied.

. To confirm that the tuning was applied correctly, start a debug shell on a node and check `/proc/cmdline`.
+
[source,terminal]
----
$ oc --kubeconfig="<hosted_cluster_kubeconfig>" \
  debug node/nodepool-1-worker-1 -- chroot /host cat /proc/cmdline
----
+
.Example output
[source,terminal]
----
BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-... hugepagesz=2M hugepages=50
----