Analyzing Cluster Capacity

You are viewing documentation for a release that is no longer supported. The latest supported version of version 3 is [3.11]. For the most recent version 4, see [4]

You are viewing documentation for a release that is no longer supported. The latest supported version of version 3 is [3.11]. For the most recent version 4, see [4]

Overview

As a cluster administrator, you can use the cluster capacity tool to view the number of pods that can be scheduled to increase the current resources before they become exhausted, and to ensure any future pods can be scheduled. This capacity comes from an individual node host in a cluster, and includes CPU, memory, disk space, and others.

The cluster capacity tool simulates a sequence of scheduling decisions to determine how many instances of an input pod can be scheduled on the cluster before it is exhausted of resources to provide a more accurate estimation.

The remaining allocatable capacity is a rough estimation, because it does not count all of the resources being distributed among nodes. It analyzes only the remaining resources and estimates the available capacity that is still consumable in terms of a number of instances of a pod with given requirements that can be scheduled in a cluster.

Also, pods might only have scheduling support on particular sets of nodes based on its selection and affinity criteria. As a result, the estimation of which remaining pods a cluster can schedule can be difficult.

You can run the cluster capacity analysis tool as a stand-alone utility from the command line, or as a job in a pod inside an OKD cluster. Running it as job inside of a pod enables you to run it multiple times without intervention.

Running Cluster Capacity Analysis on the Command Line

To run the tool on the command line:

  1. $ cluster-capacity --kubeconfig <path-to-kubeconfig> \
  2.     --podspec <path-to-pod-spec>

The --kubeconfig option indicates your Kubernetes configuration file, and the --podspec option indicates a sample pod specification file, which the tool uses for estimating resource usage. The podspec specifies its resource requirements as limits or requests. The cluster capacity tool takes the pod’s resource requirements into account for its estimation analysis.

An example of the pod specification input is:

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: small-pod
  5.   labels:
  6.     app: guestbook
  7.     tier: frontend
  8. spec:
  9.   containers:
  10.   - name: php-redis
  11.     image: gcr.io/google-samples/gb-frontend:v4
  12.     imagePullPolicy: Always
  13.     resources:
  14.       limits:
  15.         cpu: 150m
  16.         memory: 100Mi
  17.       requests:
  18.         cpu: 150m
  19.         memory: 100Mi

You can also add the --verbose option to output a detailed description of how many pods can be scheduled on each node in the cluster:

  1. $ cluster-capacity --kubeconfig <path-to-kubeconfig> \
  2.     --podspec <path-to-pod-spec> --verbose

The output will look similar to the following:

  1. small-pod pod requirements:
  2.     - CPU: 150m
  3.     - Memory: 100Mi
  5. The cluster can schedule 52 instance(s) of the pod small-pod.
  7. Termination reason: Unschedulable: No nodes are available that match all of the
  8. following predicates:: Insufficient cpu (2).
  10. Pod distribution among nodes:
  11. small-pod
  12.     - 192.168.124.214: 26 instance(s)
  13.     - 192.168.124.120: 26 instance(s)

In the above example, the number of estimated pods that can be scheduled onto the cluster is 52.

Running Cluster Capacity as a Job Inside of a Pod

Running the cluster capacity tool as a job inside of a pod has the advantage of being able to be run multiple times without needing user intervention. Running the cluster capacity tool as a job involves using a ConfigMap.

  1. Create the cluster role:

    1. $ cat << EOF| oc create -f -
    2. kind: ClusterRole
    3. apiVersion: v1
    4. metadata:
    5.   name: cluster-capacity-role
    6. rules:
    7. - apiGroups: [""]
    8.   resources: ["pods", "nodes", "persistentvolumeclaims", "persistentvolumes", "services"]
    9.   verbs: ["get", "watch", "list"]
    10. EOF

  2. Create the service account:

    1. $ oc create sa cluster-capacity-sa

  3. Add the role to the service account:

    1. $ oc adm policy add-cluster-role-to-user cluster-capacity-role \
    2.     system:serviceaccount:default:cluster-capacity-sa

  4. Define and create the pod specification:

    1. apiVersion: v1
    2. kind: Pod
    3. metadata:
    4.   name: small-pod
    5.   labels:
    6.     app: guestbook
    7.     tier: frontend
    8. spec:
    9.   containers:
    10.   - name: php-redis
    11.     image: gcr.io/google-samples/gb-frontend:v4
    12.     imagePullPolicy: Always
    13.     resources:
    14.       limits:
    15.         cpu: 150m
    16.         memory: 100Mi
    17.       requests:
    18.         cpu: 150m
    19.         memory: 100Mi

  5. The cluster capacity analysis is mounted in a volume using a ConfigMap named cluster-capacity-configmap to mount input pod spec file pod.yaml into a volume test-volume at the path /test-pod.

    If you haven’t created a ConfigMap, create one before creating the job:

    1. $ oc create configmap cluster-capacity-configmap \
    2.     --from-file=pod.yaml=pod.yaml

  6. Create the job using the below example of a job specification file:

    1. apiVersion: batch/v1
    2. kind: Job
    3. metadata:
    4.   name: cluster-capacity-job
    5. spec:
    6.   parallelism: 1
    7.   completions: 1
    8.   template:
    9.     metadata:
    10.       name: cluster-capacity-pod
    11.     spec:
    12.         containers:
    13.         - name: cluster-capacity
    14.           image: openshift/origin-cluster-capacity
    15.           imagePullPolicy: "Always"
    16.           volumeMounts:
    17.           - mountPath: /test-pod
    18.             name: test-volume
    19.           env:
    20.           - name: CC_INCLUSTER (1)
    21.             value: "true"
    22.           command:
    23.           - "/bin/sh"
    24.           - "-ec"
    25.           - |
    26.             /bin/cluster-capacity --podspec=/test-pod/pod.yaml --verbose
    27.         restartPolicy: "Never"
    28.         serviceAccountName: cluster-capacity-sa
    29.         volumes:
    30.         - name: test-volume
    31.           configMap:
    32.             name: cluster-capacity-configmap
    1A required environment variable letting the cluster capacity tool know that it is running inside a cluster as a pod.
    The pod.yaml key of the ConfigMap is the same as the pod specification file name, though it is not required. By doing this, the input pod spec file can be accessed inside the pod as /test-pod/pod.yaml.

  7. Run the cluster capacity image as a job in a pod:

    1. $ oc create -f cluster-capacity-job.yaml

  8. Check the job logs to find the number of pods that can be scheduled in the cluster:

    1. $ oc logs jobs/cluster-capacity-job
    2. small-pod pod requirements:
    3.         - CPU: 150m
    4.         - Memory: 100Mi
    6. The cluster can schedule 52 instance(s) of the pod small-pod.
    8. Termination reason: Unschedulable: No nodes are available that match all of the
    9. following predicates:: Insufficient cpu (2).
    11. Pod distribution among nodes:
    12. small-pod
    13.         - 192.168.124.214: 26 instance(s)
    14.         - 192.168.124.120: 26 instance(s)