Namespace Resources

There are three main types of namespace resources that have to be monitored: CPU, memory, and storage.

CPU

Each pod has a request and a limit of the amount of CPU (computing power) that the pod needs. The request amount roughly represents the normal amount the pod uses, and the limit is the amount that the pod is able to spike to during high load. These amounts of CPU are measured in m (millicores). If there is no unit shown then it is in cores (1000 millicores). The YAML for DeployConfigs and StatefulSets contains the CPU settings:

...

If you do need to adjust the CPU, note that changing the values in the OCP console will only change the values until the next deployment of CHEFS. It’s a good way to try something out without too much effort. To make the change permanent, though, you will need to update the values in the /openshift files in the repo.

There is not an endless supply of CPU, we need to stay within the bounds of what is allocated to the namespace. This amount can be increased if needed, but we will be asked to justify the increase, and as a good cluster citizen we have to make an effort to conserve resources. The compute-long-running-quota looks something like:

...

Memory

Each pod has a request and a limit of the amount of memory that the pod needs. The request amount roughly represents the normal amount the pod uses, and the limit is the amount that the pod is able to spike to during high load. These amounts of memory are typically measured in Mi (megabytes) or Gi (gigabytes). The YAML for DeployConfigs and StatefulSets contains the memory settings:

...

If you do need to adjust the memory, note that changing the values in the OCP console will only change the values until the next deployment of CHEFS. It’s a good way to try something out without too much effort. To make the change permanent, though, you will need to update the values in the /openshift files in the repo.

There is not an endless supply of memory, we need to stay within the bounds of what is allocated to the namespace. This amount can be increased if needed, but we will be asked to justify the increase, and as a good cluster citizen we have to make an effort to conserve resources. The compute-long-running-quota looks something like:

...

Storage

Most storage in the pods is ephemeral and disappears when the pod is deleted. However, some pods have persistent storage that survives pod restarts, which is needed for things like database data. When storage fills to 100% it makes things much harder to recover, so it is best to expand storage long before it hits capacity.

...

• Expanding a PVC is nearly instantaneous

• Expanding a PVC does not cause a pod restart - there is no effect on the users

• Expanding a PVC is a one way operation - there is no corresponding way to shrink a PVC

• It is very time consuming (take down app, backup PVC, delete, recreate smaller, restore backup, bring up app) so ensure that you truly need to expand

As with CPU and memory, there is a limit to the amount of storage that is available. There is the overall quota in storage-quota that includes all “classes” of storage:

...

Storage is tricky, though in that each different class of storage also has its own quota. That is, the netapp-file-standard storage for general use has a different quota than the netapp-block-standard storage that performs better for databases. For example:

...

If you use up the 128Gi of requests.storage in the top image with netapp-block-standard storage, then you cannot use the storage quota in different classes, even though you're below the quota for that class. It's the overall quota that is at the limit.