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


24.1. 概要

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

注記

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

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

24.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」でも参照できます。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.