トラブルシューティング

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

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

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

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

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

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

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

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

2.2.1. 証明書のローテーション

証明書が古くなると、Red Hat build of MicroShift を再起動して証明書をローテーションできます。有効期限が近づいている証明書も、自動的に再起動する可能性があります。次の状況の概要を読んで、各時点でのアクションを確認してください。

1. グリーンゾーン:

   1. 短期証明書が 5 か月経過している場合には、ローテーションは発生しません。
   2. 長期証明書が 8.5 年経過している場合には、ローテーションは発生しません。

2. イエローゾーン:

   1. 短期証明書が 8 か月経過すると、Red Hat build of MicroShift の起動または再起動時にローテーションされます。
   2. 長期証明書が 9 年経過すると、Red Hat build of MicroShift の開始または再起動時にローテーションされます。

3. レッドゾーン

   1. 短期証明書が 8 か月経過すると、Red Hat build of MicroShift は再起動してローテーションし、新しい証明書を適用します。
   2. 長期証明書が 9 年経過すると、Red Hat build of MicroShift が再起動して、新しい証明書がローテーションされて適用されます。

注記

ローテーションされた証明書が認証局である場合は、署名されたすべての証明書がローテーションされます。

図2.1 Red Hat build of MicroShift 証明書の有効期限のストップライトタイムライン。

OVN-Kubernetes は、ネットワークアドレス変換 (NAT) テーブルに iptable チェーンをセットアップして、NodePort サービスへの着信トラフィックを処理します。NodePort サービスに到達できない場合、または接続が拒否された場合は、ホストの iptable ルールをチェックして、関連するルールが適切に挿入されていることを確認してください。