In the below mentioned yaml 
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: worker-kubeconfig 
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: "" 
  kubeletConfig:
    evictionSoft: 
      memory.available: "500Mi" 
      nodefs.available: "10%"
      nodefs.inodesFree: "5%"
      imagefs.available: "15%"
      imagefs.inodesFree: "10%"
    evictionSoftGracePeriod:  
      memory.available: "1m30s"
      nodefs.available: "1m30s"
      nodefs.inodesFree: "1m30s"
      imagefs.available: "1m30s"
      imagefs.inodesFree: "1m30s"
    evictionHard: 
      memory.available: "200Mi"
      nodefs.available: "5%"
      nodefs.inodesFree: "4%"
      imagefs.available: "10%"
      imagefs.inodesFree: "5%"
    evictionPressureTransitionPeriod: 0s 
    imageMinimumGCAge: 5m 
    imageGCHighThresholdPercent: 80 
    imageGCLowThresholdPercent: 75 
#...
Note:
Regarding the evictionPressureTransitionPeriod configuration being set to 0s and instead defaulting to 5m0s is likely related to a few internal Kubernetes settings and constraints.
In Kubernetes, the evictionPressureTransitionPeriod setting specifies how long the kubelet should wait before initiating eviction pressure after a condition like memory or disk pressure is triggered. It is expected to have a meaningful value to allow the kubelet to stabilize resources before starting eviction.
When you set evictionPressureTransitionPeriod to 0s, Kubernetes might interpret this as an invalid configuration since 0s could potentially imply "no waiting time," which doesn't align with how eviction processes are supposed to work. Kubernetes, instead, likely reverts to the default value (5m0s) to maintain a stable operational behavior.


Please refer the link:[https://docs.openshift.com/container-platform/4.14/nodes/nodes/nodes-nodes-garbage-collection.html] 

    1.
    2.
    3.