OpenShift Container Probes
External
- 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 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.
A pod may contain one or more application containers, one or more init containers.
Pod Definition
The definition of an already existing pod can be obtained with 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
The defining characteristic of a pod is that all its containers share a virtual network device - an unique IP -, and a set of persistent volumes. Pods also define the security and runtime policy for each container.
The "pod" is a Kubernetes concept, for more details, see Kubernetes Pods. Each pod gets a pod IP address that is routable by default from any other pod in the environment. 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. They also share persistent storage volumes, and other resources allocated to the pod. The pod 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.
Pods must not created or managed directly, but by their controllers, which are specified in the pod description.
OpenShift treats pods as 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, not directly by users.
The pods for a project are displayed by the following commands:
oc get all oc get pods
Pods for a project can also be viewed in the web console to the project -> Applications -> Pods.
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".
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 Configuration
Pods are treated as static, and cannot be changed while they are running. 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.
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.