Managing the maximum number of pods per node

    Exceeding these values can result in:

    • Increased CPU utilization by OKD.

    • Slow pod scheduling.

    • Potential out-of-memory scenarios, depending on the amount of memory in the node.

    • Exhausting the IP address pool.

    • Resource overcommitting, leading to poor user application performance.

    The parameter limits the number of pods the node can run based on the number of processor cores on the node. For example, if podsPerCore is set to 10 on a node with 4 processor cores, the maximum number of pods allowed on the node is 40.

    Two parameters control the maximum number of pods that can be scheduled to a node: podsPerCore and maxPods. If you use both options, the lower of the two limits the number of pods on a node.

    For example, if podsPerCore is set to 10 on a node with 4 processor cores, the maximum number of pods allowed on the node will be 40.

    Prerequisites

    1. Obtain the label associated with the static MachineConfigPool CRD for the type of node you want to configure by entering the following command:

      For example:

      1. $ oc edit machineconfigpool worker

      Example output

      1. apiVersion: machineconfiguration.openshift.io/v1
      2. kind: MachineConfigPool
      3. metadata:
      4.   generation: 4
      6.     pools.operator.machineconfiguration.openshift.io/worker: "" (1)
      7.   name: worker

    Procedure

    1. Sample configuration for a max-pods CR

      1. apiVersion: machineconfiguration.openshift.io/v1
      2. kind: KubeletConfig
      3. metadata:
      4.   name: set-max-pods (1)
      5. spec:
      6.   machineConfigPoolSelector:
      7.       pools.operator.machineconfiguration.openshift.io/worker: "" (2)
      8.   kubeletConfig:
      9.     podsPerCore: 10 (3)
      10.     maxPods: 250 (4)

      In the above example, the default value for podsPerCore is 10 and the default value for maxPods is 250. This means that unless the node has 25 cores or more, by default, podsPerCore will be the limiting factor.

    2. Run the following command to create the CR:

      1. $ oc create -f <file_name>.yaml

    Verification

    1. List the MachineConfigPool CRDs to see if the change is applied. The UPDATING column reports True if the change is picked up by the Machine Config Controller:

      Example output

      1. NAME     CONFIG                        UPDATED   UPDATING   DEGRADED
      2. master   master-9cc2c72f205e103bb534   False     False      False
      3. worker   worker-8cecd1236b33ee3f8a5e   False     True       False

      Once the change is complete, the UPDATED column reports .

      1. $ oc get machineconfigpools