Getting Started with Kubernetes | Understanding Kubernetes RuntimeClass and Using Multiple Container Runtimes

Source of RuntimeClass Requirements

Evolution of Container Runtimes

The evolution of container runtimes can be divided into three phases:

  • How do I select an appropriate container runtime for a pod?
  • How do I schedule a pod to a node that has a specific container runtime configured?
  • Extra overhead other than the service operation overhead is incurred when container runtimes run containers. How do I measure the extra overhead?

RuntimeClass Workflow

To answer the preceding questions, the community introduced RuntimeClass. RuntimeClass was initially introduced in Kubernetes 1.12 in the form of CustomResourceDefinitions (CRDs). After Kubernetes 1.14, RuntimeClass was introduced again as a built-in cluster resource. Kubernetes 1.16 extends the scheduling capability based on Kubernetes 1.14 and reduces overhead.

  • Three types of nodes are available. Each node has a label to indicate the supported container runtimes. Each node has one or more handlers, each of which corresponds to a container runtime. For example, the second node includes the handlers that support the runc and runv container runtimes, respectively. The third node includes the handler that supports the runhcs container runtime.
  • According to the scheduling.nodeSelector field, the pod is scheduled to the second node, and a pod is created by the runv handler.

Functions of RuntimeClass

Definition of the RuntimeClass Structure

  • The Overhead field was introduced in Kubernetes 1.16 and indicates the extra overhead other than the resources required to run the pod business.
  • The Scheduling field was introduced in Kubernetes 1.16. Its setting is automatically injected into the pod’s nodeSelector.

Example of RuntimeClass Resource Definition

Definition of the Scheduling Structure

The Scheduling field is related to the scheduling of the pod that references the RuntimeClass object.

Why Was the Pod Overhead Field Introduced?

Scenarios and Limits of the Pod Overhead Field

The Pod Overhead field is used in three scenarios:

Example of Running Multiple Container Runtimes

Summary

Let’s summarize what we have learned in this article.

  • You can set the Scheduling field in RuntimeClass to automatically schedule a pod to the node with a specified container runtime. For automatic scheduling, you need to configure labels for this node in advance.
  • You can set the Overhead field in RuntimeClass to calculate the overhead that is incurred beyond the scope of the pod business. This will give you a better understanding of scheduling, resource quotas, and Kubelet pod eviction.

Original Source:

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store