OpenShift Container Probes: Difference between revisions
| Line 112: | Line 112: | ||
startedAt: 2018-02-28T20:03:07Z | startedAt: 2018-02-28T20:03:07Z | ||
hostIP: 192.168.122.26 | hostIP: 192.168.122.26 | ||
'''phase''': Running | '''phase''': <font color=teal>Running</font> | ||
podIP: 10.130.1.26 | podIP: 10.130.1.26 | ||
qosClass: BestEffort | qosClass: BestEffort | ||
Revision as of 20:20, 28 February 2018
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 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. Its phase is reflected by the value of the status.phase field of the state maintained by Kubernetes for the pod.
- 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 Status
The pod's status is reflected in the status field of the oc get command result:
status:
conditions:
- lastProbeTime: null
lastTransitionTime: 2018-02-28T20:03:00Z
status: "True"
type: Initialized
- lastProbeTime: null
lastTransitionTime: 2018-02-28T20:03:20Z
status: "True"
type: Ready
- lastProbeTime: null
lastTransitionTime: 2018-02-28T20:03:00Z
status: "True"
type: PodScheduled
containerStatuses:
- containerID: docker://b25[...]
image: docker.io/novaordis/rest-service@sha256:81e[...]
imageID: docker-pullable://docker.io/novaordis/rest-service@sha256:81e1[...]
lastState: {}
name: rest-service
ready: true
restartCount: 0
state:
running:
startedAt: 2018-02-28T20:03:07Z
hostIP: 192.168.122.26
phase: Running
podIP: 10.130.1.26
qosClass: BestEffort
startTime: 2018-02-28T20:03:00Z
phase
The phase is a simple, high-level summary of where the pod is in its lifecycle.
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" ...
TODO 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. If a container does not provide a readiness probe, the readiness state after creation is by default "Success".
Readines probes: httpGet.
The following sequence should go in the container declaration, at the same level as "name":
readinessProbe: initialDelaySeconds: 5 timeoutSeconds: 1 successThreshold: 1 failureThreshold: 3 periodSeconds: 10 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, Kubernetes waits for initialDelaySeconds, specified in seconds, then it triggers the execution of the probe specified by "exec", "httpGet", "tcpSocket", etc. Once the probe execution is started, Kubernetes waits for timeoutSeconds (default 1 second) for the probe execution to complete.
If the probe execution is successful, the success counts towards the successThreshold_initialDelaySeconds. A total number of successful execution specified in successThreshold must be counted before the container to be considered "ready". However, by default, the successThreshold value is 1, so the container is considered ready after the first successful execution.
If the probe does not complete within "timeoutSeconds" seconds or it explicitly fails, the failure counts towards the failureThreshold. A total number of failed execution specified in failureThreshold must be counted before the container to be considered "not ready". Its readiness state becomes "Failure", though the container may still show up as "Running".
NAME READY STATUS RESTARTS AGE po/rest-service-3-bm1t9 0/1 Running 0 2m
The EndpointsController removes the Pod’s IP address from the endpoints of all Services that match the Pod.
The probe is executed periodically with a periodicity of periodSeconds.
Available probes:
Container Execution Checks
Kubernetes executes the command specified by "exec". If the command exists with 0, the probe execution is considered a success, anything else is a failure.
HTTP Checks
TCP Socket Checks
Operations:
Local Manifest Pod
Bare Pod
A pod that is not backed by a replication controller. Bare pods cannot be evacuated from nodes.