Description of problem:
streamingConnectionIdleTimeout kubelet parameter is set to 0 while creating a KubeletConfig object for allocating resources for nodes


Version-Release number of selected component (if applicable):
4.10

How reproducible:
100%

Steps to Reproduce:

1. Create an OCP cluster on any platform once ready debug the node and check if the streamingConnectionIdleTimeout is set.

# oc debug node/node1.example.com
Starting pod/node1-examplecom-debug...
To use host binaries, run `chroot /host`
Pod IP: 10.189.112.5
If you don't see a command prompt, try pressing enter.
sh-4.4# chroot /host
sh-4.4# grep streamingConnectionIdleTimeout /etc/kubernetes/kubelet.conf

2. Create a kubeletconfig object for node system-reservation.

# cat kubeletconfig.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-allocatable 
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: small-pods 
  kubeletConfig:
    systemReserved: 
      cpu: 1000m
      memory: 1Gi

# oc label mcp worker "custom-kubelet=small-pods"
# oc create -f kubeletconfig.yaml

3. Once MCP reboots all the worker nodes sequentially, check the streamingConnectionIdleTimeout kubelet parameter again.

# oc debug node/node1.example.com
Starting pod/node1-examplecom-debug...
To use host binaries, run `chroot /host`
Pod IP: 10.189.112.5
If you don't see a command prompt, try pressing enter.
sh-4.4# chroot /host
sh-4.4# grep streamingConnectionIdleTimeout /etc/kubernetes/kubelet.conf
 "streamingConnectionIdleTimeout": "0s",


Actual results:

After creating a kubeletconfig object for manual system-reservation the streamingConnectionIdleTimeout is set to 0. 

Expected results:

The streamingConnectionIdleTimeout kubelet parameter default value should not be modified without manual intervention, ideally, it should not be set and should have the default value of 4h.

Additional info:

Setting up the value of streamingConnectionIdleTimeout parameter to 0s would let the idle connections be present without any time limit, leaving the cluster vulnerable to a DoS attack.

That's why it is not advisable to set it to 0.