[Kubernetes, WLS] Voyager/HAProxy as Load Balancer to Weblogic Domains in Kubernetes

原文はこちら。
https://blogs.oracle.com/weblogicserver/voyagerhaproxy-as-load-balancer-to-weblogic-domains-in-kubernetes

---

Overview

負荷分散は、スケーラブルで復元力のあるアプリケーションを構築するために広く使用されているテクノロジーです。負荷分散の主な機能は、サーバーの監視と、ネットワークトラフィックの複数のサーバー（Webアプリケーション、データベースなど）への分散です。Kubernetesで動作するコンテナ化されたアプリケーションでは、負荷分散も必要です。Oracle WebLogic Server Kubernetes Operator version 1.0で、Voyager/HAProxyのサポートを追加しました。create-weblogic-domain.shスクリプトを拡張してVoyager/HAProxyをすぐに使用できるようにしています。

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

このスクリプトは、1個のWebLogicドメイン/クラスタのサーバへの負荷分散をサポートしています。このエントリでは、Kubernetesの複数のWebLogicドメインにデプロイされたアプリケーションに対して負荷分散のサポートを拡張するためのVoyager/HAProxyの設定方法を説明します。

Basics of Voyager/HAProxy

HAProxyとVoyagerに詳しくない方は、HAProxyとVoyagerの基本を時間を掛けて学ぶ価値があります。

HAProxyは、TCPおよびHTTPベースのアプリケーション用の可用性の高いロードバランサとプロキシサーバを提供する、無料のオープンソース・ソフトウェアです。（プロセッサ速度とメモリ使用量の面で）高速で効率的であることはよく知られています。HAProxyの初心者ガイドは以下からどうぞ。

HAProxy Starter Guide version 1.9-dev1
http://cbonte.github.io/haproxy-dconv/1.9/intro.html

VoyagerはHAProxyを使うIngressコントローラです（IngressについてはKubernetesのドキュメントを参照してください）。

Ingress
https://kubernetes.io/docs/concepts/services-networking/ingress/

Kubernetesクラスタにインストールすると、VoyagerオペレータはKubernetes IngressリソースとVoyager自身のIngress CRDを監視し、状況に応じてHAProxyインスタンスを自動作成、更新、削除します。 Voyagerオペレータの仕組みを理解するには、voyagerの概要をご覧ください。

Voyager Overview
https://appscode.com/products/voyager/7.1.1/concepts/overview/

Running WebLogic Domains in Kubernetes

wls-operator-quickstartプロジェクトをGitHubからあなたのローカル環境にチェックアウトしてください。このプロジェクトを使うと、最小限の作業でWebLogic Operatorとドメインを設定できます。READMEのPre-Requirementsの章に記載の手順を実行して、ローカル環境を構成してください。

Quick Start of WLS Operator
https://github.com/lilyhe123/wls-operator-quickstart

wls-operator-quickstartプロジェクトとWebLogic Operatorを使用して、Kubernetes上で実行される2つのWebLogicドメインを、それぞれ独自の名前空間に設定します。

• 'domain1'という名前のドメインは名前空間 'default'で実行され、2個の管理対象サーバ 'domain1-managed-server1'と 'domain1-managed-server2'を含む 'cluster-1'という1個のクラスタを有します。
• 'domain2'という名前のドメインは名前空間 'test1'で実行され、2個の管理対象サーバ 'domain2-managed-server1'と 'domain2-managed-server2'を含む 'cluster-1'という1個のクラスタを有します。
• Webアプリケーション 'testwebapp.war'は、domain1とdomain2の両方のクラスタに別々にデプロイされます。このWebアプリケーションには、どちらの管理対象サーバがHTTPリクエストを処理しているかを表示するデフォルトページがあります。

次の手順を実行して、HAProxyの背後にあるWebLogicドメインを準備します。

# change directory to root folder of wls-operator-quickstart
$ cd xxx/wls-operator-quickstart

# Build and deploy weblogic operator
$ ./operator.sh create

# Create domain1. Change value of `loadBalancer` to `NONE` in domain1-inputs.yaml before run.
$ ./domain.sh create

# Create domain2. Change value of `loadBalancer` to `NONE` in domain2-inputs.yaml before run.
$ ./domain.sh create -d domain2 -n test1

# Install Voyager
$ kubectl create namespace voyager
$ curl -fsSL https://raw.githubusercontent.com/appscode/voyager/6.0.0/hack/deploy/voyager.sh \
    | bash -s -- --provider=baremetal --namespace=voyager

以下のようにWebLogicドメインの状態を確認します。

# Check status of domain1
$ kubectl get all
NAME                          READY     STATUS    RESTARTS   AGE
pod/domain1-admin-server      1/1       Running   0          5h
pod/domain1-managed-server1   1/1       Running   0          5h
pod/domain1-managed-server2   1/1       Running   0          5h

NAME                                                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)           AGE
service/domain1-admin-server                        NodePort    10.105.135.58    <none>        7001:30705/TCP    5h
service/domain1-admin-server-extchannel-t3channel   NodePort    10.111.9.15      <none>        30015:30015/TCP   5h
service/domain1-cluster-cluster-1                   ClusterIP   10.108.34.66     <none>        8001/TCP          5h
service/domain1-managed-server1                     ClusterIP   10.107.185.196   <none>        8001/TCP          5h
service/domain1-managed-server2                     ClusterIP   10.96.86.209     <none>        8001/TCP          5h
service/kubernetes                                  ClusterIP   10.96.0.1        <none>        443/TCP           5h

# Verify web app in domain1 via running curl on admin server pod to access the cluster service
$ kubectl -n default exec -it domain1-admin-server -- curl http://domain1-cluster-cluster-1:8001/testwebapp/

# Check status of domain2
$ kubectl -n test1 get all
NAME                          READY     STATUS    RESTARTS   AGE
pod/domain2-admin-server      1/1       Running   0          5h
pod/domain2-managed-server1   1/1       Running   0          5h
pod/domain2-managed-server2   1/1       Running   0          5h

NAME                                                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)           AGE
service/domain2-admin-server                        NodePort    10.97.77.35      <none>        7001:30701/TCP    5h
service/domain2-admin-server-extchannel-t3channel   NodePort    10.98.239.28     <none>        30012:30012/TCP   5h
service/domain2-cluster-cluster-1                   ClusterIP   10.102.228.204   <none>        8001/TCP          5h
service/domain2-managed-server1                     ClusterIP   10.96.59.190     <none>        8001/TCP          5h
service/domain2-managed-server2                     ClusterIP   10.101.102.102   <none>        8001/TCP          5h

# Verify the web app in domain2 via running curl in admin server pod to access the cluster service
$ kubectl -n test1 exec -it domain2-admin-server -- curl http://domain2-cluster-cluster-1:8001/testwebapp/

Kubernetesで両WebLogicドメインが稼働してから、異なるHAProxy機能を使って、2個のWebLogicドメインに帯する単一エントリポイントとしてVoyagerを構成します。

Using Host Name-Based Routing

Ingressリソースファイル 'voyager-host-routing.yaml'を作成します。このファイルにはホスト名ベース・ルーティングを使ったIngressリソースが含まれています。

apiVersion: voyager.appscode.com/v1beta1
kind: Ingress
metadata:
  name: hostname-routing 
  namespace: default
  annotations:
    ingress.appscode.com/type: 'NodePort'
    ingress.appscode.com/stats: 'true'
    ingress.appscode.com/affinity: 'cookie'
spec:
  rules:
  - host: domain1.org
    http:
      nodePort: '30305'
      paths:
      - backend:
          serviceName: domain1-cluster-cluster-1
          servicePort: '8001'
  - host: domain2.org
    http:
      nodePort: '30305'
      paths:
      - backend:
          serviceName: domain2-cluster-cluster-1.test1
          servicePort: '8001'

YAMLファイルを以下のコマンドを使ってデプロイします。

kubectl create -f voyager-host-routing.yaml

Testing Load Balancing with Host Name-Based Routing

ホスト名ベース・ルーティングを行うには、通常はDNSの変更を伴う仮想ホスティングを設定する必要があります。デモ目的のため、curlコマンドを使用して、ホスト名ベース・ルーティングによるロードバランシングをシミュレートします。

# Verify load balancing on domain1
$ curl --silent -H 'host: domain1.org' http://${HOSTNAME}:30305/testwebapp/ | grep InetAddress.hostname
<li>InetAddress.hostname: domain1-managed-server1
$ curl --silent -H 'host: domain1.org' http://${HOSTNAME}:30305/testwebapp/ | grep InetAddress.hostname
<li>InetAddress.hostname: domain1-managed-server2

# Verify load balancing on domain2
$ curl --silent -H 'host: domain2.org' http://${HOSTNAME}:30305/testwebapp/ | grep InetAddress.hostname
<li>InetAddress.hostname: domain2-managed-server1
$ curl --silent -H 'host: domain2.org' http://${HOSTNAME}:30305/testwebapp/ | grep InetAddress.hostname
<li>InetAddress.hostname: domain2-managed-server2

結果は以下の通りです。

• ホスト名 'domain1.org'を指定すると、リクエストはdomain1の管理対象サーバで処理される。
• ホスト名 'domain2.org'を指定すると、リクエストはdomain2の管理対象サーバで処理される。

Using Path-Based Routing and URL Rewriting

この章では、URL書き換えによるパスベース・ルーティングを使用して、ホスト名ベース・ルーティングと同じ動作を実現します。

Ingressリソースファイル 'voyager-path-routing.yaml'を作成します。

apiVersion: voyager.appscode.com/v1beta1
kind: Ingress
metadata:
  name: path-routing
  namespace: default
  annotations:
    ingress.appscode.com/type: 'NodePort'
    ingress.appscode.com/stats: 'true'
    ingress.appscode.com/rewrite-target: "/testwebapp"
spec:
  rules:
  - host: '*'
    http:
      nodePort: '30307'
      paths:
      - path: /domain1
        backend:
          serviceName: domain1-cluster-cluster-1
          servicePort: '8001'
      - path: /domain2
        backend:
          serviceName: domain2-cluster-cluster-1.test1
          servicePort: '8001' 

YAMLファイルを以下のコマンドを使ってデプロイします。

kubectl create -f voyager-path-routing.yaml

Verify Load Balancing with Path-Based Routing

負荷分散の結果を検証するため、curlコマンドを使います。別の方法として、Webブラウザから直接URLにアクセスすることもできます。

# Verify load balancing on domain1
$ curl --silent http://${HOSTNAME}:30307/domain1/ | grep InetAddress.hostname
<li>InetAddress.hostname: domain1-managed-server1
$ curl --silent http://${HOSTNAME}:30307/domain1/ | grep InetAddress.hostname
<li>InetAddress.hostname: domain1-managed-server2

# Verify load balancing on domain2
$ curl --silent http://${HOSTNAME}:30307/domain2/ | grep InetAddress.hostname
<li>InetAddress.hostname: domain2-managed-server1
$ curl --silent http://${HOSTNAME}:30307/domain2/ | grep InetAddress.hostname
<li>InetAddress.hostname: domain2-managed-server2

異なるURLを指定してパスベース・ルーティングによりトラフィックが異なるWebLogicドメインに振り分けられることを確認できます。URL書き換え機能を使えば、最終的に各ドメインの同じコンテキスト・パスを持つWebアプリケーションにアクセスできます。

Cleanup

このエントリの手順を使った演習終了後は、Kubernetesで作成した全てのリソースをクリーンアップしたいと思うことでしょう。

# Cleanup voyager ingress resources
$ kubectl delete -f voyager-host-routing.yaml
$ kubectl delete -f voyager-path-routing.yaml
 
# Uninstall Voyager
$ curl -fsSL https://raw.githubusercontent.com/appscode/voyager/6.0.0/hack/deploy/voyager.sh \
      | bash -s -- --provider=baremetal --namespace=voyager --uninstall --purge

# Delete wls domains and wls operator
$ cd <QUICKSTART_ROOT>
$ ./domain.sh delete --clean-all
$ ./domain.sh delete -d domain2 -n test1 --clean-all
$ ./operator.sh delete

Summary

このエントリでは、Voyagerロードバランサを構成し、WebLogic ServerドメインにデプロイしたTCPベースおよびHTTPベースのアプリケーションのための、可用性の高いリクエストの負荷分散とプロキシサーバ機能を提供する方法を説明しました。このエントリで提供したサンプルでは、Voyagerを複数のWebLogicドメインの前の単一ポイントとして使用する方法を説明しました。ホスト名ベースルーティング、パスベースルーティング、URL書き換えなどのVoyager機能の使用方法を示す例を示しました。このブログが皆様のお役に立つことを願いつつ、是非Kubernetes上のWebLogic環境でVoyagerを使用してみてください。