サポートコンソール開発者トライアルの開始お問い合わせ

5.3. MCO 関連のカスタムリソースの設定

MCO は MachineConfig オブジェクトを管理する以外にも、2 つのカスタムリソース (CR)(KubeletConfig および ContainerRuntimeConfig) を管理します。これらの CR を使用すると、Kubelet および CRI-O コンテナーランタイムサービスの動作に影響を与えるノードレベルの設定を変更することができます。

5.3.1. kubelet パラメーターを編集するための KubeletConfig CRD の作成

kubelet 設定は、現時点で Ignition 設定としてシリアル化されているため、直接編集することができます。ただし、新規の kubelet-config-controller も Machine Config Controller (MCC) に追加されます。これにより、KubeletConfig カスタムリソース (CR) を使用して kubelet パラメーターを編集できます。

注記

kubeletConfig オブジェクトのフィールドはアップストリーム Kubernetes から kubelet に直接渡されるため、kubelet はそれらの値を直接検証します。kubeletConfig オブジェクトに無効な値により、クラスターノードが利用できなくなります。有効な値は、Kubernetes ドキュメント を参照してください。

以下のガイダンスを参照してください。

  • 既存の KubeletConfig CR を編集して既存の設定を編集するか、変更ごとに新規 CR を作成する代わりに新規の設定を追加する必要があります。CR を作成するのは、別のマシン設定プールを変更する場合、または一時的な変更を目的とした変更の場合のみにして、変更を元に戻すことができるようにすることを推奨します。
  • マシン設定プールごとに、そのプールに加える設定変更をすべて含めて、KubeletConfig CR を 1 つ作成します。
  • 必要に応じて、クラスターごとに 10 を制限し、複数の KubeletConfig CR を作成します。最初の KubeletConfig CR について、Machine Config Operator (MCO) は kubelet で追加されたマシン設定を作成します。それぞれの後続の CR で、コントローラーは数字の接尾辞が付いた別の kubelet マシン設定を作成します。たとえば、kubelet マシン設定があり、その接尾辞が -2 の場合に、次の kubelet マシン設定には -3 が付けられます。
注記

kubelet またはコンテナーのランタイム設定をカスタムマシン設定プールに適用する場合、machineConfigSelector のカスタムロールは、カスタムマシン設定プールの名前と一致する必要があります。

たとえば、次のカスタムマシン設定プールの名前は infra であるため、カスタムロールも infra にする必要があります。 

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: infra
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,infra]}
# ...

マシン設定を削除する場合は、制限を超えないようにそれらを逆の順序で削除する必要があります。たとえば、kubelet-3 マシン設定を、kubelet-2 マシン設定を削除する前に削除する必要があります。

注記

接尾辞が kubelet-9 のマシン設定があり、別の KubeletConfig CR を作成する場合には、kubelet マシン設定が 10 未満の場合でも新規マシン設定は作成されません。

KubeletConfig CR の例

$ oc get kubeletconfig

NAME                AGE
set-max-pods        15m

KubeletConfig マシン設定を示す例

$ oc get mc | grep kubelet

...
99-worker-generated-kubelet-1                  b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             26m
...

以下の手順は、ワーカーノードでノードあたりの Pod の最大数を設定する方法を示しています。

前提条件

  1. 設定するノードタイプの静的な MachineConfigPool CR に関連付けられたラベルを取得します。以下のいずれかの手順を実行します。

    1. マシン設定プールを表示します。 

      $ oc describe machineconfigpool <name>

      以下に例を示します。 

      $ oc describe machineconfigpool worker

      出力例

      apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: 2019-02-08T14:52:39Z
  generation: 1
  labels:
    custom-kubelet: set-max-pods 1

      1
      ラベルが追加されると、labels の下に表示されます。

    2. ラベルが存在しない場合は、キー/値のペアを追加します。 

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods

手順

  1. 選択可能なマシン設定オブジェクトを表示します。 

    $ oc get machineconfig

    デフォルトで、2 つの kubelet 関連の設定である 01-master-kubelet および 01-worker-kubelet を選択できます。

  2. ノードあたりの最大 Pod の現在の値を確認します。 

    $ oc describe node <node_name>

    以下に例を示します。 

    $ oc describe node ci-ln-5grqprb-f76d1-ncnqq-worker-a-mdv94

    Allocatable スタンザで value: pods: <value> を検索します。

    出力例

    Allocatable:
 attachable-volumes-aws-ebs:  25
 cpu:                         3500m
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      15341844Ki
 pods:                        250

  3. ワーカーノードでノードあたりの最大の Pod を設定するには、kubelet 設定を含むカスタムリソースファイルを作成します。

    重要

    特定のマシン設定プールをターゲットとする kubelet 設定は、依存するプールにも影響します。たとえば、ワーカーノードを含むプール用の kubelet 設定を作成すると、インフラストラクチャーノードを含むプールを含むすべてのサブセットプールにも設定が適用されます。これを回避するには、ワーカーノードのみを含む選択式を使用して新しいマシン設定プールを作成し、kubelet 設定でこの新しいプールをターゲットにする必要があります。 

    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-max-pods
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: set-max-pods 1
  kubeletConfig:
    maxPods: 500 2
    1
    Machine Config Pool からラベルを入力します。
    2
    kubelet 設定を追加します。この例では、maxPods を使用してノードあたりの最大 Pod を設定します。
    注記

    kubelet が API サーバーと通信する速度は、1 秒あたりのクエリー (QPS) およびバースト値により異なります。デフォルト値の 50 (kubeAPIQPS の場合) および 100 (kubeAPIBurst の場合) は、各ノードで制限された Pod が実行されている場合には十分な値です。ノード上に CPU およびメモリーリソースが十分にある場合には、kubelet QPS およびバーストレートを更新することが推奨されます。 

    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-max-pods
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: set-max-pods
  kubeletConfig:
    maxPods: <pod_count>
    kubeAPIBurst: <burst_rate>
    kubeAPIQPS: <QPS>

    1. ラベルを使用してワーカーのマシン設定プールを更新します。 

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods

    2. KubeletConfig オブジェクトを作成します。 

      $ oc create -f change-maxPods-cr.yaml

    3. KubeletConfig オブジェクトが作成されていることを確認します。 

      $ oc get kubeletconfig

      出力例

      NAME                AGE
set-max-pods        15m

      クラスター内のワーカーノードの数によっては、ワーカーノードが 1 つずつ再起動されるのを待機します。3 つのワーカーノードを持つクラスターの場合は、10 分から 15 分程度かかる可能性があります。

  4. 変更がノードに適用されていることを確認します。

    1. maxPods 値が変更されたワーカーノードで確認します。 

      $ oc describe node <node_name>

    2. Allocatable スタンザを見つけます。 

       ...
Allocatable:
  attachable-volumes-gce-pd:  127
  cpu:                        3500m
  ephemeral-storage:          123201474766
  hugepages-1Gi:              0
  hugepages-2Mi:              0
  memory:                     14225400Ki
  pods:                       500 1
 ...
      1
      この例では、pods パラメーターは KubeletConfig オブジェクトに設定した値を報告するはずです。

  5. KubeletConfig オブジェクトの変更を確認します。 

    $ oc get kubeletconfigs set-max-pods -o yaml

    これは、以下の例のように True および type:Success のステータスを表示します。 

    spec:
  kubeletConfig:
    maxPods: 500
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: set-max-pods
status:
  conditions:
  - lastTransitionTime: "2021-06-30T17:04:07Z"
    message: Success
    status: "True"
    type: Success

5.3.2. CRI-O パラメーターを編集するための ContainerRuntimeConfig CR の作成

特定のマシン設定プール (MCP) に関連付けられたノードの OpenShift Container Platform CRI-O ランタイムに関連付けられる設定の一部を変更することができます。ContainerRuntimeConfig カスタムリソース (CR) を使用して、設定値を設定し、MCP に一致するラベルを追加します。次に、MCO は関連付けられたノードで crio.conf および storage.conf 設定ファイルを更新された値を使用して再ビルドします。

注記

ContainerRuntimeConfig CR を使用して実装された変更を元に戻すには、CR を削除する必要があります。マシン設定プールからラベルを削除しても、変更は元に戻されません。

ContainerRuntimeConfig CR を使用して以下の設定を変更することができます。

  • PID 制限: ContainerRuntimeConfig での PID 制限の設定は非推奨になる予定です。PID 制限が必要な場合は、代わりに KubeletConfig CR の podPidsLimit フィールドを使用することを推奨します。デフォルトの podPidsLimit 値は 4096 で、デフォルトの pids_limit 値は 0 です。podPidsLimit が pids_limit より低いと、有効なコンテナー PID 制限は podPidsLimit に設定された値により定義されます。

    注記

    CRI-O フラグはコンテナーの cgroup に適用され、Kubelet フラグは Pod の cgroup に設定されます。それに応じて PID 制限を調整してください。

  • Log level: logLevel パラメーターは CRI-O log_level パラメーターを設定します。これはログメッセージの詳細レベルです。デフォルトは info (log_level = info) です。他のオプションには、fatal、panic、error、warn、debug、および trace が含まれます。
  • Overlay size: overlaySize パラメーターは、コンテナーイメージの最大サイズである CRI-O Overlay ストレージドライバーの size パラメーターを設定します。
  • 最大ログサイズ: ContainerRuntimeConfig での最大ログサイズの設定は非推奨になる予定です。最大ログサイズが必要な場合は、代わりに KubeletConfig CR の containerLogMaxSize フィールドを使用することを推奨します。
  • コンテナーランタイム: defaultRuntime パラメーターは、コンテナーランタイムを runc または crun に設定します。デフォルトは runc です。
重要

Crun コンテナーランタイムのサポートは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

マシン設定プールごとに、そのプールに加える設定変更をすべて含めて、ContainerRuntimeConfig CR を 1 つ割り当てる必要があります。同じコンテンツをすべてのプールに適用している場合には、すべてのプールに必要となるのは ContainerRuntimeConfig CR 1 つだけです。

既存の ContainerRuntimeConfig CR を編集して既存の設定を編集するか、変更ごとに新規 CR を作成する代わりに新規の設定を追加する必要があります。異なるマシン設定プールを変更する場合や、変更が一時的で元に戻すことができる場合のみ、新しい ContainerRuntimeConfig CR の作成を推奨しています。

必要に応じて複数の ContainerRuntimeConfig CR を作成できます。この場合、制限はクラスターごとに 10 個となっています。最初の ContainerRuntimeConfig CR について、MCO は containerruntime で追加されたマシン設定を作成します。それぞれの後続の CR で、コントローラーは数字の接尾辞が付いた新規の containerruntime マシン設定を作成します。たとえば、containerruntime マシン設定に -2 接尾辞がある場合、次の containerruntime マシン設定が -3 を付けて追加されます。

マシン設定を削除する場合、制限を超えないようにそれらを逆の順序で削除する必要があります。たとえば、containerruntime-3 マシン設定を、containerruntime-2 マシン設定を削除する前に削除する必要があります。

注記

接尾辞が containerruntime-9 のマシン設定があり、別の ContainerRuntimeConfig CR を作成する場合には、containerruntime マシン設定が 10 未満の場合でも新規マシン設定は作成されません。

複数の ContainerRuntimeConfig CR を示す例

$ oc get ctrcfg

出力例

NAME         AGE
ctr-overlay  15m
ctr-level    5m45s

複数の containerruntime マシン設定を示す例

$ oc get mc | grep container

出力例

...
01-master-container-runtime                        b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             57m
...
01-worker-container-runtime                        b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             57m
...
99-worker-generated-containerruntime               b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             26m
99-worker-generated-containerruntime-1             b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             17m
99-worker-generated-containerruntime-2             b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             7m26s
...

次の例では、log_level フィールドを debug に設定し、オーバーレイサイズを 8 GB に設定します。

ContainerRuntimeConfig CR の例

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: overlay-size
spec:
 machineConfigPoolSelector:
   matchLabels:
     pools.operator.machineconfiguration.openshift.io/worker: '' 1
 containerRuntimeConfig:
   logLevel: debug 2
   overlaySize: 8G 3
   defaultRuntime: "crun" 4

1
マシン設定プールのラベルを指定します。コンテナーのランタイム設定の場合、ロールは関連付けられているマシン設定プールの名前と一致する必要があります。
2
オプション: ログメッセージの詳細レベルを指定します。
3
オプション: コンテナーイメージの最大サイズを指定します。
4
オプション：新規コンテナーにデプロイするコンテナーランタイムを指定します。デフォルト値は runc です。

前提条件

  • crun を有効にするには、TechPreviewNoUpgrade 機能セットを有効にする必要があります。

    注記

    TechPreviewNoUpgrade 機能セットを有効にすると元に戻すことができなくなり、マイナーバージョンの更新ができなくなります。これらの機能セットは、実稼働クラスターではは推奨されません。

手順

ContainerRuntimeConfig CR を使用して CRI-O 設定を変更するには、以下を実行します。

  1. ContainerRuntimeConfig CR の YAML ファイルを作成します。 

    apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: overlay-size
spec:
 machineConfigPoolSelector:
   matchLabels:
     pools.operator.machineconfiguration.openshift.io/worker: '' 1
 containerRuntimeConfig: 2
   logLevel: debug
   overlaySize: 8G
    1
    変更する必要のあるマシン設定プールのラベルを指定します。
    2
    必要に応じてパラメーターを設定します。

  2. ContainerRuntimeConfig CR を作成します。 

    $ oc create -f <file_name>.yaml

  3. CR が作成されたことを確認します。 

    $ oc get ContainerRuntimeConfig

    出力例

    NAME           AGE
overlay-size   3m19s

  4. 新規の containerruntime マシン設定が作成されていることを確認します。 

    $ oc get machineconfigs | grep containerrun

    出力例

    99-worker-generated-containerruntime   2c9371fbb673b97a6fe8b1c52691999ed3a1bfc2  3.2.0  31s

  5. すべてが準備状態にあるものとして表示されるまでマシン設定プールをモニターします。 

    $ oc get mcp worker

    出力例

    NAME    CONFIG               UPDATED  UPDATING  DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT  DEGRADEDMACHINECOUNT  AGE
worker  rendered-worker-169  False    True      False     3             1                  1                    0                     9h

  6. 設定が CRI-O で適用されたことを確認します。

    1. マシン設定プールのノードに対して oc debug セッションを開き、chroot /host を実行します。 

      $ oc debug node/<node_name>
      sh-4.4# chroot /host

    2. crio.conf ファイルの変更を確認します。 

      sh-4.4# crio config | grep 'log_level'

      出力例

      log_level = "debug"

    3. `storage.conf` ファイルの変更を確認します。 

      sh-4.4# head -n 7 /etc/containers/storage.conf

      出力例

      [storage]
  driver = "overlay"
  runroot = "/var/run/containers/storage"
  graphroot = "/var/lib/containers/storage"
  [storage.options]
    additionalimagestores = []
    size = "8G"

5.3.3. CRI-O を使用した Overlay のデフォルトのコンテナールートパーティションの最大サイズの設定

各コンテナーのルートパーティションには、基礎となるホストの利用可能なディスク領域がすべて表示されます。以下のガイダンスに従って、すべてのコンテナーのルートディスクの最大サイズを設定します。

Overlay の最大サイズや、ログレベルなどの他の CRI-O オプションを設定するには、以下の ContainerRuntimeConfig カスタムリソース定義 (CRD) を作成します。 

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: overlay-size
spec:
 machineConfigPoolSelector:
   matchLabels:
     custom-crio: overlay-size
 containerRuntimeConfig:
   logLevel: debug
   overlaySize: 8G

手順

  1. 設定オブジェクトを作成します。 

    $ oc apply -f overlaysize.yml

  2. 新規の CRI-O 設定をワーカーノードに適用するには、ワーカーのマシン設定プールを編集します。 

    $ oc edit machineconfigpool worker

  3. ContainerRuntimeConfig CRD に設定した matchLabels 名に基づいて custom-crio ラベルを追加します。 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: "2020-07-09T15:46:34Z"
  generation: 3
  labels:
    custom-crio: overlay-size
    machineconfiguration.openshift.io/mco-built-in: ""

  4. 変更を保存して、マシン設定を表示します。 

    $ oc get machineconfigs

    新規の 99-worker-generated-containerruntime および rendered-worker-xyz オブジェクトが作成されます。

    出力例

    99-worker-generated-containerruntime  4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m42s
rendered-worker-xyz                   4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m36s

  5. これらのオブジェクトの作成後に、変更が適用されるようにマシン設定プールを監視します。 

    $ oc get mcp worker

    ワーカーノードには、マシン数、更新数およびその他の詳細と共に UPDATING が True として表示されます。

    出力例

    NAME   CONFIG              UPDATED   UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
worker rendered-worker-xyz False True False     3             2                   2                    0                      20h

    完了すると、ワーカーノードは UPDATING を False に戻し、UPDATEDMACHINECOUNT 数は MACHINECOUNT に一致します。

    出力例

    NAME   CONFIG              UPDATED   UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
worker   rendered-worker-xyz   True      False      False      3         3            3             0           20h

    ワーカーマシンを見ると、新規の 8 GB の最大サイズの設定がすべてのワーカーに適用されていることを確認できます。

    出力例

    head -n 7 /etc/containers/storage.conf
[storage]
  driver = "overlay"
  runroot = "/var/run/containers/storage"
  graphroot = "/var/lib/containers/storage"
  [storage.options]
    additionalimagestores = []
    size = "8G"

    コンテナー内では、ルートパーティションが 8 GB であることを確認できます。

    出力例

    ~ $ df -h
Filesystem                Size      Used Available Use% Mounted on
overlay                   8.0G      8.0K      8.0G   0% /

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.