第5章 インストール後のマシン設定タスク


OpenShift Container Platform ノードで実行しているオペレーティングシステムに変更を加える必要がある場合があります。これには、ネットワークタイムサービスの設定変更、カーネル引数の追加、特定の方法でのジャーナルの設定などが含まれます。

いくつかの特殊な機能のほかに、OpenShift Container Platform ノードのオペレーティングシステムへの変更のほとんどは、Machine Config Operator によって管理される MachineConfig オブジェクトというオブジェクトを作成することで実行できます。

このセクションのタスクでは、Machine Config Operator の機能を使用して OpenShift Container Platform ノードでオペレーティングシステム機能を設定する方法を説明します。

重要

NetworkManager は、新しいネットワーク設定を鍵ファイル形式で /etc/NetworkManager/system-connections/ に保存します。

以前は、NetworkManager が、新しいネットワーク設定を ifcfg 形式で /etc/sysconfig/network-scripts/ に保存していました。RHEL 9.0 以降では、RHEL は新しいネットワーク設定を鍵ファイル形式で /etc/NetworkManager/system-connections/ に保存します。以前の形式で /etc/sysconfig/network-scripts/ に保存された接続設定は、引き続き中断されることなく動作します。既存のプロファイルに変更を加えると、そのまま以前のファイルが更新されます。

5.1. Machine Config Operator について

OpenShift Container Platform 4.15 は、オペレーティングシステムとクラスター管理を統合します。クラスターは、クラスターノードでの Red Hat Enterprise Linux CoreOS (RHCOS) への更新を含め、独自の更新を管理するため、OpenShift Container Platform では事前に設定されたライフサイクル管理が実行され、ノードのアップグレードのオーケストレーションが単純化されます。

OpenShift Container Platform は、ノードの管理を単純化するために 3 つのデーモンセットとコントローラーを採用しています。これらのデーモンセットは、Kubernetes 形式のコンストラクトを使用してオペレーティングシステムの更新とホストの設定変更をオーケストレーションします。これには、以下が含まれます。

  • machine-config-controller: コントロールプレーンからマシンのアップグレードを調整します。すべてのクラスターノードを監視し、その設定の更新をオーケストレーションします。
  • machine-config-daemon デーモンセット: クラスターの各ノードで実行され、マシン設定で定義された設定で、MachineConfigController の指示通りにマシンを更新します。 ノードは、変更を検知すると Pod からドレイン (解放) され、更新を適用して再起動します。これらの変更は、指定されたマシン設定を適用し、kubelet 設定を制御する Ignition 設定ファイルの形式で実行されます。更新自体はコンテナーで行われます。このプロセスは、OpenShift Container Platform と RHCOS の更新を同時に管理する際に不可欠です。
  • machine-config-server デーモンセット: コントロールプレーンノードがクラスターに参加する際に Ignition 設定ファイルをコントロールプレーンノードに提供します。

このマシン設定は Ignition 設定のサブセットです。machine-config-daemon はマシン設定を読み取り、OSTree の更新を行う必要があるか、一連の systemd kubelet ファイルの変更、設定の変更、オペレーティングシステムまたは OpenShift Container Platform 設定へのその他の変更などを適用する必要があるかを確認します。

ノード管理操作の実行時に、KubeletConfig カスタムリソース (CR) を作成または変更します。

重要

マシン設定への変更が行われると、Machine Config Operator (MCO) は変更を有効にするために、対応するすべてのノードを自動的に再起動します。

マシン設定の変更後、変更が適用される前にノードが自動的に起動されないようにするには、対応する machine config pool で spec.paused フィールドを true に設定して自動再起動プロセスを一時停止する必要があります。一時停止すると、spec.paused フィールドを false に設定し、ノードが新しい設定で再起動されるまで、マシン設定の変更は適用されません。

  • MCO が以下の変更のいずれかを検出すると、ノードの drain (Pod の退避) の実行または再起動を行わずに更新を適用します。

    • マシン設定の spec.config.passwd.users.sshAuthorizedKeys パラメーターの SSH キーの変更。
    • openshift-config namespace でのグローバルプルシークレットまたはプルシークレットへの変更。
    • Kubernetes API Server Operator による /etc/kubernetes/kubelet-ca.crt 認証局 (CA) の自動ローテーション。
  • MCO は、/etc/containers/registries.conf ファイルへの変更 (ImageDigestMirrorSetImageTagMirrorSet、または ImageContentSourcePolicy オブジェクトの編集など) を検出すると、対応するノードの drain (Pod の退避) を実行し、変更を適用して、ノードをスケジューリング対象に戻します。次の変更ではノードの drain (Pod の退避) の実行は発生しません。

    • pull-from-mirror = "digest-only" パラメーターがミラーごとに設定されたレジストリーの追加。
    • pull-from-mirror = "digest-only" パラメーターがレジストリーに設定されたミラーの追加。
    • unqualified-search-registries へのアイテムの追加。

ノードの設定が、現在適用されているマシン設定で指定されているものと完全に一致しない場合があります。この状態は 設定ドリフト と呼ばれます。Machine Config Daemon (MCD) は、ノードの設定ドリフトを定期的にチェックします。MCD が設定のドリフトを検出すると、管理者がノード設定を修正するまで、MCO はノードを degraded とマークします。degraded 状態のノードは、オンライン状態で動作していますが、更新することはできません。

5.1.1. Machine Config Operator ノードのドレイン動作について

マシン設定を使用して、新しい設定ファイルの追加、systemd ユニットまたはカーネル引数の変更、SSH キーの更新などのシステム機能を変更すると、Machine Config Operator (MCO) がそれらの変更を適用し、各ノードが目的の設定状態にあることを確認します。

変更を加えると、MCO は新しくレンダリングされたマシン設定を生成します。ほとんどの場合、新しくレンダリングされたマシン設定を適用するときに、Operator は、影響を受けるすべてのノードの設定が更新されるまで、影響を受ける各ノードで次の手順を実行します。

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

このプロセス全体を通じて、MCO はマシン設定プールで設定された MaxUnavailable 値に基づいて必要な数の Pod を維持します。

注記

MCO によるノードのドレインを防止できる条件があります。MCO がノードのドレインに失敗すると、Operator はノードを再起動できず、マシン設定を通じてノードに変更を加えることができなくなります。詳細情報と対応手順は、MCCDrainError ランブックを参照してください。

MCO がマスターノード上の Pod をドレインする場合は、次の条件に注意してください。

  • シングルノードの OpenShift クラスターでは、MCO はドレイン操作をスキップします。
  • MCO は、etcd などのサービスへの干渉を防ぐために、静的 Pod をドレインしません。
注記

場合によっては、ノードがドレインされないことがあります。詳細は、「Machine Config Operator について」を参照してください。

コントロールプレーンの再起動を無効にすることで、ドレイン(解放)および再起動サイクルによって引き起こされる中断を軽減できます。詳細は、Disabling the Machine Config Operator from automatically rebooting を参照してください。

5.1.2. 設定ドリフト検出について

ノードのディスク上の状態がマシン設定で設定される内容と異なる場合があります。これは、設定ドリフト と呼ばれます。たとえば、クラスター管理者は、マシン設定で設定されたファイル、systemd ユニットファイル、またはファイルパーミッションを手動で変更する場合があります。これにより、設定のドリフトが発生します。設定ドリフトにより、Machine Config Pool のノード間で問題が発生したり、マシン設定が更新されると問題が発生したりする可能性があります。

Machine Config Operator (MCO) は Machine Config Daemon (MCD) を使用して、設定ドリフトがないかノードを定期的に確認します。検出されると、MCO はノードおよびマシン設定プール (MCP) を Degraded に設定し、エラーを報告します。degraded 状態のノードは、オンライン状態で動作していますが、更新することはできません。

MCD は、以下の条件の時に設定ドリフトの検出を実行します。

  • ノードがブートする時。
  • マシン設定で指定されたファイル (Ignition ファイルと systemd ドロップインユニット) がマシン設定以外で変更された後。
  • 新しいマシン設定が適用される前。

    注記

    新しいマシン設定をノードに適用すると、MCD は設定ドリフトの検出を一時的に停止します。新しいマシン設定はノード上のマシン設定とは必ず異なるため、この停止処理が必要です。新しいマシン設定が適用された後に、MCD は新しいマシン設定を使用して設定ドリフトの検出を再開します。

設定ドリフトの検出を実行する際に、MCD はファイルの内容とパーミッションが、現在適用されているマシン設定で指定されるものに完全に一致することを確認します。通常、MCD は検出がトリガーされてから 1 秒未満で設定ドリフトを検出します。

MCD が設定ドリフトを検出すると、MCD は以下のタスクを実行します。

  • コンソールログにエラーを出力する
  • Kubernetes イベントを生成する
  • ノードでのそれ以上の検出を停止する
  • ノードと MCP を degraded に設定する

MCP をリスト表示することで、デグレード状態のノードがあるかどうかを確認できます。

$ oc get mcp worker

デグレード状態の MCP がある場合、DEGRADEDMACHINECOUNT フィールドの値がゼロ以外になり、次の出力のようになります。

出力例

NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
worker   rendered-worker-404caf3180818d8ac1f50c32f14b57c3   False     True       True       2              1                   1                     1                      5h51m

マシン設定プールを調べることで、設定ドリフトによって問題が発生しているかどうかを判別できます。

$ oc describe mcp worker

出力例

 ...
    Last Transition Time:  2021-12-20T18:54:00Z
    Message:               Node ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4 is reporting: "content mismatch for file \"/etc/mco-test-file\"" 
1

    Reason:                1 nodes are reporting degraded status on sync
    Status:                True
    Type:                  NodeDegraded 
2

 ...

1
このメッセージは、マシン設定によって追加されたノードの /etc/mco-test-file ファイルが、マシン設定外で変更されていることを示しています。
2
ノードの状態は NodeDegraded です。

あるいは、degraded 状態のノードがわかっている場合は、そのノードを確認します。

$ oc describe node/ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4

出力例

 ...

Annotations:        cloud.network.openshift.io/egress-ipconfig: [{"interface":"nic0","ifaddr":{"ipv4":"10.0.128.0/17"},"capacity":{"ip":10}}]
                    csi.volume.kubernetes.io/nodeid:
                      {"pd.csi.storage.gke.io":"projects/openshift-gce-devel-ci/zones/us-central1-a/instances/ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4"}
                    machine.openshift.io/machine: openshift-machine-api/ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4
                    machineconfiguration.openshift.io/controlPlaneTopology: HighlyAvailable
                    machineconfiguration.openshift.io/currentConfig: rendered-worker-67bd55d0b02b0f659aef33680693a9f9
                    machineconfiguration.openshift.io/desiredConfig: rendered-worker-67bd55d0b02b0f659aef33680693a9f9
                    machineconfiguration.openshift.io/reason: content mismatch for file "/etc/mco-test-file" 
1

                    machineconfiguration.openshift.io/state: Degraded 
2

 ...

1
エラーメッセージは、ノードとリスト表示されたマシン設定の間で設定ドリフトが検出されたことを示しています。このエラーメッセージは、マシン設定によって追加された /etc/mco-test-file の内容が、マシン設定以外で変更されていることを示しています。
2
ノードの状態は Degraded です。

以下の修復策のいずれかを実行して、設定ドリフトを修正し、ノードを Ready の状態に戻すことができます。

  • ノード上のファイルの内容とパーミッションがマシン設定で設定される内容と一致するようにします。手動でファイルの内容を書き換えたり、ファイルパーミッション変更したりすることができます。
  • degraded 状態のノードで 強制ファイル を生成します。強制ファイルにより、MCD は通常の設定ドリフトの検出をバイパスし、現在のマシン設定を再度適用します。

    注記

    ノード上で強制ファイルを生成すると、そのノードが再起動されます。

5.1.3. マシン設定プールのステータスの確認

Machine Config Operator (MCO)、そのサブコンポーネント、およびこれが管理するリソースのステータスを表示するには、以下の oc コマンドを使用します。

手順

  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 つのノードに現在のまたは目的のマシン設定を適用することをブロックされているか、設定が失敗していることを示します。degraded 状態のノードは、スケジューリングに使用できない場合があります。False ステータスは、MCP 内のすべてのノードの準備ができていることを示します。
    MACHINECOUNT
    その MCP 内のマシンの総数を示します。
    READYMACHINECOUNT
    現在のマシン設定を実行しており、スケジューリングの準備ができているマシンの数を示します。この数は常に UPDATEDMACHINECOUNT の数以下になります。
    UPDATEDMACHINECOUNT
    現在のマシン設定を持つ MCP 内のマシンの総数を示します。
    DEGRADEDMACHINECOUNT
    degraded または unreconcilable とマークされている、その MCP 内のマシンの総数を示します。

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

    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.4.0            5h18m
    00-worker                        2c9371fbb673b97a6fe8b1c52...   3.4.0            5h18m
    01-master-container-runtime      2c9371fbb673b97a6fe8b1c52...   3.4.0            5h18m
    01-master-kubelet                2c9371fbb673b97a6fe8b1c52…     3.4.0            5h18m
    ...
    rendered-master-dde...           2c9371fbb673b97a6fe8b1c52...   3.4.0            5h18m
    rendered-worker-fde...           2c9371fbb673b97a6fe8b1c52...   3.4.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.4.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 \ ...

適用するマシン設定で問題が発生した場合は、この変更を常に取り消すことができます。たとえば、oc create -f ./myconfig.yaml を実行してマシン設定を適用した場合、次のコマンドを実行してそのマシン設定を削除できます。

$ oc delete -f ./myconfig.yaml

これが唯一の問題である場合、影響を受けるプールのノードは degraded 以外の状態に戻るはずです。これにより、レンダリングされた設定は、直前のレンダリングされた状態にロールバックされます。

独自のマシン設定をクラスターに追加する場合、直前の例に示されたコマンドを使用して、それらのステータスと、それらが適用されるプールの関連するステータスを確認できます。

5.1.4. マシン設定ノードのステータスの確認

更新中は、問題が発生してノードのトラブルシューティングが必要になる場合に備えて、個々のノードの進行状況を監視することをお勧めします。

クラスターに対する Machine Config Operator (MCO) 更新のステータスを確認するには、次の oc コマンドを使用します。

重要

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

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

手順

  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 オプションを使用すると、更新の二次フェーズを含む詳細情報を取得できます。これにより、UPDATECOMPATIBLEUPDATEFILESANDOSDRAINEDNODECORDONEDNODEREBOOTNODERELOADEDCRIO、および 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 フェーズを正常に通過すると、ステータスに新しい設定が追加されます。

5.1.5. 証明書の表示と操作

次の証明書はクラスター内で Machine Config Controller (MCC) によって処理され、ControllerConfig リソースにあります。

  • /etc/kubernetes/kubelet-ca.crt
  • /etc/kubernetes/static-pod-resources/configmaps/cloud-config/ca-bundle.pem
  • /etc/pki/ca-trust/source/anchors/openshift-config-user-ca-bundle.crt

MCC は、イメージレジストリー証明書とそれに関連するユーザーバンドル証明書も処理します。

証明書の元となる基礎バンドル、署名データとサブジェクトデータなど、リストされた証明書に関する情報を取得できます。

前提条件

  • この手順には、python-yq RPM パッケージがインストールされていなければ実行できないオプションの手順が含まれています。

手順

  • 次のコマンドを実行して、詳細な証明書情報を取得します。

    $ oc get controllerconfig/machine-config-controller -o yaml | yq -y '.status.controllerCertificates'

    出力例

    - bundleFile: KubeAPIServerServingCAData
      notAfter: '2034-10-23T13:13:02Z'
      notBefore: '2024-10-25T13:13:02Z'
      signer: CN=admin-kubeconfig-signer,OU=openshift
      subject: CN=admin-kubeconfig-signer,OU=openshift
    - bundleFile: KubeAPIServerServingCAData
      notAfter: '2024-10-26T13:13:05Z'
      notBefore: '2024-10-25T13:27:14Z'
      signer: CN=kubelet-signer,OU=openshift
      subject: CN=kube-csr-signer_@1729862835
    - bundleFile: KubeAPIServerServingCAData
      notAfter: '2024-10-26T13:13:05Z'
      notBefore: '2024-10-25T13:13:05Z'
      signer: CN=kubelet-signer,OU=openshift
      subject: CN=kubelet-signer,OU=openshift
    # ...

  • 次のコマンドを使用してマシン設定プールのステータスを確認し、ControllerConfig リソースで見つかった情報のより単純なバージョンを取得します。

    $ oc get mcp master -o yaml | yq -y '.status.certExpirys'

    出力例

    - bundle: KubeAPIServerServingCAData
      expiry: '2034-10-23T13:13:02Z'
      subject: CN=admin-kubeconfig-signer,OU=openshift
    - bundle: KubeAPIServerServingCAData
      expiry: '2024-10-26T13:13:05Z'
      subject: CN=kube-csr-signer_@1729862835
    - bundle: KubeAPIServerServingCAData
      expiry: '2024-10-26T13:13:05Z'
      subject: CN=kubelet-signer,OU=openshift
    - bundle: KubeAPIServerServingCAData
      expiry: '2025-10-25T13:13:05Z'
      subject: CN=kube-apiserver-to-kubelet-signer,OU=openshift
    # ...

    このメソッドは、マシン設定プール情報をすでに使用している OpenShift Container Platform アプリケーションを対象としています。

  • ノード上にあるイメージレジストリー証明書を確認します。

    1. ノードにログインします。

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

      sh-5.1# chroot /host
    3. /etc/docker/cert.d ディレクトリーの内容を確認します。

      sh-5.1# ls /etc/docker/certs.d

      出力例

      image-registry.openshift-image-registry.svc.cluster.local:5000
      image-registry.openshift-image-registry.svc:5000

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hat
トップに戻る