6.2. RHCOS コンピュートマシンの OpenShift Container Platform クラスターへの追加

ベアメタルの OpenShift Container Platform クラスターに Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートマシンを追加することができます。

ベアメタルインフラストラクチャーにインストールされているクラスターにコンピュートマシンを追加する前に、それが使用する RHCOS マシンを作成する必要があります。ISO イメージまたはネットワーク PXE ブートを使用してマシンを作成できます。

6.2.1. 前提条件

クラスターをベアメタルにインストールしている。
クラスターの作成に使用したインストールメディアおよび Red Hat Enterprise Linux CoreOS (RHCOS) イメージがある。これらのファイルがない場合は、インストール手順に従ってこれらを取得する必要があります。

6.2.2. ISO イメージを使用した RHCOS マシンの作成

ISO イメージを使用して、ベアメタルクラスターの追加の Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートマシンを作成できます。

前提条件

クラスターのコンピュートマシンの Ignition 設定ファイルの URL を取得します。このファイルがインストール時に HTTP サーバーにアップロードされている必要があります。
OpenShift CLI (oc) がインストールされている。

手順

次のコマンドを実行して、クラスターから Ignition 設定ファイルを抽出します。
```
$ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
```
クラスターからエクスポートした worker.ign Ignition 設定ファイルを HTTP サーバーにアップロードします。これらのファイルの URL をメモします。
Ignition ファイルが URL で利用可能であることを検証できます。次の例では、コンピュートノードの Ignition 設定ファイルを取得します。
```
$ curl -k http://<HTTP_server>/worker.ign
```

次のコマンドを実行すると、新しいマシンを起動するための ISO イメージにアクセスできます。

RHCOS_VHD_ORIGIN_URL=$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.<architecture>.artifacts.metal.formats.iso.disk.location')

ISO ファイルを使用して、追加のコンピュートマシンに RHCOS をインストールします。クラスターのインストール前にマシンを作成する際に使用したのと同じ方法を使用します。
- ディスクに ISO イメージを書き込み、これを直接起動します。
- LOM インターフェイスで ISO リダイレクトを使用します。
オプションを指定したり、ライブ起動シーケンスを中断したりせずに、RHCOS ISO イメージを起動します。インストーラーが RHCOS ライブ環境でシェルプロンプトを起動するのを待ちます。
注記
RHCOS インストールの起動プロセスを中断して、カーネル引数を追加できます。ただし、この ISO 手順では、カーネル引数を追加する代わりに、次の手順で概説するように coreos-installer コマンドを使用する必要があります。
coreos-installer コマンドを実行し、インストール要件を満たすオプションを指定します。少なくとも、ノードタイプの Ignition 設定ファイルを参照する URL と、インストール先のデバイスを指定する必要があります。
```
$ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> --ignition-hash=sha512-<digest> 12
```
1
コア ユーザーにはインストールを実行するために必要な root 権限がないため、sudo を使用して coreos-installer コマンドを実行する必要があります。
2
--ignition-hash オプションは、Ignition 設定ファイルを HTTP URL を使用して取得し、クラスターノードの Ignition 設定ファイルの信頼性を検証するために必要です。<digest> は、先の手順で取得した Ignition 設定ファイル SHA512 ダイジェストです。
注記
TLS を使用する HTTPS サーバーを使用して Ignition 設定ファイルを提供する場合は、coreos-installer を実行する前に、内部認証局 (CA) をシステムのトラストストアに追加できます。
以下の例では、/dev/sda デバイスへのブートストラップノードのインストールを初期化します。ブートストラップノードの Ignition 設定ファイルは、IP アドレス 192.168.1.2 で HTTP Web サーバーから取得されます。
```
$ sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b
```
マシンのコンソールで RHCOS インストールの進捗を監視します。
重要
OpenShift Container Platform のインストールを開始する前に、各ノードでインストールが成功していることを確認します。インストールプロセスを監視すると、発生する可能性のある RHCOS インストールの問題の原因を特定する上でも役立ちます。
継続してクラスター用の追加のコンピュートマシンを作成します。

6.2.3. PXE または iPXE ブートによる RHCOS マシンの作成

PXE または iPXE ブートを使用して、ベアメタルクラスターの追加の Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートマシンを作成できます。

前提条件

クラスターのコンピュートマシンの Ignition 設定ファイルの URL を取得します。このファイルがインストール時に HTTP サーバーにアップロードされている必要があります。
クラスターのインストール時に HTTP サーバーにアップロードした RHCOS ISO イメージ、圧縮されたメタル BIOS、kernel、および initramfs ファイルの URL を取得します。
インストール時に OpenShift Container Platform クラスターのマシンを作成するために使用した PXE ブートインフラストラクチャーにアクセスできる必要があります。RHCOS のインストール後にマシンはローカルディスクから起動する必要があります。
UEFI を使用する場合、OpenShift Container Platform のインストール時に変更した grub.conf ファイルにアクセスできます。

手順

RHCOS イメージの PXE または iPXE インストールが正常に行われていることを確認します。
- PXE の場合:
```
DEFAULT pxeboot
TIMEOUT 20
PROMPT 0
LABEL pxeboot
    KERNEL http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> 1
    APPEND initrd=http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img 2
```
  1
  HTTP サーバーにアップロードしたライブ kernel ファイルの場所を指定します。
  2
  HTTP サーバーにアップロードした RHCOS ファイルの場所を指定します。initrd パラメーターはライブ initramfs ファイルの場所であり、coreos.inst.ignition_url パラメーター値はワーカー Ignition 設定ファイルの場所であり、coreos.live.rootfs_url パラメーター値はライブ rootfs ファイルの場所になります。coreos.inst.ignition_url および coreos.live.rootfs_url パラメーターは HTTP および HTTPS のみをサポートします。
  注記
  この設定では、グラフィカルコンソールを使用するマシンでシリアルコンソールアクセスを有効にしません。別のコンソールを設定するには、APPEND 行に 1 つ以上の console= 引数を追加します。たとえば、console=tty0 console=ttyS0 を追加して、最初の PC シリアルポートをプライマリーコンソールとして、グラフィカルコンソールをセカンダリーコンソールとして設定します。詳細は、How does one set up a serial terminal and/or console in Red Hat Enterprise Linux? を参照してください。
- iPXE (x86_ 64 + aarch64):
```
kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2
initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img 3
boot
```
  1
  HTTP サーバーにアップロードした RHCOS ファイルの場所を指定します。kernel パラメーター値は kernel ファイルの場所であり、initrd=main 引数は UEFI システムでの起動に必要であり、coreos.live.rootfs_url パラメーター値はワーカー Ignition 設定ファイルの場所であり、coreos.inst.ignition_url パラメーター値は rootfs のライブファイルの場所です。
  2
  複数の NIC を使用する場合、ip オプションに単一インターフェイスを指定します。たとえば、eno1 という名前の NIC で DHCP を使用するには、ip=eno1:dhcp を設定します。
  3
  HTTP サーバーにアップロードした initramfs ファイルの場所を指定します。
  注記
  この設定では、グラフィカルコンソールを備えたマシンでのシリアルコンソールアクセスは有効になりません。別のコンソールを設定するには、kernel 行に 1 つ以上の console= 引数を追加します。たとえば、console=tty0 console=ttyS0 を追加して、最初の PC シリアルポートをプライマリーコンソールとして、グラフィカルコンソールをセカンダリーコンソールとして設定します。詳細は、How does one set up a serial terminal and/or console in Red Hat Enterprise Linux? と、「高度な RHCOS インストール設定」セクションの「PXE および ISO インストール用シリアルコンソールの有効化」を参照してください。
  注記
  aarch64 アーキテクチャーで CoreOS kernel をネットワークブートするには、IMAGE_GZIP オプションが有効になっているバージョンの iPXE ビルドを使用する必要があります。iPXE の IMAGE_GZIP オプションを参照してください。
- aarch64 上の PXE (第 2 段階として UEFI および GRUB を使用) の場合:
```
menuentry 'Install CoreOS' {
    linux rhcos-<version>-live-kernel-<architecture>  coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2
    initrd rhcos-<version>-live-initramfs.<architecture>.img 3
}
```
  1
  HTTP/TFTP サーバーにアップロードした RHCOS ファイルの場所を指定します。kernel パラメーター値は、TFTP サーバー上の kernel ファイルの場所になります。coreos.live.rootfs_url パラメーター値は rootfs ファイルの場所であり、coreos.inst.ignition_url パラメーター値は HTTP サーバー上のブートストラップ Ignition 設定ファイルの場所になります。
  2
  複数の NIC を使用する場合、ip オプションに単一インターフェイスを指定します。たとえば、eno1 という名前の NIC で DHCP を使用するには、ip=eno1:dhcp を設定します。
  3
  TFTP サーバーにアップロードした initramfs ファイルの場所を指定します。
PXE または iPXE インフラストラクチャーを使用して、クラスターに必要なコンピュートマシンを作成します。

6.2.4. マシンの証明書署名要求の承認

マシンをクラスターに追加する際に、追加したそれぞれのマシンについて 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。

前提条件

マシンがクラスターに追加されています。

手順

クラスターがマシンを認識していることを確認します。
```
$ oc get nodes
```
出力例
```
NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.29.4
master-1  Ready     master  63m  v1.29.4
master-2  Ready     master  64m  v1.29.4
```
出力には作成したすべてのマシンがリスト表示されます。
注記
上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。
保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。
```
$ oc get csr
```
出力例
```
NAME        AGE     REQUESTOR                                                                   CONDITION
csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
...
```
この例では、2 つのマシンがクラスターに参加しています。このリストにはさらに多くの承認された CSR が表示される可能性があります。
追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。
注記
CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に machine-approver によって自動的に承認されます。
注記
ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、oc exec、oc rsh、および oc logs コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR が system:node または system:admin グループの node-bootstrapper サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。
- それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。
```
$ oc adm certificate approve <csr_name> 1
```
  1
  <csr_name> は、現行の CSR のリストからの CSR の名前です。
- すべての保留中の CSR を承認するには、以下のコマンドを実行します。
```
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
```
  注記
  一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。

クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。

$ oc get csr

出力例

NAME        AGE     REQUESTOR                                                                   CONDITION
csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
...

残りの CSR が承認されず、それらが Pending ステータスにある場合、クラスターマシンの CSR を承認します。
- それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。
```
$ oc adm certificate approve <csr_name> 1
```
  1
  <csr_name> は、現行の CSR のリストからの CSR の名前です。
- すべての保留中の CSR を承認するには、以下のコマンドを実行します。
```
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
```
すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。
```
$ oc get nodes
```
出力例
```
NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.29.4
master-1  Ready     master  73m  v1.29.4
master-2  Ready     master  74m  v1.29.4
worker-0  Ready     worker  11m  v1.29.4
worker-1  Ready     worker  11m  v1.29.4
```
注記
サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。

関連情報

CSR の詳細は、Certificate Signing Requests を参照してください。

6.2.5. AWS でのカスタム `/var` パーティションを持つ新規 RHCOS ワーカーノードの追加

OpenShift Container Platform は、ブートストラップ時に処理されるマシン設定を使用したインストール時のデバイスのパーティション設定をサポートします。ただし、/var パーティション設定を使用する場合は、デバイス名はインストール時に決定する必要があり、変更することはできません。デバイス命名スキーマが異なる場合は、異なるインスタンスタイプをノードとして追加することはできません。たとえば、m4.large インスタンスにデフォルトの AWS デバイス名 (dev/xvdb) で/var パーティションを設定した場合、m5.large インスタンスはデフォルトで /dev/nvme1n1 デバイスを使用するため、直接 AWS m5.large インスタンスを追加することはできません。異なる命名スキーマにより、デバイスはパーティション設定に失敗する可能性があります。

本セクションの手順では、インストール時に設定したものとは異なるデバイス名を使用するインスタンスと共に、新規の Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートノードを追加する方法を説明します。カスタムユーザーデータシークレットを作成し、新規コンピュートマシンセットを設定します。これらの手順は AWS クラスターに固有のものです。この原則は、他のクラウドデプロイメントにも適用されます。ただし、デバイスの命名スキーマは他のデプロイメントでは異なり、ケースごとに決定する必要があります。

手順

コマンドラインで、openshift-machine-api namespace に移動します。
```
$ oc project openshift-machine-api
```
worker-user-data シークレットから新規シークレットを作成します。
1. シークレットの userData セクションをテキストファイルにエクスポートします。
```
$ oc get secret worker-user-data --template='{{index .data.userData | base64decode}}' | jq > userData.txt
```
2. テキストファイルを編集して、新規ノードに使用するパーティションの storage、filesystems、および systemd スタンザを追加します。必要に応じて Ignition 設定パラメーターを指定できます。
  注記
  ignition スタンザの値は変更しないでください。
```
{
  "ignition": {
    "config": {
      "merge": [
        {
          "source": "https:...."
        }
      ]
    },
    "security": {
      "tls": {
        "certificateAuthorities": [
          {
            "source": "data:text/plain;charset=utf-8;base64,.....=="
          }
        ]
      }
    },
    "version": "3.2.0"
  },
  "storage": {
    "disks": [
      {
        "device": "/dev/nvme1n1", 1
        "partitions": [
          {
            "label": "var",
            "sizeMiB": 50000, 2
            "startMiB": 0 3
          }
        ]
      }
    ],
    "filesystems": [
      {
        "device": "/dev/disk/by-partlabel/var", 4
        "format": "xfs", 5
        "path": "/var" 6
      }
    ]
  },
  "systemd": {
    "units": [ 7
      {
        "contents": "[Unit]\nBefore=local-fs.target\n[Mount]\nWhere=/var\nWhat=/dev/disk/by-partlabel/var\nOptions=defaults,pquota\n[Install]\nWantedBy=local-fs.target\n",
        "enabled": true,
        "name": "var.mount"
      }
    ]
  }
}
```
  1
  AWS ブロックデバイスへの絶対パスを指定します。
  2
  データパーティションのサイズをメビバイト単位で指定します。
  3
  メビバイト単位でパーティションの開始点を指定します。データパーティションをブートディスクに追加する場合は、最小値の 25000 MB (メビバイト) が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。
  4
  /var パーティションへの絶対パスを指定します。
  5
  ファイルシステムのフォーマットを指定します。
  6
  Ignition がルートファイルシステムがマウントされる場所に対して相対的な場所で実行される、ファイルシステムのマウントポイントを指定します。これは実際のルートにマウントする場所と同じである必要はありませんが、同じにすることが推奨されます。
  7
  /dev/disk/by-partlabel/var デバイスを /var パーティションにマウントする systemd マウントユニットを定義します。
3. disableTemplating セクションを work-user-data シークレットからテキストファイルに展開します。
```
$ oc get secret worker-user-data --template='{{index .data.disableTemplating | base64decode}}' | jq > disableTemplating.txt
```
4. 2 つのテキストファイルから新しいユーザーデータのシークレットファイルを作成します。このユーザーデータのシークレットは、userData.txt ファイルの追加のノードパーティション情報を新規作成されたノードに渡します。
```
$ oc create secret generic worker-user-data-x5 --from-file=userData=userData.txt --from-file=disableTemplating=disableTemplating.txt
```

新規ノードの新規コンピュートマシンセットを作成します。

AWS 向けに設定される新規のコンピュートマシンセット YAML ファイルを、以下のように作成します。必要なパーティションおよび新規に作成されたユーザーデータシークレットを追加します。

ヒント

既存のコンピュートマシンセットをテンプレートとして使用し、新規ノード用に必要に応じてパラメーターを変更します。

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: auto-52-92tf4
  name: worker-us-east-2-nvme1n1 1
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: auto-52-92tf4
      machine.openshift.io/cluster-api-machineset: auto-52-92tf4-worker-us-east-2b
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: auto-52-92tf4
        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: auto-52-92tf4-worker-us-east-2b
    spec:
      metadata: {}
      providerSpec:
        value:
          ami:
            id: ami-0c2dbd95931a
          apiVersion: awsproviderconfig.openshift.io/v1beta1
          blockDevices:
          - DeviceName: /dev/nvme1n1 2
            ebs:
              encrypted: true
              iops: 0
              volumeSize: 120
              volumeType: gp2
          - DeviceName: /dev/nvme1n2 3
            ebs:
              encrypted: true
              iops: 0
              volumeSize: 50
              volumeType: gp2
          credentialsSecret:
            name: aws-cloud-credentials
          deviceIndex: 0
          iamInstanceProfile:
            id: auto-52-92tf4-worker-profile
          instanceType: m6i.large
          kind: AWSMachineProviderConfig
          metadata:
            creationTimestamp: null
          placement:
            availabilityZone: us-east-2b
            region: us-east-2
          securityGroups:
          - filters:
            - name: tag:Name
              values:
              - auto-52-92tf4-worker-sg
          subnet:
            id: subnet-07a90e5db1
          tags:
          - name: kubernetes.io/cluster/auto-52-92tf4
            value: owned
          userDataSecret:
            name: worker-user-data-x5 4

1: 新規ノードの名前を指定します。
2: AWS ブロックデバイスへの絶対パスを指定します (ここでは暗号化された EBS ボリューム)。
3: オプション: 追加の EBS ボリュームを指定します。
4: ユーザーデータシークレットファイルを指定します。

コンピュートマシンセットを作成します。
```
$ oc create -f <file-name>.yaml
```
マシンが利用可能になるまでに少し時間がかかる場合があります。

新しいパーティションとノードが作成されたことを確認します。

コンピュートマシンセットが作成されていることを確認します。

$ oc get machineset

出力例

NAME                                               DESIRED   CURRENT   READY   AVAILABLE   AGE
ci-ln-2675bt2-76ef8-bdgsc-worker-us-east-1a        1         1         1       1           124m
ci-ln-2675bt2-76ef8-bdgsc-worker-us-east-1b        2         2         2       2           124m
worker-us-east-2-nvme1n1                           1         1         1       1           2m35s 1

1: これが新しいコンピュートマシンセットです。

新規ノードが作成されていることを確認します。

$ oc get nodes

出力例

NAME                           STATUS   ROLES    AGE     VERSION
ip-10-0-128-78.ec2.internal    Ready    worker   117m    v1.29.4
ip-10-0-146-113.ec2.internal   Ready    master   127m    v1.29.4
ip-10-0-153-35.ec2.internal    Ready    worker   118m    v1.29.4
ip-10-0-176-58.ec2.internal    Ready    master   126m    v1.29.4
ip-10-0-217-135.ec2.internal   Ready    worker   2m57s   v1.29.4 1
ip-10-0-225-248.ec2.internal   Ready    master   127m    v1.29.4
ip-10-0-245-59.ec2.internal    Ready    worker   116m    v1.29.4

1: これは新しいノードです。

カスタム /var パーティションが新しいノードに作成されていることを確認します。

$ oc debug node/<node-name> -- chroot /host lsblk

以下に例を示します。

$ oc debug node/ip-10-0-217-135.ec2.internal -- chroot /host lsblk

出力例

NAME        MAJ:MIN  RM  SIZE RO TYPE MOUNTPOINT
nvme0n1     202:0    0   120G  0 disk
|-nvme0n1p1 202:1    0     1M  0 part
|-nvme0n1p2 202:2    0   127M  0 part
|-nvme0n1p3 202:3    0   384M  0 part /boot
`-nvme0n1p4 202:4    0 119.5G  0 part /sysroot
nvme1n1     202:16   0    50G  0 disk
`-nvme1n1p1 202:17   0  48.8G  0 part /var 1

1: nvme1n1 デバイスが /var パーティションにマウントされます。

関連情報

OpenShift Container Platform がディスクパーティションを使用する仕組みについては、Disk partitioningをしてください。

6.2. RHCOS コンピュートマシンの OpenShift Container Platform クラスターへの追加

6.2.1. 前提条件

6.2.2. ISO イメージを使用した RHCOS マシンの作成

6.2.3. PXE または iPXE ブートによる RHCOS マシンの作成

6.2.4. マシンの証明書署名要求の承認

6.2.5. AWS でのカスタム `/var` パーティションを持つ新規 RHCOS ワーカーノードの追加

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links

6.2. RHCOS コンピュートマシンの OpenShift Container Platform クラスターへの追加

6.2.1. 前提条件

6.2.2. ISO イメージを使用した RHCOS マシンの作成

6.2.3. PXE または iPXE ブートによる RHCOS マシンの作成

6.2.4. マシンの証明書署名要求の承認

6.2.5. AWS でのカスタム /var パーティションを持つ新規 RHCOS ワーカーノードの追加

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links

6.2.5. AWS でのカスタム `/var` パーティションを持つ新規 RHCOS ワーカーノードの追加