Break New Ground

Announcing the Oracle WebLogic Server Kubernetes Operator

Mark Nelson

We are very excited to announce the Oracle WebLogic Server Kubernetes Operator, which is available today as a Technology Preview and which is delivered in open source at https://oracle.github.io/weblogic-kubernetes-operator.  The operator can manage any number of WebLogic domains running in a Kubernetes environment.  It provides a mechanism to create domains, automates domain startup, allows scaling WebLogic clusters up and down either manually (on-demand) or through integration with the WebLogic Diagnostics Framework or Prometheus, manages load balancing for web applications deployed in WebLogic clusters, and provides integration with ElasticSearch, logstash and Kibana.

The operator uses the standard Oracle WebLogic Server Docker image, which can be found in the Docker Store or in the Oracle Container Registry.  It treats this image as immutable, and all of the state is persisted in a Kubernetes persistent volume.  This allows us to treat all of the pods as throwaway and replaceable, and it completely eliminates the need to manage state written into Docker containers at runtime (because there is none).

The diagram below gives a high level overview of the layout of a domain in Kubernetes when using the operator:

The operator can expose the WebLogic Server Administration Console to external users (if desired), and can also allow external T3 access; for example for WLST.  Domains can talk to each other, allowing distributed transactions, and so on. All of the pods are configured with Kubernetes liveness and readiness probes, so that Kubernetes can automatically restart failing pods, and the load balancer configuration can include only those Managed Servers in the cluster that are actually ready to service user requests.

We have a lot of documentation available on the project pages on GitHub including details about our design philosophy and architecture, as well as instructions on how to use the operator, video demonstrations of the operator in action, and a developer page for people who are interested in contributing to the operator.

We hope you take the opportunity to play with the Technology Preview and we look forward to getting your feedback.

Getting Started

The Oracle WebLogic Server Kubernetes Operator has the following requirements:

  • Kubernetes 1.7.5+, 1.8.0+ (check with kubectl version)
  • Flannel networking v0.9.1-amd64 (check with docker images | grep flannel)
  • Docker 17.03.1.ce (check with docker version)
  • Oracle WebLogic Server

For more details on the certification and support statement of WebLogic Server on Kubernetes, refer to My Oracle Support Doc Id 2349228.1.

A series of video demonstrations of the operator are available here:

The overall process of installing and configuring the operator and using it to manage WebLogic domains consists of the following steps. The provided scripts will perform most of these steps, but some must be performed manually:

  • Registering for access to the Oracle Container Registry
  • Setting up secrets to access the Oracle Container Registry
  • Customizing the operator parameters file
  • Deploying the operator to a Kubernetes cluster
  • Setting up secrets for the Administration Server credentials
  • Creating a persistent volume for a WebLogic domain
  • Customizing the domain parameters file
  • Creating a WebLogic domain

Complete up-to-date instructions are available at https://github.com/oracle/weblogic-kubernetes-operator/blob/master/site/installation.md or read on for an abbreviated version:

Build the Docker image for the operator

To run the operator in a Kubernetes cluster, you need to build the Docker image and then deploy it to your cluster.

First run the build using this command:

mvn clean install

Then create the Docker image as follows:

docker build -t weblogic-kubernetes-operator:developer --no-cache=true

We recommend that you use a tag other than latest to make it easy to distinguish your image. In the example above, the tag could be the GitHub ID of the developer.

Next, upload your image to your Kubernetes server as follows:

# on your build machine docker save weblogic-kubernetes-operator:developer > operator.tar scp operator.tar YOUR_USER@YOUR_SERVER:/some/path/operator.tar # on the Kubernetes server docker load < /some/path/operator.tar

Verify that you have the right image by running docker images | grep webloogic-kubernetes-operator on both machines and comparing the image ID.

We will be publishing the image in Oracle Container Registry and the instructions will be updated when it is available there.  After it is published, you will not need to build the image yourself, you will have the option to pull it from the registry instead.

Customizing the operator parameters file

The operator is deployed with the provided installation script, create-weblogic-operator.sh. The input to this script is the file create-operator-inputs.yaml, which needs to updated to reflect the target environment.

The following parameters must be provided in the input file:


Parameter Definition Default
externalOperatorCert A base64 encoded string containing the X.509 certificate that the operator will present to clients accessing its REST endpoints. This value is only used when externalRestOption is set to custom-cert.  
externalOperatorKey A base64 encoded string containing the private key ask tom This value is only used when externalRestOption is set to custom-cert.  
externalRestOption Write me. Allowed values:
- none Write me
- self-signed-cert The operator will use a self-signed certificate for its REST server. If this value is specified, then the externalSans parameter must also be set.
- custom-cert Write me. If this value is specified, then the externalOperatorCert and externalOperatorKey must also be provided.
externalSans A comma-separated list of Subject Alternative Names that should be included in the X.509 Certificate. This list should include ...
Example: DNS:myhost,DNS:localhost,IP:
namespace The Kubernetes namespace that the operator will be deployed in. It is recommended that a namespace be created for the operator rather than using the default namespace. weblogic-operator
targetNamespaces A list of the Kubernetes namespaces that may contain WebLogic domains that the operator will manage. The operator will not take any action against a domain that is in a namespace not listed here. default
remoteDebugNodePort Tom is adding a debug on/off parameter
If the debug parameter if set to on, then the operator will start a Java remote debug server on the provided port and will suspend execution until a remote debugger has attached.
restHttpsNodePort The NodePort number that should be allocated for the operator REST server on which it should listen for HTTPS requests on. 31001
serviceAccount The name of the service account that the operator will use to make requests to the Kubernetes API server. weblogic-operator
loadBalancer The load balancer that is installed to provide load balancing for WebLogic clusters. Allowed values are:
- none – do not configure a load balancer
- traefik – configure the Traefik Ingress provider
- nginx – reserved for future use
- ohs – reserved for future use
loadBalancerWebPort The NodePort for the load balancer to accept user traffic. 30305
enableELKintegration Determines whether the ELK integration will be enabled. If set to true, then ElasticSearch, Logstash and Kibana will be installed, and Logstash will be configured to export the operator’s logs to ElasticSearch. false

Decide which REST configuration to use

The operator provides three REST certificate options:

  • none will disable the REST server.
  • self-signed-cert will generate self-signed certificates.
  • custom-cert provides a mechanism to provide certificates that were created and signed by some other means.

Decide which optional features to enable

The operator provides some optional features that can be enabled in the configuration file.

Load Balancing

The operator can install the Traefik Ingress provider to provide load balancing for web applications running in WebLogic clusters. If enabled, an instance of Traefik and an Ingress will be created for each WebLogic cluster. Additional configuration is performed when creating the domain.

Note that the Technology Preview release provides only basic load balancing:

  • Only HTTP(S) is supported. Other protocols are not supported.
  • A root path rule is created for each cluster. Rules based on the DNS name, or on URL paths other than ‘/’, are not supported.
  • No non-default configuration of the load balancer is performed in this release. The default configuration gives round robin routing and WebLogic Server will provide cookie-based session affinity.

Note that Ingresses are not created for servers that are not part of a WebLogic cluster, including the Administration Server. Such servers are exposed externally using NodePort services.

Log integration with ELK

The operator can install the ELK stack and publish its logs into ELK. If enabled, ElasticSearch and Kibana will be installed in the default namespace, and a logstash pod will be created in the operator’s namespace. Logstash will be configured to publish the operator’s logs into Elasticsearch, and the log data will be available for visualization and analysis in Kibana.

To enable the ELK integration, set the enableELKintegration option to true.

Deploying the operator to a Kubernetes cluster

To deploy the operator, run the deployment script and give it the location of your inputs file:

./create-weblogic-operator.sh –i /path/to/create-operator-inputs.yaml

What the script does

The script will carry out the following actions:

  • A set of Kubernetes YAML files will be created from the inputs provided.
  • A namespace will be created for the operator.
  • A service account will be created in that namespace.
  • If ELK integration was enabled, a persistent volume for ELK will be created.
  • A set of RBAC roles and bindings will be created.
  • The operator will be deployed.
  • If requested, the load balancer will be deployed.
  • If requested, ELK will be deployed and logstash will be configured for the operator’s logs.

The script will validate each action before it proceeds.

This will deploy the operator in your Kubernetes cluster.  Please refer to the documentation for next steps, including using the REST services, creating a WebLogic domain, starting a domain, and so on.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.