49 ダイレクトネットワークプロビジョニングのトラブルシューティング #
ダイレクトネットワークプロビジョニングシナリオには、Metal3およびCAPI要素を使用したダウンストリームクラスタのプロビジョニングが含まれます。EIBを使用したOSイメージの作成も含まれます。ホストの初回起動時、または検査プロセスまたはプロビジョニングプロセス中に問題が発生する可能性があります。
古いファームウェア: 使用されている物理ホスト上のさまざまなファームウェアがすべて最新であることを確認します。これには、BMCファームウェアが含まれます。Metal3 では特定のファームウェアや更新されたファームウェアが必要になる場合があるためです。
プロビジョニングがSSLエラーで失敗した: イメージを提供するWebサーバがhttpsを使用する場合、Metal3はIPAイメージに証明書を挿入して信頼するように設定する必要があります。
ca-additional.crt
ファイルをMetal3チャートに含める方法については、Kubernetesフォルダ(40.3.4項 「Kubernetesフォルダ」)を参照してください。IPAを使用したホストの起動時に証明書の問題が発生する: 一部のサーバベンダは仮想メディアISOイメージをBMCにアタッチする際にSSL接続を確認します。このため、Metal3デプロイメント用に生成された証明書が自己署名されているために、問題が発生する可能性があります。ホストが起動中であるにもかかわらずUEFIシェルに切り替わってしまう可能性があります。この問題の解決方法については、「仮想メディアISOをアタッチするためのTLSの無効化」(1.6.2項 「仮想メディアISOをアタッチするためのTLSの無効化」)を参照してください。
間違った名前またはラベル参照: クラスタが間違った名前またはラベルでノードを参照する場合、クラスタはデプロイ済みと表示されますが、BMHは「使用可能」のままとなります。BMHに関連するオブジェクトの参照を再確認します。
BMC通信の問題: 管理クラスタ上で実行されているMetal3 Podがプロビジョニング中のホストのBMCにアクセスできることを確認します(通常BMCネットワークは非常に制限されています)。
不正なベアメタルホストの状態: BMHオブジェクトは、 その存続期間中にさまざまな状態(検査中、準備中、プロビジョニング済みなど)に移行します(存続期間中のマシンの状態)。不正な状態が検出された場合は、BMHオブジェクトの
status
フィールドを確認してください。このフィールドにはkubectl get bmh <name> -o jsonpath=’{.status}’| jq
のような詳細情報が含まれています。ホストがプロビジョニング解除されない: プロビジョニング解除しようとしていたホストが失敗した場合、BMHオブジェクトに次のように「detached」アノテーションを追加すると削除を試行できます:
kubectl annotate bmh/<BMH> baremetalhost.metal3.io/detached=””
。イメージエラー: ダウンストリームクラスタに対してEIBを使用して構築されるイメージが使用可能であり、適切なチェックサムがあり、解凍するには大きすぎない、またはディスクに対して大きすぎないことを確認します。
ディスクサイズの不一致: デフォルトでは、全ディスクを満たすようにディスクは拡張されません。「Growfsスクリプト」(1.3.4.1.2項 「Growfsスクリプト」)セクションで説明しているように、ダウンストリームクラスタホスト用にEIBで構築されるイメージにはgrowfsスクリプトを含める必要があります。
クリーニングプロセスの停止: クリーニングプロセスは数回再試行されます。ホストの問題によりクリーニングができなくなった場合は、まず、BMHオブジェクトの
automatedCleanMode
フィールドをdisabled
に設定してクリーニングを無効にします。警告クリーニングプロセスに必要以上に時間がかかっている、または失敗している場合は、ファイナライザを手動で削除することは推奨されません。手動で削除すると、Kubernetesからホストレコードが削除されますが、Ironicには残ります。現在実行中のアクションはバックグラウンドで続行されるため、ホストを再度追加しようとすると競合により失敗する可能性があります。
Metal3/Rancher Turtles/CAPI Podの問題: すべての必要なコンポーネントのデプロイメントフローは次のとおりです。
Rancher TurtlesコントローラはCAPIオペレータコントローラをデプロイします。
次に、CAPIオペレータコントローラはプロバイダコントローラ(CAPIコア、CAPM3、およびRKE2コントロールプレーン/ブートストラップ)をデプロイします。
すべてのPodが正常に実行されていることを確認し、そうでない場合はログを確認します。
Metal3ログ: さまざまなPodのログを確認します。
kubectl logs -n metal3-system -l app.kubernetes.io/component=baremetal-operator kubectl logs -n metal3-system -l app.kubernetes.io/component=ironic
注記metal3-ironic Podには、少なくとも4つの異なるコンテナ(
ironic-httpd
、「 ironic-log-watch」、ironic
、ironic-ipa-downloader
(init))が同じPod上に含まれています。kubectlログ
を使用する場合は-c
フラグを指定して、各コンテナのログを確認します。注記ironic-log-watch
コンテナは、ネットワーク接続により、管理クラスタにコンソールログを返送できる場合は、検査/プロビジョニング後にホストからこのログを公開します。これはプロビジョニングエラーが発生したが、BMCコンソールログに直接アクセスできない場合に役立つ可能性があります。Rancher Turtlesログ: さまざまなPodのログを確認します。
kubectl logs -n rancher-turtles-system -l control-plane=controller-manager kubectl logs -n rancher-turtles-system -l app.kubernetes.io/name=cluster-api-operator kubectl logs -n rke2-bootstrap-system -l cluster.x-k8s.io/provider=bootstrap-rke2 kubectl logs -n rke2-control-plane-system -l cluster.x-k8s.io/provider=control-plane-rke2 kubectl logs -n capi-system -l cluster.x-k8s.io/provider=cluster-api kubectl logs -n capm3-system -l cluster.x-k8s.io/provider=infrastructure-metal3
BMCログ: 通常BMCには、ほとんどの操作を実行できるUIがあります。また、通常は潜在的な問題(イメージにアクセスできない、ハードウェアエラーなど)がないか確認できる「ログ」セクションもあります。
コンソールログ: BMCコンソールに接続して(BMC Web UI、シリアルなどを経由)、書き込まれているログにエラーがないか確認します。
BareMetalHost
ステータスの確認:kubectl get bmh -A
を実行すると、現在の状態が表示されます。provisioning
、ready
、error
、registering
を探してください。kubectl describe bmh -n <namespace> <bmh_name>
を実行すると、BMHが停止する可能性がある理由を説明する、詳細なイベントと状態が表示されます。
RedFishの接続性のテスト:
Metal3コントロールプレーンから
curl
を使用して、RedFishを介してBMCへの接続性をテストします。BareMetalHost-Secret
定義に正しいBMC資格情報が提供されていることを確認します。
turtles/CAPI/metal3 Podのステータスの確認: 管理クラスタ上のコンテナが稼働中であることを確認します:
kubectl get pods -n metal3-system
およびkubectl get pods -n rancher-turtles-system
(capi-system
、capm3-system
、rke2-bootstrap-system
、およびrke2-control-plane-system
も参照)。Ironicエンドポイントにプロビジョニング中のホストからアクセスできることを確認する: プロビジョニング中のホストは、レポートをMetal3に返すため、Ironicエンドポイントにアクセスできる必要があります。
kubectl get svc -n metal3-system metal3-metal3-ironic
を使用してIPを確認し、curl/nc
経由でアクセスを試みてください。IPAイメージがBMCからアクセスできることを確認する: IPAはIronicエンドポイントによって提供されており、仮想CDとして使用されているため、BMCからアクセスできる必要があります。
OSイメージがプロビジョニング中のホストからアクセスできることを確認する: ホストのプロビジョニングに使用されるイメージは、一時的にダウンロードされ、ディスクに書き込まれるため、ホスト自体からアクセスできる必要があります(IPA実行時)。
Metal3コンポーネントログの調査: 上記を参照してください。
BMH検査の再トリガ: 検査に失敗するか、使用可能なホストのハードウェアが変更された場合、BMHオブジェクトに
inspect.metal3.io: ""
というアノテーションを付けることで、新しい検査プロセスをトリガできます。詳細については、Metal3の「Controlling inspection (検査の制御)」ガイドを参照してください。ベアメタルIPAコンソール: IPAの問題をトラブルシューティングするには、いくつかの代替手段が存在します。
「自動ログイン」を有効にします。これにより、IPAコンソールへの接続時に、ルートユーザが自動的にログインできるようになります。
警告これはホストへの完全なアクセス権を付与するため、デバッグ目的のみに使用されます。
自動ログインを有効にするには、Metal3 helmの
global.ironicKernelParams
値がconsole=ttyS0 suse.autologin=ttyS0
のようになる必要があります(コンソールによっては、ttyS0
を変更できます)。次にMetal3チャートの再デプロイメントを実行する必要があります(ttyS0
は一例であり、実際の端末と一致する必要があることに注意してください。たとえば、ベアメタルでは多くの場合tty1
となります。これは、起動時にIPA RAMディスクのコンソール出力で/etc/issue
にコンソール名が表示されていることを見ることで確認できます)。別の方法は、
metal3-system
ネームスペースのironic-bmo
configmapのIRONIC_KERNEL_PARAMS
パラメータを変更することです。この方法は、kubectl
editで実行できるため簡単ですが、チャートを更新すると上書きされます。その後、Metal3 Podをkubectl delete pod -n metal3-system -l app.kubernetes.io/component=ironic
で再起動する必要があります。IPAにルートユーザのsshキーを挿入します。
警告これはホストへの完全なアクセス権を付与するため、デバッグ目的のみに使用されます。
ルートユーザのsshキーを挿入するには、Metal3 helm
debug.ironicRamdiskSshKey
値を使用する必要があります。その後、Metal3 チャートの再デプロイメントを実行する必要があります。別の方法は、
metal3-system
ネームスペースのironic-bmo configmap
のIRONIC_RAMDISK_SSH_KEY
パラメータを変更することです。この方法は、kubectl
editで実行できるため簡単ですが、チャートを更新すると上書きされます。その後、Metal3 Podをkubectl delete pod -n metal3-system -l app.kubernetes.io/component=ironic
で再起動する必要があります。