Public-health cluster nodes need bridged IPv4 traffic sysctl settings before CNI networking works reliably. Which preparation is appropriate?
Select an answer to reveal the explanation.
Short Explanation
Pod networking needs the node’s bridge and forward knobs switched on—like opening the water main before the sprinkler heads work. Load the usual modules and sysctls so CNI packets get iptables treatment. Turning forwarding off fights the CNI.
Full Explanation
Public-health cluster nodes need bridged IPv4 traffic handling before CNI networking works reliably—the civic analogue of opening the water main before sprinkler heads can flow. Enable the required kernel modules and sysctls such as bridged traffic iptables handling (br_netfilter related settings) and IP forwarding per Kubernetes networking prerequisites so Pod packets traversing bridges receive correct iptables treatment. Disabling IP forwarding so Pods cannot leave the node actively fights CNI egress and inter-node routing expectations. Unloading br_netfilter permanently to “simplify iptables” removes the bridge netfilter hooks many CNIs rely on. Replacing CNI with hostNetwork on every control-plane static Pod only does not prepare worker networking for general workloads and is not a substitute for node sysctl readiness. Exam caveat: kubeadm networking prerequisites are host-level—modules and sysctls—distinct from merely applying a CNI YAML later. Operational check: load br_netfilter if needed, set net.bridge.bridge-nf-call-iptables and net.ipv4.ip_forward persistently via sysctl.d, reboot or apply, confirm with sysctl, then install the CNI and verify Pods receive IPs on public-health namespaces.