ドメインまたはクラスタのYAMLファイルのデプロイ後にドメインの問題をデバッグするための提案を次に示します。
デバッグする際は、失敗タイプ、失敗の重大度、再試行動作およびチューニングの再試行を理解するのに役立ちます。「ドメイン失敗再試行処理」を参照してください。 これらは、リソース・ステータス、イベント、イントロスペクタ・ジョブおよびポッドでレポートされた失敗に適用されます。
ドメイン・ステータスを確認するには: kubectl -n MY_NAMESPACE describe domain MY_DOMAIN_RESOURCE_NAME
。 詳細は、「ドメイン条件」を参照してください。
ノート: .status.observedGeneration
が.metadata.generation
と等しくない場合、これは、.spec
または.metadata
に対する最新の変更に関して、ステータスが最新ではないことを示します。 オペレータがステータスの更新処理中であるか、オペレータが実行中ではありません。
クラスタ・リソースをデプロイしている場合は、オプションでkubectl -n MY_NAMESPACE describe cluster MY_CLUSTER_NAME
を使用して各リソースのステータスを確認できます。
同じ情報がdomain.status.clusters
の下のDomainリソースのステータスで報告されます。 詳細は、「クラスタ条件」を参照してください。
ノート: 特定のクラスタ・ステータスの.observedGeneration
が、対応するクラスタ・リソースの.metadata.generation
と等しくない場合、これは、.spec
または.metadata
に対する最新の変更に関して、ステータスが最新ではないことを示します。 オペレータがステータスの更新処理中であるか、オペレータが実行中ではありません。
ドメインのイベントを確認するには: kubectl -n MY_NAMESPACE get events --sort-by='.lastTimestamp'
。
詳細は、「ドメイン・イベント」を参照してください。
イントロスペクタ・ジョブが失敗した場合は、ジョブとそのポッドのkubectl describe
を調べ、ログ(存在する場合)も調べます。
失敗のデバッグ中にイントロスペクタ・ジョブが再試行されないようにするには、domain.spec.failureRetryLimitMinutes
を0
に構成します。 詳細は、「ドメイン失敗再試行処理」を参照してください。
たとえば、ドメインUIDがsample-domain1
で、ドメイン・ネームスペースがsample-domain1-ns
であるとします。
ここでは、ドメインのポッド間に失敗したイントロスペクタ・ジョブ・ポッドが表示されます:
$ kubectl -n sample-domain1-ns get pods -l weblogic.domainUID=sample-domain1
NAME READY STATUS RESTARTS AGE
sample-domain1-admin-server 1/1 Running 0 19h
sample-domain1-introspector-v2l7k 0/1 Error 0 75m
sample-domain1-managed-server1 1/1 Running 0 19h
sample-domain1-managed-server2 1/1 Running 0 19h
まず、ジョブのdescribe
コマンドの出力を確認します。
$ kubectl -n sample-domain1-ns describe job/sample-domain1-introspector
次に、ジョブのポッドdescribe
出力を確認します。特に、そのevents
を参照してください。
$ kubectl -n sample-domain1-ns describe pod/sample-domain1-introspector-v2l7k
最後に、ジョブのポッドのログを確認します。
$ kubectl -n sample-domain1-ns logs job/sample-domain1-introspector
前述のコマンドと同じ出力を持つ代替のログ・コマンドを次に示します。$ kubectl -n sample-domain1-ns logs pod/sample-domain1-introspector-v2l7k
Model in Imageドメインでイントロスペクタ・ジョブが失敗する一般的な理由は、モデル・ファイルのエラーが原因です。 このような失敗を示すイントロスペクタ・ジョブからのサンプル・ログ出力を次に示します:
...
SEVERE Messages:
1. WLSDPLY-05007: Model file /u01/wdt/models/model1.yaml,/weblogic-operator/wdt-config-map/..2020_03_19_15_43_05.993607882/datasource.yaml contains an unrecognized section: TYPOresources. The recognized sections are domainInfo, topology, resources, appDeployments, kubernetes
イントロスペクタ・ログは、spec.logHome
が構成され、spec.logHomeEnabled
がtrueの場合、ドメイン・リソースのspec.logHome
ディレクトリにミラー化されます。
モデル・ファイル・エラーがspec.configuration.model.configMap
のモデル・ファイルを参照している場合は、修正したモデル・ファイルを使用してConfigMapを再デプロイし、ドメインの再起動またはロールを開始することでエラーを修正できます。 同様に、モデル・ファイル・エラーがモデル・イメージ内のモデル・ファイルを参照している場合は、修正したイメージをデプロイし、新しいイメージを参照するようにドメインYAMLファイルを変更してから、ドメインの再起動またはロールを開始することでエラーを修正できます。
イントロスペクタ・ジョブが成功した場合、イントロスペクタ・ジョブまたはポッドは存在せず、オペレータがドメインのMY_DOMAIN_UID-weblogic-domain-introspect-cm
ConfigMapを作成し、オペレータがドメインのWebLogic Serverポッドを実行します。
kubectl -n MY_NAMESPACE get pods
でWebLogic Serverポッドにエラーがあることが判明した場合は、kubectl -n MY_NAMESPACE describe pod POD_NAME
、kubectl -n MY_NAMESPACE logs POD_NAME
またはkubectl -n MY_NAMESPACE get events --sort-by='.lastTimestamp'
(あるいはその両方)を使用してデバッグします。
実行中のドメインのWebLogic構成に対してオンライン更新を実行する場合は、「オンライン更新ステータスとラベル」を参照してください。
対応するドキュメントがある一般的な問題は次のとおりです:
describe
でイメージ・アクセス・エラーが表示される場合は、「イメージをプルできません」のFAQを参照してください。問題がオペレータ自体またはネームスペース管理に固有である場合は、オペレータ「トラブルシューティング」のドキュメントを参照してください。