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
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
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
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:
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 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 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:
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" ...
Consolidate with OpenShift_Concepts#Node_Selector
Pod Probe
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
},
}
Readiness Probe
A readiness probe is deployed in a container to expose whether the container is ready to service requests.
Readines probes: httpGet.
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'
Local Manifest Pod
Bare Pod
A pod that is not backed by a replication controller. Bare pods cannot be evacuated from nodes.
Static Pod
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 Presets
TO DISTRIBUTE
A pod executing a container based on a simple image, suited for experimentation, can be created as described here: "Simple Pod Running inside an OpenShift Project".