Description of problem:
It is extremely difficult to validate all known Kubelet Configuration options. We had this debate when we began the project if we should open up all the KubeletConfiguration options or just a subset. We agreed on opening the entire structure up to allow for any configuration (similar to how we did it in Openshift 3.x).
For these reasons, we cannot add an unlimited amount of validation to the CR object for Kubelet configuration options. There is a risk associated to setting the options.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
There is a little flaw in this fix, for "important" is misspelled to "importent" in 3rd line of DESCRIPTION
$ oc explain kubeletconfig.spec.kubeletConfig --recursive=true
The fields of the kubelet configuration are defined in kubernetes upstream.
Please refer to the types defined in the version/commit used by OpenShift
of the upstream kubernetes. It's importent to note that, since the fields
of the kubelet configuration are directly fetched from upstream the
validation of those values is handled directly by the kubelet. Please refer
to the upstream version of the relavent kubernetes for the valid values of
these fields. Invalid values of the kubelet configuration fields may render
cluster nodes unusable.
$ oc get clusterversion
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.7.0-0.nightly-2021-02-02-223803 True False 124m Cluster version is 4.7.0-0.nightly-2021-02-02-223803
verified on version: 4.7.0-0.nightly-2021-02-06-084550
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (Moderate: OpenShift Container Platform 4.7.0 security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.