第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-confignamespace でのグローバルプルシークレットまたはプルシークレットへの変更。 -
Kubernetes API Server Operator による
/etc/kubernetes/kubelet-ca.crt認証局 (CA) の自動ローテーション。
-
マシン設定の
MCO は、
/etc/containers/registries.confファイルへの変更 (ImageDigestMirrorSet、ImageTagMirrorSet、または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 は、影響を受けるすべてのノードの設定が更新されるまで、影響を受ける各ノードで次の手順を実行します。
- スケジューリング対象から外します。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 を参照してください。
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\""
Reason: 1 nodes are reporting degraded status on sync
Status: True
Type: 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"
machineconfiguration.openshift.io/state: Degraded
...
以下の修復策のいずれかを実行して、設定ドリフトを修正し、ノードを Ready の状態に戻すことができます。
- ノード上のファイルの内容とパーミッションがマシン設定で設定される内容と一致するようにします。手動でファイルの内容を書き換えたり、ファイルパーミッション変更したりすることができます。
degraded 状態のノードで 強制ファイル を生成します。強制ファイルにより、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 つのノードに現在のまたは目的のマシン設定を適用することをブロックされているか、設定が失敗していることを示します。degraded 状態のノードは、スケジューリングに使用できない場合があります。Falseステータスは、MCP 内のすべてのノードの準備ができていることを示します。 - MACHINECOUNT
- その MCP 内のマシンの総数を示します。
- READYMACHINECOUNT
-
現在のマシン設定を実行しており、スケジューリングの準備ができているマシンの数を示します。この数は常に
UPDATEDMACHINECOUNTの数以下になります。 - UPDATEDMACHINECOUNT
- 現在のマシン設定を持つ MCP 内のマシンの総数を示します。
- DEGRADEDMACHINECOUNT
- degraded または unreconcilable とマークされている、その 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 4h42mMachineConfigPoolカスタムリソースを調べて 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.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 5h18mrenderedとして一覧表示された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.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 のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
手順
次のコマンドを実行して、すべてのマシン設定プールに含まれる全ノードの更新ステータスの概要を取得します。
$ 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-823ff8dc2b33bf444709ed7cd2b9855b1 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-823ff8dc2b33bf444709ed7cd2b9855b2 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-yqRPM パッケージがインストールされていなければ実行できないオプションの手順が含まれています。
手順
次のコマンドを実行して、詳細な証明書情報を取得します。
$ 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