Red Hat OpenShift Developer II: Building and Deploying Cloud-native Applications

OpenShift lets you limit your pod resource consumption and also request the minimum resources that your pod requires.

The following deployment definition shows a pod that has both limits and requests for memory and CPU.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      deployment: example-deployment
  template:
    metadata:
      labels:
        deployment: example-deployment
    spec:
      containers:
      - image: quay.io/example/deployment:1.0
        name: example-deployment
        resources:
          requests:
            cpu: 100m 
            memory: 200Mi 
          limits:
            memory: 200Mi 

The sum of limits in a pod can be higher than the node's resources, when this happens the node is overcommitted.

Limits and request play an important role when a node runs low on resources. Depending on the resource type the behavior differs. When a pod consumes more memory than the node has available or than specified in the resource limits, Kubernetes terminates that pod with an Out of Memory (OOM) error. On the other hand, if a pod requests more CPU than available, then the pod continues working but the CPU throttles. If a node does not have enough memory, then it evicts pods.

In low memory situations, OpenShift decides which pods to evict based on their resource definitions. Kubernetes classifies the following Quality of Service (QoS) categories:

By using the QoS categories, you can design your workloads for stability or for better resource usage. For example, in a production cluster, where you want to have predictable workload allocation, you might want to have the Guaranteed type and some burstable workloads with increased CPU limits to improve CPU use.

In multitenant environments, OpenShift administrators can define resource quotas per project to improve isolation. Administrators can also enforce a range for limits in a project and configure default resources for workloads that do not specify any.

A health check or probe is a periodic check that monitors the health of an application. Probes allow automating workload management. With probes OpenShift can detect the following situations for a pod:

OpenShift uses this information to route traffic or to control deployment strategies.

Also, developers can use probes to monitor their applications. Applications can become unreliable for various reasons, for example:

Developers can configure probes by using either the oc command-line client, a YAML deployment template, or by using the Red Hat OpenShift web console.

There are currently three types of probes in OpenShift:

OpenShift provides the following options to configure these probes:

Startup, readiness and liveness probes can verify that an application is in a healthy state in three ways.

...contents omitted...
readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 15
  timeoutSeconds: 1
...contents omitted...

...contents omitted...
livenessProbe:
  exec:
    command:
    - cat
    - /tmp/health
  initialDelaySeconds: 15
  timeoutSeconds: 1
...contents omitted...

...contents omitted...
livenessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 15
  timeoutSeconds: 1
...contents omitted...

Developers can create probes by using the OpenShift web console. In the Topology view you can click the three dot menu for a deployment, and then click Add Health Checks.

This opens the Add health checks form where you can add the probes for your deployment.

For example, to add a readiness probe, click Add Readiness probe, which opens a form where you can input the settings for the probe. To terminate editing the probe click the checkmark button at the bottom of the readiness probe section.

At this point you can add more probes before clicking Add.

When you click Add OpenShift deploys the changes. You can follow the new deployment by going to the Details tab of the deployment.

You can use the command oc set probe to create probes on existing workloads.

The following examples demonstrate using the oc set probe command with several options:

[user@host ~]$ oc set probe deployment myapp --readiness \
--get-url=http://:8080/readyz --period=20

[user@host ~]$ oc set probe deployment myapp --liveness \
--open-tcp=3306 --period=20 \
--timeout-seconds=1

[user@host ~]$ oc set probe deployment myapp --liveness \
--get-url=http://:8080/livez --initial-delay-seconds=30 \
--success-threshold=1 --failure-threshold=3

Use the oc set probe --help command to view the available options.