Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

トラブルシューティング

Red Hat build of MicroShift 4.18

一般的な問題のトラブルシューティング

Red Hat OpenShift Documentation Team

概要

Red Hat build of MicroShift に関する一般的な問題のトラブルシューティングに関する情報。

第1章 インストールされているバージョンの確認
リンクのコピー

トラブルシューティングを開始するには、インストールされている Red Hat build of MicroShift のバージョンを確認します。

1.1. コマンドラインインターフェイスを使用したバージョンの確認
リンクのコピー

トラブルシューティングを開始するには、MicroShift のバージョンを知っている必要があります。この情報を取得する方法として、CLI を使用する方法があります。

手順

  • 次のコマンドを実行して、バージョン情報を確認します。 

    $ microshift version
    Copy to Clipboard Toggle word wrap

    出力例

    Red Hat build of MicroShift Version: 4.18-0.microshift-e6980e25
Base OCP Version: 4.18
    Copy to Clipboard Toggle word wrap

1.2. API を使用した MicroShift バージョンの確認
リンクのコピー

トラブルシューティングを開始するには、MicroShift のバージョンを知っている必要があります。この情報を取得する方法として、API を使用する方法があります。

手順

  • OpenShift CLI (oc) を使用してバージョン番号を取得するには、次のコマンドを実行して kube-public/microshift-version 設定マップを表示します。 

    $ oc get configmap -n kube-public microshift-version -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: v1
data:
  major: "4"
  minor: "13"
  version: 4.13.8-0.microshift-fa441af87431
kind: ConfigMap
metadata:
  creationTimestamp: "2023-08-03T21:06:11Z"
  name: microshift-version
  namespace: kube-public
    Copy to Clipboard Toggle word wrap

1.3. etcd のバージョンの確認
リンクのコピー

必要な情報のレベルに応じて、次のいずれかまたは両方の方法を使用して、MicroShift に含まれている etcd データベースのバージョン情報を取得できます。

手順

  • ベースデータベースのバージョン情報を表示するには、次のコマンドを実行します。 

    $ microshift-etcd version
    Copy to Clipboard Toggle word wrap

    出力例

    microshift-etcd Version: 4.17.1
Base etcd Version: 3.5.13
    Copy to Clipboard Toggle word wrap

  • データベースの完全なバージョン情報を表示するには、次のコマンドを実行します。 

    $ microshift-etcd version -o json
    Copy to Clipboard Toggle word wrap

    出力例

    {
  "major": "4",
  "minor": "16",
  "gitVersion": "4.17.1~rc.1",
  "gitCommit": "140777711962eb4e0b765c39dfd325fb0abb3622",
  "gitTreeState": "clean",
  "buildDate": "2024-05-10T16:37:53Z",
  "goVersion": "go1.21.9"
  "compiler": "gc",
  "platform": "linux/amd64",
  "patch": "",
  "etcdVersion": "3.5.13"
}
    Copy to Clipboard Toggle word wrap

第2章 ノードのトラブルシューティング
リンクのコピー

MicroShift ノードのトラブルシューティングを開始するには、まずノードのステータスにアクセスします。

2.1. ノードのステータス確認
リンクのコピー

MicroShift ノードのステータスを確認したり、アクティブな Pod を確認したりできます。ノードのトラブルシューティングに必要な情報を取得するには、次のコマンドの一部またはすべてを実行します。

手順

  • 次のコマンドを実行して、ノードのステータスを返すシステムステータスを確認します。 

    $ sudo systemctl status microshift
    Copy to Clipboard Toggle word wrap

    MicroShift の起動に失敗した場合、このコマンドは前回の実行からのログを返します。

    正常な出力の例

    ● microshift.service - MicroShift
     Loaded: loaded (/usr/lib/systemd/system/microshift.service; enabled; preset: disabled)
     Active: active (running) since <day> <date> 12:39:06 UTC; 47min ago
   Main PID: 20926 (microshift)
      Tasks: 14 (limit: 48063)
     Memory: 542.9M
        CPU: 2min 41.185s
     CGroup: /system.slice/microshift.service
             └─20926 microshift run

<Month-Day> 13:23:06 i-06166fbb376f14a8b.<hostname> microshift[20926]: kube-apiserver I0528 13:23:06.876001   20926 controll>
<Month-Day> 13:23:06 i-06166fbb376f14a8b.<hostname> microshift[20926]: kube-apiserver I0528 13:23:06.876574   20926 controll>
# ...
    Copy to Clipboard Toggle word wrap

  • オプション: 次のコマンドを実行して包括的なログを取得します。 

    $ sudo journalctl -u microshift
    Copy to Clipboard Toggle word wrap
    注記

    systemd ジャーナルサービスのデフォルト設定では、データは揮発性ディレクトリーに保存されます。システムの再起動後もシステムログを保持するには、ログの保持を有効にし、最大ジャーナルデータサイズの制限を設定します。

  • オプション: MicroShift が実行中の場合は、次のコマンドを入力してアクティブな Pod のステータスを確認します。 

    $ oc get pods -A
    Copy to Clipboard Toggle word wrap

    出力例

    NAMESPACE                   NAME                                                     READY   STATUS   RESTARTS  AGE
default                     i-06166fbb376f14a8bus-west-2computeinternal-debug-qtwcr  1/1     Running  0		    46m
kube-system                 csi-snapshot-controller-5c6586d546-lprv4                 1/1     Running  0		    51m
openshift-dns               dns-default-45jl7                                        2/2     Running  0		    50m
openshift-dns               node-resolver-7wmzf                                      1/1     Running  0		    51m
openshift-ingress           router-default-78b86fbf9d-qvj9s                          1/1     Running  0		    51m
openshift-ovn-kubernetes    ovnkube-master-5rfhh                                     4/4     Running  0		    51m
openshift-ovn-kubernetes    ovnkube-node-gcnt6                                       1/1     Running  0		    51m
openshift-service-ca        service-ca-bf5b7c9f8-pn6rk                               1/1     Running  0		    51m
openshift-storage           topolvm-controller-549f7fbdd5-7vrmv                      5/5     Running  0		    51m
openshift-storage           topolvm-node-rht2m                                       3/3     Running  0		    50m
    Copy to Clipboard Toggle word wrap

    注記

    この出力例は、基本的な MicroShift インストールを示しています。オプションの RPM をインストールした場合は、それらのサービスを実行している Pod のステータスも出力に表示されることが予想されます。

第3章 インストールの問題のトラブルシューティング
リンクのコピー

MicroShift インストールが失敗した場合にトラブルシューティングを行うには、sos report を実行します。sos report コマンドを使用して、システム内のさまざまなコンポーネントやアプリケーションからの有効なプラグインとデータをすべて表示する詳細レポートを生成します。

3.1. sos レポートからのデータの収集
リンクのコピー

前提条件

  • sos パッケージがインストールされている。

手順

  1. 障害が発生したホストに root ユーザーとしてログインします。

  2. 次のコマンドを実行して、デバッグレポートの作成手順を実行します。 

    $ microshift-sos-report
    Copy to Clipboard Toggle word wrap

    出力例

    sosreport (version 4.5.1)

This command will collect diagnostic and configuration information from
this Red Hat Enterprise Linux system and installed applications.

An archive containing the collected information will be generated in
/var/tmp/sos.o0sznf_8 and may be provided to a Red Hat support
representative.

Any information provided to Red Hat will be treated in accordance with
the published support policies at:

        Distribution Website : https://www.redhat.com/
        Commercial Support   : https://www.access.redhat.com/

The generated archive may contain data considered sensitive and its
content should be reviewed by the originating organization before being
passed to any third party.

No changes will be made to system configuration.


 Setting up archive ...
 Setting up plugins ...
 Running plugins. Please wait ...

  Starting 1/2   microshift      [Running: microshift]
  Starting 2/2   microshift_ovn  [Running: microshift microshift_ovn]
  Finishing plugins              [Running: microshift]

  Finished running plugins

Found 1 total reports to obfuscate, processing up to 4 concurrently

sosreport-microshift-rhel9-2023-03-31-axjbyxw :    Beginning obfuscation...
sosreport-microshift-rhel9-2023-03-31-axjbyxw :    Obfuscation completed

Successfully obfuscated 1 report(s)

Creating compressed archive...

A mapping of obfuscated elements is available at
	/var/tmp/sosreport-microshift-rhel9-2023-03-31-axjbyxw-private_map

Your sosreport has been generated and saved in:
	/var/tmp/sosreport-microshift-rhel9-2023-03-31-axjbyxw-obfuscated.tar.xz

 Size	444.14KiB
 Owner	root
 sha256	922e5ff2db25014585b7c6c749d2c44c8492756d619df5e9838ce863f83d4269

Please send this file to your support representative.
    Copy to Clipboard Toggle word wrap

第4章 データのバックアップと復元のトラブルシューティング
リンクのコピー

データのバックアップと復元に失敗した場合のトラブルシューティングを行うには、まずデータパス、ストレージ設定、ストレージ容量などの基本事項を確認します。

4.1. データバックアップの失敗
リンクのコピー

rpm-ostree システムではデータのバックアップが自動的に行われます。rpm-ostree システムを使用せずに手動バックアップを作成しようとした場合、次の理由によりバックアップが失敗する可能性があります。

  • システムの起動後、数分間待たずに MicroShift を正常に停止したため。バックアップを正常に実行するには、システムがヘルスチェックとその他のバックグラウンドプロセスを完了する必要があります。

  • MicroShift がエラーのために実行を停止した場合、データのバックアップを実行することはできません。

    • システムが健全な状態であることを確認してください。
    • バックアップを試みる前に、健全な状態で停止してください。
  • データ用の十分なストレージがない場合、バックアップは失敗します。MicroShift データ用に十分なストレージがあることを確認してください。
  • 十分な権限がない場合、バックアップが失敗する可能性があります。バックアップの作成および必要な設定を実行するための正しいユーザー権限があることを確認してください。

4.2. バックアップログ
リンクのコピー

  • 手動バックアップ中にログが端末コンソールに出力されます。

  • rpm-ostree システムの自動バックアップのログは、MicroShift ジャーナルログの一部として自動的に生成されます。次のコマンドを実行してログを確認できます。 

    $ sudo journalctl -u microshift
    Copy to Clipboard Toggle word wrap

4.3. データ復元の失敗
リンクのコピー

データの復元は、ストレージや権限の問題など、さまざまな理由で失敗する可能性があります。データのバージョンが一致しないと、MicroShift の再起動時に障害が発生する可能性があります。

4.3.1. RPM-OSTree ベースのシステムデータ復元の失敗
リンクのコピー

データの復元は rpm-ostree システムでは自動的に行われますが、次のように失敗する可能性があります。

  • rpm-ostree システムで復元されるバックアップは、現在のデプロイメントまたはロールバックデプロイメントからのバックアップのみです。異常なシステムではバックアップは作成されません。

    • 対応するデプロイメントがある最新のバックアップのみが保持されます。対応するデプロイメントがない古いバックアップは自動的に削除されます。
    • 通常、データが後のバージョンの MicroShift から復元されることはありません。
    • 復元するデータが更新パスと同じバージョン管理パターンに従っていることを確認してください。たとえば、復元先の MicroShift のバージョンが、現在使用している MicroShift データのバージョンよりも古いバージョンである場合、復元が失敗する可能性があります。

4.3.2. RPM ベースの手動データ復元の失敗
リンクのコピー

rpm-ostree ではない RPM システムを使用しており、手動バックアップを復元しようとした場合、次の理由により復元が失敗する可能性があります。

  • MicroShift がエラーのために実行を停止した場合、データを復元することはできません。

    • システムが健全な状態であることを確認してください。
    • データの復元を試みる前に、健全な状態で起動してください。

  • 受信するデータ用に十分なストレージ領域が割り当てられていない場合、復元は失敗します。

    • 現在のシステムストレージが復元されたデータを受け入れるように設定されていることを確認してください。

  • 後のバージョンの MicroShift からデータを復元しようとしたため。

    • 復元するデータが更新パスと同じバージョン管理パターンに従っていることを確認してください。たとえば、復元先の MicroShift のバージョンが、使用しようとしている MicroShift データのバージョンよりも古いバージョンである場合、復元が失敗する可能性があります。

4.4. ストレージ移行の失敗
リンクのコピー

通常、ストレージ移行の失敗は、ある MicroShift から次の MicroShift へのカスタムリソース (CR) の大幅な変更によって発生します。ストレージ移行が失敗した場合は、通常、バージョン間に解決できない不一致があり、手動での確認が必要になります。

第5章 更新のトラブルシューティング
リンクのコピー

MicroShift の更新のトラブルシューティングを行うには、更新パスの確認、ジャーナルと greenboot のヘルスチェックログの確認、更新の問題を解決するためのその他の手法を実行します。

5.1. MicroShift の更新のトラブルシューティング
リンクのコピー

場合によっては、MicroShift の更新に失敗することがあります。そのような場合に備えて、障害の種類とそのトラブルシューティング方法を理解しておくと役立ちます。

5.1.1. MicroShift バージョンの更新順序が原因で更新パスを使用できない
リンクのコピー

MicroShift の非 EUS バージョンではシリアル更新が必要です。たとえば、MicroShift 4.15.5 から 4.17.1 に直接更新しようとすると、更新は失敗します。4.15.5 を 4.16.z に更新してから、4.16.z から 4.17.0 に更新する必要があります。

5.1.2. バージョンの互換性がなく更新パスを使用できない
リンクのコピー

MicroShift の更新と、Red Hat Enterprise Linux for Edge (RHEL for Edge) または Red Hat Enterprise Linux (RHEL) のバージョンとの間で互換性がない場合、RPM 依存関係エラーが発生します。次の互換性に関する表を確認してください。

Red Hat Device Edge リリースの互換性に関する表

Red Hat Enterprise Linux (RHEL) と MicroShift は、device-edge コンピューティング向けの単一のソリューションとして連携します。各コンポーネントを個別に更新できますが、製品バージョンの互換性を確保する必要があります。次の表に示すように、Red Hat Device Edge のサポート対象設定では、それぞれ検証済みのリリースが使用されます。

Expand
RHEL バージョンMicroShift バージョンサポートされている MicroShift バージョン → バージョンの更新

9.4

4.18

4.18.0 → 4.18.z

9.4

4.17

4.17.1 → 4.17.z, 4.17 → 4.18

9.4

4.16

4.16.0 → 4.16.z, 4.16 → 4.17, 4.16 → 4.18

9.2、9.3

4.15

RHEL 9.4 の 4.15.0 → 4.15.z, 4.15 → 4.16

9.2、9.3

4.14

RHEL 9.4 の 4.14.0 → 4.14.z, 4.14 → 4.15, 4.14 → 4.16

5.1.2.1. バージョンの互換性
リンクのコピー

次の更新パスを確認してください。

Red Hat build of MicroShift の更新パス

  • RHEL 9.4 の場合、一般提供バージョン 4.18.0 から 4.18.z
  • RHEL 9.4 の場合、一般提供バージョン 4.17.1 から 4.17.z
  • 一般提供バージョン 4.15.0 (RHEL 9.2) から 4.16.0 (RHEL 9.4) へ
  • 一般提供バージョン 4.14.0 (RHEL 9.2) から 4.15.0 (RHEL 9.4) へ

5.1.3. RHEL for Edge の更新に失敗した
リンクのコピー

rpm-ostree システムで更新した場合、greenboot ヘルスチェックが自動的にログを記録し、システムの健全性に基づいて動作します。greenboot によるシステムロールバックは更新の失敗を示している可能性があります。更新が失敗しても、Greenboot がシステムのロールバックを完了しなかった場合は、「関連情報」セクションにある RHEL for Edge ドキュメントへのリンクを使用してトラブルシューティングを行うことができます。

  • 次のコマンドを実行して、greenboot ログを手動でチェックしてシステムの健全性を確認します。 

    $ sudo systemctl restart --no-block greenboot-healthcheck && sudo journalctl -fu greenboot-healthcheck
    Copy to Clipboard Toggle word wrap

5.1.4. RPM 手動更新の失敗
リンクのコピー

OSTree 以外のシステムで RPM を使用して更新した場合、greenboot は更新の失敗を示すことがありますが、ヘルスチェックは情報提供のみとなります。RPM 手動更新の失敗をトラブルシューティングする際には、次のステップとして、システムログを確認します。greenboot と sos report ツールを使用して、MicroShift 更新とホストシステムの両方を確認できます。

5.2. 更新後のジャーナルログの確認
リンクのコピー

ジャーナルログは、MicroShift 更新の失敗の診断に役立ちます。systemd ジャーナルサービスのデフォルト設定では、データは揮発性ディレクトリーに保存されます。システムの再起動後もシステムログを保持するには、ログの保持を有効にし、最大ジャーナルデータサイズの制限を設定します。

手順

  • 次のコマンドを実行して、包括的な MicroShift ジャーナルログを取得します。 

    $ sudo journalctl -u microshift
    Copy to Clipboard Toggle word wrap

  • 次のコマンドを実行して、greenboot ジャーナルログを確認します。 

    $ sudo journalctl -u greenboot-healthcheck
    Copy to Clipboard Toggle word wrap

  • 特定のブートの詳しいログを調べるには、次の 2 つのステップを使用します。まずブートをリストし、取得したリストから必要なものを選択します。

    • 次のコマンドを実行して、ジャーナルログに存在するブートをリスト表示します。 

      $ sudo journalctl --list-boots
      Copy to Clipboard Toggle word wrap

      出力例

      IDX  BOOT ID                          	FIRST ENTRY                 LAST ENTRY
 0   681ece6f5c3047e183e9d43268c5527f 	<Day> <Date> 12:27:58 UTC 	<Day> <Date>> 13:39:41 UTC
#....
      Copy to Clipboard Toggle word wrap

    • 次のコマンドを実行して、ジャーナルログで必要な特定のブートを確認します。 

      $ sudo journalctl --boot <idx_or_boot_id>
      1
      Copy to Clipboard Toggle word wrap
      1
      <idx_or_boot_id> を、確認する特定のブートに割り当てられた IDX または BOOT ID 番号に置き換えます。

    • 次のコマンドを実行して、特定のサービスのブートに関するジャーナルログを確認します。 

      $ sudo journalctl --boot <idx_or_boot_id> -u <service_name>
      1
      2
      Copy to Clipboard Toggle word wrap
      1
      <idx_or_boot_id> を、確認する特定のブートに割り当てられた IDX または BOOT ID 番号に置き換えます。
      2
      <service_name> を、確認するサービスの名前に置き換えます。

5.3. greenboot ヘルスチェックのステータスの確認
リンクのコピー

システムに変更を加える前、およびトラブルシューティング中に、greenboot ヘルスチェックのステータスを確認します。次のコマンドのいずれかを使用すると、greenboot スクリプトの実行が完了したことを確認できます。

手順

  • ヘルスチェックステータスのレポートを表示するには、次のコマンドを使用します。 

    $ systemctl show --property=SubState --value greenboot-healthcheck.service
    Copy to Clipboard Toggle word wrap
    • start が出力される場合、greenboot チェックがまだ実行中であることを意味します。
    • exited が出力される場合、チェックが合格し、greenboot が終了したことを意味します。Greenboot は、システムが正常な状態の場合、green.d ディレクトリー内のスクリプトを実行します。
    • failed の出力は、チェックが合格しなかったことを意味します。システムがこの状態にある場合、Greenboot は red.d ディレクトリー内のスクリプトを実行し、システムを再起動する可能性があります。

  • サービスの数値終了コードを示すレポートを表示するには、次のコマンドを使用します。0 は成功を、0 以外の値は失敗を意味します。 

    $ systemctl show --property=ExecMainStatus --value greenboot-healthcheck.service
    Copy to Clipboard Toggle word wrap

  • Boot Status is GREEN - Health Check SUCCESS など、ブートステータスに関するメッセージを表示するレポートを表示するには、次のコマンドを使用します。 

    $ cat /run/motd.d/boot-status
    Copy to Clipboard Toggle word wrap

第6章 監査ログの確認
リンクのコピー

監査ログを使用すると、Pod のセキュリティー違反を特定できます。

6.1. 監査ログによる Pod のセキュリティー違反の特定
リンクのコピー

サーバー監査ログを表示することで、ワークロード上の Pod セキュリティーアドミッション違反を特定できます。次の手順では、監査ログにアクセスして解析し、ワークロードの Pod セキュリティーアドミッション違反を見つける方法を示します。

前提条件

  • jq がインストールされている。
  • ノードへの root アクセス権限がある。

手順

  1. ノード名を取得するために、次のコマンドを実行します。 

    $ <node_name>=$(oc get node -ojsonpath='{.items[0].metadata.name}')
    Copy to Clipboard Toggle word wrap

  2. 監査ログを表示するために、次のコマンドを実行します。 

    $ oc adm node-logs <node_name> --path=kube-apiserver/
    1
    Copy to Clipboard Toggle word wrap
    1
    <node_name> を、前の手順で取得したノードの名前に置き換えます。

    出力例

    rhel-94.lab.local audit-2024-10-18T18-25-41.663.log
rhel-94.lab.local audit-2024-10-19T11-21-29.225.log
rhel-94.lab.local audit-2024-10-20T04-16-09.622.log
rhel-94.lab.local audit-2024-10-20T21-11-41.163.log
rhel-94.lab.local audit-2024-10-21T14-06-10.402.log
rhel-94.lab.local audit-2024-10-22T06-35-10.392.log
rhel-94.lab.local audit-2024-10-22T23-26-27.667.log
rhel-94.lab.local audit-2024-10-23T16-52-15.456.log
rhel-94.lab.local audit-2024-10-24T07-31-55.238.log
    Copy to Clipboard Toggle word wrap

  3. 該当する監査ログを解析するために、次のコマンドを入力します。 

    $ oc adm node-logs <node_name> --path=kube-apiserver/audit.log \
  | jq -r 'select((.annotations["pod-security.kubernetes.io/audit-violations"] != null) and (.objectRef.resource=="pods")) | .objectRef.namespace + " " + .objectRef.name + " " + .objectRef.resource' \
  | sort | uniq -c
    1
    Copy to Clipboard Toggle word wrap
    1
    <node_name> を、前の手順で取得したノードの名前に置き換えます。

第7章 etcd のトラブルシューティング
リンクのコピー

etcd のトラブルシューティングを行い、パフォーマンスを向上させるには、サービスのメモリー許容量を設定します。

7.1. etcd サーバーのパラメーターを設定するための memoryLimitMB 値の設定
リンクのコピー

デフォルトでは、etcd はシステムの負荷を処理するために必要な量のメモリーを使用します。メモリーに制約のあるシステムでは、etcd が使用するメモリーの量を制限する必要がある場合があります。

手順

  • /etc/microshift/config.yaml ファイルを編集して、memoryLimitMB 値を設定します。 

    etcd:
  memoryLimitMB: 128
    Copy to Clipboard Toggle word wrap
    注記

    MicroShift の memoryLimitMB に必要な最小値は 128 MB です。最小値に近い値は、etcd のパフォーマンスに影響を与える可能性が高くなります。制限が低いほど、etcd がクエリーに応答するまでにかかる時間が長くなります。制限が低すぎる場合、または etcd の使用量が多い場合、クエリーはタイムアウトになります。

検証

  1. /etc/microshift/config.yaml の memoryLimitMB 値を変更した後、次のコマンドを実行して MicroShift を再起動します。 

    $ sudo systemctl restart microshift
    Copy to Clipboard Toggle word wrap

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

    $ systemctl show --property=MemoryHigh microshift-etcd.scope
    Copy to Clipboard Toggle word wrap

第8章 応答型の再起動およびセキュリティー証明書
リンクのコピー

MicroShift はシステム設定の変更に対応し、IP アドレスの変更、クロックの調整、セキュリティー証明書の有効期限などの変更が検出されると再起動します。

8.1. IP アドレスの変更またはクロックの調整
リンクのコピー

MicroShift は、デバイスの IP アドレスとシステム全体のクロック設定に依存して、ランタイム時に一貫性を保ちます。ただし、これらの設定は、DHCP やネットワークタイムプロトコル (NTP) の更新など、エッジデバイスで変更されることがあります。

このような変更が発生すると、一部の MicroShift コンポーネントが正しく機能しなくなる可能性があります。この状況を軽減するために、MicroShift は IP アドレスとシステム時間を監視し、設定の変更が検出された場合に再起動します。

時計の変更のしきい値は、いずれかの方向で時間の調整が 10 秒以上になった場合に適用されます。ネットワークタイムプロトコル (NTP) サービスによって実行される定期的な時刻調整の誤差が小さいと、再起動が行われません。

8.2. セキュリティー証明書の有効期間
リンクのコピー

MicroShift 証明書は、次の 2 つの基本グループに分けられます。

  1. 証明書の有効期間が 1 年間の短期証明書。
  2. 証明書の有効期間が 10 年間の長期証明書。

ほとんどのサーバーまたはリーフ証明書の有効期限は短くなっています。

有効期間の長い証明書の例は、system:admin user 認証用のクライアント証明書、または kube-apiserver 外部提供証明書の署名者の証明書です。

8.2.1. 証明書のローテーション
リンクのコピー

有効期限が切れている、または有効期限が近づいている証明書は、継続的な MicroShift 操作を確保するためにローテーションする必要があります。MicroShift が何らかの理由で再起動すると、有効期限が近づいている証明書がローテーションされます。まもなく期限切れになるように設定されている証明書、または期限切れになっている証明書は、MicroShift の自動再起動によってローテーションを実行する可能性があります。

重要

ローテーションされた証明書が MicroShift 認証局 (CA) の場合は、すべての署名付き証明書がローテーションされます。カスタム CA を作成した場合は、CA を手動でローテーションするようにしてください。

8.2.1.1. 短期証明書
リンクのコピー

以下の状況は、短期間の証明書の有効期間中の MicroShift のアクションを説明します。

  1. 回転なし:

    1. 短期証明書が 5 か月経過していると、ローテーションは発生しません。

  2. 再起動時のローテーション:

    1. 短期証明書が 5 ~ 8 か月経過すると、MicroShift の起動または再起動時にローテーションされます。

  3. ローテーションの自動再起動:

    1. 短期証明書が 8 か月以上経過している場合、MicroShift は自動的に再起動して新しい証明書をローテーションおよび適用できます。
8.2.1.2. 長期証明書
リンクのコピー

以下の状況は、証明書の長期有効期間中の MicroShift のアクションを示しています。

  1. 回転なし:

    1. 長期証明書が 8.5 年より短いと、ローテーションは発生しません。

  2. 再起動時のローテーション:

    1. 長期証明書が 8.5 ~ 9 年経過すると、MicroShift の起動または再起動時にローテーションされます。

  3. ローテーションの自動再起動:

    1. 長期証明書が 9 年以上経過している場合、MicroShift は自動的に再起動し、新しい証明書をローテーションおよび適用できる場合があります。

第9章 サポートによるデータのクリーンアップ
リンクのコピー

MicroShift は、すべてのデータ、証明書、コンテナーイメージの削除など、さまざまなトラブルシューティングタスク用の microshift-cleanup-data スクリプトを提供します。

警告

このスクリプトは、製品 Support チームのガイダンスなしに実行しないでください。サポートケースを送信 し、Support チームにご連絡ください。

9.1. データクリーンアップスクリプトの概要
リンクのコピー

引数なしでスクリプトを実行することにより、microshift-cleanup-data スクリプトの使用状況と利用可能なオプションを確認できます。引数なしでスクリプトを実行しても、データが削除されたり、MicroShift サービスが停止したりすることはありません。

手順

  1. 次のコマンドを入力して、microshift-cleanup-data スクリプトの使用状況を表示し、利用可能なオプションをリスト表示します。

    警告

    以下のスクリプト操作のオプションの一部は破壊的なため、データが失われる可能性があります。警告は、各引数の手順を参照してください。 

    $ microshift-cleanup-data
    Copy to Clipboard Toggle word wrap

    出力例

    Stop all MicroShift services, also cleaning their data

Usage: microshift-cleanup-data <--all [--keep-images] | --ovn | --cert>
   --all         Clean all MicroShift and OVN data
   --keep-images Keep container images when cleaning all data
   --ovn         Clean OVN data only
   --cert        Clean certificates only
    Copy to Clipboard Toggle word wrap

9.2. すべてのデータと設定のクリーニング
リンクのコピー

microshift-cleanup-data スクリプトを実行して、すべての MicroShift データと設定をクリーンアップできます。

--all 引数を指定してスクリプトを実行すると、以下のクリーンアップアクションが実行されます。

  • すべての MicroShift サービスを停止して無効にする
  • すべての MicroShift Pod を削除する
  • すべてのコンテナーイメージストレージを削除する
  • ネットワーク設定をリセットする
  • /var/lib/microshift データディレクトリーを削除する
  • OVN-K ネットワーク設定を削除する

前提条件

  • root ユーザーアクセス権を持つ管理者として MicroShift にログインしている。
  • サポートケースを作成している。

手順

  1. 次のコマンドを入力し、microshift-cleanup-data スクリプトを --all 引数を指定して実行し、すべての MicroShift データと設定をクリーンアップします。

    警告

    このオプションは、すべての MicroShift データとユーザーワークロードを削除します。注意して使用してください。 

    $ sudo microshift-cleanup-data --all
    Copy to Clipboard Toggle word wrap
    ヒント

    スクリプトは、操作を確認するためのメッセージを表示します。続行するには、1 または Yes と入力します。これ以外が入力されると、クリーンアップが取り消されます。

    クリーンアップを続行した場合の出力例

    DATA LOSS WARNING: Do you wish to stop and clean ALL MicroShift data AND cri-o container workloads?
1) Yes
2) No
#? 1
Stopping MicroShift services
Disabling MicroShift services
Removing MicroShift pods
Removing crio image storage
Deleting the br-int interface
Killing conmon, pause and OVN processes
Removing MicroShift configuration
Removing OVN configuration
MicroShift service was stopped
MicroShift service was disabled
Cleanup succeeded
    Copy to Clipboard Toggle word wrap

    クリーンアップをキャンセルした場合の出力例

    DATA LOSS WARNING: Do you wish to stop and clean ALL MicroShift data AND cri-o container workloads?
1) Yes
2) No
#? no
Aborting cleanup
    Copy to Clipboard Toggle word wrap

    重要

    スクリプトの実行後に、MicroShift サービスが停止および無効になります。

  2. 次のコマンドを実行して、MicroShift サービスを再起動します。 

    $ sudo systemctl enable --now microshift
    Copy to Clipboard Toggle word wrap

9.3. すべてのデータをクリーンアップしてコンテナーイメージを維持する
リンクのコピー

--all および --keep-images 引数を指定して microshift-cleanup-data スクリプトを実行することにより、すべてのデータをクリーンアップしながら、MicroShift コンテナーイメージを保持できます。

コンテナーイメージを保持すると、サービスの起動時に必要なコンテナーイメージがすでにローカルに存在するため、データのクリーンアップ後に MicroShift の再起動を迅速化できます。

--all および --keep-images 引数を使用してスクリプトを実行すると、次のクリーンアップアクションが実行されます。

  • すべての MicroShift サービスを停止して無効にする
  • すべての MicroShift Pod を削除する
  • ネットワーク設定をリセットする
  • /var/lib/microshift データディレクトリーを削除する
  • OVN-K ネットワーク設定を削除する
警告

このオプションは、すべての MicroShift データとユーザーワークロードを削除します。注意して使用してください。

前提条件

  • root ユーザーアクセス権を持つ管理者として MicroShift にログインしている。
  • サポートケースを作成している。

手順

  1. 次のコマンドを入力し、--all および --keep-images 引数を指定して microshift-cleanup-data スクリプトを実行し、MicroShift コンテナーイメージを保持しながらすべてのデータとユーザーワークロードをクリーンアップします。 

    $ sudo microshift-cleanup-data --all --keep-images
    Copy to Clipboard Toggle word wrap

    出力例

    DATA LOSS WARNING: Do you wish to stop and clean ALL MicroShift data AND cri-o container workloads?
1) Yes
2) No
#? Yes
Stopping MicroShift services
Disabling MicroShift services
Removing MicroShift pods
Deleting the br-int interface
Killing conmon, pause and OVN processes
Removing MicroShift configuration
Removing OVN configuration
MicroShift service was stopped
MicroShift service was disabled
Cleanup succeeded
    Copy to Clipboard Toggle word wrap

  2. 以下のコマンドを実行して、コンテナーイメージがまだ存在することを確認します。 

    $ sudo crictl images | awk '{print $1}'
    Copy to Clipboard Toggle word wrap

    出力例

    IMAGE
quay.io/openshift-release-dev/ocp-v4.0-art-dev
quay.io/openshift-release-dev/ocp-v4.0-art-dev
quay.io/openshift-release-dev/ocp-v4.0-art-dev
quay.io/openshift-release-dev/ocp-v4.0-art-dev
quay.io/openshift-release-dev/ocp-v4.0-art-dev
quay.io/openshift-release-dev/ocp-v4.0-art-dev
quay.io/openshift-release-dev/ocp-v4.0-art-dev
quay.io/openshift-release-dev/ocp-v4.0-art-dev
quay.io/openshift-release-dev/ocp-v4.0-art-dev
quay.io/openshift-release-dev/ocp-v4.0-art-dev
registry.redhat.io/lvms4/topolvm-rhel9
registry.redhat.io/openshift4/ose-csi-external-provisioner
registry.redhat.io/openshift4/ose-csi-external-resizer
registry.redhat.io/openshift4/ose-csi-livenessprobe
registry.redhat.io/openshift4/ose-csi-node-driver-registrar
registry.redhat.io/ubi9
    Copy to Clipboard Toggle word wrap

    重要

    スクリプトの実行後に、MicroShift サービスが停止および無効になります。

  3. 次のコマンドを実行して、MicroShift サービスを再起動します。 

    $ sudo systemctl enable --now microshift
    Copy to Clipboard Toggle word wrap

9.4. OVN-Kubernetes データのクリーニング
リンクのコピー

microshift-cleanup-data スクリプトを実行して、OVN-Kubernetes (ONV-K) データをクリーンアップできます。スクリプトを使用して OVN-K ネットワーク設定をリセットします。

--ovn 引数を指定してスクリプトを実行すると、次のクリーンアップアクションが実行されます。

  • すべての MicroShift サービスを停止する
  • すべての MicroShift Pod を削除する
  • OVN-K ネットワーク設定を削除する

前提条件

  • root ユーザーアクセス権を持つ管理者として MicroShift にログインしている。
  • サポートケースを作成している。

手順

  1. 次のコマンドを入力し、--ovn 引数を指定して microshift-cleanup-data スクリプトを実行し、OVN-K データをクリーンアップします。 

    $ sudo microshift-cleanup-data --ovn
    Copy to Clipboard Toggle word wrap

    出力例

    Stopping MicroShift services
Removing MicroShift pods
Killing conmon, pause and OVN processes
Removing OVN configuration
MicroShift service was stopped
Cleanup succeeded
    Copy to Clipboard Toggle word wrap

    重要

    スクリプトの実行後に、MicroShift サービスが停止します。

  2. 次のコマンドを実行して、MicroShift サービスを再起動します。 

    $ sudo systemctl start microshift
    Copy to Clipboard Toggle word wrap

9.5. カスタム証明書データのクリーニング
リンクのコピー

MicroShift サービスの再起動時に再作成されるように、microshift-cleanup-data スクリプトを使用して MicroShift カスタム証明書をリセットできます。

--cert 引数を指定してスクリプトを実行すると、以下のクリーンアップアクションが実行されます。

  • すべての MicroShift サービスを停止する
  • すべての MicroShift Pod を削除する
  • すべての MicroShift 証明書を削除する

前提条件

  • root ユーザーアクセス権を持つ管理者として MicroShift にログインしている。
  • サポートケースを作成している。

手順

  1. 次のコマンドを入力し、--cert 引数を指定して microshift-cleanup-data スクリプトを実行し、MicroShift 証明書をクリーンアップします。 

    $ sudo microshift-cleanup-data --cert
    Copy to Clipboard Toggle word wrap

    出力例

    Stopping MicroShift services
Removing MicroShift pods
Removing MicroShift certificates
MicroShift service was stopped
Cleanup succeeded
    Copy to Clipboard Toggle word wrap

    重要

    スクリプトの実行後に、MicroShift サービスが停止します。

  2. 次のコマンドを実行して、MicroShift サービスを再起動します。 

    $ sudo systemctl start microshift
    Copy to Clipboard Toggle word wrap

法律上の通知
リンクのコピー

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat