インストール設定

手順

1. Butane イメージのダウンロードページ (https://mirror.openshift.com/pub/openshift-v4/clients/butane/) に移動してください。

2. butane バイナリーを取得します。

   1. 最新バージョンの Butane の場合は、最新の butane イメージを現在のディレクトリーに保存します。

      $ curl https://mirror.openshift.com/pub/openshift-v4/clients/butane/latest/butane --output butane

   2. オプション: aarch64 や ppc64le など、Butane をインストールする特定のタイプのアーキテクチャーの場合は、適切な URL を指定してください。以下に例を示します。

      $ curl https://mirror.openshift.com/pub/openshift-v4/clients/butane/latest/butane-aarch64 --output butane

3. ダウンロード済みのバイナリーファイルを実行可能にします。

   $ chmod +x butane

4. butane バイナリーファイルを PATH にあるディレクトリーに移動します。

   PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

   $ echo $PATH

手順

1. Butane 設定ファイルを作成します。以下の例では、99-worker-custom.bu という名前のファイルを作成します。このファイルは、カーネルデバッグメッセージを表示するようにシステムコンソールを設定し、chrony タイムサービスのカスタム設定を指定します。

   variant: openshift
   version: 4.13.0
   metadata:
     name: 99-worker-custom
     labels:
       machineconfiguration.openshift.io/role: worker
   openshift:
     kernel_arguments:
       - loglevel=7
   storage:
     files:
       - path: /etc/chrony.conf
         mode: 0644
         overwrite: true
         contents:
           inline: |
             pool 0.rhel.pool.ntp.org iburst
             driftfile /var/lib/chrony/drift
             makestep 1.0 3
             rtcsync
             logdir /var/log/chrony

   注記

   99-worker-custom.bu ファイルは、ワーカーノードのマシン設定を作成するように設定されます。コントロールプレーンノードにデプロイするには、ロールを worker から master に変更します。どちらの方法でも、デプロイメントの種類ごとに異なるファイル名を使用して手順全体を繰り返すことができます。

2. 直前の手順で作成したファイルを Butane に指定して MachineConfig オブジェクトを作成します。

   $ butane 99-worker-custom.bu -o ./99-worker-custom.yaml

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

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

4. クラスターがまだ起動していない場合は、マニフェストファイルを生成し、MachineConfig オブジェクト YAML ファイルを openshift ディレクトリーに追加します。クラスターがすでに実行中の場合は、ファイルを以下のように適用します。

   $ oc create -f 99-worker-custom.yaml

手順

1. RHEL 8 システムを登録します。

   # subscription-manager register

2. RHEL 8 システムにサブスクリプションを割り当てます。

   # subscription-manager attach --auto

3. ソフトウェアとコンテナーのビルドに必要なソフトウェアをインストールします。

   # yum install podman make git -y

4. kmod-via-containers リポジトリーのクローンを作成します。

   1. リポジトリーのフォルダーを作成します。

      $ mkdir kmods; cd kmods

   2. リポジトリーのクローンを作成します。

      $ git clone https://github.com/kmods-via-containers/kmods-via-containers

5. RHEL 8 ビルドホストに KVC フレームワークインスタンスをインストールし、モジュールをテストします。これにより、kmods-via-container systemd サービスが追加され、読み込まれます。

   1. kmod-via-containers ディレクトリーに移動します。

      $ cd kmods-via-containers/

   2. KVC フレームワークインスタンスをインストールします。

      $ sudo make install

   3. systemd マネージャー設定を再読み込みします。

      $ sudo systemctl daemon-reload

6. カーネルモジュールのソースコードを取得します。ソースコードは、制御下になく、他から提供されるサードパーティーモジュールをビルドするために使用される可能性があります。システムに対してクローン作成できる以下の kvc-simple-kmod サンプルのコンテンツと同様のコンテンツが必要になります。

   $ cd .. ; git clone https://github.com/kmods-via-containers/kvc-simple-kmod

7. この例では、設定ファイル simple-kmod.conf を編集し、Dockerfile の名前を Dockerfile.rhel に変更します。

   1. kvc-simple-kmod ディレクトリーに移動します。

      $ cd kvc-simple-kmod

   2. Dockerfile の名前を変更します。

      $ cat simple-kmod.conf

      Dockerfile の例

      KMOD_CONTAINER_BUILD_CONTEXT="https://github.com/kmods-via-containers/kvc-simple-kmod.git"
      KMOD_CONTAINER_BUILD_FILE=Dockerfile.rhel
      KMOD_SOFTWARE_VERSION=dd1a7d4
      KMOD_NAMES="simple-kmod simple-procfs-kmod"

8. この例ではカーネルモジュール simple-kmod の kmods-via-containers@.service のインスタンスを作成します。

   $ sudo make install

9. kmods-via-containers@.service インスタンスを有効にします。

   $ sudo kmods-via-containers build simple-kmod $(uname -r)

10. systemd サービスを有効にし、起動します。

    $ sudo systemctl enable kmods-via-containers@simple-kmod.service --now

    1. サービスのステータスを確認します。

       $ sudo systemctl status kmods-via-containers@simple-kmod.service

       出力例

       ● kmods-via-containers@simple-kmod.service - Kmods Via Containers - simple-kmod
          Loaded: loaded (/etc/systemd/system/kmods-via-containers@.service;
                 enabled; vendor preset: disabled)
          Active: active (exited) since Sun 2020-01-12 23:49:49 EST; 5s ago...

11. カーネルモジュールがロードされていることを確認するには、lsmod コマンドを使用してモジュールをリスト表示します。

    $ lsmod | grep simple_

    出力例

    simple_procfs_kmod     16384  0
    simple_kmod            16384  0

12. オプション: 他の方法を使用して simple-kmod のサンプルが機能していることを確認します。

    • dmesg を使用してカーネルリングバッファーで "Hello world" メッセージを探します。

      $ dmesg | grep 'Hello world'

      出力例

      [ 6420.761332] Hello world from simple_kmod.

    • /proc で simple-procfs-kmod の値を確認します。

      $ sudo cat /proc/simple-procfs-kmod

      出力例

      simple-procfs-kmod number = 0

    • spkut コマンドを実行して、モジュールの詳細情報を取得します。

      $ sudo spkut 44

      出力例

      KVC: wrapper simple-kmod for 4.18.0-147.3.1.el8_1.x86_64
      Running userspace wrapper using the kernel module container...
      + podman run -i --rm --privileged
         simple-kmod-dd1a7d4:4.18.0-147.3.1.el8_1.x86_64 spkut 44
      simple-procfs-kmod number = 0
      simple-procfs-kmod number = 44

手順

1. TPM v2 を使用してクラスターを暗号化する必要がある場合は、TPM v2 暗号化を各ノードのホストファームウェアで有効にする必要があるかどうかを確認します。これは、ほとんどの Dell システムで必要になります。特定のシステムのマニュアルを確認してください。

2. Tang を使用してクラスターを暗号化する必要がある場合は、以下の準備段階の手順に従います。

   1. Tang サーバーを設定するか、既存のサーバーにアクセスします。手順は、Network-bound disk encryption を参照してください。

   2. RHEL 8 マシンに clevis パッケージがインストールされていない場合はインストールします。

      $ sudo yum install clevis

   3. RHEL 8 マシンで以下のコマンドを実行し、交換キーのサムプリントを生成します。http://tang.example.com:7500 を Tang サーバーの URL に置き換えます。

      $ clevis-encrypt-tang '{"url":"http://tang.example.com:7500"}' < /dev/null > /dev/null 

      1

      1 1

      この例では、tangd.socket は Tang サーバーのポート 7500 でリッスンしています。

      注記

      clevis-encrypt-tang コマンドは、交換キーの拇印を生成します。このステップでは、データは暗号化コマンドに渡されません。/dev/null は、プレーンテキストの代わりに入力としてここに存在します。この手順には必要ないため、暗号化された出力は /dev/null に送信されます。

      出力例

      The advertisement contains the following signing keys:
      
      PLjNyRdGw03zlRoGjQYMahSZGu9 

      1

      エクスチェンジキーのサムプリント。

      Do you wish to trust these keys? [ynYN] のプロンプトが表示されたら、Y と入力します。

   4. ノードが静的 IP アドレス指定で設定されている場合は、RHCOS ノードをインストールするときに coreos-installer iso customize --dest-karg-append を実行するか、coreos-installer --append-karg オプションを使用して、インストール済みシステムの IP アドレスを設定します。ネットワークに必要な ip= およびその他の引数を追加します。

      重要

      一部の静的 IP の設定方法は、初回のブート後に initramfs に影響を与えず、Tang 暗号化では機能しない場合があります。これらには、coreos-installer --copy-network オプション、coreos-installer iso customize --network-keyfile オプション、および coreos-installer pxe customize --network-keyfile オプションが含まれるほか、インストール中のライブ ISO または PXE イメージのカーネルコマンドラインに ip= 引数が追加されます。静的 IP 設定が間違っていると、ノードの 2 回目のブートが失敗します。

3. インストールノードで、インストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。

   $ ./openshift-install create manifests --dir <installation_directory> 

   1

   1

   <installation_directory> は、インストールファイルを保存するディレクトリーへのパスに置き換えます。

4. ディスクの暗号化、ミラーリング、またはそれら両方を設定する Butane 設定を作成します。たとえば、コンピュートノードのストレージを設定するには、$HOME/clusterconfig/worker-storage.bu ファイルを作成します。

   起動デバイスの Butane 設定例

   variant: openshift
   version: 4.13.0
   metadata:
     name: worker-storage 

   1

   
     labels:
       machineconfiguration.openshift.io/role: worker 

   2

   
   boot_device:
     layout: x86_64 

   3

   
     luks: 

   4

   
       tpm2: true 

   5

   
       tang: 

   6

   
         - url: http://tang.example.com:7500 

   7

   
           thumbprint: PLjNyRdGw03zlRoGjQYMahSZGu9 

   8

   
       threshold: 1 

   9

   
     mirror: 

   10

   
       devices: 

   11

   
         - /dev/sda
         - /dev/sdb
   openshift:
     fips: true 

   12

   1 2

   コントロールプレーンの設定は、これらの両方の場所で worker を master に置き換えます。

   3

   このフィールドをクラスターノードの命令セットアーキテクチャーに設定します。いくつかの例には、x86_64、aarch64、または ppc64le が含まれます。

   4

   ルートファイルシステムを暗号化する必要がある場合は、このセクションを追加してください。詳細は、「ディスクの暗号化について」を参照してください。

   5

   Trusted Platform Module (TPM) を使用してルートファイルシステムを暗号化する場合は、このフィールドを追加してください。

   6

   1 台以上の Tang サーバーを使用する必要がある場合は、このセクションを追加してください。

   7

   Tang サーバーの URL を指定します。この例では、tangd.socket は Tang サーバーのポート 7500 でリッスンしています。

   8

   前述のステップで生成された Exchange キーサムプリントを指定します。

   9

   復号化に実行に必要な TPM v2 および Tang 暗号化条件の最小数を指定します。デフォルト値は 1 です。このトピックの詳細は、「暗号化しきい値の設定」を参照してください。

   10

   ブートディスクをミラーリングする必要がある場合は、このセクションを追加してください。詳細は、「ディスクのミラーリングについて」を参照してください。

   11

   RHCOS がインストールされるディスクを含む、ブートディスクミラーに含まれる必要があるすべてのディスクデバイスを一覧表示します。

   12

   クラスターで FIPS モードを有効にするためにこのディレクティブを追加します。

   重要

   OpenShift Container Platform 4.13 は Red Hat Enterprise Linux (RHEL) 9.2 をベースにしています。FIPS 検証用に RHEL 9.2 暗号化モジュールがまだ送信されていません。詳細は、4.13 OpenShift Container Platform リリースノート の "About this release" を参照してください。

   重要

   ノードをディスク暗号化とミラーリングの両方を使用するように設定する場合、両方の機能を同じ Butane 設定に設定する必要があります。

5. 対応する Butane 設定からコントロールプレーンまたはコンピュートノードのマニフェストを作成し、<installation_directory>/openshift ディレクトリーに保存します。たとえば、コンピュートノードのマニフェストを作成するには、以下のコマンドを実行します。

   $ butane $HOME/clusterconfig/worker-storage.bu -o <installation_directory>/openshift/99-worker-storage.yaml

   ディスクの暗号化またはミラーリングを必要とするノード種別ごとに、この手順を繰り返します。

6. 今後マニフェストを更新する必要がある場合には、Butane 設定を保存します。

7. 残りの OpenShift Container Platform インストールを継続します。

   ヒント

   インストール時に、ディスク暗号化またはミラーリングに関連するエラーメッセージがないか、RHCOS ノードでコンソールログをモニタリングできます。

   重要

   追加のデータパーティションを設定する場合、暗号化が明示的に要求されない限り、それらは暗号化されません。

1. インストールホストから、デバッグ Pod を使用してクラスターノードにアクセスします。

   1. ノードのデバッグ Pod を開始します。次に例を示します。

      $ oc debug node/compute-1

   2. /host をデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の /host にノードのルートファイルシステムをマウントします。root ディレクトリーを /host に変更すると、ノードの実行可能パスに含まれるバイナリーを実行できます。

      # chroot /host

      注記

      Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Container Platform クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されません。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合は、oc 操作がその影響を受けます。この場合は、代わりに ssh core@<node>.<cluster_name>.<base_domain> を使用してノードにアクセスできます。

2. ブートディスクの暗号化を設定している場合は、有効であるかどうかを確認します。

   1. デバッグシェルで、ノードでのルートマッピングのステータスを確認します。

      # cryptsetup status root

      出力例

      /dev/mapper/root is active and is in use.
        type:    LUKS2 

      1

      
        cipher:  aes-xts-plain64 

      2

      
        keysize: 512 bits
        key location: keyring
        device:  /dev/sda4 

      3

      
        sector size:  512
        offset:  32768 sectors
        size:    15683456 sectors
        mode:    read/write

      1

      暗号化形式。TPM v2 または Tang 暗号化モードを有効にすると、RHCOS ブートディスクは LUKS2 形式を使用して暗号化されます。

      2

      LUKS2 ボリュームの暗号化に使用される暗号化アルゴリズム。

      3

      暗号化した LUKS2 ボリュームを含むデバイス。ミラーリングを有効にすると、値は /dev/md126 などのソフトウェアミラーデバイスを表します。

   2. 暗号化されたデバイスにバインドされる Clevis プラグインを一覧表示します。

      # clevis luks list -d /dev/sda4 

      1

      1 1

      前述のステップの出力の device フィールドに一覧表示されるデバイスを指定します。

      出力例

      1: sss '{"t":1,"pins":{"tang":[{"url":"http://tang.example.com:7500"}]}}' 

      1

      この出力例では、Tang プラグインは、/dev/sda4 デバイスの Shamir の Secret Sharing (SSS) Clevis プラグインにより使用されます。

3. ミラーリングを設定している場合は、有効かどうかを確認します。

   1. デバッグシェルから、ノードにあるソフトウェアの RAID デバイスのリストを表示します。

      # cat /proc/mdstat

      出力例

      Personalities : [raid1]
      md126 : active raid1 sdb3[1] sda3[0] 

      1

      
      	  393152 blocks super 1.0 [2/2] [UU]
      
      md127 : active raid1 sda4[0] sdb4[1] 

      2

      
      	  51869632 blocks super 1.2 [2/2] [UU]
      
      unused devices: <none>

      1

      /dev/md126 ソフトウェア RAID ミラーデバイスは、クラスターノードの /dev/sda3 および /dev/sdb3 ディスクデバイスを使用します。

      2

      /dev/md127 ソフトウェア RAID ミラーデバイスは、クラスターノードの /dev/sda4 および /dev/sdb4 ディスクデバイスを使用します。

   2. 上記のコマンドの出力に記載されている各ソフトウェア RAID デバイスの詳細を確認してください。以下の例は、/dev/md126 デバイスの詳細を示しています。

      # mdadm --detail /dev/md126

      出力例

      /dev/md126:
                 Version : 1.0
           Creation Time : Wed Jul  7 11:07:36 2021
              Raid Level : raid1 

      1

      
              Array Size : 393152 (383.94 MiB 402.59 MB)
           Used Dev Size : 393152 (383.94 MiB 402.59 MB)
            Raid Devices : 2
           Total Devices : 2
             Persistence : Superblock is persistent
      
             Update Time : Wed Jul  7 11:18:24 2021
                   State : clean 

      2

      
          Active Devices : 2 

      3

      
         Working Devices : 2 

      4

      
          Failed Devices : 0 

      5

      
           Spare Devices : 0
      
      Consistency Policy : resync
      
                    Name : any:md-boot 

      6

      
                    UUID : ccfa3801:c520e0b5:2bee2755:69043055
                  Events : 19
      
          Number   Major   Minor   RaidDevice State
             0     252        3        0      active sync   /dev/sda3 

      7

      
             1     252       19        1      active sync   /dev/sdb3 

      8

      1

      デバイスの RAID レベルを指定します。raid1 は、RAID 1 ディスクミラーリングを示します。

      2

      RAID デバイスの状態を指定します。

      3 4

      アクティブかつ機能している基礎となるディスクデバイスの数を示します。

      5

      ステータスが failed のディスクデバイスの数を示します。

      6

      ソフトウェア RAID デバイスの名前。

      7 8

      ソフトウェア RAID デバイスが使用する基礎となるディスクデバイスに関する情報を提供します。

   3. ソフトウェア RAID デバイスにマウントされているファイルシステムを一覧表示します。

      # mount | grep /dev/md

      出力例

      /dev/md127 on / type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /etc type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /usr type xfs (ro,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /sysroot type xfs (ro,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /var type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /var/lib/containers/storage/overlay type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/1 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/2 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/3 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/4 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/5 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md126 on /boot type ext4 (rw,relatime,seclabel)

      この出力例では、/boot ファイルシステムが /dev/md126 software RAID デバイスに、root ファイルシステムが /dev/md127 にマウントされています。

4. OpenShift Container Platform ノードタイプごとに検証手順を繰り返します。

手順

1. ソフトウェア RAID を使用してデータボリュームを設定する Butane 設定を作成します。

   • ミラーリングされた起動ディスクに使用されるのと同じディスク上に RAID 1 を使用してデータボリュームを設定するには、$HOME/clusterconfig/raid1-storage.bu ファイルを作成します。以下に例を示します。

     ミラーリングされた起動ディスク上の RAID 1

     variant: openshift
     version: 4.13.0
     metadata:
       name: raid1-storage
       labels:
         machineconfiguration.openshift.io/role: worker
     boot_device:
       mirror:
         devices:
           - /dev/disk/by-id/scsi-3600508b400105e210000900000490000
           - /dev/disk/by-id/scsi-SSEAGATE_ST373453LW_3HW1RHM6
     storage:
       disks:
         - device: /dev/disk/by-id/scsi-3600508b400105e210000900000490000
           partitions:
             - label: root-1
               size_mib: 25000 

     1

     
             - label: var-1
         - device: /dev/disk/by-id/scsi-SSEAGATE_ST373453LW_3HW1RHM6
           partitions:
             - label: root-2
               size_mib: 25000 

     2

     
             - label: var-2
       raid:
         - name: md-var
           level: raid1
           devices:
             - /dev/disk/by-partlabel/var-1
             - /dev/disk/by-partlabel/var-2
       filesystems:
         - device: /dev/md/md-var
           path: /var
           format: xfs
           wipe_filesystem: true
           with_mount_unit: true

     1 2

     データパーティションをブートディスクに追加する場合は、25000 のメビバイトの最小値が推奨されます。値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合は、生成されるルートファイルシステムのサイズが小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。

   • セカンダリーディスク上に RAID 1 を使用してデータボリュームを設定するには、$HOME/clusterconfig/raid1-alt-storage.bu ファイルを作成します。以下に例を示します。

     セカンダリーディスク上の RAID 1

     variant: openshift
     version: 4.13.0
     metadata:
       name: raid1-alt-storage
       labels:
         machineconfiguration.openshift.io/role: worker
     storage:
       disks:
         - device: /dev/sdc
           wipe_table: true
           partitions:
             - label: data-1
         - device: /dev/sdd
           wipe_table: true
           partitions:
             - label: data-2
       raid:
         - name: md-var-lib-containers
           level: raid1
           devices:
             - /dev/disk/by-partlabel/data-1
             - /dev/disk/by-partlabel/data-2
       filesystems:
         - device: /dev/md/md-var-lib-containers
           path: /var/lib/containers
           format: xfs
           wipe_filesystem: true
           with_mount_unit: true

2. 前のステップで作成した Butane 設定から RAID マニフェストを作成し、それを <installation_directory>/openshift ディレクトリーに保存します。たとえば、コンピュートノードのマニフェストを作成するには、以下のコマンドを実行します。

   $ butane $HOME/clusterconfig/<butane_config>.bu -o <installation_directory>/openshift/<manifest_name>.yaml 

   1

   1

   <butane_config> および <manifest_name> を直前の手順のファイル名に置き換えます。たとえば、セカンダリーディスクの場合は、raid1-alt-storage.bu および raid1-alt-storage.yaml になります。

3. 今後マニフェストを更新する必要がある場合には、Butane 設定を保存します。
4. 残りの OpenShift Container Platform インストールを継続します。