Problem Description

When running tuned-adm profile <any-profile>, TuneD breaks Kubernetes overlay networking (tested with Canal/Calico CNI). The overlay network (pod network) becomes completely unreachable after any profile switch.

Root Cause

The reapply_sysctl=1 setting (default) causes TuneD to re-apply ALL sysctl settings from /run/sysctl.d/, /etc/sysctl.d/, and /etc/sysctl.conf after every profile application. This overwrites runtime sysctl changes made by Kubernetes CNI plugins.

Specifically, CNI plugins set net.ipv4.ip_forward=1 at runtime, but system sysctl.d files typically contain net.ipv4.ip_forward=0, which gets re-applied and breaks routing.

Code location: tuned/plugins/plugin_sysctl.py lines 83-85 and 103-156

Steps to Reproduce

1. Deploy a Kubernetes cluster with overlay networking (e.g., Canal, Calico, Flannel)
2. Verify pod-to-pod networking works
3. Run tuned-adm profile balanced (or any profile)
4. Pod-to-pod networking breaks immediately
5. Check: sysctl net.ipv4.ip_forward shows 0 instead of 1

Expected Behavior

TuneD should provide a way to exclude specific sysctl parameters from reapplication, allowing Kubernetes CNI plugins to manage networking sysctls independently.

Proposed Solution

Add a reapply_sysctl_exclude configuration option to /etc/tuned/tuned-main.conf that accepts a comma-separated list of sysctl patterns (supporting shell-style wildcards via fnmatch).

Example configuration:

reapply_sysctl_exclude = net.ipv4.ip_forward, net.ipv6.conf.*.forwarding, net.bridge.bridge-nf-call-iptables

Workarounds

Current workarounds (all have drawbacks):

1. Set reapply_sysctl=0 - disables ALL sysctl reapplication
2. Modify /etc/sysctl.d/ files - may conflict with security policies
3. Add CNI sysctls to TuneD profile - requires custom profiles

Environment

• TuneD version: 2.26.0
• Kubernetes: Various versions
• CNI: Canal (also affects Calico, Flannel, and others)
• OS: RHEL/CentOS/Rocky Linux