原文はこちら。
https://blogs.oracle.com/weblogicserver/weblogic-dynamic-clusters-on-kubernetes

---

Overview

WebLogic Serverクラスタは、複数の管理対象サーバ・インスタンスで構成され、スケーラビリティと信頼性を向上させるために同時に実行し、連携して動作します。WebLogic Serverは構成済みと動的クラスタの2種類のクラスタ構成をサポートします。構成済みクラスタは手作業で各管理対象サーバインスタンスを構成して作成します。動的クラスタの場合、管理対象サーバ構成を単一の共有テンプレートから生成します。テンプレートを利用することで、管理対象サーバのクラスタ構成を大幅に簡素化し、動的にサーバをマシンリソースに割り当てることができるため、最小限の構成でリソースを最大限に活用できます。動的クラスタでは、追加サーバの容量が必要な場合、新規サーバインスタンスをクラスタに追加できます。個々に管理対象サーバを手作業で構成する必要はありません。また、構成済みクラスタとは異なり、動的クラスタのスケールアップはクラスタ向けに定義済みの一連のサーバに制限されませんが、ランタイムの要求に基づいて増やすことができます。
WebLogic Serverで動的クラスタの作成、構成、利用方法は、以下のドキュメントをご覧ください。

Oracle® Fusion Middleware Administering Clusters for Oracle WebLogic Server 12c (12.2.1.3.0)
Dynamic Clusters
http://docs.oracle.com/middleware/12213/wls/CLUST/dynamic_clusters.htm
Oracle® Fusion Middleware Oracle WebLogic Serverクラスタの管理 12c (12.2.1.3.0)
動的クラスタ
https://docs.oracle.com/cd/E92951_01/wls/CLUST/dynamic_clusters.htm

Support for Dynamic Clusters by Oracle WebLogic Server Kubernetes Operator

以前は、WebLogic Server Kubernetes Operatorは構成済みクラスタのみをサポートしていました。つまりOperatorは、構成済みクラスタに対して定義された管理対象サーバのみを管理、拡張できましたが、その制限はとうとう削除されました。Operatorは、動的クラスタをサポートすることで、最初に手作業で設定するのではなく、サーバテンプレートに基づいて管理対象サーバ・インスタンスの数を容易に調整できます。

Creating a Dynamic Cluster in a WebLogic Domain in Kubernetes

WebLogic Serverチームは、KubernetesでのWebLogic Serverの統合、Kubernetes上でのWebLogic Serverの動作保証に積極的に取り組んでいます。

WebLogic Server Certification on Kubernetes
https://blogs.oracle.com/weblogicserver/weblogic-server-certification-on-kubernetes
https://orablogs-jp.blogspot.jp/2018/01/weblogic-server-certification-on.html

Oracle WebLogic Server Kubernetes Operatorは、任意の数のWebLogicドメインの作成と管理、ドメイン起動の自動化、WebLogicクラスタのスケール、WebLogicクラスタにデプロイされたWebアプリケーションの負荷分散の管理、Elasticsearch、Logstash、およびKibanaとの統合を提供します。Operatorは現在、オープンソースプロジェクトとしてご利用いただけるようになっています。

Oracle Weblogic Server Kubernetes Operator
https://oracle.github.io/weblogic-kubernetes-operator/

WebLogicドメインを作成する場合、推奨方法は提供されるスクリプト（weblogic-domain.sh）を使い、Kuberenetesクラスタ内でWebLogicドメインの作成を自動化することです。

create-weblogic-domain.sh
https://github.com/oracle/weblogic-kubernetes-operator/blob/master/kubernetes/create-weblogic-domain.sh

このスクリプトはcreate-weblogic-domain-inputs.yamlという入力ファイルを取ります。このファイルはWebLogicドメインの構成プロパティを指定するものです。

create-weblogic-domain-inputs.yaml
https://github.com/oracle/weblogic-kubernetes-operator/blob/master/kubernetes/create-weblogic-domain-inputs.yaml

入力ファイルの以下のパラメータを使って動的クラスタを作成します。

initialManagedServerReplicas

Parameter	Definition	Default
clusterName	ドメインで生成するWebLogicクラスタインスタンスの名前	cluster-1
clusterType	WebLogicクラスタのタイプ（CONFIGUREDもしくは DYNAMIC）	CONFIGURED
configuredManagedServerCount	ドメインに生成する管理対象サーバインスタンスの個数	2
initialManagedServerReplicas	ドメインで最初に起動する管理対象サーバの個数	2
managedServerNameBase	管理対象サーバ名を生成するために使う基礎文字列。動的クラスタのサーバテンプレートでサーバ名の接頭辞として利用。	managed-server

以下の構成例では、cluster-1という名前の動的クラスタを作成します。このクラスタには定義済みの管理対象サーバ4個（managed-server1 … managed-server4）があり、最初2個の管理対象サーバ（managed-server1と managed-server2）が立ち上がります。

# Type of WebLogic Cluster

# Legal values are "CONFIGURED" or "DYNAMIC"
clusterType: DYNAMIC

# Cluster name
clusterName: cluster-1

# Number of Managed Servers to generate for the domain
configuredManagedServerCount: 4

# Number of Managed Servers to initially start for the domain
initialManagedServerReplicas: 2

# Base string used to generate Managed Server names
managedServerNameBase: managed-server

WebLogicドメインを作成するには、入力ファイルと生成された構成ファイルを格納するための出力ディレクトリを指定して、create-weblogic-domain.shスクリプトを実行します。

create-weblogic-domain.sh
https://github.com/oracle/weblogic-kubernetes-operator/blob/master/kubernetes/create-weblogic-domain.sh

#> create-weblogic-domain.sh  –i create-domain-job-inputs.yaml  -o /path/to/weblogic-domain-output-directory

ドメイン作成スクリプトを使ってWebLogicクラスタを作成する場合、いくつかの制限があります。

• スクリプトは指定の個数の管理対象サーバインスタンスを作成し、全てを1個のクラスタに配置する
• スクリプトは常に1個のクラスタを作成する

代替策として、以下のURLに概要を記載しているように、WebLogicドメインを手作業で作成できます。

Manually creating a WebLogic domain
https://github.com/oracle/weblogic-kubernetes-operator/blob/master/site/manually-creating-domain.md

How WebLogic Kubernetes Operator Manages a Dynamic Cluster

Kubernetes Operatorは、Kubernetes APIを拡張して複雑なアプリケーションのインスタンスを作成、構成、管理するためのアプリケーション固有のコントローラです。Operatorsの詳細情報は、以下のエントリをご覧ください。

Introducing Operators: Putting Operational Knowledge into Software
https://coreos.com/blog/introducing-operators.html

Oracle WebLogic Server Kubernetes OperatorはKubernetesを拡張し、Kubernetes環境で動作する任意の個数のWebLogicドメインを作成、構成、管理します。ドメイン作成、ドメイン起動の自動化、構成済みクラスタならびに動的クラスタのいずれもスケールできる機能を有します。WebLogic Server Kubernetes Operatorの詳細は、以下のエントリをご覧ください。

Announcing the Oracle WebLogic Server Kubernetes Operator
https://blogs.oracle.com/weblogicserver/announcing-the-new-weblogic-server-kubernetes-operator
https://orablogs-jp.blogspot.jp/2018/03/announcing-oracle-weblogic-server.html

WebLogic Server Kubernetes Operatorは、Kubernetesクラスタ内の管理対象サーバのライフサイクルを管理するため、WebLogic動的クラスタを起動およびスケールアップ（アップまたはダウン）する機能を提供します。 WebLogic Server Kubernetes Operatorは、カスタムリソースドメイン（Custom Resource Domain、CRD）で定義された設定に基づいて、WebLogicドメインの起動を管理します。

動的クラスタの場合、Kubernetesクラスタで実行されているWLS Pod/管理対象サーバインスタンスの数は、次のドメインカスタムリソースYAMLファイルのClusterStartupエントリの 'replicas'という属性値で表されます。

clusterStartup:
  - desiredState: "RUNNING"
    clusterName: "cluster-1"
    replicas: 2
    env:
    - name: JAVA_OPTIONS
      value: "-Dweblogic.StdoutDebugEnabled=false"
    - name: USER_MEM_ARGS
      value: "-Xms64m -Xmx256m"

上記の例では、WebLogic Server Kubernetes OperatorはWebLogicドメイン起動中に2個のPod/管理対象サーバインスタンスをcluster-1という動的クラスタのために起動します。ドメインカスタムリソースYAMLファイルの詳細は以下のURLをご覧ください。

Starting a WebLogic domain
https://github.com/oracle/weblogic-kubernetes-operator/blob/master/site/starting-domain.md

Scaling of WebLogic Dynamic Clusters on Kubernetes

WebLogic Server Kubernetes Operatorを使ってスケールを開始するにはいくつかの方法があります。具体的には以下のようなものです。

1. オンデマンドでCustom Resource Domain仕様を直接更新する（kubectlの利用）
2. cURLなどを使い、WebLogic Server Kubernetes OperatorのREST APIを呼び出す
3. WLDFポリシールールとスクリプトアクションを使って、WebLogic Kubernetes OperatorのREST API呼び出す
4. Prometheusアラートアクションを使ってWebLogic Server Kubernetes OperatorのREST APIを呼び出す

1) On-Demand, Updating the Custom Resource Domain Directly

動的クラスタのスケールはCustom Resource Domainファイルを直接編集することで実現できます。具体的にはkubectl editコマンドを使って属性replicasの値を変更することで対応します。

#> kubectl edit domain domain1 -n [namespace]

このコマンドで定義済みのCustom Resource Domain仕様の編集が可能なエディタを開きます。コミットしたら、WebLogic Server Kubernetes Operatorは変更を検知して、実行中のPod/管理対象サーバインスタンスの数をreplicasの値と照合し、即座に対応する動的クラスタをスケールしようと試みます。

Calling the Operator's REST Scale API

WebLogic Server Kubernetes Operatorは、次のURL形式のRESTエンドポイントを公開しており、承認されたアクタがWebLogicクラスタのスケーリングを要求できます。

http(s)://${OPERATOR_ENDPOINT}/operator/<version>/domains/<domainUID>/clusters/<clusterName>/scale

• <version> : RESTリソースのバージョン
• <domainUID> : 特定のドメインを示すために利用するユニークなID。Kubernetesクラスタ内の全ドメインにわたり一意である必要がある。
• <clusterName> : スケールしたいWebLogicクラスタインスタンスの名前

例えば以下のようなURLです。

http(s)://${OPERATOR_ENDPOINT}/operator/v1/domains/domain1/clusters/cluster-1/scale

/scaleというRESTエンドポイントでは、

• HTTP POSTリクエストを受け付ける
• リクエスト本体ではJSON（application/json）メディアタイプをサポートする
• リクエスト本体はmanagedServerCountというシンプルな名前と値を持つ

{
      ”managedServerCount": 3
}

managedServerCountで、スケール後のWebLogic Serverインスタンスの個数を指示します。

Note: cURLコマンドを使ったREST APIの利用例は、以下のシェルスクリプトにあります。

scalingAction.sh
https://github.com/oracle/weblogic-kubernetes-operator/blob/master/src/scripts/scaling/scalingAction.sh

Using a WLDF Policy Rule and Script Action to Call the Operator's REST Scale API

WebLogic診断フレームワーク（WLDF）が提供するリソースメトリックに基づいて、Podの数を増やしたり減らしたりして、WebLogic Serverの動的クラスタを自動的に拡大/縮小できます。WLDFは、サーバーとアプリケーションのパフォーマンスを可視化するメトリックを収集し表出する一連のサービスとAPIです。WLDFでは、動的クラスタの自動スケーリングをサポートするPoliciesとActionsというコンポーネントを提供します。WLDFでは2種類のスケーリングをサポートしています。

• カレンダーベースのスケール：特定の日時に実行される動的クラスターに対するスケール操作。
• ポリシーベースのスケール：需要の変化に応じて実行される動的クラスタのスケール操作。

このエントリでは、ルールを満たす際に構成済みアクションを自動的に実行するためのポリシー式を記述できるポリシーベースのスケーリングに焦点を当てます。これらのポリシーは、メモリ、アイドルなスレッド、CPU負荷など、1つ以上のWebLogic Serverメトリックを監視します。ポリシー内に設定したしきい値を超えると、ポリシーが呼び出され、対応するスケールアクションを実行します。

Example Policy Expression Rule
以下はAutomatic Scaling of WebLogic Clusters on Kubernetesというエントリで利用した、ポリシー式ルールの例です。

Automatic Scaling of WebLogic Clusters on Kubernetes
https://blogs.oracle.com/weblogicserver/automatic-scaling-of-weblogic-clusters-on-kubernetes-v2
https://orablogs-jp.blogspot.jp/2018/01/automatic-scaling-of-weblogic-clusters.html

wls:ClusterGenericMetricRule("cluster-1","com.bea:Type=WebAppComponentRuntime,ApplicationRuntime=OpenSessionApp,*","OpenSessionsCurrentCount",">=",0.01,5,"1 seconds","10 seconds")

この ‘ClusterGenericMetricRule’ というスマートルールは、Server Runtime MBean Serverから公開されているJMXメトリックのトレンドを監察するために利用され、以下のように読むことができます。

‘cluster-1’というクラスタについては、WLDFがアプリケーション（OpenSessionApp）のMBean（WebAppComponentRuntime）の属性（OpenSessionsCurrentCount）を監視します。OpenSessionsCurrentCountがクラスタ内のサーバの5％で0.01以上である場合、ポリシーをTrueとして評価します。1秒のサンプリングレートでメトリックを収集し、指定された10秒間の保持タイムウィンドウでサンプルデータを平均化します。

以下のツールのいずれかを使って、診断システムモジュール用のポリシーを構成できます。

• WebLogic Server管理コンソール
• WLST
• REST
• JMXアプリケーション

以下はポリシー構成例です。myScaleUpPolicyというポリシーをWebLogic Server管理コンソールで表示しています。
Example Action
アクションはポリシー式がTrueと評価された場合に実行されるオペレーションです。WLDFは以下の種類の診断アクションをサポートしています。

• Java Management Extensions (JMX)
• Java Message Service (JMS)
• Simple Network Management Protocol (SNMP)
• Simple Mail Transfer Protocol (SMTP)
• 診断イメージのキャプチャ
• Elasticityフレームワーク
• REST
• WebLogicロギングシステム
• スクリプト

WebLogic Serverチームでは、scalingAction.shというサンプルのシェルスクリプトをScript Action用に用意しています。これでOperatorのRESTエンドポイントにリクエストを発行するしくみを説明しています。

scalingAction.sh
https://github.com/oracle/weblogic-kubernetes-operator/blob/master/src/scripts/scaling/scalingAction.sh

以下はWebLogic Server管理コンソールのScript Action構成ページのスクリーンショットです。


Script Actionの構成プロパティで重要な点を纏めておきます。

• ScriptへのPathと作業ディレクトリの構成エントリは、WebLogicドメインホームへアクセスするためのボリュームマウントパス（/shared）を指定します。
• scalingAction.shスクリプトはOperatorエンドポイントのSSL証明書にアクセスできる必要があり、これは環境変数INTERNAL_OPERATOR_CERTで情報が提供されます。OperatorのSSL証明書は、OperatorのConfigMap weblogic-operator-cmのinternalOperatorCertというエントリにあります。以下はその例です。

#> kubectl describe configmap weblogic-operator-cm -n weblogic-operator

Name:         weblogic-operator-cm
Namespace:    weblogic-operator
Labels:       weblogic.operatorName=weblogic-operator
Annotations:  kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","data":{"externalOperatorCert":"","internalOperatorCert":"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t...

Data
====
internalOperatorCert:
----
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR3akNDQXFxZ0F3SUJBZ0lFRzhYT1N6QU...

• scalingAction.shスクリプトでは、数多くのカスタマイズ可能なパラメータを許容しています。
• action - scaleUp もしくは scaleDown （必須）
• domain_uid - WebLogicドメインの一意の識別子（必須）
• cluster_name - WebLogicクラスタ名（必須）
• kubernetes_master - KubernetesマスタのURL。デフォルトはhttps://kubernetes
• access_token - RESTリソースへアクセスするための認証認可のService Account Bearerトークン
• wls_domain_namespace - WebLogicドメインを定義したKubernetes名前空間。デフォルトはdefault
• operator_service_name - RESTエンドポイントのWebLogic Operator Service名。デフォルトはinternal-weblogic-operator-service
• operator_service_account - WebLogic OperatorのKubernetes Service Account名。デフォルトはweblogic-operator
• operator_namespace – WebLogic Operatorをデプロイした名前空間。デフォルトはweblogic-operator
• scaling_size – スケールアップ、ダウンによって増分するWebLogic Serverインスタンスの個数、デフォルトは1

WLDFおよび診断ポリシーおよびアクションに関する詳細は、以下のドキュメントをご覧ください。

Oracle® Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使用 12c (12.2.1.3.0)
ポリシーとアクションの構成
https://docs.oracle.com/cd/E92951_01/wls/WLDFC/config_watch_notif.htm
Oracle® Fusion Middleware
Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
Configuring Policies and Actions
http://docs.oracle.com/middleware/1221/wls/WLDFC/config_watch_notif.htm#WLDFC188

Note: WLDFを使った自動スケールの詳細は以下のエントリで説明しています。

WebLogic on Kubernetes, Try It!
https://blogs.oracle.com/weblogicserver/weblogic-on-kubernetes,-try-it
https://orablogs-jp.blogspot.jp/2017/10/weblogic-on-kubernetes-try-it.html
Automatic Scaling of WebLogic Clusters on Kubernetes
https://blogs.oracle.com/weblogicserver/automatic-scaling-of-weblogic-clusters-on-kubernetes-v2
https://orablogs-jp.blogspot.jp/2018/01/automatic-scaling-of-weblogic-clusters.html

WebLogicクラスタの自動スケールについて、このエントリで紹介している方法と、以下の以前のエントリで紹介した方法にはいくつか重要な違いがあります。

Automatic Scaling of WebLogic Clusters on Kubernetes
https://blogs.oracle.com/weblogicserver/automatic-scaling-of-weblogic-clusters-on-kubernetes-v2
https://orablogs-jp.blogspot.jp/2018/01/automatic-scaling-of-weblogic-clusters.html

• 以前のエントリでは、早期リリースだったので、構成済みクラスタのスケールのみをサポートしていました。
• このエントリでは以下の違いがあります。
  
  • 動的クラスタをスケールするには、Webhookを使用する代わりにWebLogic Server Kubernetes Operatorを使用します。
  • 動的クラスタをスケールするには、RESTアクションではなくScript Actionを使用します。
  • Podをスケールするには、スケーリング・アクションが、Kubernetes APIサーバではなくOperatorのRESTエンドポイントに対するリクエストを呼び出します。

Using a Prometheus Alert Action to Call the Operator's REST Scale API

In addition to using the WebLogic Diagnostic Frameworkを利用するのに加えて、動的クラスタの自動スケールのために、Prometheusのような3rdパーティの監視アプリケーションを使うことができます。詳細は以下のエントリをご一読ください。

Using Prometheus to Automatically Scale WebLogic Clusters on Kubernetes
https://blogs.oracle.com/weblogicserver/using-prometheus-to-automatically-scale-weblogic-clusters-on-kubernetes-v5
https://orablogs-jp.blogspot.jp/2018/04/using-prometheus-to-automatically-scale.html

What Does the Operator Do in Response to a REST Scaling Request?

WebLogic Server Kubernetes OperatorがスケールのリクエストをスケールRESTエンドポイントを通じて受け取ると、以下のアクションを実行します。

• 指定されたユーザーが指定されたリソースに対して指定された操作を実行することを許可されていることを確認するために、認証および許可チェックを実行します。
• domainUIDで識別される指定されたドメインが存在することを検証します。domainUIDは、この特定のドメインを識別するために使用される一意のIDです。このIDは、Kubernetesクラスタ内のすべてのドメインで一意でなければなりません。
• clusterNameによって識別されるWebLogicクラスタが存在することを検証します。clusterNameは、スケーリング対象のWebLogicクラスタインスタンスの名前です。
• スケール・リクエストの 'managedServerCount'値が、指定されたWebLogicクラスタの構成された最大クラスタサイズを超えないことを確認します。 動的クラスタの場合、'MaxDynamicClusterSize'は、スケールアップ操作で許可されている実行中の管理対象サーバ・インスタンスの最大数を指定するWebLogic属性です。 動的クラスタの構成に使用される属性の詳細は、以下のドキュメントをご覧ください。
  

  Oracle® Fusion Middleware Oracle WebLogic Server動的クラスタの拡張度の構成 12c (12.2.1.3.0)
  動的クラスタの構成
  https://docs.oracle.com/cd/E92951_01/wls/ELAST/requirements.htm#GUID-58D37E45-38A1-4EBF-BBD9-1BFE88F9C35E
  Oracle® Fusion Middleware
  Configuring Elasticity in Dynamic Clusters for Oracle WebLogic Server 12c (12.2.1)
  Configuring Dynamic Clusters
  https://docs.oracle.com/middleware/1221/wls/ELAST/requirements.htm#ELAST530

• 対応するDomain Custom Resource内のReplicasプロパティを設定してスケールを開始します。これは以下のいずれかの方法で実行できます。
• 特定のWebLogicクラスタに対してclusterStartupエントリを定義している場合
（例）

Spec:
  …
  Cluster Startup:
    Cluster Name:   cluster-1
    Desired State:  RUNNING
    Env:
      Name:     JAVA_OPTIONS
      Value:    -Dweblogic.StdoutDebugEnabled=false
      Name:     USER_MEM_ARGS
      Value:    -Xms64m -Xmx256m
    Replicas:   2
   …

• ドメインレベルで、clusterStartupエントリを特定のWebLogicクラスタ向けに設定していない場合や、startupControlプロパティをAUTOに設定している場合
  （例）

Spec:
  Domain Name:  base_domain
  Domain UID:   domain1
  Export T 3 Channels:
  Image:              store/oracle/weblogic:12.2.1.3
  Image Pull Policy:  IfNotPresent
  Replicas:           2
  Server Startup:
    Desired State:  RUNNING
    Env:
      Name:         JAVA_OPTIONS
      Value:        -Dweblogic.StdoutDebugEnabled=false
      Name:         USER_MEM_ARGS
      Value:        -Xms64m -Xmx256m
    Server Name:    admin-server
  Startup Control:  AUTO

Note: 以下のコマンドを使って、WebLogic Kubernetesドメインリソースの完全な情報を閲覧できます。

#> kubectl describe domain <domain resource name>

• Custom Resource DomainのReplicaプロパティへの変更に対応し、OperatorはPod（管理対象サーバ）の個数を増減して所望のレプリカ個数に一致するよう調整します。
  

Wrap Up

WebLogic Serverチームは、Kubernetes環境でWebLogic Serverを統合するため、Kubernetes Operatorパターンに基づいて、Oracle WebLogic Server Kubernetes Operatorを開発しました。このOracle WebLogic Server Kubernetes Operatorを使って、WebLogicドメインのライフサイクル管理、具体的には、動的クラスタを拡張します。WebLogic Diagnostic Framework（WLDF、WebLogic診断フレームワーク）またはPrometheusなどのサードパーティの監視アプリケーションを使用して、オンデマンドまたは自動でWebLogicの動的クラスタのスケールが可能です。まとめると、Kubernetesクラスタ上で構成済みクラスタに比べてWebLogic動的クラスタを使用する利点は次のとおりです。

• 単一のサーバテンプレートを使って管理対象サーバを構成できる
• サーバ容量の追加が必要な場合、個々に手作業で構成せずに新たなサーバインスタンスをクラスタに追加できる
• 構成済みクラスタとは異なり、動的クラスタのスケールアップはクラスタで定義済みのサーバ・セットに限定されず、ランタイムの要求に基づいて増加することが可能

Oracle WebLogic Server Kubernetes Operatorをダウンロードして、動的クラスタの自動スケーリング機能をお試しになることをお勧めします。Oracle WebLogic Server Kubernetes Operatorを拡張するために追加される予定機能に関するエントリはしばらくお待ちください。

Oracle Weblogic Server Kubernetes Operator
https://github.com/oracle/weblogic-kubernetes-operator