第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 について

5.1.1. Machine Config Operator

目的

Machine Congig Operator は、カーネルと kubelet 間のすべてのものを含め、ベースオペレーティングシステムおよびコンテナーランタイムの設定および更新を管理し、適用します。

以下の 4 つのコンポーネントがあります。

  • machine-config-server: クラスターに参加する新規マシンに Ignition 設定を提供します。
  • machine-config-controller: マシンのアップグレードを MachineConfig オブジェクトで定義される必要な設定に調整します。マシンセットのアップグレードを個別に制御するオプションが提供されます。
  • machine-config-daemon: 更新時に新規のマシン設定を適用します。マシンの状態を要求されたマシン設定に対して検証し、確認します。
  • machine-config: インストール時のマシン設定の完全なソース、初回の起動、およびマシンの更新を提供します。
重要

現在、マシン設定サーバーエンドポイントをブロックまたは制限する方法はサポートされていません。マシン設定サーバーは、既存の設定または状態を持たない新しくプロビジョニングされたマシンが設定を取得できるように、ネットワークに公開する必要があります。このモデルでは、信頼のルートは証明書署名要求 (CSR) エンドポイントであり、kubelet がクラスターに参加するための承認のために証明書署名要求を送信する場所です。このため、シークレットや証明書などの機密情報を配布するためにマシン設定を使用しないでください。

マシン設定サーバーエンドポイント、ポート 22623 および 22624 がベアメタルシナリオで確実に保護されるようにするには、顧客は適切なネットワークポリシーを設定する必要があります。

プロジェクト

openshift-machine-config-operator

5.1.2. マシン設定の概要

Machine Config Operator (MCO) は systemd、CRI-O、Kubelet、カーネル、ネットワークマネージャーその他のシステム機能への更新を管理します。また、これはホストに設定ファイルを書き込むことができる MachineConfig CRD を提供します (machine-config-operator を参照)。MCO の機能や、これが他のコンポーネントとどのように対話するかを理解することは、詳細なシステムレベルの変更を OpenShift Container Platform クラスターに加える上で重要です。以下は、MCO、マシン設定、およびそれらの使用方法について知っておく必要のある点です。

  • マシン設定は、名前のアルファベット順、辞書編集上の昇順に処理されます。レンダーコントローラーは、リストの最初のマシン設定をベースとして使用し、残りをベースマシン設定に追加します。
  • マシン設定は、OpenShift Container Platform ノードのプールを表す各システムのオペレーティングシステムのファイルまたはサービスに特定の変更を加えることができます。
  • MCO はマシンのプールのオペレーティングシステムに変更を適用します。すべての OpenShift Container Platform クラスターについては、ワーカーおよびコントロールプレーンノードプールから始まります。ロールラベルを追加することで、ノードのカスタムプールを設定できます。たとえば、アプリケーションが必要とする特定のハードウェア機能が含まれるワーカーノードのカスタムプールを設定できます。ただし、このセクションの例では、デフォルトのプールタイプの変更に重点を置いています。

    重要

    ノードには、master または worker などの複数のラベルを適用できますが、ノードを 単一 のマシン設定プールのメンバーにすることもできます。

  • Machine Config Operator(MCO) は topology.kubernetes.io/zone ラベルに基づいて、ゾーンによってアルファベット順に影響を受けるノードを更新するようになりました。ゾーンに複数のノードがある場合、最も古いノードが最初に更新されます。ベアメタルデプロイメントなど、ゾーンを使用しないノードの場合、ノードは年齢別にアップグレードされ、最も古いノードが最初に更新されます。MCO は、マシン設定プールの maxUnavailable フィールドで指定されたノード数を一度に更新します。
  • 一部のマシン設定は、OpenShift Container Platform がディスクにインストールされる前に行われる必要があります。ほとんどの場合、これは、インストール後のマシン設定として実行されるのではなく、OpenShift Container Platform インストーラープロセスに直接挿入されるマシン設定を作成して実行できます。他の場合に、ノードごとの個別 IP アドレスの設定や高度なディスクのパーティション設定などを行うには、OpenShift Container Platform インストーラーの起動時にカーネル引数を渡すベアメタルのインストールを実行する必要がある場合があります。
  • MCO はマシン設定で設定される項目を管理します。MCO が競合するファイルを管理することを明示的に指示されない限り、システムに手動で行う変更は MCO によって上書きされることはありません。つまり、MCO は要求される特定の更新のみを行い、ノード全体に対する制御を要求しません。
  • ノードの手動による変更は推奨されません。ノードの使用を中止して新規ノードを起動する必要がある場合は、それらの直接的な変更は失われます。
  • MCO は、/etc および /var ディレクトリーのファイルに書き込みを行う場合にのみサポートされます。ただし、これらの領域のいずれかにシンボリックリンクを指定して書き込み可能になるディレクトリーへのシンボリックリンクもあります。/opt および /usr/local ディレクトリーが例になります。
  • Ignition は MachineConfig で使用される設定形式です。詳細は、Ignition 設定仕様 v3.2.0 を参照してください。
  • Ignition 設定は OpenShift Container Platform のインストール時に直接提供でき、MCO が Ignition 設定を提供するのと同じ方法でフォーマットできますが、MCO では元の Ignition 設定を確認する方法がありません。そのため、それらをデプロイする前に Ignition 設定をマシン設定にラップする必要があります。
  • MCO で管理されるファイルが MCO 外で変更されると、Machine Config Daemon (MCD) はノードを degraded として設定します。これは問題のあるファイルを上書きしませんが、継続して degraded 状態で動作します。
  • マシン設定を使用する主な理由として、これは OpenShift Container Platform クラスターのプールに対して新規ノードを起動する際に適用されます。machine-api-operator は新規マシンをプロビジョニングし、MCO がこれを設定します。

MCO は Ignition を設定形式として使用します。OpenShift Container Platform バージョン 4.6 では、Ignition 設定仕様のバージョン 2 から 3 に移行しています。

5.1.2.1. マシン設定で変更できる設定

MCO で変更できるコンポーネントの種類には、以下が含まれます。

  • config: Ignition 設定オブジェクト (Ignition 設定仕様 を参照してください) を作成し、以下を含む OpenShift Container Platform マシン上でのファイル、systemd サービスおよびその他の機能の変更などを実行できます。

    • Configuration files: /var または /etc ディレクトリーでファイルを作成するか、上書きします。
    • systemd units: systemd サービスを作成し、そのステータスを設定するか、追加設定により既存の systemd サービスに追加します。
    • users and groups: インストール後に passwd セクションで SSH キーを変更します。

      重要
      • マシン設定を使用した SSH キーの変更は、core ユーザーにのみサポートされています。
      • マシン設定を使用した新しいユーザーの追加はサポートされていません。
  • kernelArguments: OpenShift Container Platform ノードの起動時に、引数をカーネルコマンドラインに追加します。
  • kernelType: オプションで、標準カーネルの代わりに使用する標準以外のカーネルを特定します。(RAN の) RT カーネルを使用するには、realtime を使用します。これは一部のプラットフォームでのみサポートされます。64k-pages パラメーターを使用して、64k ページサイズのカーネルを有効にします。この設定は、64 ビット ARM アーキテクチャーを使用するマシンに限定されます。
  • fips: FIPS モードを有効にします。FIPS は、インストール後の手順ではなく、インストール時に設定する必要があります。
重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。

  • extensions: 事前にパッケージ化されたソフトウェアを追加して RHCOS 機能を拡張します。この機能には、利用可能な拡張機能には usbguard およびカーネルモジュールが含まれます。
  • カスタムリソース (ContainerRuntime および Kubelet 用): マシン設定外で、MCO は CRI-O コンテナーランタイムの設定 (ContainerRuntime CR) および Kubelet サービス (Kubelet CR) を変更するために 2 つの特殊なカスタムリソースを管理します。

MCO は、OpenShift Container Platform ノードでオペレーティングシステムコンポーネントを変更できる唯一の Operator という訳ではありません。他の Operator もオペレーティングシステムレベルの機能を変更できます。1 つの例として、Node Tuning Operator を使用して、Tuned デーモンプロファイルを使用したノードレベルのチューニングを実行できます。

インストール後に実行可能な MCO 設定のタスクは、以下の手順に記載されています。OpenShift Container Platform のインストール時またはインストール前に実行する必要のあるシステム設定タスクには、RHCOS ベアメタルのインストールに関する説明を参照してください。

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

5.1.2.2. プロジェクト

詳細は、openshift-machine-config-operator GitHub サイトを参照してください。

5.1.3. 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.4. 設定ドリフト検出について

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

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

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

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

    注記

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

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

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 です。

あるいは、パフォーマンスが低下しているノードが分かっている場合は、そのノードを確認します。

$ 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 の状態に戻すことができます。

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

    注記

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

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

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

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

$ oc delete -f ./myconfig.yaml

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

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

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

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

クラスターに対する 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.7. 証明書の表示と操作

次の証明書はクラスター内で 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 は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.