Kubernetes v1.14
beta
beta
がつきます(例:v2beta3
)。このページではRuntimeClassリソースと、runtimeセクションのメカニズムについて説明します。
警告: RuntimeClassはKubernetes1.14のβ版アップグレードにおいて破壊的な 変更を含んでいます。もしユーザーがKubernetes1.14以前のバージョンを使っていた場合、RuntimeClassのα版からβ版へのアップグレードを参照してください。
RuntimeClassはコンテナランタイムの設定を選択するための機能です。そのコンテナランタイム設定はPodのコンテナを稼働させるために使われます。
RuntimeClass機能のFeature Gateが有効になっていることを確認してください(デフォルトで有効です)。Feature Gateを有効にする方法については、Feature
Gatesを参照してください。
そのRuntimeClass
のFeature GateはApiServerとkubeletのどちらも有効になっていなければなりません。
RuntimeClassを通じて利用可能な設定はContainer Runtime Interface (CRI)の実装依存となります。 ユーザーの環境のCRI実装の設定方法は、対応するドキュメント(下記)を参照ください。
備考: RuntimeClassは現時点において、クラスター全体で同じ種類のNode設定であることを仮定しています。(これは全てのNodeがコンテナランタイムに関して同じ方法で構成されていることを意味します)。 設定が異なるNodeに関しては、スケジューリング機能を通じてRuntimeClassとは独立して管理されなくてはなりません。(PodをNodeに割り当てる方法を参照して下さい)。
RuntimeClassの設定は、RuntimeClassによって参照されるハンドラー
名を持ちます。そのハンドラーは正式なDNS-1123に準拠する形式のラベルでなくてはなりません(英数字 + -
の文字で構成されます)。
ステップ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の書き込み操作(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のインストールを参照してください。
Kubernetesのビルトインのdockershim CRIは、ランタイムハンドラーをサポートしていません。
ランタイムハンドラーは、/etc/containerd/config.toml
にあるcontainerdの設定ファイルにより設定されます。
正しいハンドラーは、そのruntime
セクションで設定されます。
[plugins.cri.containerd.runtimes.${HANDLER_NAME}]
containerdの設定に関する詳細なドキュメントは下記を参照してください。
https://github.com/containerd/cri/blob/master/docs/config.md
ランタイムハンドラーは、/etc/crio/crio.conf
にあるcri-oの設定ファイルにより設定されます。
正しいハンドラーはcrio.runtime
tableで設定されます。
[crio.runtime.runtimes.${HANDLER_NAME}]
runtime_path = "${PATH_TO_BINARY}"
cri-oの設定に関する詳細なドキュメントは下記を参照してください。
https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go
RuntimeClassのβ版の機能は、下記の変更点を含みます。
node.k8s.io
APIグループと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においてもはや有効ではありません。正しい形式のハンドラー設定に変更しなくてはなりません(先ほど記載した内容を確認ください)。
このページは役に立ちましたか?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to 問題を報告する or 改善を提案.