You are viewing documentation for Kubernetes version: v1.18

Kubernetes v1.18 のドキュメントは積極的にメンテナンスされていません。現在表示されているバージョンはスナップショットです。最新のドキュメントはこちらです: 最新バージョン

Edit This Page

ランタイムクラス(Runtime Class)

FEATURE STATE: Kubernetes v1.14 [beta]

このページではRuntimeClassリソースと、runtimeセクションのメカニズムについて説明します。

警告: RuntimeClassはKubernetes1.14のβ版アップグレードにおいて破壊的な 変更を含んでいます。もしユーザーがKubernetes1.14以前のバージョンを使っていた場合、RuntimeClassのα版からβ版へのアップグレードを参照してください。

RuntimeClassについて

RuntimeClassはコンテナランタイムの設定を選択するための機能です。そのコンテナランタイム設定はPodのコンテナを稼働させるために使われます。

セットアップ

RuntimeClass機能のフィーチャーゲートが有効になっていることを確認してください(デフォルトで有効です)。フィーチャーゲートを有効にする方法については、フィーチャーゲートを参照してください。 そのRuntimeClassのフィーチャーゲートはApiServerとkubeletのどちらも有効になっていなければなりません。

  1. ノード上でCRI実装を設定する。(ランタイムに依存)
  2. 対応するRuntimeClassリソースを作成する。

1. ノード上でCRI実装を設定する。

RuntimeClassを通じて利用可能な設定はContainer Runtime Interface (CRI)の実装依存となります。 ユーザーの環境のCRI実装の設定方法は、対応するドキュメント(下記)を参照ください。

備考: RuntimeClassは、クラスター全体で同じ種類のノード設定であることを仮定しています。(これは全てのノードがコンテナランタイムに関して同じ方法で構成されていることを意味します)。 設定が異なるノードをサポートするには、スケジューリングを参照してください。

RuntimeClassの設定は、RuntimeClassによって参照されるハンドラー名を持ちます。そのハンドラーは正式なDNS-1123に準拠する形式のラベルでなくてはなりません(英数字 + -の文字で構成されます)。

2. 対応するRuntimeClassリソースを作成する

ステップ1にて設定する各項目は、関連するハンドラー 名を持ちます。それはどの設定かを指定するものです。各ハンドラーにおいて、対応するRuntimeClassオブジェクトが作成されます。

そのRuntimeClassリソースは現時点で2つの重要なフィールドを持ちます。それはRuntimeClassの名前(metadata.name)とハンドラー(handler)です。そのオブジェクトの定義は下記のようになります。

apiVersion: node.k8s.io/v1beta1  # RuntimeClassはnode.k8s.ioというAPIグループで定義されます。
kind: RuntimeClass
metadata:
  name: myclass  # RuntimeClass名
  # RuntimeClassはネームスペースなしのリソースです。
handler: myconfiguration  # 対応するCRI設定

RuntimeClassオブジェクトの名前はDNSサブドメイン名に従う必要があります。

備考: RuntimeClassの書き込み操作(create/update/patch/delete)はクラスター管理者のみに制限されることを推奨します。 これはたいていデフォルトで有効となっています。さらなる詳細に関してはAuthorization Overviewを参照してください。

使用例

一度RuntimeClassがクラスターに対して設定されると、それを使用するのは非常に簡単です。PodSpecのruntimeClassNameを指定してください。
例えば

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

これは、Kubeletに対してPodを稼働させるためのRuntimeClassを使うように指示します。もし設定されたRuntimeClassが存在しない場合や、CRIが対応するハンドラーを実行できない場合、そのPodはFailedというフェーズになります。 エラーメッセージに関しては対応するイベントを参照して下さい。

もしruntimeClassNameが指定されていない場合、デフォルトのRuntimeHandlerが使用され、これはRuntimeClassの機能が無効であるときのふるまいと同じものとなります。

CRIの設定

CRIランタイムのセットアップに関するさらなる詳細は、CRIのインストールを参照してください。

dockershim

Kubernetesのビルトインのdockershim CRIは、ランタイムハンドラーをサポートしていません。

containerdA container runtime with an emphasis on simplicity, robustness and portability

ランタイムハンドラーは、/etc/containerd/config.tomlにあるcontainerdの設定ファイルにより設定されます。 正しいハンドラーは、そのruntimeセクションで設定されます。

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

containerdの設定に関する詳細なドキュメントは下記を参照してください。
https://github.com/containerd/cri/blob/master/docs/config.md

CRI-OA lightweight container runtime specifically for Kubernetes

ランタイムハンドラーは、/etc/crio/crio.confにあるCRI-Oの設定ファイルにより設定されます。 正しいハンドラーはcrio.runtime tableで設定されます。

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

CRI-Oの設定に関するドキュメントの詳細は下記を参照してください。

スケジューリング

FEATURE STATE: Kubernetes v1.16 [beta]

Kubernetes 1.16では、RuntimeClassはschedulingフィールドを使ったクラスター内での異なる設定をサポートしています。 このフィールドによって、設定されたRuntimeClassをサポートするノードに対してPodがスケジュールされることを保証できます。 スケジューリングをサポートするためにはRuntimeClass アドミッションコントローラーを有効にしなければなりません。(1.16ではデフォルトです)

特定のRuntimeClassをサポートしているノードへPodが配置されることを保証するために、各ノードはruntimeclass.scheduling.nodeSelectorフィールドによって選択される共通のラベルを持つべきです。 RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSelectorに統合され、効率よくノードを選択します。 もし設定が衝突した場合は、Pod作成は拒否されるでしょう。

もしサポートされているノードが他のRuntimeClassのPodが稼働しないようにtaint付与されていた場合、RuntimeClassに対してtolerationsを付与することができます。 nodeSelectorと同様に、tolerationsはPodのtolerationsにアドミッション機能によって統合され、効率よく許容されたノードを選択します。

ノードの選択とtolerationsについての詳細はノード上へのPodのスケジューリングを参照してください。

Podオーバーヘッド

FEATURE STATE: Kubernetes v1.16 [alpha]

Kubernetes 1.16ではRuntimeClassはPodOverhead機能の一部である、Podが稼働する時に関連するオーバーヘッドを指定することをサポートしています。 PodOverheadを使うためには、PodOverheadフィーチャーゲートを有効にしなければなりません。(デフォルトではoffです)

PodのオーバーヘッドはRuntimeClass内のOverheadフィールドによって定義されます。 このフィールドを使用することで、RuntimeClassを使用して稼働するPodのオーバーヘッドを指定することができ、Kubernetes内部で使用されるオーバーヘッドを確保することができます。

RutimeClassをα版からβ版にアップグレードする

RuntimeClassのβ版の機能は、下記の変更点を含みます。

  • node.k8s.ioAPIグループとruntimeclasses.node.k8s.ioリソースはCustomResourceDefinitionからビルトインAPIへとマイグレーションされました。
  • specはRuntimeClassの定義内にインライン化されました(RuntimeClassSpecはすでにありません)。
  • runtimeHandlerフィールドはhandlerにリネームされました。
  • handlerフィールドは、全てのAPIバージョンにおいて必須となりました。これはα版のAPIでのruntimeHandlerフィールドもまた必須であることを意味します。
  • handlerフィールドは正しいDNSラベルの形式である必要があり(RFC 1123)、これは.文字はもはや含むことができないことを意味します(全てのバージョンにおいて)。有効なハンドラー名は、次の正規表現に従います。^[a-z0-9]([-a-z0-9]*[a-z0-9])?$

Action Required: 次のアクションはRuntimeClassのα版からβ版へのアップグレードにおいて対応が必須です。

  • RuntimeClassリソースはKubernetes v1.14にアップグレードされた後に 再作成されなくてはなりません。そしてruntimeclasses.node.k8s.ioというCRDは手動で削除されるべきです。
    kubectl delete customresourcedefinitions.apiextensions.k8s.io runtimeclasses.node.k8s.io
    
  • runtimeHandlerの指定がないか、もしくは空文字の場合や、ハンドラー名に.文字列が使われている場合はα版のRuntimeClassにおいてもはや有効ではありません。正しい形式のハンドラー設定に変更しなくてはなりません(先ほど記載した内容を確認ください)。

参考文献