Red Hat Summitトラブルシューティング
一般的な問題のトラブルシューティング
概要
第1章 インストールされているバージョンの確認
トラブルシューティングを開始するには、インストールされている MicroShift のバージョンを確認します。
1.1. コマンドラインインターフェイスを使用したバージョンの確認
トラブルシューティングを開始するには、MicroShift のバージョンを知っている必要があります。この情報を取得する方法として、CLI を使用する方法があります。
手順
次のコマンドを実行して、バージョン情報を確認します。
$ microshift version
出力例
MicroShift Version: 4.17-0.microshift-e6980e25 Base OCP Version: 4.17
1.2. API を使用した MicroShift バージョンの確認
トラブルシューティングを開始するには、MicroShift のバージョンを知っている必要があります。この情報を取得する方法として、API を使用する方法があります。
手順
OpenShift CLI (
oc) を使用してバージョン番号を取得するには、次のコマンドを実行してkube-public/microshift-version設定マップを表示します。$ oc get configmap -n kube-public microshift-version -o yaml
出力例
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
1.3. etcd のバージョンの確認
必要な情報のレベルに応じて、次のいずれかまたは両方の方法を使用して、MicroShift に含まれている etcd データベースのバージョン情報を取得できます。
手順
ベースデータベースのバージョン情報を表示するには、次のコマンドを実行します。
$ microshift-etcd version
出力例
microshift-etcd Version: 4.17.1 Base etcd Version: 3.5.13
データベースの完全なバージョン情報を表示するには、次のコマンドを実行します。
$ microshift-etcd version -o json
出力例
{ "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" }
第2章 クラスターのトラブルシューティング
MicroShift クラスターのトラブルシューティングを開始するには、まずクラスターのステータスにアクセスします。
2.1. クラスターのステータスの確認
MicroShift クラスターのステータスを確認したり、アクティブな Pod を確認したりできます。次の手順では、クラスターのステータスを確認するために使用できる各種コマンドを示します。必要に応じて 1 つ、2 つ、またはすべてのコマンドを実行し、クラスターのトラブルシューティングに必要な情報を取得できます。
手順
次のコマンドを実行して、クラスターのステータスを返すシステムステータスを確認します。
$ sudo systemctl status microshift
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> # ...オプション: 次のコマンドを実行して包括的なログを取得します。
$ sudo journalctl -u microshift
注記systemdジャーナルサービスのデフォルト設定では、データは揮発性ディレクトリーに保存されます。システムの再起動後もシステムログを保持するには、ログの保持を有効にし、最大ジャーナルデータサイズの制限を設定します。オプション: MicroShift が実行中の場合は、次のコマンドを入力してアクティブな Pod のステータスを確認します。
$ oc get pods -A
出力例
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 kube-system csi-snapshot-webhook-6bf8ddc7f5-kz6k9 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
注記この出力例は、基本的な MicroShift を示しています。オプションの RPM をインストールしている場合は、それらのサービスを実行している Pod のステータスも出力に表示されるはずです。
第3章 インストールの問題のトラブルシューティング
MicroShift インストールが失敗した場合にトラブルシューティングを行うには、sos report を実行します。sos report コマンドを使用して、システム内のさまざまなコンポーネントやアプリケーションからの有効なプラグインとデータをすべて表示する詳細レポートを生成します。
3.1. sos レポートからのデータの収集
前提条件
-
sosパッケージがインストールされている。
手順
- 障害が発生したホストに root ユーザーとしてログインします。
次のコマンドを実行して、デバッグレポートの作成手順を実行します。
$ microshift-sos-report
出力例
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.
3.2. 関連情報
第4章 データのバックアップと復元のトラブルシューティング
データのバックアップと復元に失敗した場合のトラブルシューティングを行うには、まずデータパス、ストレージ設定、ストレージ容量などの基本事項を確認します。
4.1. データバックアップの失敗
rpm-ostree システムではデータのバックアップが自動的に行われます。rpm-ostree システムを使用せずに手動バックアップを作成しようとした場合、次の理由によりバックアップが失敗する可能性があります。
- システムの起動後、数分間待たずに MicroShift を正常に停止したため。バックアップを正常に実行するには、システムがヘルスチェックとその他のバックグラウンドプロセスを完了する必要があります。
MicroShift がエラーのために実行を停止した場合、データのバックアップを実行することはできません。
- システムが健全な状態であることを確認してください。
- バックアップを試みる前に、健全な状態で停止してください。
- データ用の十分なストレージがない場合、バックアップは失敗します。MicroShift データ用に十分なストレージがあることを確認してください。
- 十分な権限がない場合、バックアップが失敗する可能性があります。バックアップの作成および必要な設定を実行するための正しいユーザー権限があることを確認してください。
4.2. バックアップログ
- 手動バックアップ中にログが端末コンソールに出力されます。
rpm-ostreeシステムの自動バックアップのログは、MicroShift ジャーナルログの一部として自動的に生成されます。次のコマンドを実行してログを確認できます。$ sudo journalctl -u microshift
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 更新のトラブルシューティングを行うには、次のガイドを使用してください。
5.1. MicroShift の更新のトラブルシューティング
場合によっては、MicroShift の更新に失敗することがあります。そのような場合に備えて、障害の種類とそのトラブルシューティング方法を理解しておくと役立ちます。
5.1.1. バージョンの互換性がなく更新パスを使用できない
MicroShift の更新と、Red Hat Enterprise Linux for Edge (RHEL for Edge) または Red Hat Enterprise Linux (RHEL) のバージョンとの間で互換性がない場合、RPM 依存関係エラーが発生します。
5.1.1.1. 互換性に関する表
次の互換性に関する表を確認してください。
Red Hat Device Edge リリースの互換性に関する表
Red Hat Enterprise Linux (RHEL) と MicroShift は、device-edge コンピューティング向けの単一のソリューションとして連携します。各コンポーネントを個別に更新できますが、製品バージョンの互換性を確保する必要があります。次の表に示すように、Red Hat Device Edge のサポート対象設定では、それぞれ検証済みのリリースが使用されます。
| RHEL バージョン | MicroShift バージョン | サポートされている MicroShift バージョン → バージョンの更新 |
|---|---|---|
| 9.4 | 4.17 | 4.17.1 → 4.17.z |
| 9.4 | 4.16 | 4.16.0 → 4.16.z, 4.16 → 4.17 |
| 9.2、9.3 | 4.15 | 4.15.0 → 4.15.z, 4.15 → 4.16 on RHEL 9.4 |
| 9.2、9.3 | 4.14 | 4.14.0 → 4.14.z, 4.14 → 4.15 or 4.14 → 4.16 on RHEL 9.4 |
5.1.1.2. バージョンの互換性
次の更新パスを確認してください。
MicroShift 更新パス
- 一般提供バージョン 4.17.1 から 4.17.z (RHEL 9.4) へ
- 一般提供バージョン 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.2. OSTree 更新の失敗
OSTree システムで更新した場合、Greenboot ヘルスチェックが自動的にログを記録し、システムの健全性に基づいて動作します。Greenboot によるシステムのロールバックにより、障害の発生が判明する場合があります。更新が失敗しても、Greenboot がシステムのロールバックを完了しなかった場合は、後述の「関連情報」セクションにある RHEL for Edge ドキュメントへのリンクを使用してトラブルシューティングを行うことができます。
- Greenboot ログの手動確認
次のコマンドを実行して、Greenboot ログを手動でチェックしてシステムの健全性を確認します。
$ sudo systemctl restart --no-block greenboot-healthcheck && sudo journalctl -fu greenboot-healthcheck
5.1.3. RPM 手動更新の失敗
非 OSTree システムで RPM を使用して更新した場合、Greenboot によって更新の失敗が判明することがあります。ただし、ヘルスチェックは情報を提供するだけです。RPM 手動更新の失敗をトラブルシューティングする際には、次のステップとして、システムログを確認します。Greenboot と sos report を使用して、MicroShift 更新とホストシステムの両方を確認できます。
5.2. 更新後のジャーナルログの確認
場合によっては、MicroShift の更新に失敗することがあります。そのような場合に備えて、障害の種類とそのトラブルシューティング方法を理解しておくと役立ちます。ジャーナルログは、更新の失敗の診断に役立ちます。
systemd ジャーナルサービスのデフォルト設定では、データは揮発性ディレクトリーに保存されます。システムの再起動後もシステムログを保持するには、ログの保持を有効にし、最大ジャーナルデータサイズの制限を設定します。
手順
次のコマンドを実行して、包括的な MicroShift ジャーナルログを取得します。
$ sudo journalctl -u microshift
次のコマンドを実行して、Greenboot ジャーナルログを確認します。
$ sudo journalctl -u greenboot-healthcheck
特定のブートの詳しいログを調べるには、次の 2 つのステップを使用します。まずブートをリストし、取得したリストから必要なものを選択します。
次のコマンドを実行して、ジャーナルログに存在するブートをリスト表示します。
$ sudo journalctl --list-boots
出力例
IDX BOOT ID FIRST ENTRY LAST ENTRY 0 681ece6f5c3047e183e9d43268c5527f <Day> <Date> 12:27:58 UTC <Day> <Date>> 13:39:41 UTC #....
次のコマンドを実行して、ジャーナルログで必要な特定のブートを確認します。
$ sudo journalctl --boot <idx_or_boot_id> 1
- 1
<idx_or_boot_id>を、確認する特定のブートに割り当てられたIDXまたはBOOT ID番号に置き換えます。
次のコマンドを実行して、特定のサービスのブートに関するジャーナルログを確認します。
$ sudo journalctl --boot <idx_or_boot_id> -u <service_name> 1 2
5.3. greenboot ヘルスチェックのステータスの確認
システムに変更を加える前、またはトラブルシューティング中に、greenboot ヘルスチェックのステータスを確認します。次のコマンドのいずれかを使用すると、greenboot スクリプトの実行が完了したことを確認できます。
手順
ヘルスチェックステータスのレポートを表示するには、次のコマンドを使用します。
$ systemctl show --property=SubState --value greenboot-healthcheck.service
-
startが出力される場合、greenboot チェックがまだ実行中であることを意味します。 -
exitedが出力される場合、チェックが合格し、greenboot が終了したことを意味します。Greenboot は、システムが正常な状態の場合、green.dディレクトリー内のスクリプトを実行します。 -
failedの出力は、チェックが合格しなかったことを意味します。システムがこの状態にある場合、Greenboot はred.dディレクトリー内のスクリプトを実行し、システムを再起動する可能性があります。
-
サービスの数値終了コードを示すレポートを表示するには、次のコマンドを使用します。
0は成功を、0 以外の値は失敗を意味します。$ systemctl show --property=ExecMainStatus --value greenboot-healthcheck.service
Boot Status is GREEN - Health Check SUCCESSなど、ブートステータスに関するメッセージを表示するレポートを表示するには、次のコマンドを使用します。$ cat /run/motd.d/boot-status
第6章 監査ログの確認
監査ログを使用すると、Pod のセキュリティー違反を特定できます。
6.1. 監査ログによる Pod のセキュリティー違反の特定
サーバー監査ログを表示することで、ワークロード上の Pod セキュリティーアドミッション違反を特定できます。次の手順では、監査ログにアクセスして解析し、ワークロードの Pod セキュリティーアドミッション違反を見つける方法を示します。
前提条件
-
jqがインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
ノード名を取得するために、次のコマンドを実行します。
$ <node_name>=$(oc get node -ojsonpath='{.items[0].metadata.name}')監査ログを表示するために、次のコマンドを実行します。
$ oc adm node-logs <node_name> --path=kube-apiserver/ 1- 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
該当する監査ログを解析するために、次のコマンドを入力します。
$ 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- 1
- <node_name> を、前の手順で取得したノードの名前に置き換えます。
第7章 etcd のトラブルシューティング
etcd のトラブルシューティングを行い、パフォーマンスを向上させるには、サービスのメモリー許容量を設定します。
7.1. etcd サーバーのパラメーターを設定するための memoryLimitMB 値の設定
デフォルトでは、etcd はシステムの負荷を処理するために必要な量のメモリーを使用します。メモリーに制約のあるシステムでは、etcd が使用するメモリーの量を制限する必要がある場合があります。
手順
/etc/microshift/config.yamlファイルを編集して、memoryLimitMB値を設定します。etcd: memoryLimitMB: 128
注記MicroShift の
memoryLimitMBに必要な最小値は 128 MB です。最小値に近い値は、etcd のパフォーマンスに影響を与える可能性が高くなります。制限が低いほど、etcd がクエリーに応答するまでにかかる時間が長くなります。制限が低すぎる場合、または etcd の使用量が多い場合、クエリーはタイムアウトになります。
検証
/etc/microshift/config.yamlのmemoryLimitMB値を変更した後、次のコマンドを実行して MicroShift を再起動します。$ sudo systemctl restart microshift
次のコマンドを実行して、新しい
memoryLimitMB値が使用されていることを確認します。$ systemctl show --property=MemoryHigh microshift-etcd.scope
第8章 応答型の再起動およびセキュリティー証明書
MicroShift はシステム設定の変更に対応し、IP アドレスの変更、クロックの調整、セキュリティー証明書の有効期限などの変更が検出されると再起動します。
8.1. IP アドレスの変更またはクロックの調整
MicroShift は、デバイスの IP アドレスとシステム全体のクロック設定に依存して、ランタイム時に一貫性を保ちます。ただし、これらの設定は、DHCP やネットワークタイムプロトコル (NTP) の更新など、エッジデバイスで変更されることがあります。
このような変更が発生すると、一部の MicroShift コンポーネントが正しく機能しなくなる可能性があります。この状況を軽減するために、MicroShift は IP アドレスとシステム時間を監視し、設定の変更が検出された場合に再起動します。
時計の変更のしきい値は、いずれかの方向で時間の調整が 10 秒以上になった場合に適用されます。ネットワークタイムプロトコル (NTP) サービスによって実行される定期的な時刻調整の誤差が小さいと、再起動が行われません。
8.2. セキュリティー証明書の有効期間
MicroShift 証明書は、次の 2 つの基本グループに分けられます。
- 証明書の有効期間が 1 年間の短期証明書。
- 証明書の有効期間が 10 年間の長期証明書。
ほとんどのサーバーまたはリーフ証明書の有効期限は短くなっています。
有効期間の長い証明書の例は、system:admin user 認証用のクライアント証明書、または kube-apiserver 外部提供証明書の署名者の証明書です。
8.2.1. 証明書のローテーション
有効期限が切れている、または有効期限が近づいている証明書は、継続的な MicroShift 操作を確保するためにローテーションする必要があります。MicroShift が何らかの理由で再起動すると、有効期限が近づいている証明書がローテーションされます。まもなく期限切れになるように設定されている証明書、または期限切れになっている証明書は、MicroShift の自動再起動によってローテーションを実行する可能性があります。
ローテーションされた証明書が認証局である場合は、署名されたすべての証明書がローテーションされます。
8.2.1.1. 短期証明書
以下の状況は、短期間の証明書の有効期間中の MicroShift のアクションを説明します。
回転なし:
- 短期証明書が 5 か月経過していると、ローテーションは発生しません。
再起動時のローテーション:
- 短期証明書が 5 ~ 8 か月経過すると、MicroShift の起動または再起動時にローテーションされます。
ローテーションの自動再起動:
- 短期証明書が 8 か月以上経過している場合、MicroShift は自動的に再起動して新しい証明書をローテーションおよび適用できます。
8.2.1.2. 長期証明書
以下の状況は、証明書の長期有効期間中の MicroShift のアクションを示しています。
回転なし:
- 長期証明書が 8.5 年より短いと、ローテーションは発生しません。
再起動時のローテーション:
- 長期証明書が 8.5 ~ 9 年経過すると、MicroShift の起動または再起動時にローテーションされます。
ローテーションの自動再起動:
- 長期証明書が 9 年以上経過している場合、MicroShift は自動的に再起動して新しい証明書をローテーションおよび適用できます。
第9章 サポートによるデータのクリーンアップ
MicroShift は、すべてのデータ、証明書、コンテナーイメージの削除など、さまざまなトラブルシューティングタスク用の microshift-cleanup-data スクリプトを提供します。
このスクリプトは、製品 Support チームのガイダンスなしに実行しないでください。サポートケースを送信 し、Support チームにご連絡ください。
9.1. データクリーンアップスクリプトの概要
引数なしでスクリプトを実行することにより、microshift-cleanup-data スクリプトの使用状況と利用可能なオプションを確認できます。引数なしでスクリプトを実行しても、データが削除されたり、MicroShift サービスが停止したりすることはありません。
手順
次のコマンドを入力して、
microshift-cleanup-dataスクリプトの使用状況を表示し、利用可能なオプションをリスト表示します。警告以下のスクリプト操作のオプションの一部は破壊的なため、データが失われる可能性があります。警告については、各引数の手順を参照してください。
$ microshift-cleanup-data
出力例
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
9.2. すべてのデータと設定のクリーニング
microshift-cleanup-data スクリプトを実行して、すべての MicroShift データと設定をクリーンアップできます。
--all 引数を指定してスクリプトを実行すると、以下のクリーンアップアクションが実行されます。
- すべての MicroShift サービスを停止して無効にする
- すべての MicroShift Pod を削除する
- すべてのコンテナーイメージストレージを削除する
- ネットワーク設定をリセットする
-
/var/lib/microshiftデータディレクトリーを削除する - OVN-K ネットワーク設定を削除する
前提条件
- root ユーザーアクセス権を持つ管理者として MicroShift にログインしている。
- サポートケースを作成している。
手順
次のコマンドを入力し、
microshift-cleanup-dataスクリプトを--all引数を指定して実行し、すべての MicroShift データと設定をクリーンアップします。警告このオプションは、すべての MicroShift データとユーザーワークロードを削除します。注意して使用してください。
$ sudo microshift-cleanup-data --all
ヒントスクリプトは、操作を確認するためのメッセージを表示します。続行するには、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
クリーンアップをキャンセルした場合の出力例
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
重要スクリプトの実行後に、MicroShift サービスが停止および無効になります。
次のコマンドを実行して、MicroShift サービスを再起動します。
$ sudo systemctl enable --now microshift
9.3. すべてのデータをクリーンアップしてコンテナーイメージを維持する
--all および --keep-images 引数を指定して microshift-cleanup-data スクリプトを実行することにより、すべてのデータをクリーンアップしながら、MicroShift コンテナーイメージを保持できます。
コンテナーイメージを保持すると、サービスの起動時に必要なコンテナーイメージがすでにローカルに存在するため、データのクリーンアップ後に MicroShift の再起動を迅速化できます。
--all および --keep-images 引数を使用してスクリプトを実行すると、次のクリーンアップアクションが実行されます。
- すべての MicroShift サービスを停止して無効にする
- すべての MicroShift Pod を削除する
- ネットワーク設定をリセットする
-
/var/lib/microshiftデータディレクトリーを削除する - OVN-K ネットワーク設定を削除する
このオプションは、すべての MicroShift データとユーザーワークロードを削除します。注意して使用してください。
前提条件
- root ユーザーアクセス権を持つ管理者として MicroShift にログインしている。
- サポートケースを作成している。
手順
次のコマンドを入力し、
--allおよび--keep-images引数を指定してmicroshift-cleanup-dataスクリプトを実行し、MicroShift コンテナーイメージを保持しながらすべてのデータとユーザーワークロードをクリーンアップします。$ sudo microshift-cleanup-data --all --keep-images
出力例
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
以下のコマンドを実行して、コンテナーイメージがまだ存在することを確認します。
$ sudo crictl images | awk '{print $1}'出力例
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
重要スクリプトの実行後に、MicroShift サービスが停止および無効になります。
次のコマンドを実行して、MicroShift サービスを再起動します。
$ sudo systemctl enable --now microshift
9.4. OVN-Kubernetes データのクリーニング
microshift-cleanup-data スクリプトを実行して、OVN-Kubernetes (ONV-K) データをクリーンアップできます。スクリプトを使用して OVN-K ネットワーク設定をリセットします。
--ovn 引数を指定してスクリプトを実行すると、次のクリーンアップアクションが実行されます。
- すべての MicroShift サービスを停止する
- すべての MicroShift Pod を削除する
- OVN-K ネットワーク設定を削除する
前提条件
- root ユーザーアクセス権を持つ管理者として MicroShift にログインしている。
- サポートケースを作成している。
手順
次のコマンドを入力し、
--ovn引数を指定してmicroshift-cleanup-dataスクリプトを実行し、OVN-K データをクリーンアップします。$ sudo microshift-cleanup-data --ovn
出力例
Stopping MicroShift services Removing MicroShift pods Killing conmon, pause and OVN processes Removing OVN configuration MicroShift service was stopped Cleanup succeeded
重要スクリプトの実行後に、MicroShift サービスが停止します。
次のコマンドを実行して、MicroShift サービスを再起動します。
$ sudo systemctl start microshift
9.5. カスタム証明書データのクリーニング
MicroShift サービスの再起動時に再作成されるように、microshift-cleanup-data スクリプトを使用して MicroShift カスタム証明書をリセットできます。
--cert引数を指定してスクリプトを実行すると、以下のクリーンアップアクションが実行されます。
- すべての MicroShift サービスを停止する
- すべての MicroShift Pod を削除する
- すべての MicroShift 証明書を削除する
前提条件
- root ユーザーアクセス権を持つ管理者として MicroShift にログインしている。
- サポートケースを作成している。
手順
次のコマンドを入力し、
--cert引数を指定してmicroshift-cleanup-dataスクリプトを実行し、MicroShift 証明書をクリーンアップします。$ sudo microshift-cleanup-data --cert
出力例
Stopping MicroShift services Removing MicroShift pods Removing MicroShift certificates MicroShift service was stopped Cleanup succeeded
重要スクリプトの実行後に、MicroShift サービスが停止します。
次のコマンドを実行して、MicroShift サービスを再起動します。
$ sudo systemctl start microshift
