This topic describes the management of pods, including limiting their run-once duration, and how much bandwidth they can use.
OpenShift Origin relies on run-once pods to perform tasks such as deploying a pod
or performing a build. Run-once pods are pods that have a RestartPolicy of
Never or OnFailure.
The cluster administrator can use the RunOnceDuration admission control plug-in to force a limit on the time that those run-once pods can be active. Once the time limit expires, the cluster will try to actively terminate those pods. The main reason to have such a limit is to prevent tasks such as builds to run for an excessive amount of time.
The plug-in configuration should include the default active deadline for run-once pods. This deadline is enforced globally, but can be superseded on a per-project basis.
kubernetesMasterConfig:
admissionConfig:
pluginConfig:
RunOnceDuration:
configuration:
apiVersion: v1
kind: RunOnceDurationConfig
activeDeadlineSecondsOverride: 3600 (1)| 1 | Specify the global default for run-once pods in seconds. |
In addition to specifying a global maximum duration for run-once pods, an
administrator can add an annotation
(openshift.io/active-deadline-seconds-override) to a specific project to
override the global default.
apiVersion: v1
kind: Project
metadata:
annotations:
openshift.io/active-deadline-seconds-override: "1000" (1)| 1 | Overrides the default active deadline seconds for run-once pods to 1000 seconds. Note that the value of the override must be specified in string form. |
You can apply quality-of-service traffic shaping to a pod and effectively limit its available bandwidth. Egress traffic (from the pod) is handled by policing, which simply drops packets in excess of the configured rate. Ingress traffic (to the pod) is handled by shaping queued packets to effectively handle data. The limits you place on a pod do not affect the bandwidth of other pods.
To limit the bandwidth on a pod:
Write an object definition JSON file, and specify the data traffic speed using
kubernetes.io/ingress-bandwidth and kubernetes.io/egress-bandwidth
annotations. For example, to limit both pod egress and ingress bandwidth to 10M/s:
{
"kind": "Pod",
"spec": {
"containers": [
{
"image": "nginx",
"name": "nginx"
}
]
},
"apiVersion": "v1",
"metadata": {
"name": "iperf-slow",
"annotations": {
"kubernetes.io/ingress-bandwidth": "10M",
"kubernetes.io/egress-bandwidth": "10M"
}
}
}
Create the pod using the object definition:
oc create -f <file_or_dir_path>
A pod disruption budget is part of the
Kubernetes API, which can be
managed with oc commands like other
object types. They
allow the specification of safety constraints on pods during operations, such as
draining a node for maintenance.
PodDisruptionBudget is an API object that specifies the minimum number or
percentage of replicas that must be up at a time. Setting these in projects can
be helpful during node maintenance (such as scaling a cluster down or a cluster
upgrade) and is only honored on voluntary evictions (not on node failures).
A PodDisruptionBudget object’s configuration consists of the following key
parts:
A label selector, which is a label query over a set of pods.
An availability level, which specifies the minimum number of pods that must be available simultaneously.
The following is an example of a PodDisruptionBudget resource:
apiVersion: policy/v1beta1 (1)
kind: PodDisruptionBudget
metadata:
name: my-pdb
spec:
selector: (2)
matchLabels:
foo: bar
minAvailable: 2 (3)| 1 | PodDisruptionBudget is part of the policy/v1beta1 API group. |
| 2 | A label query over a set of resources. The result of matchLabels and
matchExpressions are logically conjoined. |
| 3 | The minimum number of pods that must be available simultaneously. This can
be either an integer or a string specifying a percentage (for example, 20%). |
If you created a YAML file with the above object definition, you could add it to project with the following:
$ oc create -f </path/to/file> -n <project_name>
You can check for pod disruption budgets across all projects with the following:
$ oc get poddisruptionbudget --all-namespaces NAMESPACE NAME MIN-AVAILABLE SELECTOR another-project another-pdb 4 bar=foo test-project my-pdb 2 foo=bar
The PodDisruptionBudget is considered healthy when there are at least
minAvailable pods running in the system. Every pod above that limit can be
evicted.
A pod preset is an object that injects user-specified information into pods as they are created.
|
Pod presets is a Technology Preview feature only. |
Using pod preset objects you can inject:
container volume mounts
environment variables
Developers only need make sure the pod labels match the label selector on the PodPreset in order to add all that information to the pod. The label on a pod associates the pod with one or more pod preset objects that have a matching label selectors.
Using pod presets, a developer can provision pods without needing to know the details about the services the pod will consume. An administrator can keep configuration items of a service invisible from a developer without preventing the developer from deploying pods. For example, an administrator can create a pod preset that provides the name, user name, and password for a database through a secret and the database port through environment variables. The pod developer only needs to know the label to use to include all the information in pods. A developer can also create pod presets and perform all the same tasks. For example, the developer can create a preset that injects environment variable automatically into multiple pods.
|
The Pod Preset feature is available only if the Service Catalog has been installed. |
You can exclude specific pods from being injected using the podpreset.admission.kubernetes.io/exclude: "true" parameter in the pod specification. See the example pod specification.
For more information, see Injecting Information into Pods Using Pod Presets.
There are a number of core components, such as Heapster and DNS, that are critical to a fully functional cluster,
but, run on a regular cluster node rather than the master. A cluster may stop working properly if a critical add-on is evicted.
You can make a pod critical by adding the the scheduler.alpha.kubernetes.io/critical-pod annotation to the pod specification so that
the descheduler will not remove these pods.
spec:
template:
metadata:
name: critical-pod
annotations:
scheduler.alpha.kubernetes.io/critical-pod: "true"