5.3. Linux コントロールグループバージョン 2 (cgroups v2) の有効化


マシン設定を使用して、クラスター内の特定ノードで Linux コントロールグループバージョン 2 (cgroups v2) を有効化できます。cgroups v2 を有効にする OpenShift Container Platform プロセスにより、cgroups バージョン 1 コントローラーおよび階層がすべて無効になります。

重要

OpenShift Container Platform cgroups バージョン 2 機能は Developer プレビューとして提供されており、現時点では Red Hat ではサポートされていません。

前提条件

  • バージョン 4.10 以降を使用する OpenShift Container Platform クラスターが実行中である。
  • 管理者権限を持つユーザーとしてクラスターにログインしている。
  • 設定するノードの node-role.kubernetes.io 値を把握している。

    $ oc describe node <node-name>

    出力例

    Name:               ci-ln-v05w5m2-72292-5s9ht-worker-a-r6fpg
    Roles:              worker
    Labels:             beta.kubernetes.io/arch=amd64
                        beta.kubernetes.io/instance-type=n1-standard-4
                        beta.kubernetes.io/os=linux
                        failure-domain.beta.kubernetes.io/region=us-central1
                        failure-domain.beta.kubernetes.io/zone=us-central1-a
                        kubernetes.io/arch=amd64
                        kubernetes.io/hostname=ci-ln-v05w5m2-72292-5s9ht-worker-a-r6fpg
                        kubernetes.io/os=linux
                        node-role.kubernetes.io/worker= 1
    #...

    1
    この値は、必要なノードロールです。

手順

  1. ノードで cgroups v2 を有効にします。

    • worker-cgroups-v2.yaml などのマシン設定ファイル YAML を作成します。

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: "worker" 1
        name: worker-enable-cgroups-v2
      spec:
        kernelArguments:
          - systemd.unified_cgroup_hierarchy=1 2
          - cgroup_no_v1="all" 3
      1
      設定するノードの node-role.kubernetes.io 値を指定します (例: masterworker、または infra)。
      2
      systemd で cgroups v2 を有効にします。
      3
      cgroups v1 を無効にします。
    • 新規のマシン設定を作成します。

      $ oc create -f worker-enable-cgroups-v2.yaml
  2. マシン設定で新規の追加内容を確認します。

    $ oc get MachineConfig

    出力例

    NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
    00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-master-ssh                                                                                 3.2.0             40m
    99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-worker-ssh                                                                                 3.2.0             40m
    rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    worker-enable-cgroups-v2                                                                      3.2.0             10s

  3. ノードを確認して、影響を受ける各ノードでスケジューリングが無効にされていることを確認します。これは、変更が適用されていることを示しています。

    $ oc get nodes

    出力例

    NAME                                       STATUS                     ROLES    AGE   VERSION
    ci-ln-fm1qnwt-72292-99kt6-master-0         Ready                      master   58m   v1.24.0
    ci-ln-fm1qnwt-72292-99kt6-master-1         Ready                      master   58m   v1.24.0
    ci-ln-fm1qnwt-72292-99kt6-master-2         Ready                      master   58m   v1.24.0
    ci-ln-fm1qnwt-72292-99kt6-worker-a-h5gt4   Ready,SchedulingDisabled   worker   48m   v1.24.0
    ci-ln-fm1qnwt-72292-99kt6-worker-b-7vtmd   Ready                      worker   48m   v1.24.0
    ci-ln-fm1qnwt-72292-99kt6-worker-c-rhzkv   Ready                      worker   48m   v1.24.0

  4. ノードが Ready 状態に戻ったら、sys/fs/cgroup/cgroup.controllers ファイルがノードに存在することを確認して、cgroups v2 が有効になっていることを確認できます。このファイルは cgroups v2 によって作成されます。

    • そのノードのデバッグセッションを開始します。

      $ oc debug node/<node_name>
    • sys/fs/cgroup/cgroup.controllers ファイルを探します。このファイルが存在する場合は、cgroups v2 がそのノードで有効になっています。

      出力例

      cgroup.controllers	cgroup.stat		cpuset.cpus.effective  io.stat		pids
      cgroup.max.depth	cgroup.subtree_control	cpuset.mems.effective  kubepods.slice	system.slice
      cgroup.max.descendants	cgroup.threads		init.scope	       memory.pressure	user.slice
      cgroup.procs		cpu.pressure		io.pressure	       memory.stat

関連情報

  • インストール時に cgroups v2 を有効にする方法は、インストールプロセスの Installation configuration parameters セクションの Optional parameters の表を参照してください。

5.3.1. リアルタイムカーネルのノードへの追加

一部の OpenShift Container Platform ワークロードには、高度な決定論的アプローチが必要になります。Linux はリアルタイムのオペレーティングシステムではありませんが、Linux のリアルタイムカーネルには、リアルタイムの特性を持つオペレーティングシステムを提供するプリエンプティブなスケジューラーが含まれます。

OpenShift Container Platform ワークロードでこれらのリアルタイムの特性が必要な場合、マシンを Linux のリアルタイムカーネルに切り替えることができます。OpenShift Container Platform 4.11 の場合、MachineConfig オブジェクトを使用してこの切り替えを行うことができます。変更はマシン設定の kernelType 設定を realtime に変更するだけで簡単に行えますが、この変更を行う前に他のいくつかの点を考慮する必要があります。

  • 現在、リアルタイムカーネルはワーカーノードでのみサポートされ、使用できるのはラジオアクセスネットワーク (RAN) のみになります。
  • 以下の手順は、Red Hat Enterprise Linux for Real Time 8 で認定されているシステムを使用したベアメタルのインストールで完全にサポートされます。
  • OpenShift Container Platform でのリアルタイムサポートは、特定のサブスクリプションに制限されます。
  • 以下の手順は、Google Cloud Platform での使用についてもサポートされます。

前提条件

  • OpenShift Container Platform クラスター (バージョン 4.4 以降) が実行中である。
  • 管理者権限を持つユーザーとしてクラスターにログインしている。

手順

  1. リアルタイムカーネルのマシン設定を作成します。realtime カーネルタイプの MachineConfig オブジェクトが含まれる YAML ファイル (99-worker-realtime.yaml など) を作成します。以下の例では、すべてのワーカーノードにリアルタイムカーネルを使用するようにクラスターに指示します。

    $ cat << EOF > 99-worker-realtime.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: "worker"
      name: 99-worker-realtime
    spec:
      kernelType: realtime
    EOF
  2. マシン設定をクラスターに追加します。以下を入力してマシン設定をクラスターに追加します。

    $ oc create -f 99-worker-realtime.yaml
  3. リアルタイムカーネルを確認します。影響を受けるそれぞれのノードの再起動後に、クラスターにログインして以下のコマンドを実行し、リアルタイムカーネルが設定されたノードのセットの通常のカーネルを置き換えていることを確認します。

    $ oc get nodes

    出力例

    NAME                                        STATUS  ROLES    AGE   VERSION
    ip-10-0-143-147.us-east-2.compute.internal  Ready   worker   103m  v1.24.0
    ip-10-0-146-92.us-east-2.compute.internal   Ready   worker   101m  v1.24.0
    ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.24.0

    $ oc debug node/ip-10-0-143-147.us-east-2.compute.internal

    出力例

    Starting pod/ip-10-0-143-147us-east-2computeinternal-debug ...
    To use host binaries, run `chroot /host`
    
    sh-4.4# uname -a
    Linux <worker_node> 4.18.0-147.3.1.rt24.96.el8_1.x86_64 #1 SMP PREEMPT RT
            Wed Nov 27 18:29:55 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

    カーネル名には rt が含まれ、PREEMPT RT のテキストは、これがリアルタイムカーネルであることを示します。

  4. 通常のカーネルに戻るには、MachineConfig オブジェクトを削除します。

    $ oc delete -f 99-worker-realtime.yaml

5.3.2. journald の設定

OpenShift Container Platform ノードで journald サービスの設定が必要な場合は、適切な設定ファイルを変更し、そのファイルをマシン設定としてノードの適切なプールに渡すことで実行できます。

この手順では、/etc/systemd/journald.conf ファイルの journald 速度制限の設定を変更し、それらをワーカーノードに適用する方法について説明します。このファイルの使用方法についての情報は、journald.conf man ページを参照してください。

前提条件

  • OpenShift Container Platform クラスターが実行中である。
  • 管理者権限を持つユーザーとしてクラスターにログインしている。

手順

  1. 必要な設定で /etc/systemd/journald.conf ファイルが含まれる Butane 設定ファイル 40-worker-custom -journald.bu を作成します。

    注記

    Butane の詳細は、Butane を使用したマシン設定の作成を参照してください。

    variant: openshift
    version: 4.11.0
    metadata:
      name: 40-worker-custom-journald
      labels:
        machineconfiguration.openshift.io/role: worker
    storage:
      files:
      - path: /etc/systemd/journald.conf
        mode: 0644
        overwrite: true
        contents:
          inline: |
            # Disable rate limiting
            RateLimitInterval=1s
            RateLimitBurst=10000
            Storage=volatile
            Compress=no
            MaxRetentionSec=30s
  2. Butane を使用して、ワーカーノードに配信される設定を含む MachineConfig オブジェクトファイル (40-worker-custom-journald.yaml) を生成します。

    $ butane 40-worker-custom-journald.bu -o 40-worker-custom-journald.yaml
  3. マシン設定をプールに適用します。

    $ oc apply -f 40-worker-custom-journald.yaml
  4. 新規マシン設定が適用され、ノードの状態が低下した状態にないことを確認します。これには数分の時間がかかる場合があります。各ノードで新規マシン設定が正常に適用されるため、ワーカープールには更新が進行中であることが表示されます。

    $ oc get machineconfigpool
    NAME   CONFIG             UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
    master rendered-master-35 True    False    False    3            3                 3                   0                    34m
    worker rendered-worker-d8 False   True     False    3            1                 1                   0                    34m
  5. 変更が適用されたことを確認するには、ワーカーノードにログインします。

    $ oc get node | grep worker
    ip-10-0-0-1.us-east-2.compute.internal   Ready    worker   39m   v0.0.0-master+$Format:%h$
    $ oc debug node/ip-10-0-0-1.us-east-2.compute.internal
    Starting pod/ip-10-0-141-142us-east-2computeinternal-debug ...
    ...
    sh-4.2# chroot /host
    sh-4.4# cat /etc/systemd/journald.conf
    # Disable rate limiting
    RateLimitInterval=1s
    RateLimitBurst=10000
    Storage=volatile
    Compress=no
    MaxRetentionSec=30s
    sh-4.4# exit

5.3.3. 拡張機能の RHCOS への追加

RHCOS はコンテナー指向の最小限の RHEL オペレーティングシステムであり、すべてのプラットフォームで OpenShift Container Platform クラスターに共通の機能セットを提供するように設計されています。ソフトウェアパッケージを RHCOS システムに追加することは一般的に推奨されていませんが、MCO は RHCOS ノードに最小限の機能セットを追加するために使用できる extensions 機能を提供します。

現時点で、以下の拡張機能が利用可能です。

  • usbguard: usbguard 拡張機能を追加すると、RHCOS システムを割り込みの USB デバイスから保護します。詳細は、USBGuard を参照してください。
  • kerberos: kerberos 拡張機能を追加すると、ユーザーとマシンの両方がネットワークに対して自分自身を識別し、管理者が設定したエリアとサービスへの定義済みの制限付きアクセスを取得できるメカニズムが提供されます。Kerberos クライアントのセットアップ方法や Kerberos 化された NFS 共有のマウント方法などの詳細は、Kerberos の使用 を参照してください。

以下の手順では、マシン設定を使用して 1 つ以上の拡張機能を RHCOS ノードに追加する方法を説明します。

前提条件

  • OpenShift Container Platform クラスター (バージョン 4.6 以降) が実行中である。
  • 管理者権限を持つユーザーとしてクラスターにログインしている。

手順

  1. 拡張機能のマシン設定を作成します。MachineConfig extensions オブジェクトが含まれる YAML ファイル (例: 80-extensions.yaml) を作成します。この例では、クラスターに対して usbguard 拡張機能を追加するように指示します。

    $ cat << EOF > 80-extensions.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 80-worker-extensions
    spec:
      config:
        ignition:
          version: 3.2.0
      extensions:
        - usbguard
    EOF
  2. マシン設定をクラスターに追加します。以下を入力してマシン設定をクラスターに追加します。

    $ oc create -f 80-extensions.yaml

    これにより、すべてのワーカーノードで usbguard の rpm パッケージがインストールされるように設定できます。

  3. 拡張機能が適用されていることを確認します。

    $ oc get machineconfig 80-worker-extensions

    出力例

    NAME                 GENERATEDBYCONTROLLER IGNITIONVERSION AGE
    80-worker-extensions                       3.2.0           57s

  4. 新規マシン設定が適用され、ノードの状態が低下した状態にないことを確認します。これには数分の時間がかかる場合があります。各マシンで新規マシン設定が正常に適用されるため、ワーカープールには更新が進行中であることが表示されます。

    $ oc get machineconfigpool

    出力例

    NAME   CONFIG             UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
    master rendered-master-35 True    False    False    3            3                 3                   0                    34m
    worker rendered-worker-d8 False   True     False    3            1                 1                   0                    34m

  5. 拡張機能を確認します。拡張機能が適用されたことを確認するには、以下を実行します。

    $ oc get node | grep worker

    出力例

    NAME                                        STATUS  ROLES    AGE   VERSION
    ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.24.0

    $ oc debug node/ip-10-0-169-2.us-east-2.compute.internal

    出力例

    ...
    To use host binaries, run `chroot /host`
    sh-4.4# chroot /host
    sh-4.4# rpm -q usbguard
    usbguard-0.7.4-4.el8.x86_64.rpm

5.3.4. マシン設定マニフェストでのカスタムファームウェアブロブの読み込み

/usr/lib 内のファームウェアブロブのデフォルトの場所は読み取り専用であるため、検索パスを更新して、カスタムファームウェアブロブを特定できます。これにより、ブロブが RHCOS によって管理されない場合に、マシン設定マニフェストでローカルファームウェアブロブを読み込むことができます。

手順

  1. Butane 設定ファイル 98-worker-firmware-blob.bu を作成します。このファイルは、root 所有でローカルストレージに書き込みできるように、検索パスを更新します。以下の例では、カスタムブロブファイルをローカルワークステーションからノードの /var/lib/firmware 下に配置しています。

    注記

    Butane の詳細は、Butane を使用したマシン設定の作成を参照してください。

    カスタムファームウェアブロブ用の Butane 設定ファイル

    variant: openshift
    version: 4.11.0
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 98-worker-firmware-blob
    storage:
      files:
      - path: /var/lib/firmware/<package_name> 1
        contents:
          local: <package_name> 2
        mode: 0644 3
    openshift:
      kernel_arguments:
        - 'firmware_class.path=/var/lib/firmware' 4

    1
    ファームウェアパッケージのコピー先となるノードのパスを設定します。
    2
    Butane を実行しているシステムのローカルファイルディレクトリーから読み取るコンテンツを含むファイルを指定します。ローカルファイルのパスは files-dir ディレクトリーからの相対パスで、以下の手順の Butane で --files-dir オプションを使用して指定する必要があります。
    3
    RHCOS ノードのファイルのパーミッションを設定します。0644 パーミッションを設定することが推奨されます。
    4
    firmware_class.path パラメーターは、ローカルワークステーションからノードのルートファイルシステムにコピーされたカスタムファームウェアブロブを検索するカーネルの検索パスをカスタマイズします。この例では、/var/lib/firmware をカスタマイズされたパスとして使用します。
  2. Butane を実行して、ローカルワークステーション上の98-worker-firmware-blob.yaml という名前のファームウェアブロブのコピーを使用する MachineConfig オブジェクトファイルを生成します。ファームウェアブロブには、ノードに配信される設定が含まれます。次の例では、--files-dir オプションを使用して、ローカルファイルが配置されるワークステーション上のディレクトリーを指定します。

    $ butane 98-worker-firmware-blob.bu -o 98-worker-firmware-blob.yaml --files-dir <directory_including_package_name>
  3. 以下の 2 つの方法のいずれかで、設定をノードに適用します。

    • クラスターがまだ起動していない場合は、マニフェストファイルを生成した後に、MachineConfig オブジェクトファイルを <installation_directory>/openshift ディレクトリーに追加してから、クラスターの作成を続行します。
    • クラスターがすでに実行中の場合は、ファイルを適用します。

      $ oc apply -f 98-worker-firmware-blob.yaml

      MachineConfig オブジェクト YAML ファイルは、マシンの設定を終了するために作成されます。

  4. 将来的に MachineConfig オブジェクトを更新する必要がある場合に備えて、Butane 設定を保存します。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.