マシン設定

1. 遮断。MCO は、ノードを追加のワークロードに対してスケジュール不可としてマークします。
2. ドレイン。MCO は、ノード上で実行中のすべてのワークロードを終了します。その結果、ワークロードが他のノードに再スケジュールされます。
3. 適用。MCO は、必要に応じて新しい設定をノードに書き込みます。
4. 再起動します。MCO はノードを再起動します。
5. 遮断解除。MCO は、ノードをワークロードに対してスケジュール可能としてマークします。

手順

1. 各マシン設定プール (MCP) のクラスターで使用可能な MCO 管理ノードの数を確認するには、次のコマンドを実行します。

   $ oc get machineconfigpool

   出力例

   NAME      CONFIG                    UPDATED  UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT  AGE
   master    rendered-master-06c9c4…   True     False      False     3             3                  3                   0                     4h42m
   worker    rendered-worker-f4b64…    False    True       False     3             2                  2                   0                     4h42m

   ここでは、以下のようになります。

   UPDATED

   True ステータスは、MCO が現在のマシン設定をその MCP のノードに適用したことを示します。現在のマシン設定は、oc get mcp 出力の STATUS フィールドに指定されています。False ステータスは、MCP 内のノードが更新中であることを示します。

   UPDATING

   True ステータスは、MCO が、MachineConfigPool カスタムリソースで指定された目的のマシン設定を、その MCP 内の少なくとも 1 つのノードに適用していることを示します。目的のマシン設定は、新しく編集されたマシン設定です。更新中のノードは、スケジューリングに使用できない場合があります。False ステータスは、MCP 内のすべてのノードが更新されたことを示します。

   DEGRADED

   True ステータスは、MCO がその MCP 内の少なくとも 1 つのノードに現在のまたは目的のマシン設定を適用することをブロックされているか、設定が失敗していることを示します。機能が低下したノードは、スケジューリングに使用できない場合があります。False ステータスは、MCP 内のすべてのノードの準備ができていることを示します。

   MACHINECOUNT

   その MCP 内のマシンの総数を示します。

   READYMACHINECOUNT

   スケジューリングの準備ができているその MCP 内のマシンの総数を示します。

   UPDATEDMACHINECOUNT

   現在のマシン設定を持つ MCP 内のマシンの総数を示します。

   DEGRADEDMACHINECOUNT

   機能低下または調整不能としてマークされている、その MCP 内のマシンの総数を示します。

   前の出力では、3 つのコントロールプレーン (マスター) ノードと 3 つのワーカーノードがあります。コントロールプレーン MCP と関連するノードは、現在のマシン設定に更新されます。ワーカー MCP のノードは、目的のマシン設定に更新されています。UPDATEDMACHINECOUNT が 2 であることからわかるように、ワーカー MCP 内の 2 つのノードが更新され、1 つがまだ更新中です。DEGRADEDMACHINECOUNT が 0 で、DEGRADED が False であることからわかるように、問題はありません。

   MCP のノードが更新されている間、CONFIG の下にリストされているマシン設定は、MCP の更新元である現在のマシン設定です。更新が完了すると、リストされたマシン設定は、MCP が更新された目的のマシン設定になります。

   注記

   ノードが遮断されている場合、そのノードは READYMACHINECOUNT には含まれませんが、MACHINECOUNT には含まれます。また、MCP ステータスは UPDATING に設定されます。ノードには現在のマシン設定があるため、UPDATEDMACHINECOUNT の合計にカウントされます。

   出力例

   NAME      CONFIG                    UPDATED  UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT  AGE
   master    rendered-master-06c9c4…   True     False      False     3             3                  3                   0                     4h42m
   worker    rendered-worker-c1b41a…   False    True       False     3             2                  3                   0                     4h42m

2. MachineConfigPool カスタムリソースを調べて MCP 内のノードのステータスを確認するには、次のコマンドを実行します。

   $ oc describe mcp worker

   出力例

   ...
     Degraded Machine Count:     0
     Machine Count:              3
     Observed Generation:        2
     Ready Machine Count:        3
     Unavailable Machine Count:  0
     Updated Machine Count:      3
   Events:                       <none>

   注記

   ノードが遮断されている場合、そのノードは Ready Machine Count に含まれません。Unavailable Machine Count に含まれます。

   出力例

   ...
     Degraded Machine Count:     0
     Machine Count:              3
     Observed Generation:        2
     Ready Machine Count:        2
     Unavailable Machine Count:  1
     Updated Machine Count:      3

3. 既存の各 MachineConfig オブジェクトを表示するには、次のコマンドを実行します。

   $ oc get machineconfigs

   出力例

   NAME                             GENERATEDBYCONTROLLER          IGNITIONVERSION  AGE
   00-master                        2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
   00-worker                        2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
   01-master-container-runtime      2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
   01-master-kubelet                2c9371fbb673b97a6fe8b1c52…     3.2.0            5h18m
   ...
   rendered-master-dde...           2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
   rendered-worker-fde...           2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m

   rendered として一覧表示された MachineConfig オブジェクトが変更されたり、削除されたりすることが意図されていないことに注意してください。

4. 特定のマシン設定 (この場合は 01-master-kubelet) の内容を表示するには、次のコマンドを実行します。

   $ oc describe machineconfigs 01-master-kubelet

   コマンドの出力は、この MachineConfig オブジェクトに設定ファイル (cloud.conf および kubelet.conf) と systemd サービス (Kubernetes Kubelet) の両方が含まれていることを示しています。

   出力例

   Name:         01-master-kubelet
   ...
   Spec:
     Config:
       Ignition:
         Version:  3.2.0
       Storage:
         Files:
           Contents:
             Source:   data:,
           Mode:       420
           Overwrite:  true
           Path:       /etc/kubernetes/cloud.conf
           Contents:
             Source:   data:,kind%3A%20KubeletConfiguration%0AapiVersion%3A%20kubelet.config.k8s.io%2Fv1beta1%0Aauthentication%3A%0A%20%20x509%3A%0A%20%20%20%20clientCAFile%3A%20%2Fetc%2Fkubernetes%2Fkubelet-ca.crt%0A%20%20anonymous...
           Mode:       420
           Overwrite:  true
           Path:       /etc/kubernetes/kubelet.conf
       Systemd:
         Units:
           Contents:  [Unit]
   Description=Kubernetes Kubelet
   Wants=rpc-statd.service network-online.target crio.service
   After=network-online.target crio.service
   
   ExecStart=/usr/bin/hyperkube \
       kubelet \
         --config=/etc/kubernetes/kubelet.conf \ ...

手順

1. 次のコマンドを実行して、すべてのマシン設定プールに含まれる全ノードの更新ステータスの概要を取得します。

   $ oc get machineconfignodes

   出力例

   NAME                          UPDATED   UPDATEPREPARED   UPDATEEXECUTED   UPDATEPOSTACTIONCOMPLETED   UPDATECOMPLETED   RESUMED
   ip-10-0-12-194.ec2.internal   True      False             False              False                    False              False
   ip-10-0-17-102.ec2.internal   False     True              False              False                    False              False
   ip-10-0-2-232.ec2.internal    False     False             True               False                    False              False
   ip-10-0-59-251.ec2.internal   False     False             False              True                     False              False
   ip-10-0-59-56.ec2.internal    False     False             False              False                    True               True
   ip-10-0-6-214.ec2.internal    False     False             Unknown            False                    False              False

   ここでは、以下のようになります。

   UPDATED

   True ステータスは、MCO が現在のマシン設定をその特定のノードに適用したことを示します。False ステータスは、ノードが現在更新中であることを示します。Unknown ステータスは、操作が処理中であることを表します。

   UPDATEPREPARED

   False ステータスは、配布される新しいマシン設定の調整を MCO が開始していないことを示します。True ステータスは、MCO が更新のこのフェーズを完了したことを示します。Unknown ステータスは、操作が処理中であることを表します。

   UPDATEEXECUTED

   False ステータスは、MCO がノードの遮断とドレインを開始していないことを示します。また、ディスクの状態とオペレーティングシステムの更新が開始されていないことも示します。True ステータスは、MCO が更新のこのフェーズを完了したことを示します。Unknown ステータスは、操作が処理中であることを表します。

   UPDATEPOSTACTIONCOMPLETED

   False ステータスは、MCO がノードの再起動またはデーモンの終了を開始していないことを示します。True ステータスは、MCO が再起動とノードステータスの更新を完了したことを示します。Unknown ステータスは、このフェーズの更新プロセス中にエラーが発生したか、MCO が現在更新を適用していることを示します。

   UPDATECOMPLETED

   False ステータスは、MCO がノードの遮断解除とノードの状態およびメトリクスの更新を開始していないことを示します。True ステータスは、MCO がノードの状態と利用可能なメトリクスの更新を完了したことを示します。

   RESUMED

   False ステータスは、MCO が設定ドリフトモニターを起動していないことを示します。True ステータスは、ノードが動作を再開したことを示します。Unknown ステータスは、操作が処理中であることを表します。

   注記

   上記の 1 次フェーズには、2 次フェーズを含めることができます。2 次フェーズを使用すると、更新の進行状況をより詳細に確認できます。前述のコマンドの -o wide オプションを使用すると、更新の二次フェーズを含む詳細情報を取得できます。これにより、UPDATECOMPATIBLE、UPDATEFILESANDOS、DRAINEDNODE、CORDONEDNODE、REBOOTNODE、RELOADEDCRIO、および UNCORDONED 列が追加されます。これらの 2 次フェーズは常に発生するわけではなく、適用する更新の種類によって異なります。

2. 次のコマンドを実行して、特定のマシン設定プールに含まれるノードの更新ステータスを確認します。

   $ oc get machineconfignodes $(oc get machineconfignodes -o json | jq -r '.items[]|select(.spec.pool.name=="<pool_name>")|.metadata.name') 1

   1

   プールの名前は MachineConfigPool オブジェクト名です。

   出力例

   NAME                          UPDATED   UPDATEPREPARED   UPDATEEXECUTED   UPDATEPOSTACTIONCOMPLETE   UPDATECOMPLETE   RESUMED
   ip-10-0-48-226.ec2.internal   True      False            False            False                      False            False
   ip-10-0-5-241.ec2.internal    True      False            False            False                      False            False
   ip-10-0-74-108.ec2.internal   True      False            False            False                      False            False

3. 次のコマンドを実行して、個々のノードの更新ステータスを確認します。

   $ oc describe machineconfignode/<node_name> 1

   1

   ノードの名前は MachineConfigNode オブジェクト名です。

   出力例

   Name:         <node_name>
   Namespace:
   Labels:       <none>
   Annotations:  <none>
   API Version:  machineconfiguration.openshift.io/v1alpha1
   Kind:         MachineConfigNode
   Metadata:
     Creation Timestamp:  2023-10-17T13:08:58Z
     Generation:          1
     Resource Version:    49443
     UID:                 4bd758ab-2187-413c-ac42-882e61761b1d
   Spec:
     Node Ref:
       Name:         <node_name>
     Pool:
       Name:         master
     ConfigVersion:
       Desired: rendered-worker-823ff8dc2b33bf444709ed7cd2b9855b 1
   Status:
     Conditions:
       Last Transition Time:  2023-10-17T13:09:02Z
       Message:               Node has completed update to config rendered-master-cf99e619747ab19165f11e3546c71f1e
       Reason:                NodeUpgradeComplete
       Status:                True
       Type:                  Updated
       Last Transition Time:  2023-10-17T13:09:02Z
       Message:               This node has not yet entered the UpdatePreparing phase
       Reason:                NotYetOccured
       Status:                False
     Config Version:
       Current:            rendered-worker-823ff8dc2b33bf444709ed7cd2b9855b
       Desired:            rendered-worker-823ff8dc2b33bf444709ed7cd2b9855b 2
     Health:               Healthy
     Most Recent Error:
     Observed Generation:  3

   1

   spec.configversion.desired フィールドで指定し必要な設定は、ノード上で新しい設定が検出されるとすぐに更新されます。

   2

   status.configversion.desired フィールドに指定した必要な設定は、新しい設定が Machine Config Daemon (MCD) によって検証された場合にのみ更新されます。MCD は、更新の現在のフェーズをチェックすることによって検証を実行します。更新が UPDATEPREPARED フェーズを正常に通過すると、ステータスに新しい設定が追加されます。

手順

1. chrony.conf ファイルのコンテンツを含む Butane 設定を作成します。たとえば、ワーカーノードで chrony を設定するには、99-worker-chrony.bu ファイルを作成します。

   注記

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

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

   1 2

   コントロールプレーンノードでは、これらの両方の場所で worker の代わりに master を使用します。

   3

   マシン設定ファイルの mode フィールドに 8 進数の値でモードを指定します。ファイルを作成し、変更を適用すると、mode は 10 進数の値に変換されます。oc get mc <mc-name> -o yaml コマンドで YAML ファイルを確認できます。

   4

   DHCP サーバーが提供するものなど、有効な到達可能なタイムソースを指定します。または、NTP サーバーの 1.rhel.pool.ntp.org、2.rhel.pool.ntp.org、または 3.rhel.pool.ntp.org のいずれかを指定できます。

2. Butane を使用して、ノードに配信される設定を含む MachineConfig オブジェクトファイル (99-worker-chrony.yaml) を生成します。

   $ butane 99-worker-chrony.bu -o 99-worker-chrony.yaml

3. 以下の 2 つの方法のいずれかで設定を適用します。

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

   • クラスターがすでに実行中の場合は、ファイルを適用します。

     $ oc apply -f ./99-worker-chrony.yaml

手順

1. 指定されたノードロールの chronyd を無効にする MachineConfig CR を作成します。

   1. 以下の YAML を disable-chronyd.yaml ファイルに保存します。

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: <node_role> 1
        name: disable-chronyd
      spec:
        config:
          ignition:
            version: 3.2.0
          systemd:
            units:
              - contents: |
                  [Unit]
                  Description=NTP client/server
                  Documentation=man:chronyd(8) man:chrony.conf(5)
                  After=ntpdate.service sntp.service ntpd.service
                  Conflicts=ntpd.service systemd-timesyncd.service
                  ConditionCapability=CAP_SYS_TIME
                  [Service]
                  Type=forking
                  PIDFile=/run/chrony/chronyd.pid
                  EnvironmentFile=-/etc/sysconfig/chronyd
                  ExecStart=/usr/sbin/chronyd $OPTIONS
                  ExecStartPost=/usr/libexec/chrony-helper update-daemon
                  PrivateTmp=yes
                  ProtectHome=yes
                  ProtectSystem=full
                  [Install]
                  WantedBy=multi-user.target
                enabled: false
                name: "chronyd.service"

      1

      chronyd を無効にするノードロール (例: master)。

   2. 以下のコマンドを実行して MachineConfig CR を作成します。

      $ oc create -f disable-chronyd.yaml

手順

1. OpenShift Container Platform クラスターの既存の MachineConfig をリスト表示し、マシン設定にラベルを付ける方法を判別します。

   $ 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

2. カーネル引数を識別する MachineConfig オブジェクトファイルを作成します (例: 05-worker-kernelarg-selinuxpermissive.yaml)。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker1
     name: 05-worker-kernelarg-selinuxpermissive2
   spec:
     kernelArguments:
       - enforcing=03

   1

   新しいカーネル引数をワーカーノードのみに適用します。

   2

   マシン設定 (05) 内の適切な場所を特定するための名前が指定されます (SELinux permissive モードを設定するためにカーネル引数を追加します)。

   3

   正確なカーネル引数を enforcing=0 として特定します。

3. 新規のマシン設定を作成します。

   $ oc create -f 05-worker-kernelarg-selinuxpermissive.yaml

4. マシン設定で新規の追加内容を確認します。

   $ 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
   05-worker-kernelarg-selinuxpermissive                                                         3.2.0             105s
   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

5. ノードを確認します。

   $ oc get nodes

   出力例

   NAME                           STATUS                     ROLES    AGE   VERSION
   ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.30.3
   ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.30.3
   ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.30.3
   ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.30.3
   ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.30.3
   ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.30.3

   変更が適用されているため、各ワーカーノードのスケジューリングが無効にされていることを確認できます。

6. ワーカーノードのいずれかに移動し、カーネルコマンドライン引数 (ホストの /proc/cmdline 内) をリスト表示して、カーネル引数が機能することを確認します。

   $ oc debug node/ip-10-0-141-105.ec2.internal

   出力例

   Starting pod/ip-10-0-141-105ec2internal-debug ...
   To use host binaries, run `chroot /host`
   
   sh-4.2# cat /host/proc/cmdline
   BOOT_IMAGE=/ostree/rhcos-... console=tty0 console=ttyS0,115200n8
   rootflags=defaults,prjquota rw root=UUID=fd0... ostree=/ostree/boot.0/rhcos/16...
   coreos.oem.id=qemu coreos.oem.id=ec2 ignition.platform.id=ec2 enforcing=0
   
   sh-4.2# exit

   enforcing=0 引数が他のカーネル引数に追加されていることを確認できるはずです。

手順

1. インストール後にコントロールプレーンノードでマルチパスを有効にするには、以下を実行します。

   • 以下の例のように、master ラベルを追加し、マルチパスカーネル引数を特定するようクラスターに指示する 99-master-kargs-mpath.yaml などのマシン設定ファイルを作成します。

     apiVersion: machineconfiguration.openshift.io/v1
     kind: MachineConfig
     metadata:
       labels:
         machineconfiguration.openshift.io/role: "master"
       name: 99-master-kargs-mpath
     spec:
       kernelArguments:
         - 'rd.multipath=default'
         - 'root=/dev/disk/by-label/dm-mpath-root'

2. インストール後にワーカーノードでマルチパスを有効にするには、以下を実行します。

   • worker ラベルを追加し、マルチパスカーネル引数などを特定するようクラスターに指示する 99-worker-kargs-mpath.yaml などのマシン設定ファイルを作成します。

     apiVersion: machineconfiguration.openshift.io/v1
     kind: MachineConfig
     metadata:
       labels:
         machineconfiguration.openshift.io/role: "worker"
       name: 99-worker-kargs-mpath
     spec:
       kernelArguments:
         - 'rd.multipath=default'
         - 'root=/dev/disk/by-label/dm-mpath-root'

3. 以前に作成したマスターまたはワーカー YAML ファイルのいずれかを使用して新規のマシン設定を作成します。

   $ oc create -f ./99-worker-kargs-mpath.yaml

4. マシン設定で新規の追加内容を確認します。

   $ 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-kargs-mpath                              52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             105s
   99-worker-ssh                                                                                 3.2.0             40m
   rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

5. ノードを確認します。

   $ oc get nodes

   出力例

   NAME                           STATUS                     ROLES    AGE   VERSION
   ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.30.3
   ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.30.3
   ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.30.3
   ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.30.3
   ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.30.3
   ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.30.3

   変更が適用されているため、各ワーカーノードのスケジューリングが無効にされていることを確認できます。

6. ワーカーノードのいずれかに移動し、カーネルコマンドライン引数 (ホストの /proc/cmdline 内) をリスト表示して、カーネル引数が機能することを確認します。

   $ oc debug node/ip-10-0-141-105.ec2.internal

   出力例

   Starting pod/ip-10-0-141-105ec2internal-debug ...
   To use host binaries, run `chroot /host`
   
   sh-4.2# cat /host/proc/cmdline
   ...
   rd.multipath=default root=/dev/disk/by-label/dm-mpath-root
   ...
   
   sh-4.2# exit

   追加したカーネル引数が表示されるはずです。

手順

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.30.3
   ip-10-0-146-92.us-east-2.compute.internal   Ready   worker   101m  v1.30.3
   ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.30.3

   $ 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

手順

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

   注記

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

   variant: openshift
   version: 4.17.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

手順

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.30.3

   $ 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

手順

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

   注記

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

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

   variant: openshift
   version: 4.17.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 設定を保存します。

手順

1. オペレーティングシステムでサポートされているツールを使用して、ハッシュ化されたパスワードを作成します。たとえば次のコマンドを実行し、mkpasswd を使用してハッシュ化されたパスワードを作成します。

   $ mkpasswd -m SHA-512 testpass

   出力例

   $ $6$CBZwA6s6AVFOtiZe$aUKDWpthhJEyR3nnhM02NM1sKCpHn9XN.NPrJNQ3HYewioaorpwL3mKGLxvW0AOb4pJxqoqP4nFX77y0p00.8.

2. core ユーザー名とハッシュ化されたパスワードを含むマシン設定ファイルを作成します。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: set-core-user-password
   spec:
     config:
       ignition:
         version: 3.2.0
       passwd:
         users:
         - name: core 1
           passwordHash: <password> 2

   1

   これは core である必要があります。

   2

   core アカウントで使用するハッシュ化されたパスワード。

3. 次のコマンドを実行して、マシン設定を作成します。

   $ oc create -f <file-name>.yaml

   ノードは再起動せず、しばらくすると使用可能になります。次の例に示すように、oc get mcp を使用して、マシン設定プールが更新されるのを監視できます。

   NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master   rendered-master-d686a3ffc8fdec47280afec446fce8dd   True      False      False      3              3                   3                     0                      64m
   worker   rendered-worker-4605605a5b1f9de1d061e9d350f251e5   False     True       False      3              0                   0                     0                      64m

検証

1. ノードが UPDATED=True 状態に戻ったら、次のコマンドを実行してノードのデバッグセッションを開始します。

   $ oc debug node/<node_name>

2. 次のコマンドを実行して、デバッグシェル内のルートディレクトリーとして /host を設定します。

   sh-4.4# chroot /host

3. /etc/shadow ファイルの内容を確認します。

   出力例

   ...
   core:$6$2sE/010goDuRSxxv$o18K52wor.wIwZp:19418:0:99999:7:::
   ...

   ハッシュ化されたパスワードは、core ユーザーに割り当てられます。

手順

1. machineconfigurations.operator.openshift.io オブジェクトを編集して、ノード停止ポリシーを定義します。

   $ oc edit MachineConfiguration cluster -n openshift-machine-config-operator

2. 次のようなノード停止ポリシーを追加します。

   apiVersion: operator.openshift.io/v1
   kind: MachineConfiguration
   metadata:
     name: cluster
   # ...
   spec:
     nodeDisruptionPolicy: 1
       files: 2
       - actions: 3
         - reload: 4
             serviceName: chronyd.service 5
           type: Reload
         path: /etc/chrony.conf 6
       sshkey: 7
         actions:
         - type: Drain
         - reload:
             serviceName: crio.service
           type: Reload
         - type: DaemonReload
         - restart:
             serviceName: crio.service
           type: Restart
       units: 8
       - actions:
         - type: Drain
         - reload:
             serviceName: crio.service
           type: Reload
         - type: DaemonReload
         - restart:
             serviceName: crio.service
           type: Restart
         name: test.service

   1

   ノード停止ポリシーを指定します。

   2

   マシン設定ファイルの定義と、それらのパスの変更に対して実行するアクションのリストを指定します。このリストは最大 50 個のエントリーをサポートします。

   3

   指定したファイルが変更されたときに実行する一連のアクションを指定します。アクションは、このリストに設定されている順序で適用されます。このリストは最大 10 個のエントリーをサポートします。

   4

   指定したファイルが変更されたときに、リストしたサービスをリロードすることを指定します。

   5

   アクションの対象となるサービスの完全な名前を指定します。

   6

   マシン設定によって管理されるファイルの場所を指定します。ポリシー内のアクションは、path 内のファイルが変更されたときに適用されます。

   7

   クラスター内の SSH キーが変更されたときに実行するサービス名とアクションのリストを指定します。

   8

   systemd ユニット名のリストと、これらのユニットが変更されたときに実行するアクションを指定します。

前提条件

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

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"

手順

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% /

手順

1. 次のコマンドを実行して、cluster という名前の MachineConfiguration オブジェクトを編集し、ブートイメージの更新を有効にします。

   $ oc edit MachineConfiguration cluster

   • オプション: すべてのマシンセットのブートイメージ更新機能を設定します。

     apiVersion: operator.openshift.io/v1
     kind: MachineConfiguration
     metadata:
       name: cluster
       namespace: openshift-machine-config-operator
     spec:
     # ...
       managedBootImages: 1
         machineManagers:
         - resource: machinesets
           apiGroup: machine.openshift.io
           selection:
             mode: All 2

     1

     ブートイメージ更新機能を有効にします。

     2

     クラスター内のすべてのマシンセットを更新することを指定します。

   • オプション: 特定のマシンセットのブートイメージ更新機能を設定します。

     apiVersion: operator.openshift.io/v1
     kind: MachineConfiguration
     metadata:
       name: cluster
       namespace: openshift-machine-config-operator
     spec:
     # ...
       managedBootImages: 1
         machineManagers:
         - resource: machinesets
           apiGroup: machine.openshift.io
           selection:
             mode: Partial
             partial:
               machineResourceSelector:
                 matchLabels:
                   update-boot-image: "true" 2

     1

     ブートイメージ更新機能を有効にします。

     2

     このラベルが設定されたマシンすべてを更新するように指定します。

     ヒント

     マシンセットに適切なラベルが存在しない場合は、次のようなコマンドを実行してキー/値のペアを追加します。

     $ oc label machineset.machine ci-ln-hmy310k-72292-5f87z-worker-a update-boot-image=true -n openshift-machine-api

検証

1. マシン設定オブジェクトを表示して、ブートイメージ更新の現在の状態を確認します。

   $ oc get machineconfiguration cluster -n openshift-machine-api -o yaml

   ブートイメージ参照を含むマシンセット例

   kind: MachineConfiguration
   metadata:
     name: cluster
   # ...
   status:
     conditions:
     - lastTransitionTime: "2024-09-09T13:51:37Z" 1
       message: Reconciled 1 of 2 MAPI MachineSets | Reconciled 0 of 0 CAPI MachineSets
         | Reconciled 0 of 0 CAPI MachineDeployments
       reason: BootImageUpdateConfigurationAdded
       status: "True"
       type: BootImageUpdateProgressing
     - lastTransitionTime: "2024-09-09T13:51:37Z" 2
       message: 0 Degraded MAPI MachineSets | 0 Degraded CAPI MachineSets | 0 CAPI MachineDeployments
       reason: BootImageUpdateConfigurationAdded
       status: "False"
       type: BootImageUpdateDegraded

   1

   ブートイメージの更新のステータス。Cluster CAPI Operator のマシンセットとマシンのデプロイメントは、現在、ブートイメージの更新ではサポートされていません。

   2

   ブートイメージの更新が失敗したかどうかを示します。いずれかの更新が失敗すると、Machine Config Operator の機能が低下します。この場合、手動による介入が必要になる可能性があります。

2. 次のコマンドを実行してブートイメージのバージョンを取得します。

   $ oc get machinesets <machineset_name> -n openshift-machine-api -o yaml

   ブートイメージ参照を含むマシンセット例

   apiVersion: machine.openshift.io/v1beta1
   kind: MachineSet
   metadata:
     labels:
       machine.openshift.io/cluster-api-cluster: ci-ln-77hmkpt-72292-d4pxp
       update-boot-image: "true"
     name: ci-ln-77hmkpt-72292-d4pxp-worker-a
     namespace: openshift-machine-api
   spec:
   # ...
     template:
   # ...
       spec:
   # ...
         providerSpec:
   # ...
           value:
             disks:
             - autoDelete: true
               boot: true
               image: projects/rhcos-cloud/global/images/rhcos-416-92-202402201450-0-gcp-x86-64 1
   # ...

   1

   このブートイメージは、現在の OpenShift Container Platform バージョンと同じです。

手順

1. MachineConfiguration オブジェクトを編集して、ブートイメージ更新を無効にします。

   $ oc edit MachineConfiguration cluster

2. managedBootImages スタンザを削除します。

   apiVersion: operator.openshift.io/v1
   kind: MachineConfiguration
   metadata:
     name: cluster
     namespace: openshift-machine-config-operator
   spec:
   # ...
     managedBootImages: 1
       machineManagers:
       - resource: machinesets
         apiGroup: machine.openshift.io
         selection:
           mode: All

   1

   ブートイメージ更新を無効にするには、スタンザ全体を削除します。

手順

1. オプション: 次のコマンドを実行して、自動的に削除できるレンダリング済みマシン設定をリスト表示します。コマンド出力で as it’s currently in use とマークされているレンダリング済みマシン設定は削除されません。

   $ oc adm prune renderedmachineconfigs --pool-name=worker

   出力例

   Dry run enabled - no modifications will be made. Add --confirm to remove rendered machine configs.
   DRY RUN: Deleted rendered MachineConfig rendered-worker-23d7322831a57f02998e7e1600a0865f
   DRY RUN: Deleted rendered MachineConfig rendered-worker-fc94397dc7c43808c7014683c208956e
   DRY RUN: Skipping deletion of rendered MachineConfig rendered-worker-ad5a3cad36303c363cf458ab0524e7c0 as it's currently in use

   ここでは、以下のようになります。

   pool-name

   オプション: マシン設定を削除するマシン設定プールを指定します。

2. 次のコマンドを実行して、未使用のレンダリング済みマシン設定を削除します。次の手順のコマンドは、worker マシン設定プール内の最も古い 2 つの未使用のレンダリング済みマシン設定を削除します。

   $ oc adm prune renderedmachineconfigs --pool-name=worker --count=2 --confirm

   ここでは、以下のようになります。

   --count

   オプション: 最も古いものから順に、削除する未使用のレンダリング済みマシン設定の最大数を指定します。

   --confirm

   オプション: 最も古いものから順に、削除する未使用のレンダリング済みマシン設定の最大数を指定します。

   --pool-name

   オプション: マシンを削除するマシン設定プールを指定します。指定しない場合は、すべてのプールが評価されます。

1. 指定された 1 つ以上のプールの新しいマシン設定をレンダリングします。
2. 1 つ以上のプール内のノードでコードンおよびドレイン操作を実行します。
3. 残りのマシン設定パラメーターをノードに書き込みます。
4. カスタムレイヤーイメージをノードに適用します。
5. 新しいイメージを使用してノードを再起動します。

手順

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

   1. 以下のような YAML ファイルを作成します。

      apiVersion: machineconfiguration.openshift.io/v1alpha1
      kind: MachineOSConfig
      metadata:
        name: layered
      spec:
        machineConfigPool:
          name: <mcp_name> 1
        buildInputs:
          containerFile: 2
          - containerfileArch: noarch
            content: |-
              FROM configs AS final
              RUN dnf install -y cowsay && \
               dnf clean all && \
               ostree container commit
          imageBuilder: 3
            imageBuilderType: PodImageBuilder
          baseImagePullSecret: 4
            name: global-pull-secret-copy
          renderedImagePushspec: image-registry.openshift-image-registry.svc:5000/openshift/os-image:latest  5
          renderedImagePushSecret: 6
            name: builder-dockercfg-7lzwl
        buildOutputs: 7
          currentImagePullSecret:
            name: builder-dockercfg-7lzwl

      1

      カスタムレイヤーイメージをデプロイするノードに関連付けられているマシン設定プールの名前を指定します。

      2

      カスタムレイヤーイメージを設定するための Containerfile を指定します。

      3

      使用する Image Builder の名前を指定します。これは PodImageBuilder である必要があります。

      4

      MCO がレジストリーからベースオペレーティングシステムイメージをプルするために必要なプルシークレットの名前を指定します。

      5

      新しくビルドされたカスタムレイヤーイメージをプッシュするイメージレジストリーを指定します。これは、クラスターがアクセスできる任意のレジストリーにすることができます。この例では、内部 OpenShift Container Platform レジストリーを使用します。

      6

      MCO が新しくビルドされたカスタムレイヤーイメージをそのレジストリーにプッシュするために必要なプッシュシークレットの名前を指定します。

      7

      新しくビルドされたカスタムレイヤーイメージをノードがプルするために必要なイメージレジストリーに必要なシークレットを指定します。これは、イメージをリポジトリーにプッシュするために使用するシークレットとは異なるシークレットである必要があります。

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

      $ oc create -f <file_name>.yaml

2. MachineOSBuild オブジェクトが作成されて READY 状態になったら、必要に応じて、新しいカスタムレイヤーイメージを使用するノードのノード仕様を変更します。

   1. MachineOSBuild オブジェクトが READY であることを確認します。SUCCEEDED 値が True になったら、ビルドは完了です。

      $ oc get machineosbuild

      MachineOSBuild オブジェクトが準備完了状態であることを示す出力例

      NAME                                                                PREPARED   BUILDING   SUCCEEDED   INTERRUPTED   FAILED
      layered-rendered-layered-ad5a3cad36303c363cf458ab0524e7c0-builder   False      False      True        False         False

   2. MachineOSConfig オブジェクトで指定したマシン設定プールのラベルを追加して、カスタムレイヤーイメージをデプロイするノードを編集します。

      $ oc label node <node_name> 'node-role.kubernetes.io/<mcp_name>='

      ここでは、以下のようになります。

      node-role.kubernetes.io/<mcp_name>=

      カスタムレイヤーイメージをデプロイするノードを特定するノードセレクターを指定します。

      変更を保存すると、MCO がノードをドレイン、遮断、再起動します。再起動後、ノードは新しいカスタムレイヤーイメージを使用します。

検証

1. 次のコマンドを使用して、新しい Pod が実行されていることを確認します。

   $ oc get pods -n <machineosbuilds_namespace>

   NAME                                                              READY   STATUS    RESTARTS   AGE
   build-rendered-layered-ad5a3cad36303c363cf458ab0524e7c0           2/2     Running   0          2m40s 1
   # ...
   machine-os-builder-6fb66cfb99-zcpvq                               1/1     Running   0          2m42s 2

   1

   これは、カスタムレイヤーイメージがビルドされるビルド Pod です。

   2

   この Pod はトラブルシューティングに使用できます。

2. MachineOSConfig オブジェクトに新しいカスタムレイヤーイメージへの参照が含まれていることを確認します。

   $ oc describe MachineOSConfig <object_name>

   apiVersion: machineconfiguration.openshift.io/v1alpha1
   kind: MachineOSConfig
   metadata:
     name: layered
   spec:
     buildInputs:
       baseImagePullSecret:
         name: global-pull-secret-copy
       containerFile:
       - containerfileArch: noarch
         content: ""
       imageBuilder:
         imageBuilderType: PodImageBuilder
       renderedImagePushSecret:
         name: builder-dockercfg-ng82t-canonical
       renderedImagePushspec: image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-image:latest
     buildOutputs:
       currentImagePullSecret:
         name: global-pull-secret-copy
     machineConfigPool:
       name: layered
   status:
     currentImagePullspec: image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-image@sha256:f636fa5b504e92e6faa22ecd71a60b089dab72200f3d130c68dfec07148d11cd 1

   1

   新しいカスタムレイヤーイメージのダイジェスト付きイメージプル仕様。

3. MachineOSBuild オブジェクトに新しいカスタムレイヤーイメージへの参照が含まれていることを確認します。

   $ oc describe machineosbuild <object_name>

   apiVersion: machineconfiguration.openshift.io/v1alpha1
   kind: MachineOSBuild
   metadata:
     name: layered-rendered-layered-ad5a3cad36303c363cf458ab0524e7c0-builder
   spec:
     desiredConfig:
       name: rendered-layered-ad5a3cad36303c363cf458ab0524e7c0
     machineOSConfig:
       name: layered
     renderedImagePushspec: image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-image:latest
   # ...
   status:
     conditions:
       - lastTransitionTime: "2024-05-21T20:25:06Z"
         message: Build Ready
         reason: Ready
         status: "True"
         type: Succeeded
     finalImagePullspec: image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-image@sha256:f636fa5b504e92e6faa22ecd71a60b089dab72200f3d130c68dfec07148d11cd 1

   1

   新しいカスタムレイヤーイメージのダイジェスト付きイメージプル仕様。

4. 適切なノードが新しいカスタムレイヤーイメージを使用していることを確認します。

   1. コントロールプレーンノードの root としてデバッグセッションを開始します。

      $ oc debug node/<node_name>

   2. /host をデバッグシェル内のルートディレクトリーとして設定します。

      sh-4.4# chroot /host

   3. rpm-ostree status コマンドを実行して、カスタムレイヤーイメージが使用されていることを確認します。

      sh-5.1# rpm-ostree status

      出力例

      # ...
      Deployments:
      * ostree-unverified-registry:quay.io/openshift-release-dev/os-image@sha256:f636fa5b504e92e6faa22ecd71a60b089dab72200f3d130c68dfec07148d11cd 1
                         Digest: sha256:bcea2546295b2a55e0a9bf6dd4789433a9867e378661093b6fdee0031ed1e8a4
                        Version: 416.94.202405141654-0 (2024-05-14T16:58:43Z)

      1

      新しいカスタムレイヤーイメージのダイジェスト付きイメージプル仕様。

手順

1. マシン設定プールを作成します。

   1. 以下のような YAML ファイルを作成します。

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: worker 1
        name: os-layer-custom
      spec:
        osImageURL: quay.io/my-registry/custom-image@sha256... 2

      1

      カスタムレイヤーイメージを適用するマシン設定プールを指定します。

      2

      リポジトリー内のカスタムレイヤーイメージへのパスを指定します。

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

      $ oc create -f <file_name>.yaml

      重要

      クラスターにロールアウトする前に、実稼働環境の外でイメージをテストすることを強く推奨します。

1. ワーカーマシン設定プールが新しいマシン設定でロールアウトされていることを確認します。

   1. 新しいマシン設定が作成されたことを確認します。

      $ oc get mc

      出力例

      NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
      00-master                                          5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      00-worker                                          5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      01-master-container-runtime                        5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      01-master-kubelet                                  5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      01-worker-container-runtime                        5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      01-worker-kubelet                                  5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      99-master-generated-registries                     5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      99-master-ssh                                                                                 3.2.0             98m
      99-worker-generated-registries                     5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      99-worker-ssh                                                                                 3.2.0             98m
      os-layer-custom                                                                                                 10s 1
      rendered-master-15961f1da260f7be141006404d17d39b   5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      rendered-worker-5aff604cb1381a4fe07feaf1595a797e   5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      rendered-worker-5de4837625b1cbc237de6b22bc0bc873   5bdb57489b720096ef912f738b46330a8f577803   3.2.0             4s  2

      1

      新しいマシン設定

      2

      新しいレンダリング済みマシン設定

   2. 新しいマシン設定の osImageURL 値が予測されるイメージを指していることを確認します。

      $ oc describe mc rendered-worker-5de4837625b1cbc237de6b22bc0bc873

      出力例

      Name:         rendered-worker-5de4837625b1cbc237de6b22bc0bc873
      Namespace:
      Labels:       <none>
      Annotations:  machineconfiguration.openshift.io/generated-by-controller-version: 5bdb57489b720096ef912f738b46330a8f577803
                    machineconfiguration.openshift.io/release-image-version: 4.17.0-ec.3
      API Version:  machineconfiguration.openshift.io/v1
      Kind:         MachineConfig
      ...
        Os Image URL: quay.io/my-registry/custom-image@sha256...

   3. 関連するマシン設定プールが新しいマシン設定で更新されていることを確認します。

      $ oc get mcp

      出力例

      NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
      master   rendered-master-15961f1da260f7be141006404d17d39b   True      False      False      3              3                   3                     0                      39m
      worker   rendered-worker-5de4837625b1cbc237de6b22bc0bc873   True      False      False      3              0                   0                     0                      39m 1

      1

      UPDATING フィールドが True の場合、マシン設定プールは新しいマシン設定で更新されます。この場合、新しいマシン設定は出力にリストされません。フィールドが False になると、ワーカーマシン設定プールが新しいマシン設定にロールアウトされます。

   4. ノードをチェックして、ノードのスケジューリングが無効になっていることを確認します。これは、変更が適用されていることを示しています。

      $ oc get nodes

      出力例

      NAME                                         STATUS                     ROLES                  AGE   VERSION
      ip-10-0-148-79.us-west-1.compute.internal    Ready                      worker                 32m   v1.30.3
      ip-10-0-155-125.us-west-1.compute.internal   Ready,SchedulingDisabled   worker                 35m   v1.30.3
      ip-10-0-170-47.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.30.3
      ip-10-0-174-77.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.30.3
      ip-10-0-211-49.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.30.3
      ip-10-0-218-151.us-west-1.compute.internal   Ready                      worker                 31m   v1.30.3

2. ノードが Ready 状態に戻ったら、ノードがカスタムレイヤーイメージを使用していることを確認します。

   1. ノードへの oc debug セッションを開きます。以下に例を示します。

      $ oc debug node/ip-10-0-155-125.us-west-1.compute.internal

   2. /host をデバッグシェル内のルートディレクトリーとして設定します。

      sh-4.4# chroot /host

   3. rpm-ostree status コマンドを実行して、カスタムレイヤーイメージが使用されていることを確認します。

      sh-4.4# sudo rpm-ostree status

      出力例

      State: idle
      Deployments:
      * ostree-unverified-registry:quay.io/my-registry/...
                         Digest: sha256:...

手順

1. カスタムレイヤーイメージを適用したマシン設定を削除します。

   $ oc delete mc os-layer-custom

   マシン設定を削除した後、ノードが再起動します。

1. ワーカーマシン設定プールが以前のマシン設定で更新されていることを確認します。

   $ oc get mcp

   出力例

   NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master   rendered-master-6faecdfa1b25c114a58cf178fbaa45e2   True      False      False      3              3                   3                     0                      39m
   worker   rendered-worker-6b000dbc31aaee63c6a2d56d04cd4c1b   False     True       False      3              0                   0                     0                      39m 1

   1

   UPDATING フィールドが True の場合、マシン設定プールは以前のマシン設定で更新されます。フィールドが False になると、ワーカーマシン設定プールが以前のマシン設定にロールアウトされます。

2. ノードをチェックして、ノードのスケジューリングが無効になっていることを確認します。これは、変更が適用されていることを示しています。

   $ oc get nodes

   出力例

   NAME                                         STATUS                     ROLES                  AGE   VERSION
   ip-10-0-148-79.us-west-1.compute.internal    Ready                      worker                 32m   v1.30.3
   ip-10-0-155-125.us-west-1.compute.internal   Ready,SchedulingDisabled   worker                 35m   v1.30.3
   ip-10-0-170-47.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.30.3
   ip-10-0-174-77.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.30.3
   ip-10-0-211-49.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.30.3
   ip-10-0-218-151.us-west-1.compute.internal   Ready                      worker                 31m   v1.30.3

3. ノードが Ready 状態に戻ったら、ノードが基本イメージを使用していることを確認します。

   1. ノードへの oc debug セッションを開きます。以下に例を示します。

      $ oc debug node/ip-10-0-155-125.us-west-1.compute.internal

   2. /host をデバッグシェル内のルートディレクトリーとして設定します。

      sh-4.4# chroot /host

   3. rpm-ostree status コマンドを実行して、カスタムレイヤーイメージが使用されていることを確認します。

      sh-4.4# sudo rpm-ostree status

      出力例

      State: idle
      Deployments:
      * ostree-unverified-registry:podman pull quay.io/openshift-release-dev/ocp-release@sha256:e2044c3cfebe0ff3a99fc207ac5efe6e07878ad59fd4ad5e41f88cb016dacd73
                         Digest: sha256:e2044c3cfebe0ff3a99fc207ac5efe6e07878ad59fd4ad5e41f88cb016dacd73

1. カスタムレイヤーイメージを使用するノードを除き、クラスターはバージョン x.y.z+1 に自動的にアップグレードされます。
2. その後、更新された OpenShift Container Platform イメージと以前に適用した RPM を参照する新しい Containerfile を作成できます。
3. 更新されたカスタムレイヤーイメージを指す新しいマシン設定を作成します。