2.2. Creating a KubeletConfig CRD to edit kubelet parameters
The kubelet configuration is currently serialized as an Ignition configuration, so it can be directly edited. However, there is also a new kubelet-config-controller added to the Machine Config Controller (MCC). This allows you to create a KubeletConfig custom resource (CR) to edit the kubelet parameters.
Procedure
Run:
$ oc get machineconfigThis provides a list of the available machine configuration objects you can select. By default, the two kubelet-related configs are
01-master-kubeletand01-worker-kubelet.To check the current value of max pods per node, run:
# oc describe node <node-ip> | grep Allocatable -A6Look for
value: pods: <value>.For example:
# oc describe node ip-172-31-128-158.us-east-2.compute.internal | grep Allocatable -A6Example output
Allocatable: attachable-volumes-aws-ebs: 25 cpu: 3500m hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 15341844Ki pods: 250To set the max pods per node on the worker nodes, create a custom resource file that contains the kubelet configuration. For example,
change-maxPods-cr.yaml:apiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig metadata: name: set-max-pods spec: machineConfigPoolSelector: matchLabels: custom-kubelet: large-pods kubeletConfig: maxPods: 500The rate at which the kubelet talks to the API server depends on queries per second (QPS) and burst values. The default values,
50forkubeAPIQPSand100forkubeAPIBurst, are good enough if there are limited pods running on each node. Updating the kubelet QPS and burst rates is recommended if there are enough CPU and memory resources on the node:apiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig metadata: name: set-max-pods spec: machineConfigPoolSelector: matchLabels: custom-kubelet: large-pods kubeletConfig: maxPods: <pod_count> kubeAPIBurst: <burst_rate> kubeAPIQPS: <QPS>Run:
$ oc label machineconfigpool worker custom-kubelet=large-podsRun:
$ oc create -f change-maxPods-cr.yamlRun:
$ oc get kubeletconfigThis should return
set-max-pods.Depending on the number of worker nodes in the cluster, wait for the worker nodes to be rebooted one by one. For a cluster with 3 worker nodes, this could take about 10 to 15 minutes.
Check for
maxPodschanging for the worker nodes:$ oc describe nodeVerify the change by running:
$ oc get kubeletconfigs set-max-pods -o yamlThis should show a status of
Trueandtype:Success
Procedure
By default, only one machine is allowed to be unavailable when applying the kubelet-related configuration to the available worker nodes. For a large cluster, it can take a long time for the configuration change to be reflected. At any time, you can adjust the number of machines that are updating to speed up the process.
Run:
$ oc edit machineconfigpool workerSet
maxUnavailableto the desired value.spec: maxUnavailable: <node_count>重要When setting the value, consider the number of worker nodes that can be unavailable without affecting the applications running on the cluster.