機械翻訳について

ステータス条件

目次

概要

WebLogic Kubernetes Operatorは、ドメインおよびクラスタ・リソースにステータス条件を移入して、高レベルのステータス・レポートを提供します。 ステータス条件はKubernetes標準メカニズムであり、オペレータによって生成される条件は、Kubernetesがポッドおよびデプロイメント・リソースに提供する条件と似ています。

ドメインまたはクラスタの状態の確認

条件は、ドメイン・リソースまたはクラスタ・リソースのstatus.conditionsフィールドの下にあります。

次を使用して、ドメイン・リソースの条件を確認できます: kubectl -n MY_NAMESPACE describe domain MY_DOMAIN_RESOURCE_NAME。 同様に、次を使用してクラスタ・リソースの条件を確認できます: kubectl -n MY_NAMESPACE describe cluster MY_CLUSTER_NAME。

「条件を示すクラスタ・ステータスの例については、ここをクリックしてください。」

「ドメインによって参照されるクラスタ・リソース」の条件は、domain.status.clustersのドメイン・ステータスにもリストされます。

「ドメインとクラスタの両方の条件を示すドメイン・ステータスの例については、ここをクリックしてください。」

条件の属性

条件には、次の属性があります:

  • type - 条件のタイプ(FailedやAvailableなど)。 「ドメイン・ステータス条件のタイプ」を参照してください。
  • status - 条件のステータス(TrueやFalseなど)。
  • message - 条件の詳細を提供する、人間が読めるオプションのメッセージ。
  • reason - Failed条件の「理由」。 他のタイプの条件には適用されません。
  • severity - Failed条件の「重大度」。 他のタイプの条件には適用されません。
  • lastTransitionTime - 条件が作成された日時、または条件がステータス間で最後に遷移した時間のタイムスタンプ。

ドメイン条件のタイプ

次に、ドメイン・リソースの条件タイプのリストを示します。

Failed

  • ドメイン・リソースの処理中に失敗が発生したため、ドメイン・リソースの目的の状態を達成できません。 失敗の診断方法については、「デバッグ」を参照してください。
  • Failed条件の場合、status属性は常にTrueです。 基礎となる失敗が解決されると、Failed条件がドメイン・ステータスから削除されます。
  • message属性には、失敗の詳細を示すエラー・メッセージが含まれています。
  • reason属性は、「ドメイン失敗の理由」にリストされているいずれかの理由に設定されます。
  • severity属性は、「ドメイン失敗の重大度」にリストされている重大度レベルのいずれかに設定されます。
    「失敗条件のドメイン・ステータスの例については、ここをクリックしてください。」

Completed

  • Completed条件のstatus属性は、ドメイン・リソースの目的の状態が完全に達成されたかどうかを示します。
  • 次のすべてがtrueの場合、status属性はTrueに設定されます:
    • Failed条件はありません。たとえば、失敗は検出されません。
    • 次のいずれかの条件を満たしています:
      • 実行されると予想されるすべてのWebLogic Serverポッドは、ターゲット・イメージ(1つまたは複数)のready、restartVersionおよびintrospectVersionです。
      • WebLogic Serverポッドは実行されておらず、これは予想される状態です。
      • ドメインはAdminOnlyのspec.serverStartPolicy値を持つように構成され、管理サーバー・ポッドは実行され、準備ができています。
    • 保留中のサーバー停止リクエストはありません。

Available

  • 次のすべてに当てはまるように十分な数のポッドの準備ができたら、status属性がTrueに設定されます:
    • 少なくとも1つのWebLogic Serverポッドの準備ができました。
    • serverStartPolicy値がIfNeededまたはAlwaysのすべての非クラスタ・サーバーは、準備ができています。
    • ドメインによって参照されるすべてのクラスタ・リソースは、Available条件でTrueを持ちます。 0のreplicas値またはserverStartPolicy値Neverで構成されたクラスタは無視されます。
  • ノート: Available statusは、Completed条件のstatusがFalse、Failed条件がレポートされた場合、またはクラスタに準備が完了していない最大cluster.spec.maxUnavailableポッドがある場合でも、Trueにできます。

ConfigChangesPendingRestart

  • この条件は、Model in Imageドメイン・ホーム・ソース・タイプのWebLogic Deploy Toolingモデルに対する「ランタイム更新」の進行状況を追跡します。
  • 次のすべてがtrueの場合、status属性はTrueです:
    • ドメイン・リソース属性domain.spec.configuration.model.onlineUpdate.onNonDynamicChangesはCommitUpdateOnlyです。
    • ドメイン・リソース属性domain.spec.configuration.model.onlineUpdate.enabledはTrueです。
    • モデル変更があり、これらの変更によって非動的WebLogic構成が変更されました。
    • イントロスペクタ・ジョブを含む処理が正常に完了しました。
    • 管理者は、その後、各WebLogic Serverポッドをロールまたは再起動していません(保留中の動的でない変更を伝播するため)。
  • 保留中の非動的ランタイム更新がロールまたは再起動のために処理を完了すると、ConfigChangesPendingRestart条件がドメイン・ステータスから削除されます。
  • WebLogicポッド・ラベルを使用して再起動を待機しているポッドを確認する方法は、「オンライン更新ステータスとラベル」を参照してください。
    「ConfigChangesPendingRestart条件を持つドメイン・ステータスの例については、ここをクリックしてください。」

Rolling

  • この条件は、ドメイン・リソースへの更新を検出した後や、ドメインの「ローリング再起動」を実行する必要があるModel in Imageモデルなど、オペレータがドメイン内のサーバー・ポッドをローリングしていることを示します。
  • Rolling条件の場合、status属性は常にTrueです。
  • ローリングが完了すると、Rolling条件がドメイン・ステータスから削除されます。

クラスタ条件のタイプ

次に、クラスタ・リソースの条件タイプのリストを示します。

Completed

  • Completed条件のstatus属性は、クラスタ・リソースの目的の状態が完全に達成されているかどうかを示します。
  • 次のすべてがtrueの場合、status属性はTrueに設定されます:
    • Failed domain.status.conditionsはありません。
    • WebLogic Serverポッドが実行されていないか、クラスタ内のすべてのサーバー・ポッドがターゲット・イメージまたはイメージ(restartVersionおよびintrospectVersion)で準備できていることが予想されます
    • 保留中のサーバー停止リクエストはありません。

Available

  • クラスタで十分な数のWebLogic Serverポッドが使用可能な場合、status属性はTrueに設定されます。 次の両方がtrueである必要があります:
    • クラスタ内の少なくとも1つのポッドが実行される予定で、readyです。
    • 実行されることが予想されるnot readyサーバー・ポッドの数は、cluster.spec.maxUnavailableの値以下で、デフォルトは1です。
  • 例:
    • クラスタのserverStartPolicyがNever、replicasが0、またはクラスタがserverStartPolicyがAdminOnlyまたはNeverのドメイン内にある場合、クラスタのAvailable条件はFalseになります。
    • クラスタとドメインの両方にIfNeededのserverStartPolicyがあり、cluster.spec.replicasが1の場合、単一のポッドの準備ができている場合にのみ、クラスタのAvailable条件はTrueになります。
    • クラスタとドメインの両方でserverStartPolicyがIfNeeded、cluster.spec.replicasが4、cluster.spec.maxUnavailableが1 (デフォルト)の場合、クラスタは3つまたは4つのポッドの準備ができている場合にのみ、Available条件がTrueになります。
  • ノート: Completed条件のstatusがFalseの場合、ドメイン・リソースでFailed条件がレポートされた場合、またはクラスタに準備が完了していない最大cluster.spec.maxUnavailableポッドがある場合でも、Available条件のstatusをTrueにできます。

条件ライフ・サイクル

オペレータは、クラスタまたはドメイン・リソースを検出した後、各リソースが常にAvailableおよびCompleted条件の1回のみ発生することを確認します。 その後、オペレータはこれらの条件を削除しませんが、かわりに、必要に応じてステータスをTrueまたはFalseに変更します。 オペレータがドメインまたはクラスタ・リソースを検出したタイミングを判断する方法として、この事実を使用できます。

Failure、RollingおよびConfigChangesPendingRestart条件はエフェメラルです。これらは適用されたときにのみ追加され、適用されなくなったときに削除されます。

Failure条件は、複数回発生できる唯一の条件です。 これは、異なるタイプの同時失敗が複数ある場合に発生します。

条件および世代

ドメインおよびクラスタ・リソースでmetadata.generationおよびstatus.observedGenerationを使用して、それらの条件およびその他のステータスが最新であるかどうかを検出します。 具体的には、domain.status.observedGeneration生成がdomain.metadata.generationと等しくない場合、またはドメインのクラスタ・リソースのいずれかでcluster.status.observedGenerationがcluster.metadata.generationと等しくない場合、条件は最新でない場合があります。 これは、オペレータがステータスの更新処理中であるか、オペレータが実行中でないことを示します。

条件およびイベント

対応するイベントは、Available, Completed, FailureまたはRolling条件が変更されたときに生成されます。 詳細は、「オペレータ生成イベント・タイプ」を参照してください。