OpenShift Container Probes

External

• https://kubernetes.io/docs/concepts/workloads/pods/pod/
• https://blog.openshift.com/kubernetes-pods-life/
• https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

Internal

• OpenShift Concepts
• Pod Operations

Overview

A pod is a Kubernetes primitive that logically encapsulates one or more Docker containers, deployed together onto a node, as a single unit.

The containers of a pod are managed individually by the Docker server, they do not exist inside any physical super-structure. However, they are handled as a unit by Kubernetes. The defining characteristic of a pod is that all its containers share a virtual network device - an unique IP - and a set of volumes. Pods also define the security and runtime policy for each container. The pod IP address is routable by default from any other pod in the project. Depending on the network plugin configured for a specific cluster, pods may also be reachable across the entire cluster. The default addresses are part of the 10.x.x.x set. The containers on a pod share the IP address and TCP ports, because they share the pod's virtual network device.

The pod is intended to contains collocated applications that are relatively tightly coupled and run with a shared context. Within that context, an application may have individual cgroups isolation applied. A pod models an application-specific logical host, containing applications that in a pre-container world would have run on the same physical or virtual host, and in consequence, the pod cannot span hosts. The pod is the smallest unit that can be defined, deployed and managed by OpenShift. Complex applications can be made of any number of pods, and OpenShift helps with pod orchestration.

Pods do not maintain state, they are expendable. OpenShift treats pods as static, largely immutable - changes cannot be made to a pod definition while the pod is running - and expendable, they do not maintain state when they are destroyed and recreated. Therefore, they are managed by controllers, which are specified in the pod description, not directly by users. To change a pod, the current pod must be terminated, and a new one with a modified base image and/or configuration must be created.

A pod may contain one or more application containers, one or more init containers.

The pods for a project are displayed by the following commands, and also be viewed in the web console to the project -> Applications -> Pods:

oc get all
oc get pods

Pod Definition

Pod Definition

The definition of an existing pod can be obtained with

oc get -o yaml pod <pod-name>
oc describe pod

Container Types

Application Container

If a pod declares init containers, the application containers are only run after all init container complete successfully.

Init Container

Init Container

Controller

A controller is the OpenShift component that creates and manages pods. The controller of a pod is reported by oc describe pod command, under the "Controllers" section:

...
Controllers:		ReplicationController/logging-kibana-1
...

The most common controllers are:

• Replication Controllers
• DaemonSets

Pod Name

Pod must have an unique name in their namespace (project). The pod definition can specify a base name and use "generateName" attribute to append random characters at the end of the base name, thus generating an unique name.

Pod Type

Terminating

A terminating pod has non-zero positive integer as value of "spec.activeDeadlineSeconds". Builder or deployer pods are terminating pods. The pod type can be specified as scope for resource quotas.

NonTerminating

A non-terminating pod has no "spec.activeDeadlineSeconds" specification (nil). Long running pods as a web server or a database are non-terminating pods. The pod type can be specified as scope for resource quotas.

Pod Lifecycle

• A pod is defined in a pod definition.
• A pod is instantiated and assigned to run on a node as a result of the scheduling process.
• The pod runs until its containers exit or the pod is removed.
• Depending on policy and exit code, may be removed or retained to enable access to their container's logs.

Terminal State

A pod is in a terminal state if "status.phase" is either "Failed" or "Succeeded".

Pod Placement

https://docs.openshift.com/container-platform/3.5/admin_guide/scheduler.html#controlling-pod-placement

Pods can be configured to execute on a specific node, defined by the node name, or on nodes that match a specific node selector.

To assign a pod to a specific node, TODO https://docs.openshift.com/container-platform/3.5/admin_guide/scheduler.html#constraining-pod-placement-labels

To assign a pod to nodes that match a node selector, add the "nodeSelector" element in the pod configuration, with a value consisting in key/value pairs, as described here:

Assigning a Pod to Nodes that Match a Node Selector

After a successful placement, either by a replication controller or by a DaemonSet, the pod records the successful node selector expression as part of its definition, which can be rendered with oc get pod -o yaml:

spec:
  ...
  nodeSelector:
   logging: "true"
  ...

TODO Consolidate with OpenShift_Concepts#Node_Selector

Pod Probe

https://docs.openshift.com/container-platform/latest/dev_guide/application_health.html

Users can configure pod probes for liveness or readiness. Can be configured with:

• initialDelaySeconds
• timeoutSeconds (default 1)

Liveness Probe

A liveness probe is deployed in a container to expose whether the container is running. Examples of liveness probes: commands executed inside the container, tcpSocket.

livenessProbe: {
    initialDelaySeconds: 30,
    timeoutSeconds: 1
    periodSeconds: 10,
    failureThreshold: 3,
    successThreshold: 1,
    tcpSocket: {
        port: 5432
    },
 }

Application Health Operations

Readiness Probe

A readiness probe is deployed in a container to expose whether the container is ready to service requests.

Readines probes: httpGet.

The following sequence should go in the container declaration, at the same level as "name":

readinessProbe:
  initialDelaySeconds: 5
  timeoutSeconds: 1
  periodSeconds: 10
  failureThreshold: 3
  successThreshold: 1
  exec:
   command:
    - /bin/sh
    - -i
    - -c
    - psql -h 127.0.0.1 -U $POSTGRESQL_USER -q -d $POSTGRESQL_DATABASE -c 'SELECT 1'

After the container is started, and Kubernetes waits for initialDelaySeconds, specified in seconds, then it executes the probe.

Operations:

Application Health Operations

Local Manifest Pod

https://docs.openshift.com/container-platform/latest/install_config/master_node_configuration.html#node-configuration-files

Bare Pod

https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#bare-pods

A pod that is not backed by a replication controller. Bare pods cannot be evacuated from nodes.

Static Pod

https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#static-pods

Pod Presets

https://docs.openshift.com/container-platform/latest/dev_guide/pod_preset.html