Advanced Pod Configuration [page]deterministic

concepts

This page covers advanced Pod configuration topics including [PriorityClasses](#priorityclasses), [RuntimeClasses](#runtimeclasses), [security context](#security-context) within Pods, and introduces aspects of [scheduling](/docs/concepts/scheduling-eviction/#scheduling).

## PriorityClasses

_PriorityClasses_ allow you to set the importance of Pods relative to other Pods. If you assign a priority class to a Pod, Kubernetes sets the `.spec.priority` field for that Pod based on the PriorityClass you specified (you cannot set `.spec.priority` directly). If or when a Pod cannot be scheduled, and the problem is due to a lack of resources, the [kube-scheduler](#gloss:kube-scheduler) tries to [preempt](#gloss:preemption) lower priority Pods, in order to make scheduling of the higher priority Pod possible.

A PriorityClass is a cluster-scoped API object that maps a priority class name to an integer priority value. Higher numbers indicate higher priority.

### Defining a PriorityClass

```yaml apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority value: 10000 globalDefault: false description: "Priority class for high-priority workloads" ```

### Specify pod priority using a PriorityClass

apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx priorityClassName: high-priority

### Built-in PriorityClasses

Kubernetes provides two built-in PriorityClasses: - `system-cluster-critical`: For system components that are critical to the cluster - `system-node-critical`: For system components that are critical to individual nodes. This is the highest priority that Pods can have in Kubernetes.

For more information, see [Pod Priority and Preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/).

## RuntimeClasses

A _RuntimeClass_ allows you to specify the low-level container runtime for a Pod. It is useful when you want to specify different container runtimes for different kinds of Pod, such as when you need different isolation levels or runtime features.

### Example Pod {#runtimeclass-pod-example}

apiVersion: v1 kind: Pod metadata: name: mypod spec: runtimeClassName: myclass containers: - name: mycontainer image: nginx

A [RuntimeClass](/docs/concepts/containers/runtime-class/) is a cluster-scoped object that represents a container runtime that is available on some or all of your node.

The cluster administrator installs and configures the concrete runtimes backing the RuntimeClass.

They might set up that special container runtime configuration on all nodes, or perhaps just on some of them.

For more information, see the [RuntimeClass](/docs/concepts/containers/runtime-class/) documentation.

## Pod and container level security context configuration {#security-context}

The `Security context` field in the Pod specification provides granular control over security settings for Pods and containers.

### Pod-wide `securityContext` {#pod-level-security-context}

Some aspects of security apply to the whole Pod; for other aspects, you might want to set a default, without any container-level overrides.

Here's an example of using `securityContext` at the Pod level:

#### Example Pod {#pod-level-security-context-example}

apiVersion: v1 kind: Pod metadata: name: security-context-demo spec: securityContext: # This applies to the entire Pod runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 containers: - name: sec-ctx-demo image: registry.k8s.io/e2e-test-images/agnhost:2.45 command: ["sh", "-c", "sleep 1h"]

### Container-level security context {#container-level-security-context}

You can specify the security context just for a specific container. Here's an example:

#### Example Pod {#container-level-security-context-example}

apiVersion: v1 kind: Pod metadata: name: security-context-demo-2 spec: containers: - name: sec-ctx-demo-2 image: gcr.io/google-samples/node-hello:1.0 securityContext: …(trimmed)