Update content/ja/docs/concepts/containers/runtime-class.md to the latest.
s-kawamura-w664
parent
4efa02ef04
commit
3723417440
|
|
@ -7,7 +7,7 @@ weight: 20
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.14" state="beta" >}}
|
||||
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
|
||||
|
||||
このページではRuntimeClassリソースと、runtimeセクションのメカニズムについて説明します。
|
||||
|
||||
|
|
@ -24,9 +24,6 @@ RuntimeClassを使用して、コンテナランタイムは同じで設定が
|
|||
|
||||
## セットアップ
|
||||
|
||||
RuntimeClass機能のフィーチャーゲートが有効になっていることを確認してください(デフォルトで有効です)。フィーチャーゲートを有効にする方法については、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を参照してください。
|
||||
その`RuntimeClass`のフィーチャーゲートはApiServerとkubeletのどちらも有効になっていなければなりません。
|
||||
|
||||
1. ノード上でCRI実装を設定する。(ランタイムに依存)
|
||||
2. 対応するRuntimeClassリソースを作成する。
|
||||
|
||||
|
|
@ -40,7 +37,7 @@ RuntimeClassは、クラスター全体で同じ種類のノード設定であ
|
|||
設定が異なるノードをサポートするには、[スケジューリング](#scheduling)を参照してください。
|
||||
{{< /note >}}
|
||||
|
||||
RuntimeClassの設定は、RuntimeClassによって参照される`ハンドラー`名を持ちます。そのハンドラーは正式なDNS-1123に準拠する形式のラベルでなくてはなりません(英数字 + `-`の文字で構成されます)。
|
||||
RuntimeClassの設定は、RuntimeClassによって参照される`ハンドラー`名を持ちます。そのハンドラーは有効な[DNSラベル名](/ja/docs/concepts/overview/working-with-objects/names/#dns-label-names)でなくてはなりません。
|
||||
|
||||
### 2. 対応するRuntimeClassリソースを作成する
|
||||
|
||||
|
|
@ -49,12 +46,15 @@ RuntimeClassの設定は、RuntimeClassによって参照される`ハンドラ
|
|||
そのRuntimeClassリソースは現時点で2つの重要なフィールドを持ちます。それはRuntimeClassの名前(`metadata.name`)とハンドラー(`handler`)です。そのオブジェクトの定義は下記のようになります。
|
||||
|
||||
```yaml
|
||||
apiVersion: node.k8s.io/v1beta1 # RuntimeClassはnode.k8s.ioというAPIグループで定義されます。
|
||||
# RuntimeClassはnode.k8s.ioというAPIグループで定義されます。
|
||||
apiVersion: node.k8s.io/v1
|
||||
kind: RuntimeClass
|
||||
metadata:
|
||||
name: myclass # RuntimeClass名
|
||||
# RuntimeClass名
|
||||
# RuntimeClassはネームスペースなしのリソースです。
|
||||
handler: myconfiguration # 対応するCRI設定
|
||||
name: myclass
|
||||
# 対応するCRI設定
|
||||
handler: myconfiguration
|
||||
```
|
||||
|
||||
RuntimeClassオブジェクトの名前は[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)に従う必要があります。
|
||||
|
|
@ -68,7 +68,7 @@ Overview](/docs/reference/access-authn-authz/authorization/)を参照してく
|
|||
|
||||
## 使用例
|
||||
|
||||
一度RuntimeClassがクラスターに対して設定されると、それを使用するのは非常に簡単です。PodSpecの`runtimeClassName`を指定してください。
|
||||
RuntimeClassがクラスターに対して設定されると、PodSpecで`runtimeClassName`を指定して使用できます。
|
||||
例えば
|
||||
|
||||
```yaml
|
||||
|
|
@ -81,19 +81,15 @@ spec:
|
|||
# ...
|
||||
```
|
||||
|
||||
これは、Kubeletに対してPodを稼働させるためのRuntimeClassを使うように指示します。もし設定されたRuntimeClassが存在しない場合や、CRIが対応するハンドラーを実行できない場合、そのPodは`Failed`という[フェーズ](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)になります。
|
||||
エラーメッセージに関しては対応する[イベント](/docs/tasks/debug-application-cluster/debug-application-introspection/)を参照して下さい。
|
||||
これは、kubeletに対してPodを稼働させるためのRuntimeClassを使うように指示します。もし設定されたRuntimeClassが存在しない場合や、CRIが対応するハンドラーを実行できない場合、そのPodは`Failed`という[フェーズ](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)になります。
|
||||
エラーメッセージに関しては対応する[イベント](/docs/tasks/debug/debug-application/debug-running-pod/)を参照して下さい。
|
||||
|
||||
もし`runtimeClassName`が指定されていない場合、デフォルトのRuntimeHandlerが使用され、これはRuntimeClassの機能が無効であるときのふるまいと同じものとなります。
|
||||
|
||||
### CRIの設定
|
||||
### CRIの設定 {#cri-configuration}
|
||||
|
||||
CRIランタイムのセットアップに関するさらなる詳細は、[CRIのインストール](/docs/setup/cri/)を参照してください。
|
||||
|
||||
#### dockershim
|
||||
|
||||
Kubernetesのビルトインのdockershim CRIは、ランタイムハンドラーをサポートしていません。
|
||||
|
||||
#### {{< glossary_tooltip term_id="containerd" >}}
|
||||
|
||||
ランタイムハンドラーは、`/etc/containerd/config.toml`にあるcontainerdの設定ファイルにより設定されます。
|
||||
|
|
@ -103,8 +99,7 @@ Kubernetesのビルトインのdockershim CRIは、ランタイムハンドラ
|
|||
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
|
||||
```
|
||||
|
||||
containerdの設定に関する詳細なドキュメントは下記を参照してください。
|
||||
https://github.com/containerd/containerd/blob/main/docs/cri/config.md
|
||||
詳細はcontainerdの[設定に関するドキュメント](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)を参照してください。
|
||||
|
||||
#### {{< glossary_tooltip term_id="cri-o" >}}
|
||||
|
||||
|
|
@ -117,15 +112,14 @@ table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntim
|
|||
runtime_path = "${PATH_TO_BINARY}"
|
||||
```
|
||||
|
||||
詳細はCRI-Oの[設定に関するドキュメント](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md)を参照してください。
|
||||
詳細はCRI-Oの[設定に関するドキュメント](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md)を参照してください。
|
||||
|
||||
## スケジューリング {#scheduling}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
|
||||
|
||||
Kubernetes 1.16では、RuntimeClassは`scheduling`フィールドを使ったクラスター内での異なる設定をサポートしています。
|
||||
このフィールドによって、設定されたRuntimeClassをサポートするノードに対してPodがスケジュールされることを保証できます。
|
||||
スケジューリングをサポートするためにはRuntimeClass [アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#runtimeclass)を有効にしなければなりません。(1.16ではデフォルトです)
|
||||
RuntimeClassの`scheduling`フィールドを指定することで、設定されたRuntimeClassをサポートするノードにPodがスケジューリングされるように制限することができます。
|
||||
`scheduling`が設定されていない場合、このRuntimeClassはすべてのノードでサポートされていると仮定されます。
|
||||
|
||||
特定のRuntimeClassをサポートしているノードへPodが配置されることを保証するために、各ノードは`runtimeclass.scheduling.nodeSelector`フィールドによって選択される共通のラベルを持つべきです。
|
||||
RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSelectorに統合され、効率よくノードを選択します。
|
||||
|
|
@ -138,10 +132,9 @@ RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSele
|
|||
|
||||
### Podオーバーヘッド
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
|
||||
|
||||
Podが稼働する時に関連する _オーバーヘッド_ リソースを指定できます。オーバーヘッドを宣言すると、クラスター(スケジューラーを含む)がPodとリソースに関する決定を行うときにオーバーヘッドを考慮することができます。
|
||||
Podオーバーヘッドを使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではonです)
|
||||
|
||||
PodのオーバーヘッドはRuntimeClass内の`overhead`フィールドによって定義されます。
|
||||
このフィールドを使用することで、RuntimeClassを使用して稼働するPodのオーバーヘッドを指定することができ、Kubernetes内部で使用されるオーバーヘッドを確保することができます。
|
||||
|
|
|
|||
Loading…
Reference in New Issue