第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
デーモンセット: クラスターの各ノードで実行され、machine config で定義された設定で、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 が以下の変更のいずれかを検出すると、ノードのドレインまたは再起動を行わずに更新を適用します。
-
マシン設定の
spec.config.passwd.users.sshAuthorizedKeys
パラメーターの SSH キーの変更。 -
openshift-config
namespace でのグローバルプルシークレットまたはプルシークレットへの変更。 -
Kubernetes API Server Operator による
/etc/kubernetes/kubelet-ca.crt
認証局 (CA) の自動ローテーション。
-
マシン設定の
MCO は、
/etc/containers/registries.conf
ファイルへの変更 (ImageDigestMirrorSet
、ImageTagMirrorSet
、またはImageContentSourcePolicy
オブジェクトの追加や編集など) を検出すると、対応するノードをドレインし、変更を適用し、ノードの分離を解除します。次の変更ではノードドレインは発生しません。-
pull-from-mirror = "digest-only"
パラメーターがミラーごとに設定されたレジストリーの追加。 -
pull-from-mirror = "digest-only"
パラメーターがレジストリーに設定されたミラーの追加。 -
unqualified-search-registries
へのアイテムの追加。
-
ノードの設定が、現在適用されている machine config で指定されているものと完全に一致しない場合があります。この状態は 設定ドリフト と呼ばれます。Machine Config Daemon (MCD) は、ノードの設定ドラフトを定期的にチェックします。MCD が設定のドリフトを検出すると、管理者がノード設定を修正するまで、MCO はノードを degraded
とマークします。degraded 状態のノードは、オンラインであり動作中ですが、更新することはできません。
5.1.1. Machine Config Operator ノードのドレイン動作について
マシン設定を使用して、新しい設定ファイルの追加、systemd ユニットまたはカーネル引数の変更、SSH キーの更新などのシステム機能を変更すると、Machine Config Operator (MCO) がそれらの変更を適用し、各ノードが目的の設定状態にあることを確認します。
変更を加えると、MCO は新しくレンダリングされたマシン設定を生成します。ほとんどの場合、新しくレンダリングされたマシン設定を適用するときに、Operator は、影響を受けるすべてのノードの設定が更新されるまで、影響を受ける各ノードで次の手順を実行します。
- 遮断。MCO は、ノードを追加のワークロードに対してスケジュール不可としてマークします。
- ドレイン。MCO は、ノード上で実行中のすべてのワークロードを終了します。その結果、ワークロードが他のノードに再スケジュールされます。
- 適用。MCO は、必要に応じて新しい設定をノードに書き込みます。
- 再起動します。MCO はノードを再起動します。
- 遮断解除。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 を参照してください。
関連情報
- Machine Config Operator の自動再起動の無効化
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 は検出がトリガーされてから 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 ...
あるいは、パフォーマンスが低下しているノードが分かっている場合は、そのノードを確認します。
$ 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 ...
以下の修復策のいずれかを実行して、設定ドリフトを修正し、ノードを Ready
の状態に戻すことができます。
- ノード上のファイルの内容とパーミッションがマシン設定で設定される内容と一致するようにします。手動でファイルの内容を書き換えたり、ファイルパーミッション変更したりすることができます。
パフォーマンスが低下したノードで 強制ファイル を生成します。強制ファイルにより、MCD は通常の設定ドリフトの検出をバイパスし、現在のマシン設定を再度適用します。
注記ノード上で強制ファイルを生成すると、そのノードが再起動されます。
5.1.3. マシン設定プールのステータスの確認
Machine Config Operator (MCO)、そのサブコンポーネント、およびこれが管理するリソースのステータスを表示するには、以下の oc
コマンドを使用します。
手順
各マシン設定プール (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
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
既存の各
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
オブジェクトが変更されたり、削除されたりすることが意図されていないことに注意してください。特定のマシン設定 (この場合は
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.4. マシン設定ノードのステータスの確認
更新中は、問題が発生してノードのトラブルシューティングが必要になる場合に備えて、個々のノードの進行状況を監視することをお勧めします。
クラスターに対する Machine Config Operator (MCO) 更新のステータスを確認するには、次の oc
コマンドを使用します。
改良版の MCO 状態レポート機能は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
手順
次のコマンドを実行して、すべてのマシン設定プールに含まれる全ノードの更新ステータスの概要を取得します。
$ 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 次フェーズは常に発生するわけではなく、適用する更新の種類によって異なります。
次のコマンドを実行して、特定のマシン設定プールに含まれるノードの更新ステータスを確認します。
$ 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
次のコマンドを実行して、個々のノードの更新ステータスを確認します。
$ 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
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 アプリケーションを対象としています。
ノード上にあるイメージレジストリー証明書を確認します。
ノードにログインします。
$ oc debug node/<node_name>
/host
をデバッグシェル内のルートディレクトリーとして設定します。sh-5.1# chroot /host
/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