第22章 不透明な整数リソース

22.1. 概要

不透明な整数リソースは、クラスターのオペレーターがシステムで認識されない新規のノードレベルのリソースを提供することを可能にします。ユーザーは CPU やメモリーと同様に Pod 仕様にあるこれらのリソースを消費できます。スケジューラーは、利用可能な量を上回るリソースが複数の Pod に同時に割り当てられないようにリソースアカウンティングを実行します。

注記

不透明な整数リソースは現時点でアルファ機能であり、リソースアカウンティングのみが実装されています。これらのリソースについてのリソースクォータや制限範囲のサポートはなく、これらが QoS に影響を与えることはありません。

不透明な整数リソースが 不透明 (opaque) と言われるのは、OpenShift Container Platform がリソースが何を認識しない状態でも、そのリソースが十分にある場合に Pod をノードにスケジュールするためです。それらが 整数リソース と言われるのは、それらが整数で表される量で利用可能であるか、または 公開 されるためです。API サーバーはこれらのリソースの量を整数に制限します。有効な 量の例は、3、3000m、および 3Ki などです。

不透明な整数リソースは以下を割り当てるために使用できます。

  • ラストレベルキャッシュ (LLC)
  • Graphics processing unit (GPU) デバイス
  • Field-programmable gate array (FPGA) デバイス
  • 帯域幅を並列ファイルシステムと共有するためのスロット

たとえば、ノードに特殊な種類のディスクストレージ 800 GiB がある場合、その特殊ストレージに opaque-int-resource-special-storage などの名前を作成することができます。これを 100 GiB などの特定サイズのチャンクの単位で公開することができます。この場合、ノードではタイプ opaque-int-resource-special-storage の 8 つのリソースがあることを公開します。

不透明な整数リソースの名前はプレフィックス pod.alpha.kubernetes.io/opaque-int-resource- で開始する必要があります。

22.2. 不透明な整数リソースの作成

以下は、不透明な整数リソースを使用するために必要な 2 つの手順です。まず、クラスターのオペレーターは 1 つ以上のノードでノード別の不透明なリソースに名前を付け、これを公開する必要があります。次に、アプリケーション開発者は Pod で不透明なリソースを要求する必要があります。

不透明な整数リソースを利用可能にするには、以下を実行します。

  1. リソースを割り当て、pod.alpha.kubernetes.io/opaque-int-resource- で開始される名前を割り当てます。

  2. クラスターのノードについて status.capacity で利用可能な数量を指定する PATCH HTTP 要求を API サーバーに送信することにより、新規の不透明な整数リソースを公開します。

    たとえば、以下の HTTP 要求は openshift-node-1 ノードで 5 つの foo リソースを公開します。 

    PATCH /api/v1/nodes/openshift-node-1/status HTTP/1.1
Accept: application/json
Content-Type: application/json-patch+json
Host: openshift-master:8080

[
  {
    "op": "add",
    "path": "/status/capacity/pod.alpha.kubernetes.io~1opaque-int-resource-foo",
    "value": "5"
  }
]
    注記

    path にある ~1 は / 文字のエンコーディングです。JSON-Patch の操作パスの値は JSON-Pointer として解釈されます。詳細は、IETF RFC 6901、セクション 3 を参照してください。

    この操作の後に、ノード status.capacity には新規リソースが含まれます。status.allocatable フィールドは、新規リソースで自動的に、また非同期的に更新されます。

    注記

    スケジューラーは、Pod が適切であるかどうかを評価する際にノードの status.allocatable 値を使用するため、ノードの容量を新規リソースで修正してから、そのリソースを要求する最初の Pod がノードでスケジュールされるまでの間に少しの遅延が生じる可能性があります。

アプリケーション開発者は、不透明なリソースの名前を spec.containers[].resources.requests フィールドのキーとして組み込むよう Pod 設定を編集することにより、不透明なリソースを消費できます。

例: 以下の Pod は 2 つの CPU および 1 つの foo (不透明なリソース) を要求しています。 

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: myimage
    resources:
      requests:
        cpu: 2
        pod.alpha.kubernetes.io/opaque-int-resource-foo: 1

Pod は、(CPU、メモリー、およびすべての不透明なリソースを含む) リソース要求のすべてが満たされる場合にのみスケジュールされます。Pod は、リソース要求がいずれのノードでも満たされない場合には PENDING 状態のままになります。 

Conditions:
  Type    Status
  PodScheduled  False
...
Events:
  FirstSeen  LastSeen	Count	From		  SubObjectPath	Type	  Reason	    Message
  ---------  --------	-----	----		  -------------	--------  ------	    -------
  14s	     0s		6	default-scheduler		Warning	  FailedScheduling  No nodes are available that match all of the following predicates:: Insufficient pod.alpha.kubernetes.io/opaque-int-resource-foo (1).

この情報は『Developer Guide』の「Quotas and Limit Ranges」でも参照できます。