Concept-Kubernetes runtime type

Functional status : Kubernetes v1.14 beta
This section describes the RuntimeClass resource and runtime selection mechanism.

RuntimeClass is a function for selecting container runtime configuration. The container runtime configures the container used to run the Pod.

motivation
Build
usage
Scheduling
What to do next

motivation

We can set different RuntimeClass between different Pods to achieve a balance between performance and security. For example, if part of our workload deserves a high level of information security, we can choose to schedule these Pods so that they run in a container runtime using hardware virtualization. Then, we will benefit from the additional isolation of the standby runtime, but with some additional overhead.

We can also use RuntimeClass to run different pods in the same container runtime but with different settings

Build

Make sure that the RuntimeClass feature gating is enabled (please look forward to ~~) (yes by default). For instructions on enabling feature gating, see Feature Gating. RuntimeClass feature gating must be enabled on apiserver and kubelet.

Configure CRI implementation on nodes (depending on runtime)
Create the corresponding RuntimeClass resource

1. Configure CRI on the node

The configuration available through RuntimeClass depends on the container runtime interface (CRI) implementation. For information on how to configure, please refer to the response document implemented by CRI ( see below (please look forward to ~~)).

Note : By default, RuntimeClass assumes that the nodes on the entire cluster are evenly configured (this means that all nodes are configured the same in terms of container runtime). To support heterogeneous node configuration, see the scheduling below.

These configurations have a corresponding handlername, referenced by RuntimeClass. The handle must be a valid DNS 1123 label (alphanumeric + -characters).

2. Create the corresponding RuntimeClass resource

Configuration settings in step 1 should each have an associated handlername which identifies the configuration. For each handle, create a corresponding RuntimeClass object.

Currently, the RuntimeClass resource has only two important fields: RuntimeClass name ( metadata.name) and handle ( handler). The object definition is as follows:

apiVersion: node.k8s.io/v1beta1  # RuntimeClass is defined in the node.k8s.io API group
kind: RuntimeClass
metadata:
  name: myclass  # The name the RuntimeClass will be referenced by
  # RuntimeClass is a non-namespaced resource
handler: myconfiguration  # The name of the corresponding CRI configuration

The name of the RuntimeClass object must be a valid DNS subdomain (please look forward to ~~).

Note : It is recommended to limit RuntimeClass write operations (create / update / pudding / delete) to cluster administrators. This is usually the default setting. For more detailed information, please see the authorization overview (please look forward to ~~).

usage

Once RuntimeClasses are configured for the cluster, using them is very simple. Specified in the Pod specification runtimeClassName. E.g:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: myclass
  # ...

This will instruct Kubelet to use the named RuntimeClass to run the pod. If the named RuntimeClass does not exist or can not run CRI corresponding handle, the pod will enter the Failedterminal stage (stay tuned ~ ~). Find the corresponding event of the error message (please look forward to ~~).

If runtimeClassName is not specified, the default RuntimeHandler will be used, which is equivalent to the behavior when the RuntimeClass feature is disabled.

CRI configuration

For more detailed information on setting up the CRI runtime, please refer to CRI Installation (please look forward to ~~).

dockershim

The built-in dockershim CRI of Kubernetes does not support runtime handles.

containerd

By /etc/containerd/config.tomlthe handle when the container is configured in the running configuration. The valid handle configuration is under the runtime section:

[plugins.cri.containerd.runtimes.${HANDLER_NAME}]

For more details, please refer to the container's configuration documentation: https://github.com/containerd/cri/blob/master/docs/config.md

CRI-O

The handle is disposed through the CRI-O runtime /etc/crio/crio.confbe configured. The valid handle is configured under the crio.runtime table :

[crio.runtime.runtimes.${HANDLER_NAME}]
  runtime_path = "${PATH_TO_BINARY}"

For more detailed information, please see the CRI-O configuration documentation .

Scheduling

Characteristics status : Kubernetes v1.16 beta
from Kubernetes v1.16 beginning, RuntimeClass through its schedulingfield include support for heterogeneous cluster. By using these fields, you can ensure that the Pod running with this RuntimeClass is scheduled to the node that supports it. To use plan support, we must enable the RuntimeClass admission controller (please look forward to ~~) (default is 1.16).

To ensure that a particular node supports Pod RuntimeClass falls on, the node cluster should have a common label, then the runtimeclass.scheduling.nodeSelectorselect field of the tag. When allowed, the nodeSelector of RuntimeClass and the nodeSelector of pod are merged to effectively obtain the intersection of the node sets selected by each node. If there is a conflict, the pod will be rejected.

If the supported node is contaminated to prevent other RuntimeClass containers from running on that node, you can add fault tolerance to RuntimeClass. And nodeSelector, as fault-tolerant and fault-tolerant receiving a pod when combined, thereby effectively absorbing the tolerance of each node set of nodes and set.

To learn more about configuring node selectors and fault tolerance, see Assigning Pods to Nodes (Please look forward to ~~).

Feature status : Kubernetes v1.18 beta
We can specify overhead resources related to running Pods . The declaration overhead allows the cluster (including scheduling) to account for Pods and resources when making decisions about them. To use Pod overhead, PodOverhead feature gating must be enabled (please look forward to ~~) (it is enabled by default).

Pod overhead is RuntimeClass by overheadfield definitions. By using these fields, we can use the RuntimeClass to specify the cost of running Pods, and ensure that these costs are considered in Kubernetes.