トラブルシューティング

手順

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

  $ microshift version

  出力例

  Red Hat build of MicroShift Version: 4.16-0.microshift-e6980e25
  Base OCP Version: 4.16

手順

• 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

手順

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

  $ microshift-etcd version

  出力例

  microshift-etcd Version: 4.16.0
  Base etcd Version: 3.5.13

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

  $ microshift-etcd version -o json

  出力例

  {
    "major": "4",
    "minor": "16",
    "gitVersion": "4.16.0~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"
  }

手順

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

  $ 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 のステータスも出力に表示されるはずです。

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

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

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

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

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

  $ sudo journalctl -u microshift

手順

• 次のコマンドを実行して、包括的な 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 <-my_boot_ID> 1

    1

    ←my-boot-ID> は、確認する特定のブートに割り当てられた番号に置き換えます。

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

    $ sudo journalctl --boot <-my_boot_ID> -u <service_name> 1 2

    1

    ←my-boot-ID> は、確認する特定のブートに割り当てられた番号に置き換えます。

    2

    <service_name> は、確認するサービスの名前に置き換えます。

手順

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

  $ 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

前提条件

• jq がインストールされている。
• cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

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

  etcd:
    memoryLimitMB: 128

  注記

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