このドキュメントでは、Kubernetes環境でWebLogicクラスタをスケーリングする方法を説明します。
WebLogic Serverでは、構成済および動的の2つのタイプのクラスタリング構成がサポートされます。 構成済クラスタは、個々の管理対象サーバー・インスタンスを定義することで作成されます。 動的クラスタでは、管理対象サーバー構成は単一の共有テンプレートから生成されます。 動的クラスタでは、追加のサーバー容量が必要な場合に、新しいサーバー・インスタンスを個別に構成しなくてもクラスタに追加できます。 また、構成済クラスタとは異なり、動的クラスタのスケール・アップは、クラスタに定義されているサーバーのセットに制限されませんが、実行時の要求に基づいて増やすことができます。 WebLogic Serverで動的クラスタを作成、構成および使用する方法の詳細は、「動的クラスタ」を参照してください。
WebLogic Kubernetes Operator 4.0では、新しいカスタム・リソースCluster
が導入されています。 「クラスタ・リソース」は、個々のWebLogicクラスタとその構成を参照します。 また、実行されているメンバー・サーバーの数と、そのWebLogicクラスタに固有の追加のKubernetesリソースも制御します。 クラスタ・リソースによってKubernetes 「サブリソースをスケーリング」が有効になるため、kubectl scale
コマンドおよび「Kubernetes水平ポッド自動スケーリング(HPA)」は、個々のWebLogicクラスタのスケーリングで完全にサポートされます。
オペレータは、次のようなWebLogicクラスタのスケーリングを開始する方法をいくつか提供します:
kubectl
CLIコマンドkubectl
)curl
)kubectl
CLIコマンド次のコマンドを使用して、WebLogicクラスタを手動でスケーリングするには、Kubernetesコマンドライン・ツールkubectl
を使用します:
scale
- リソースの新しいサイズを設定します。patch
- 戦略マージ・パッチを使用して、リソースの1つ以上のフィールドを更新します。kubectl scale
コマンドkubectl scale
コマンドを使用して、個々のWebLogicクラスタを直接スケーリングできます。 たとえば、次のコマンドは、クラスタ・リソースcluster-1
の.spec.replicas
を5
に設定します:
$ kubectl scale --replicas=5 clusters/cluster-1
clusters "cluster-1" scaled
$ kubectl get clusters cluster-1 -o jsonpath='{.spec.replicas}'
5
kubectl patch
コマンドまた、パッチ・オブジェクトをインラインでkubectl patch
コマンドを使用して、個々のWebLogicクラスタを直接スケーリングできます。 たとえば、次のコマンドは、クラスタ・リソースcluster-1
の.spec.replicas
を3
に設定します:
$ kubectl patch cluster cluster-1 --type=merge -p '{"spec":{"replicas":3}}'
cluster.weblogic.oracle/cluster-1 patched
$ kubectl get clusters cluster-1 -o jsonpath='{.spec.replicas}'
3
クラスタまたはドメイン・リソースの.spec.replicas
フィールドを直接更新することで、オンデマンド・スケーリング(クラスタを手動でスケーリング)を使用できます。
個々のWebLogicクラスタを直接スケーリングするには、関連付けられたクラスタ・リソースのreplicas
フィールドを編集するだけです。この操作は、kubectl
を使用して実行できます。 具体的には、kubectl edit
コマンドを使用してクラスタを直接変更できます。 例えば:
$ kubectl edit cluster cluster-1 -n [namespace]
このコマンドでは、cluster-1
という名前のクラスタを編集します。 kubectl edit
コマンドは、エディタでクラスタ定義を開き、replicas
値を直接変更できます。 コミットされると、オペレータは変更を通知され、実行中のポッド/管理対象サーバー・インスタンスの数とreplicas
値の指定を調整して、対応するクラスタのスケーリングをすぐに試行します。
spec:
...
clusterName: cluster-1
replicas: 1
...
対応するクラスタ・リソースがない、またはcluster.spec.replicas
フィールドを指定しないクラスタ・リソースがあるドメイン内のすべてのWebLogicクラスタをスケーリングするには、kubectl edit
コマンドを使用してdomain.spec.replicas
フィールドを変更します:
$ kubectl edit domain domain1 -n [namespace]
このコマンドでは、domain1
という名前のドメインを編集します。 kubectl edit
コマンドは、エディタでドメイン定義を開き、replicas
値を直接変更できます。 コミットされると、オペレータは変更の通知を受け、実行中のポッド/管理対象サーバー・インスタンスの数をreplicas
値指定と調整して、対応するクラスタまたはクラスタのスケーリングをただちに試行します。
spec:
...
replicas: 1
...
バージョン3.1.0以降、オペレータはサンプルのライフサイクル・スクリプトを提供します。 WebLogicクラスタのスケーリングに使用できるヘルパー・スクリプトについては、「ドメイン・ライフサイクルのサンプル・スクリプト」の項を参照してください。
WebLogicクラスタのスケール・アップまたはスケール・ダウンにより、カスタマ・アプリケーションの信頼性が向上し、リソース使用率が最適化されます。 Kubernetes環境では、WebLogicクラスタのスケーリングには、管理対象サーバー・インスタンスが実行されている対応するポッドの数のスケーリングが含まれます。 オペレータはWebLogicドメインのライフ・サイクルを管理するため、認可されたアクターがWebLogicクラスタのスケーリングをリクエストできるREST APIを公開します。
次のURL形式は、WebLogicクラスタをスケール・アップ(またはスケール・ダウン)するためのリソースの記述に使用されます:
http(s)://${OPERATOR_ENDPOINT}/operator/<version>/domains/<domainUID>/clusters/<clusterName>/scale
例えば:
http(s)://${OPERATOR_ENDPOINT}/operator/v1/domains/domain1/clusters/cluster-1/scale
このURL形式では、次のようになります:
OPERATOR_ENDPOINT
は、オペレータのRESTエンドポイント(内部または外部)のホストおよびポートです。<version>
は、RESTリソースのバージョンを示します。<domainUID>
は、WebLogicドメインの一意の識別子です。<clusterName>
は、スケーリングするWebLogicクラスタの名前です。/scale
RESTエンドポイントはHTTP POSTリクエストを受け入れ、リクエスト本文はJSON "application/json"
メディア・タイプをサポートします。 リクエスト本文は、Kubernetes自動スケーリングのScaleSpec
アイテムと同じです。次に例を示します:
{
"spec":
{
"replicas": 3
}
}
replicas
値は、スケーリングする管理対象サーバー・インスタンスの数を指定します。 スケーリング・リクエストが成功すると、RESTインタフェースは204 (“No Content”)
のHTTPレスポンス・コードを返します。
/scale
RESTエンドポイントにPOSTする場合、次のヘッダーを送信する必要があります:
X-Requested-By
リクエスト値。 値は、MyClient
などの任意の名前です。 Authorization: Bearer
リクエスト値。 Bearer
トークンの値は、WebLogicドメイン・サービス・アカウント・トークンです。 たとえば、curl
を使用する場合は、次のようにします:
$ curl -v -k -H X-Requested-By:MyClient -H Content-Type:application/json -H Accept:application/json -H "Authorization:Bearer ..." -d '{ "spec": {"replicas": 3 } }' https://.../scaling
ヘッダーを省略すると、400 (bad request)
レスポンスが返されます。 Bearer認証ヘッダーを省略すると、401 (Unauthorized)
レスポンスが返されます。 Bearer
トークンに関連付けられているサービス・アカウントまたはユーザーにWebLogicドメイン・リソースをpatch
する権限がない場合は、403 (Forbidden)
レスポンスが返されます。
403 (Forbidden)
レスポンスを解決するには、オペレータのRESTスケーリングAPIをコールするときに、WebLogic domains
リソースに関連付けられたクラスタ・ロールにpatch
リクエスト動詞を追加する必要がある場合があります。 次の例のClusterRole定義は、get
, list
, patch
およびupdate
にWebLogic domains
リソースへのアクセス権を付与
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: weblogic-domain-cluster-role
rules:
- apiGroups: [""]
resources: ["services/status"]
verbs: ["get", "list", "watch"]
- apiGroups: ["weblogic.oracle"]
resources: ["domains"]
verbs: ["get", "list", "patch", "update"]
---
WebLogic Kubernetes Operatorは、内部および外部のREST HTTPSエンドポイントの両方を公開できます。 内部RESTエンドポイントは、Kubernetesクラスタ内からのみアクセスできます。 外部RESTエンドポイントは、Kubernetesクラスタの外部からアクセスできます。 内部RESTエンドポイントはデフォルトで有効になっているため、常に使用可能ですが、外部RESTエンドポイントはデフォルトで無効になっており、明示的に構成されている場合にのみ公開されます。 外部RESTエンドポイントの構成手順の詳細は、「こちら」を参照してください。
どのエンドポイントが呼び出されているかにかかわらず、スケーリングのURL形式は同じです。
オペレータは、スケーリング・リクエストを受信すると、次のことを行います:
domainUID
で識別される指定されたドメインが存在することを検証します。clusterName
で識別されるWebLogicクラスタが存在することを検証します。replicas
フィールドを設定して、スケーリングを開始します。Clusterリソースのreplicas
フィールドの変更に応じて、オペレータは、必要なレプリカ数と一致するように管理対象サーバー・インスタンス・ポッドの数を増減します。
WebLogic診断フレームワーク(WLDF)およびPrometheusを使用したWebLogicクラスタの自動スケーリングは引き続きサポートされますが、オペレータ4.0は「Kubernetes水平ポッド自動スケーリング(HPA)」をサポートするようになりました。
クラスタ・カスタム・リソースでKubernetes 「/scaleサブリソース」が有効になっているため、Kubernetes Horizontal Pod Autoscalerによる個々のWebLogicクラスタの自動スケーリングがサポートされるようになりました。 リソース・メトリクスに基づく自動スケーリングには、「Kubernetesメトリクス・サーバー」またはリソース・メトリクスAPIの別の実装のインストールが必要です。 WebLogic ServerメトリクスのモニタリングにPrometheusを使用する場合は、「Kubernetesメトリクス・サーバー」のかわりに「Prometheusアダプタ」を使用できます。
次のステップごとの例は、cpu utilization
リソース・メトリックに基づいてWebLogicクラスタcluster-1
をスケーリングするHPAを構成および実行する方法を示しています。
$ kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
kube-system
ネームスペースのポッドをリストして、Kubernetesメトリック・サーバーが実行中であることを確認します。$ kubectl get po -n kube-system
Kubernetesメトリック・サーバーがReadiness probe failed: HTTP probe failed with statuscode: 500
のためにREADY状態(たとえば、READY 0/1
)に達していない場合は、有効なクラスタ証明書をインストールする必要がある場合があります。 テストのために、components.yaml
ファイルをダウンロードし、引数--kubelet-insecure-tls
をメトリクス・サーバー・コンテナに追加することで、この問題を解決できます。
2
クラスタ・メンバーから5
クラスタ・メンバーまで自動スケーリングするクラスタ・リソース(sample-domain1-cluster-1
)をターゲットとするHPAリソースを作成し、平均CPUが一貫して50%を超えるとスケール・アップまたはスケール・ダウンが行われます。$ kubectl autoscale cluster sample-domain1-cluster-1 --cpu-percent=50 --min=2 --max=5
horizontalpodautoscaler.autoscaling/sample-domain1-cluster-1 autoscaled
オペレータ4.0から、allowReplicasBelowMinDynClusterSize
フィールドがドメイン・リソース・スキーマから削除されました。 スケール・ダウン時には、選択した自動スケーリング・コントローラで許容される最小レプリカ数を構成する必要があります。
$ kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
sample-domain1-cluster-1 Cluster/sample-domain1-cluster-1 8%/50% 2 5 2 3m27s
sample-domain1-cluster-1
をスケール・アップしていることを確認するには、クラスタ・メンバー・ポッドの1つで実行中のコンテナにシェルを取得して、ロードされたCPUを生成し、次のコマンドを実行します。$ kubectl exec --stdin --tty sample-domain1-managed-server1 -- /bin/bash
[oracle@sample-domain1-managed-server1 oracle]$ dd if=/dev/zero of=/dev/null
Kubernetes Horizontal Pod Autoscalerの詳細は、「水平ポッド自動スケーリング」を参照してください。
WebLogic Diagnostics Framework (WLDF)は、サーバーおよびアプリケーションのパフォーマンスを可視化するメトリックを収集および表示する一連のサービスおよびAPIです。 KubernetesでWebLogicクラスタの自動スケーリングをサポートするために、WLDFには、クラスタでスケーリング操作を自動的に実行するためのポリシー式を記述できるポリシーおよびアクション・コンポーネントが用意されています。 これらのポリシーは、メモリー、アイドル・スレッド、CPU負荷など、1つ以上のタイプのWebLogic Serverメトリックを監視します。 ポリシーで構成されたしきい値に達すると、ポリシーがトリガーされ、対応するスケーリング・アクションが実行されます。 WebLogic Kubernetes Operatorプロジェクトは、スクリプト・アクションとして使用するためのシェル・スクリプトscalingAction.sh
を提供します。これは、オペレータのRESTエンドポイントにリクエストを発行する方法を示しています。
オペレータ・バージョン4.0.5以降、オペレータのRESTエンドポイントはデフォルトで無効になっています。 Helmインストール・オプション--set "enableRest=true"
を指定してオペレータをインストールし、RESTエンドポイントを有効にします。
オペレータのRESTエンドポイントにスケーリング・リクエストを発行するためのWLDFポリシーおよびスクリプト・アクション・コンポーネントの構成方法に関するガイドラインとして、次のステップを示します:
scalingAction.sh
スクリプトを$DOMAIN_HOME/bin/scripts
にコピーして、管理サーバーポッド内でアクセスできるようにします。 詳細は、「Oracle WebLogic ServerのためのDiagnostics Frameworkの構成および使用」の「スクリプト・アクションの構成」を参照してください。
WLDFポリシーおよびアクションを、管理サーバーにターゲット指定された診断モジュールの一部として構成します。 WLDFポリシーおよびアクション・コンポーネントの構成の詳細は、「Oracle WebLogic ServerのためのDiagnostics Frameworkの構成および使用」での「ポリシーおよびアクションの構成」を参照してください。
a. メモリー、アイドル・スレッド、CPU負荷などのWebLogic Serverメトリックをモニタリングするためのルール式を使用してWLDFポリシーを構成します。
b. WLDFスクリプト・アクションを構成し、scalingAction.sh
スクリプトを関連付けます。
スクリプト・アクションの構成プロパティに関する重要なノート:
scalingAction.sh
スクリプトでは、オペレータのエンドポイントのSSL証明書にアクセスする必要があり、これは環境変数INTERNAL_OPERATOR_CERT
を介して提供されます。
オペレータSSL証明書は、オペレータConfigMap weblogic-operator-cm
のinternalOperatorCert
エントリにあります:
例えば:
#> kubectl describe configmap weblogic-operator-cm -n weblogic-operator
...
Data
====
internalOperatorCert:
----
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR3akNDQXFxZ0F3SUJBZ0lFRzhYT1N6QU...
...
scalingAction.shスクリプトは、いくつかのカスタマイズ可能なパラメータを受け入れます:
action
- scaleUpまたはscaleDown (必須)
domain_uid
- WebLogicドメインの一意の識別子(必須)
cluster_name
- WebLogicクラスタ名(必須)
kubernetes_master
- KubernetesマスターURL、default=https://kubernetes
管理サーバーのポッドからscalingAction.sh
を起動する場合は、これをhttps://${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT}
に設定します。
access_token
- RESTリソースにアクセスするための認証および認可用のサービス・アカウントBearerトークン
wls_domain_namespace
- WebLogicドメインが定義されているKubernetesネームスペース(デフォルト= default
)
operator_service_name
- WebLogic Kubernetes Operator RESTエンドポイントのサービス名、default=internal-weblogic-operator-service
operator_service_account
- オペレータのKubernetesサービス・アカウント名 (デフォルト=weblogic-operator
)
operator_namespace
- オペレータがデプロイされているネームスペース (デフォルト=weblogic-operator
)
scaling_size
- スケール・アップまたはスケール・ダウンする管理対象サーバー・インスタンスの増分数 (デフォルト= 1
)
次のツールのいずれかを使用して、診断システム・モジュール用のポリシーを構成できます。
WLDFのポリシーおよびアクション・コンポーネントを使用して、オペレータのRESTエンドポイントを介してスケーリング・リクエストを開始する方法の詳細および例は、ブログを参照してください:
WLDFスクリプト・アクションで指定されるスクリプトscalingAction.sh
には、ドメインの構成情報とランタイム情報の両方についてKubernetes APIサーバーに問合せするために、サービス・アカウント・ユーザー(WebLogicドメインがデプロイされているネームスペース)に付与される適切なRBAC権限が必要です。 適切なKubernetes ClusterRoleバインディングを作成するYAMLファイルの例を次に示します:
次の例のClusterRoleBinding定義では、WebLogicドメインはネームスペースweblogic-domain
にデプロイされます。 namespace値を、Kubernetes環境でWebLogicドメインがデプロイされているネームスペースの名前に置き換えます。
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: weblogic-domain-cluster-role
rules:
- apiGroups: [""]
resources: ["services/status"]
verbs: ["get", "list", "watch"]
- apiGroups: ["weblogic.oracle"]
resources: ["domains"]
verbs: ["get", "list", "patch", "update"]
---
#
# creating role-bindings for cluster role
#
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: domain-cluster-rolebinding
subjects:
- kind: ServiceAccount
name: default
namespace: weblogic-domain
apiGroup: ""
roleRef:
kind: ClusterRole
name: weblogic-domain-cluster-role
apiGroup: "rbac.authorization.k8s.io"
---
#
# creating role-bindings
#
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: weblogic-domain-operator-rolebinding
namespace: weblogic-operator
subjects:
- kind: ServiceAccount
name: default
namespace: weblogic-domain
apiGroup: ""
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: "rbac.authorization.k8s.io"
---
このブログ投稿を読んで、Kubernetes Horizontal Pod Autoscaler (HPA)を使用して、Monitoring Exporterによって提供されるWebLogicメトリクスに基づいてWebLogicクラスタをスケーリングする方法を学習します。 Prometheusアダプタを使用して、使用可能なメトリクスの名前を定期的にPrometheusから収集します。 アダプタのカスタム構成では、特定の形式に従うメトリクスのみが公開されます。 「WebLogicエクスポータ・メトリクスを使用したHorizontal Pod Autoscaler (HPA)」. 動作中のブログ投稿のデモについては、このビデオをご覧ください。 「Kubernetes Horizontal Pod AutoscalingのWebLogic Kubernetes Operatorサポート」。
WebLogic診断フレームワークを使用した動的クラスタの自動スケーリングに加えて、Prometheusなどのサード・パーティのモニタリング・アプリケーションを使用できます。 「Prometheusを使用したKubernetesでのWebLogicクラスタの自動スケーリング」の詳細は、次のブログを参照してください。
scalingAction.sh
スクリプトは、関連付けられた診断モジュールが管理サーバーにターゲット指定されているため、管理サーバーポッドのコンテナ内で実行されるように設計されています。
scalingAction.sh
スクリプトを検証およびデバッグする最も簡単な方法は、実行中の管理サーバーのポッドでシェルを開き、コマンドラインでスクリプトを実行することです。
次の例は、domain1-admin-server
という名前の実行中の管理サーバーポッドでbashシェルを開き、scriptAction.sh
スクリプトを実行する方法を示しています。 次のことを前提としています:
/u01/oracle/user-projects/domains/domain1
内にあること(つまり、ドメイン・ホームはイメージ内にあります)。scalingAction.sh
を/u01/oracle/user-projects/domains/domain1/bin/scripts/scalingAction.sh
にコピーされていること。$ kubectl exec -it domain1-admin-server /bin/bash
$ cd /u01/oracle/user-projects/domains/domain1/bin/scripts && \
./scalingAction.sh
スクリプトが実行されたディレクトリと同じディレクトリにログscalingAction.log
が生成され、エラーを調べることができます。
外部RESTエンドポイントを使用してスケーリングをテストする最も簡単な方法は、curl
などのコマンドライン・ツールを使用することです。 curl
を使用してHTTPSスケール・リクエストを発行するには、次の必須ヘッダー・プロパティが必要です:
X-Requested-By
ヘッダー値次のシェル・スクリプトは、curl
を使用して、必要なHTTPリクエスト・ヘッダー値でスケーリング・リクエストを発行する方法の例です。 この例では、オペレータおよびドメインYAMLファイルがKubernetesの次のフィールドで構成されていることを前提としています:
true
31001
weblogic-operator
ApplicationCluster
domain1
#!/bin/sh
# Setup properties
ophost=`uname -n`
opport=31001 #externalRestHttpsPort
cluster=cluster-1
size=3 #New cluster size
ns=weblogic-operator # Operator NameSpace
sa=weblogic-operator # Operator ServiceAccount
domainuid=domain1
# Retrieve service account name for given namespace
sec=`kubectl get serviceaccount ${sa} -n ${ns} -o jsonpath='{.secrets[0].name}'`
#echo "Secret [${sec}]"
# Retrieve base64 encoded secret for the given service account
enc_token=`kubectl get secret ${sec} -n ${ns} -o jsonpath='{.data.token}'`
#echo "enc_token [${enc_token}]"
# Decode the base64 encoded token
token=`echo ${enc_token} | base64 --decode`
#echo "token [${token}]"
# clean up any temporary files
rm -rf operator.rest.response.body operator.rest.stderr operator.cert.pem
# Retrieve SSL certificate from the Operator's external REST endpoint
`openssl s_client -showcerts -connect ${ophost}:${opport} </dev/null 2>/dev/null | openssl x509 -outform PEM > operator.cert.pem`
echo "Rest EndPoint url https://${ophost}:${opport}/operator/v1/domains/${domainuid}/clusters/${cluster}/scale"
# Issue 'curl' request to external REST endpoint
curl --noproxy '*' -v --cacert operator.cert.pem \
-H "Authorization: Bearer ${token}" \
-H Accept:application/json \
-H "Content-Type:application/json" \
-H "X-Requested-By:WLDF" \
-d "{\"spec\": {\"replicas\": $size} }" \
-X POST https://${ophost}:${opport}/operator/v1/domains/${domainuid}/clusters/${cluster}/scale \
-o operator.rest.response.body \
--stderr operator.rest.stderr