Tuning Node Kernel Parameters (sysctl)
Some kernel parameters are set per node rather than per workload—for example, the ARP/neighbor table garbage-collection thresholds. These are node-level (non-namespaced) settings, so they cannot be set from a Pod's securityContext.sysctls or a security context constraint; they must be applied on the host.
You can set them by writing a sysctl drop-in file with a MachineConfig object. The setting is written as a separate file under /etc/sysctl.d/, so the node's other kernel settings are left unchanged. Pair the MachineConfig with a node disruption policy so the value is applied without rebooting the node.
When to Use This
A common case is a large cluster whose nodes log a neighbour table overflow error: the ARP/neighbor table is too small for the number of peers, and its garbage-collection thresholds need to be raised. The example below raises those thresholds; the same procedure applies to any node-level sysctl key.
Setting a Kernel Parameter
The following example raises the ARP/neighbor table garbage-collection thresholds on worker nodes.
-
Create the
sysctldrop-in file. Each line is akey = valuepair: -
Base64-encode the contents:
-
Create a
MachineConfigobject that writes the file under/etc/sysctl.d/:The
rolelabel selects which nodes the file is applied to. To target only a subset of nodes, create a customMachineConfigPooland set the label to that pool's role. -
Configure a node disruption policy that re-applies
sysctlsettings when this file changes. Because the default action for file changes isNone, the file would otherwise be written to disk without taking effect. Add the following to theclusterMachineConfigurationobject in thecpaas-systemnamespace, and confirm it is reflected instatus.nodeDisruptionPolicyStatusbefore applying theMachineConfig:
Restarting systemd-sysctl.service re-applies every file under /etc/sysctl.d/. The new values take effect and the node is not rebooted.
Set the node disruption policy for the file path first and wait until it appears in status.nodeDisruptionPolicyStatus. If you apply the MachineConfig before the policy is in effect, the file is written to disk but the value is not applied. For the full list of disruption actions, see Node Disruption Policies.
Verifying the Change
On a target node, read back the parameter:
The output should show the value you set:
Reverting the Change
Delete the MachineConfig object to remove the drop-in file. Values that were already applied remain in effect on the running kernel until the node is next rebooted, after which the node's default values apply.