Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

第22章 ノードリソースの割り当て

22.1. ノードリソースの割り当ての目的

より信頼性の高いスケジューリングを提供し、ノードにおけるリソースのオーバーコミットを最小限にするために、kubelet、kube-proxy、およびコンテナーエンジンなどの基礎となる ノードコンポーネント で使用するために CPU およびメモリーの一部を予約します。また、予約するリソースは、sshdNetworkManager などの残りのシステムコンポーネントでも使用されます。予約するリソースを指定すると、スケジューラーに、ノードにある Pod で使用できる残りのメモリーおよび CPU リソースについての詳細が提供されます。

22.2. 割り当てられるリソースについてのノードの設定

system-reserved ノード設定を構成することにより、OpenShift ContainerPlatform のノードコンポーネントおよびシステムコンポーネント用にリソースが予約されます。

OpenShift Container Platform は kube-reserved 設定を使用しません。Kubernetes および Kubernetes 環境を提供する一部のクラウドベンダーについてのドキュメントでは、kube-reserved の設定が提案される場合があります。この情報については、 OpenShift Container Platform クラスターには適用されません。

リソース制限を使用してクラスターを調整し、エビクションを使用して制限を適用する場合には注意が必要です。system-reserved 制限を実行すると、重要なシステムサービスが CPU 時間を受信したり、メモリリソースが不足する場合に重要なシステムサービスを終了したりするのを防ぐことができます。

ほとんどの場合、リソース割り当ての調整は、調整を行ってから、実稼働に対応するワークロードでクラスターのパフォーマンスを監視して実行されます。このプロセスは、クラスターが安定し、サービスレベルアグリーメントを満たすまで繰り返されます。

これらの設定の効果の詳細については、「割り当てられるリソースの計算」を参照してください。

設定説明

kube-reserved

この設定は、OpenShift ContainerPlatform では使用されません。予約する予定の CPU およびメモリーリソースを system-reserved 設定に追加します。

system-reserved

ノードコンポーネントとシステムコンポーネント用に予約されているリソース。デフォルトは none です。

以下のコマンドを実行して、lscgroup などのツールで、system-reserved で制御されるサービスを表示します。

# yum install libcgroup-tools
$ lscgroup memory:/system.slice

<resource_type>=<resource_quantity> ペアのセットを追加して、ノード設定マップkubeletArguments セクションのリソースを予約します。たとえば、 cpu=500m,memory=1Gi は 500 ミリコアの CPU と 1 ギガバイトのメモリーを予約します。

例22.1 ノードの割り当て可能なリソースの設定

kubeletArguments:
  system-reserved:
    - "cpu=500m,memory=1Gi"

system-reserved フィールドを追加します (存在しない場合)。

注記

node-config.yaml ファイルを直接編集しないでください。

これらの設定についての適切な値を判断するには、ノード要約 API を使用してノードのリソース使用率を表示します。詳細は、「ノードによって報告されるシステムリソース」を参照してください。

system-reserved を設定した後:

  • ノードのメモリー使用量をモニターして、高基準値を確認します。

    $ ps aux | grep <service-name>

    例:

    $ ps aux | grep atomic-openshift-node
    
    USER       PID   %CPU  %MEM  VSZ     RSS  TTY    STAT  START  TIME  COMMAND
    root       11089 11.5  0.3   112712  996  pts/1  R+    16:23  0:00  grep --color=auto atomic-openshift-node

    この値が system-reserved の基準に近い場合は、system-reserved の値を増やすことができます。

  • 以下のコマンドを実行して、cgget などのツールを使用してシステムサービスのメモリーの使用状況を監視します。

    # yum install libcgroup-tools
    $ cgget -g memory  /system.slice | grep memory.usage_in_bytes

    この値が system-reserved の基準に近い場合は、system-reserved の値を増やすことができます。

  • OpenShift Container Platform クラスターローダー を使用して、クラスターの各種の状態でのデプロイメントのパフォーマンスメトリクスを測定します。

22.3. 割り当てられるリソースの計算

リソースの割り当てられる量は以下の数式に基づいて計算されます。

[Allocatable] = [Node Capacity] - [system-reserved] - [Hard-Eviction-Thresholds]
注記

Hard-Eviction-Thresholds を割り当て可能なリソースから差し引くと、システムの信頼性が強化されます。割り当て可能なリソースの値はノードレベルで Pod について実行されます。experimental-allocatable-ignore-eviction 設定はレガシー動作を保持するために利用できますが、今後のリリースでは非推奨となります。

[Allocatable] が負の値の場合、これは 0 に設定されます。

22.4. ノードの割り当て可能なリソースおよび容量の表示

ノードの現在の容量と割り当て可能なリソースを表示するには、以下のコマンドを実行します。

$ oc get node/<node_name> -o yaml

以下の部分的な出力では、割り当て可能な値が容量を下回っています。この差異は予想されてるものであり、system-reservedcpu=500m,memory=1Gi リソース割り当てと一致します。

status:
...
  allocatable:
    cpu: "3500m"
    memory: 6857952Ki
    pods: "110"
  capacity:
    cpu: "4"
    memory: 8010948Ki
    pods: "110"
...

スケジューラーは、allocatable の値を使用してノードが Pod スケジューリングの候補であるかどうかを判断します。

22.5. ノードによって報告されるシステムリソース

各ノードは、コンテナーランタイムと kubelet によって使用されるシステムリソースを報告します。system-reserved の設定を簡素化するには、ノード要約 API を使用してノードのリソース使用量を表示します。ノードの要約は、<master>/api/v1/nodes/<node>/proxy/stats/summary で利用可能です。

たとえば、cluster.node22 ノードからリソースにアクセスするには、以下のコマンドを実行します。

$ curl <certificate details> https://<master>/api/v1/nodes/cluster.node22/proxy/stats/summary

応答には、以下のような情報が含まれます。

{
    "node": {
        "nodeName": "cluster.node22",
        "systemContainers": [
            {
                "cpu": {
                    "usageCoreNanoSeconds": 929684480915,
                    "usageNanoCores": 190998084
                },
                "memory": {
                    "rssBytes": 176726016,
                    "usageBytes": 1397895168,
                    "workingSetBytes": 1050509312
                },
                "name": "kubelet"
            },
            {
                "cpu": {
                    "usageCoreNanoSeconds": 128521955903,
                    "usageNanoCores": 5928600
                },
                "memory": {
                    "rssBytes": 35958784,
                    "usageBytes": 129671168,
                    "workingSetBytes": 102416384
                },
                "name": "runtime"
            }
        ]
    }
}

証明書の詳細については、「REST API Overview」を参照してください。

22.6. ノードの実施

ノードは、Pod が設定された割り当て可能な値に基づいて消費できるリソースの合計量を制限できます。この機能は、Pod がリソースのシステムサービス (例: コンテナーランタイム、ノードエージェントなど) が必要とする CPU およびメモリーリソースを使用することを防ぎ、ノードの信頼性を大幅に強化します。管理者は、ノードの信頼性を強化するために、ノードの使用状況のターゲットに基づいてリソースを予約する必要があります。

ノードは、QoS (Quality of Service) を実施する新規の cgroup 階層を使用してリソースの制約を実施します。すべての Pod は、システムデーモンと切り離された専用の cgroup 階層で起動します。

ノードの実施を設定するために、適切な ノード設定マップで以下のパラメーターを使用します。

例22.2 ノードの cgroup 設定

kubeletArguments:
  cgroups-per-qos:
    - "true" 1
  cgroup-driver:
    - "systemd" 2
  enforce-node-allocatable:
    - "pods" 3
1
各 QoS ごとに cgroup 階層を有効または無効にします。cgroup はノードによって管理されます。この設定を変更するには、ノードを完全にドレイン (解放) する必要があります。ノードがノード割り当て可能なリソース制約を適用できるようにするには、このフラグをtrue にする必要があります。デフォルト値は trueであり、Red Hat はお客様がこの値を変更することを推奨していません。
2
cgroup 階層を管理する際にノードで使用される cgroup ドライバーです。この値はコンテナーランタイムに関連付けられるドライバーに一致する必要があります。有効な値は systemd および cgroupfs ですが、Red Hat では systemd のみをサポートしています。
3
ノードがノードリソース制約を適用する必要があるスコープのコンマ区切りの一覧です。デフォルト値は pods であり、Red Hat では pods のみをサポートします。

管理者は、Guaranteed QoS (Quality of Service) のある Pod と同様にシステムデーモンを処理する必要があります。システムデーモンは境界となる制御グループ内でバーストする可能性があり、この動作はクラスターデプロイメントの一部として管理する必要があります。「割り当てられるリソースについてのノードの設定」セクションに示されるリソースを指定して、システムデーモンの CPU およびメモリーリソースを予約します。

設定されている cgroup ドライバーを表示するには、以下のコマンドを実行します。

$ systemctl status atomic-openshift-node -l | grep cgroup-driver=

出力には、以下のような応答が含まれます。

--cgroup-driver=systemd

cgroup ドライバーの管理およびトラブルシューティングの詳細は、「コントロールグループ (Cgroups) について」を参照してください。

22.7. エビクションしきい値

ノードがメモリー不足の状態にある場合、ノード全体に、またノードで実行されているすべての Pod に影響が及ぶ可能性があります。システムデーモンによるメモリーの使用がメモリーの予約されている量を超える場合、メモリー不足 (OOM) イベントが発生し、ノード全体やノードで実行されているすべての Pod に影響が及び可能性があります。システムのメモリー不足 (OOM) を防止する (またはその発生可能性を下げる) ために、ノードは Out Of Resource リソース不足の処理を行います。