オペレータがインストールされ、実行されると、そのオペレータ自体をデバッグすることがほとんどありません。 特定のドメイン・リソースに問題がある場合は、最初に「ドメインのデバッグ」を参照してください。
オペレータ・ランタイムは、Kubernetesクラスタにインストールされ、Helmリリースを使用して維持されます。 インストールされているHelmリリースをリストし、各リリースの構成を取得する方法については、「有用なHelm操作」を参照してください。
オペレータをインストールして実行する場合、インストールによって、ドメイン・カスタム・リソースおよびクラスタ・カスタム・リソースがクラスタにデプロイされている必要があります。 確認するには、次のコマンドで、名前がdomains.weblogic.oracleのCRDと、名前がclusters.weblogic.oracleの別のCRDがリストされていることを確認します:
$ kubectl get crd
コマンドの出力は次のようになります:
NAME CREATED AT
clusters.weblogic.oracle 2022-10-15T03:45:27Z
domains.weblogic.oracle 2022-10-15T03:45:27Z
ドメインまたはクラスタのCRDがインストールされていない場合、オペレータ・ランタイムはドメインまたはクラスタを監視できず、kubectl get domainsなどのコマンドは失敗します。
通常、オペレータは、最初に起動したときに各CRDを自動的にインストールします。 ただし、CRDがインストールされなかった場合(たとえば、オペレータがインストールするための十分なアクセス権がない場合)は、オペレータの「インストールの準備」のドキュメントを参照してください。
weblogic.operatorNameラベルを持つすべてのデプロイメントをリストして、オペレータのデプロイメントがデプロイされ、実行されていることを確認します。
$ kubectl get deployment --all-namespaces=true -l weblogic.operatorName
オペレータ・デプロイメントの詳細ステータスを確認します:
$ kubectl -n OP_NAMESPACE get deployments/weblogic-operator -o yaml
And/or:
$ kubectl -n OP_NAMESPACE describe deployments/weblogic-operator
各オペレータ・デプロイメントには、対応するKubernetesポッドと、デプロイメント名に一致するプレフィクスを持つ名前、およびデプロイメントの再起動時に変わる一意のサフィクスが含まれます。
オペレータ・ポッドを検索し、上位レベルのステータスをチェックするには:
$ kubectl get pods --all-namespaces=true -l weblogic.operatorName
特定のポッドの詳細を確認するには:
$ kubectl -n OP_NAMESPACE get pod weblogic-operator-UNIQUESUFFIX -o yaml
$ kubectl -n OP_NAMESPACE describe pod weblogic-operator-UNIQUESUFFIX
ポッドdescribeには、オペレータに関連付けられている可能性があるイベントが含まれます。
Kubernetesクラスタのすべてのオペレータは、1つの変換webフック・デプロイメントを共有します。 すべてのデプロイメントをweblogic.webhookNameラベルとともにリストして、変換webフックがデプロイされ、実行中であることを確認します。
$ kubectl get deployment --all-namespaces=true -l weblogic.webhookName
変換webフック・デプロイメントの詳細ステータスを確認します:
$ kubectl -n WH_NAMESPACE get deployments/weblogic-operator-webhook -o yaml
And/or:
$ kubectl -n WH_NAMESPACE describe deployments/weblogic-operator-webhook
各変換webフック・デプロイメントには、対応するKubernetesポッドと、デプロイメント名に一致するプレフィクスを持つ名前、およびデプロイメントが再起動されるたびに変化する一意のサフィクスが含まれます。
変換webフック・ポッドを検索し、その高レベルのステータスを確認するには:
$ kubectl get pods --all-namespaces=true -l weblogic.webhookName
特定のポッドの詳細を確認するには:
$ kubectl -n WH_NAMESPACE get pod weblogic-operator-webhook-UNIQUESUFFIX -o yaml
$ kubectl -n WH_NAMESPACE describe pod weblogic-operator-webhook-UNIQUESUFFIX
ポッドdescribeには、変換webフックに関連付けられている可能性があるイベントが役立ちます。 webフックのインストールおよびアンインストールの詳細は、「WebLogicドメイン・リソース変換webフック」を参照してください。
オペレータのネームスペースに記録されたKubernetesイベントを確認するには:
$ kubectl -n OP_NAMESPACE get events --sort-by='.lastTimestamp'
変換webフックのネームスペースに記録された可能性のあるKubernetesイベントを確認するには:
$ kubectl -n WH_NAMESPACE get events --sort-by='.lastTimestamp'
オペレータ・ログでSEVEREおよびERRORレベルのメッセージを探します。 例えば:
オペレータを検索します。
$ kubectl get deployment --all-namespaces=true -l weblogic.operatorName
NAMESPACE NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
sample-weblogic-operator-ns weblogic-operator 1 1 1 1 20h
オペレータ・ログでgrepを使用し、SEVEREおよびWARNINGレベルのメッセージを探します。
$ kubectl logs deployment/weblogic-operator -n sample-weblogic-operator-ns \
| egrep -e "level...(SEVERE|WARNING)"
{"timestamp":"03-18-2020T20:42:21.702+0000","thread":11,"fiber":"","domainUID":"","level":"WARNING","class":"oracle.kubernetes.operator.helpers.HealthCheckHelper","method":"createAndValidateKubernetesVersion","timeInMillis":1584564141702,"message":"Kubernetes minimum version check failed. Supported versions are 1.13.5+,1.14.8+,1.15.7+, but found version v1.12.3","exception":"","code":"","headers":{},"body":""}
grep "domainUID...MY_DOMAINUID"を使用して前のlogコマンドをパイプすることで、domainUIDに固有のオペレータ・ログ・メッセージをフィルタで除外できます。 たとえば、オペレータがネームスペースsample-weblogic-operator-nsで実行されており、ドメインUIDがsample-domain1であるとします:
$ kubectl logs deployment/weblogic-operator -n sample-weblogic-operator-ns \
| egrep -e "level...(SEVERE|WARNING)" \
| grep "domainUID...sample-domain1"
変換webフック・デプロイメントのログを確認するには(特に、SEVEREおよびERRORレベルのメッセージを探します):
$ kubectl logs -n YOUR_CONVERSION_WEBHOOK_NS -c weblogic-operator-webhook deployments/weblogic-operator-webhook
オペレータの設定は、Helmによって、オペレータと同じネームスペースのweblogic-operator-cmという名前のKubernetes ConfigMapに自動的に保持されます。 このConfigMapの内容を表示するには、kubectl -n sample-weblogic-operator-ns get cm weblogic-operator-cm -o yamlをコールします。
オペレータは、失敗が発生した場合でも何千ものドメインを堅牢に処理するように設計されているため、アップグレード後でもオペレータを強制的に再起動する必要はありません。 したがって、解決するためにオペレータの再起動が必要と思われる問題が発生した場合は、オペレータの開発チームが問題を認識していることを確認してください(「ヘルプを表示」を参照)。
オペレータを再起動すると、次のようになります:
オペレータを再起動するには、いくつかの方法があります:
ほとんどの場合、helm upgradeコマンドを使用: helm upgrade <release-name> --reuse-values --recreate-pods
$ helm upgrade weblogic-operator --reuse-values --recreate-pods
オペレータ・ポッドを削除し、Kubernetesで再起動します。
a. まず、削除するオペレータ・ポッドを検索します:
$ kubectl get pods --all-namespaces=true -l weblogic.operatorName
b. 次に、ポッドを削除します。 例えば:
$ kubectl delete pod/weblogic-operator-65b95bc5b5-jw4hh -n OP_NAMESPACE
replicasの値を変更して、オペレータのデプロイメントを0にスケーリングし、1に戻ります。
a. まず、再起動するオペレータ・デプロイメントのネームスペースを見つけます:
$ kubectl get deployment --all-namespaces=true -l weblogic.operatorName
b. 次に、デプロイメントをゼロ・レプリカにスケール・ダウンします:
$ kubectl scale deployment.apps/weblogic-operator -n OP_NAMESPACE --replicas=0
c. 最後に、デプロイメントを1つのレプリカにスケール・アップします:
$ kubectl scale deployment.apps/weblogic-operator -n OP_NAMESPACE --replicas=1
より詳細なロギング・レベルを使用するようにオペレータおよび変換webフックを変更する必要があることはほとんどありませんが、まれにオペレータ・サポート・チームが指示する場合があります。 ロギング・レベルを変更する場合、FINEまたは細かいロギング・レベルはきわめて冗長で、数時間の間にギガバイトのディスク容量をすばやく使い切ることができます。また、アクティビティが重い場合は数分で最大レベルを上げることができます。 その結果、ロギング・レベルを増やすのは、特定の問題のデバッグ・データを取得するために必要になるかぎりです。
オペレータjavaLoggingLevelをFINE (デフォルトはINFO)に設定するには、オペレータHelmリリースの名前がsample-weblogic-operatorであると仮定します。そのネームスペースはsample-weblogic-operator-nsで、オペレータsrcを/tmp/weblogic-kubernetes-operatorにローカルでダウンロードしています:
$ cd /tmp/weblogic-kubernetes-operator
$ helm upgrade \
sample-weblogic-operator \
weblogic-operator/weblogic-operator \
--namespace sample-weblogic-operator-ns \
--reuse-values \
--set "javaLoggingLevel=FINE" \
--wait
オペレータjavaLoggingLevelをINFOに戻すには:
$ helm upgrade \
sample-weblogic-operator \
weblogic-operator/weblogic-operator \
--namespace sample-weblogic-operator-ns \
--reuse-values \
--set "javaLoggingLevel=INFO" \
--wait
詳細は、javaLoggingLevelのドキュメントを参照してください。
変換webフックの一般的なミスや解決策を次に示します。
「変換webフック・デプロイメントの確認」のステップに従って、変換webフックがデプロイされ、実行されていることを確認します。 デプロイされていない場合、weblogic.oracle/v8スキーマのドメイン・リソースを使用してドメインを作成すると、次のconversion webhook not foundエラーが表示されます。
Error from server: error when creating "k8s-domain.yaml": conversion webhook for weblogic.oracle/v9, Kind=Domain failed: Post "https://weblogic-operator-webhook-svc.sample-weblogic-operator-ns.svc:8084/webhook?timeout=30s": service "weblogic-operator-webhook-svc" not found
変換webフックはスタンドアロンでデプロイすることも、オペレータ・インストールの一部としてデプロイすることもできます。 変換webフックがオペレータ・インストールの一部としてインストールされた場合、オペレータのアンインストール時にデフォルトで暗黙的に削除されます。 変換webフックがデプロイまたは実行されていない場合は、「変換webフックのインストール」のステップに従って再インストールします。
変換webフック・デプロイメントがデプロイされているが、準備完了ステータスではない場合、weblogic.oracle/v8スキーマのドメイン・リソースを使用してドメインを作成すると、connection refusedエラーが表示されます。
エラー・メッセージのPOST URLには、変換webフック・サービスの名前とネームスペースがあります。 たとえば、POST URLがhttps://weblogic-operator-webhook-svc.sample-weblogic-operator-ns.svc:8084/webhook?timeout=30sの場合、サービス名はweblogic-operator-webhook-svcで、ネームスペースはsample-weblogic-operator-nsです。 この場合、次のコマンドを実行して、デプロイメントが実行され、webフック・サービスがsample-weblogic-operator-nsネームスペースに存在することを確認します。
$ kubectl get deployment weblogic-operator-webhook -n sample-weblogic-operator-ns
NAME READY UP-TO-DATE AVAILABLE AGE
weblogic-operator-webhook 1/1 1 1 87m
$ kubectl get service weblogic-operator-webhook-svc -n sample-weblogic-operator-ns
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
weblogic-operator-webhook-svc ClusterIP 10.106.89.198 <none> 8084/TCP 88m
変換webフック・デプロイメント・ステータスが準備完了でない場合、変換webフック・ネームスペースの「変換webフック・ログの確認」および「変換webフック・イベント」。 変換webフック・サービスが存在しない場合は、変換webフックが正しくインストールされていることを確認し、変換webフックを再インストールして、問題が解決されるかどうかを確認します。
変換webフックからの次のx509: certificate signed by unknown authorityエラーは、環境内のKubernetes APIサーバーのプロキシ構成が正しくないか、ドメインCRDの変換Webフック構成の自己署名証明書が正しくないことが原因である可能性があります。
Error from server (InternalError): error when creating "./weblogic-domains/sample-domain1/domain.yaml": Internal error occurred: conversion webhook for weblogic.oracle/v8, Kind=Domain failed: Post "https://weblogic-operator-webhook-svc.sample-weblogic-operator-ns.svc:8084/webhook?timeout=30s": x509: certificate signed by unknown authority
環境でPROXYサーバーを使用する場合は、Kubernetes APIサーバーのNO_PROXY設定に.svc値が含まれていることを確認してください。 Kubernetes APIサーバーは、POST URLのホスト名weblogic-operator-webhook-svc.${NAMESPACE}.svcを使用して、変換webフックRESTエンドポイントへのRESTリクエストを行います。 RESTリクエストがPROXYサーバーを介してルーティングされると、次のエラーが表示されます"x509: certificate signed by unknown authority"。 このRESTリクエストはKubernetesクラスタの内部にあるため、.svcをNO_PROXY設定に追加してPROXYサーバーを介してルーティングされないようにしてください。
なんらかの理由でドメインCRD変換webフック構成に正しくない自己署名証明書がある場合は、ドメインCRDにパッチを適用して、既存の変換Webフック構成を削除できます。 オペレータは、ドメインCRDの正しい自己署名証明書を使用して、変換webフック構成を再作成します。 次のpatchコマンドを使用して、ドメインCRD内の変換webフック構成を削除し、エラーを解決するかどうかを確認します。
kubectl patch crd domains.weblogic.oracle --type=merge --patch '{"spec": {"conversion": {"strategy": "None", "webhook": null}}}'
オペレータ・バージョン4.xをインストールするか、オペレータ4.xにアップグレードすると、変換webフック構成がドメインCRDに追加されます。 オペレータ・バージョン3.xにダウングレードまたはスイッチバックした場合、変換webフック構成はCRDから削除されません。 これは、複数のオペレータ・インストールが異なるバージョンを持つ可能性のある環境をサポートするためのものです。 オペレータが1つインストールされている環境では、次のpatchコマンドを使用して、ドメインCRDから変換webフック構成を手動で削除します。
kubectl patch crd domains.weblogic.oracle --type=merge --patch '{"spec": {"conversion": {"strategy": "None", "webhook": null}}}'
オペレータがDedicatedモードで実行されている場合、オペレータのサービス・アカウントにはCRDの読取りまたは更新の権限がありません。 変換webフックをDedicatedモードで使用して、weblogic.oracle/v8スキーマを持つドメイン・リソースをweblogic.oracle/v9スキーマに変換する必要がある場合は、変換Webフック構成をドメインCRDに手動で追加できます。 次のpatchコマンドを使用して、変換webフック構成をドメインCRDに追加します。
ノート: 次のコマンドのYOUR_OPERATOR_NSを、オペレータがインストールされているネームスペースに置き換えます。
export OPERATOR_NS=YOUR_OPERATOR_NS
kubectl patch crd domains.weblogic.oracle --type=merge --patch '{"spec": {"conversion": {"strategy": "Webhook", "webhook": {"clientConfig": { "caBundle": "'$(kubectl get secret weblogic-webhook-secrets -n ${OPERATOR_NS} -o=jsonpath="{.data.webhookCert}"| base64 --decode)'", "service": {"name": "weblogic-operator-webhook-svc", "namespace": "'${OPERATOR_NS}'", "path": "/webhook", "port": 8084}}, "conversionReviewVersions": ["v1"]}}}}'
weblogic.oracle/v8スキーマ・ドメイン・リソースを使用してドメインを作成するときにWebLogic Domain custom resource conversion webhook failedエラーが表示された場合は、変換webフック・ネームスペースで「変換webフック・ランタイムPodログの確認」および「生成されたイベントのチェック」になります。 変換webフックがsample-weblogic-operator-nsネームスペースにデプロイされていると想定して、次のコマンドを実行してログおよびイベントを確認します。
$ kubectl logs -n sample-weblogic-operator-ns -c weblogic-operator-webhook deployments/weblogic-operator-webhook
$ kubectl get events -n sample-weblogic-operator-ns
次のいずれかを設定した場合、これらのドキュメントはデバッグに役立ちます: