16 Installing and Configuring WebLogic Kubernetes Operator

The WebLogic Operator for Kubernetes facilitates the creation and management of WebLogic domains in a Kubernetes cluster.

The WebLogic Operator can manage several different domains in different namespaces. The WebLogic Operator for Kubernetes is installed in its own dedicated namespace.

This chapter includes the following topics:

Setting Up a Product Specific Work Directory

Before you begin the installation, you must have downloaded and staged the Oracle Access Manager container image and the sample code repository.

See Identifying and Obtaining Software Distributions for an Enterprise Deployment.

You must also have deployed the Oracle WebLogic Operator as described in Installing the WebLogic Kubernetes Operator.

This section describes the procedure to copy the downloaded sample deployment scripts to a temporary working directory on the configuration host for OAM.

  1. Create a temporary working directory as the install user. The install user should have kubectl access to the Kubenetes cluster.
    mkdir -p <WORKDIR>
    For example:
    mkdir -p /workdir/OPER
  2. Change directory to this location:
    cd /workdir/OPER


    The same set of sample files are used by several products in this guide. To avoid having to download them each time, the files are staged in a non-product specific working directory.

    The WebLogic Operator files are identical for Oracle Access Manager and Oracle Identity Governance. Therefore, you can use any version from the samples.

  3. Copy the sample scripts to the work directory.
    cp -R <WORKDIR>/fmw-kubernetes/OracleAccessManagement/kubernetes <WORKDIR>/samples
    For example:
    cp -R /workdir/OPER/fmw-kubernetes/OracleAccessManagement/kubernetes /workdir/OPER/samples

Variables Used in this Chapter

The later sections of this chapter provide instructions to create a files. These sample files contain variables which you need to substitute with values applicable to your deployment.

Variables are formatted as <VARIABLE_NAME>. The following table provides the values you should set for each of these variables.

Table 16-1 The Variables to be Changed

Variable Sample Value Description



The location where you want to create the working directory for the Kubernetes Operator.



The Kubernetes namespace to hold the Operator objects.



The version of Kubernetes Operator.



The service account for Kubernetes Operator.



Set to true if you are using Elasticsearch/Kibana monitoring.



The http or https protocol used to access the Elasticsearch cluster.



The host to which you want to send the Elasticsearch logs. This can be inside the Kubernetes cluster or external to it.



The Elasticsearch port used to receive the log information.



The version of Elasticsearch you want to use.

Removing Existing Custom Resource Definitions

Remove any custom resource definitions for WebLogic, if they exist.

Use the following commands to determine if a custom resource definition exists, and if so to delete it:
kubectl get crd
NAME                               AGE 
domains.weblogic.oracle            5d
kubectl delete crd domains.weblogic.oracle
customresourcedefinition.apiextensions.k8s.io "domains.weblogic.oracle" deleted

Installing the WebLogic Kubernetes Operator

The procedure to install the WebLogic Kubernetes Operator consists of creating a namespace and a Kubernetes service account. Start the operator after the installation.

Creating a Namespace

Create a namespace to contain all the WebLogic Operator Kubernetes objects.
kubectl create namespace <OPERNS>
For example:
kubectl create namespace opns
The output will look similar to the following:
namespace/opns created

Creating a Container Registry Secret

If you are using your own container registry and want to pull the Oracle container images on demand, you must create a secret which contains the login details of the container registry.

If you have staged your container images locally or if you are pulling them from a public repository there is no need to run the following command.

Use the following command to create a container registry secret:

kubectl create secret -n <OPERNS> docker-registry <REGISTRY_SECRET_NAME> --docker-server=<REGISTRY_ADDRESS> --docker-username=<REG_USER> --docker-password=<REG_PWD>

For Example:

kubectl create secret -n opns docker-registry regcred --docker-server=iad.ocir.io/mytenancy --docker-username=mytenancy/oracleidentitycloudservice/myemail@email.com --docker-password=<password>

Creating a Kubernetes Service Account

Create a Kubernetes Service Account for the WebLogic Operator. This account is created inside the namespace.
kubectl create serviceaccount -n <OPERNS> <OPER_ACT>
For example:
kubectl create serviceaccount -n opns operadmin

The output will look similar to the following:

serviceaccount/op-sa created

Creating a Secret for Elasticsearch

If you are using Elasticsearch and your Elasticsearch requires connections to use SSL, then you must place the elasticsearch certificate in a Kubernetes secret.

If you are using Elasticsearch in Kubernetes, then you can obtain the certificate by using the following command:
kubectl cp <ELKNS>/elasticsearch-es-default-0:/usr/share/elasticsearch/config/http-certs/..data/ca.crt <WORKDIR>/ca.crt

If you are not using Elasticsearch inside Kubernetes, then you must copy the ca.crt file from your Elasticsearch installation to your working directory.

To create a secret from the Elasticsearch certificate, use the following command:
kubectl create secret generic logstash-certs-secret --from-file=<WORKDIR>/ca.crt -n $<OPERNS>

Installing and Starting the WebLogic Operator

To install and start the WebLogic Operator:
  1. Use the following command:
    cd <WORKDIR>/samples
    helm install kubernetes/charts/weblogic-operator \
     --namespace <OPERNS> \ 
     --set image=weblogic-kubernetes-operator:<OPER_VER> \ 
     --set serviceAccount=<OPER_ACT> \
     --set "enableClusterRoleBinding=true" \
     --set "domainNamespaceSelectionStrategy=LabelSelector" \
     --set "domainNamespaceLabelSelector=weblogic-operator\=enabled" \
     --set "elasticSearchProtocol=<ELK_PROTO>" \
     --set "elkIntegrationEnabled=<USE_ELK>" \
     --set "elasticSearchHost=<ELK_HOST>" \
     --set "elasticSearchPort=<ELK_PORT>" \
     --set "logStashImage=docker.elastic.co/logstash/logstash:<ELK_VER>" \
     --set "createLogStashConfigMap=true" \


    • The image name includes the name of the repository. For example, if you use a container registry, it will have appear as registry/weblogic-kubernetes-operator. If you use Oracle Cloud Native Environment, the name will appear as local/weblogic-kubernetes-operator.
    • If you use locally staged images, you can use the podman images or docker images commands to determine the full name.
    • The ELK/Elasticsearch parameters are required only if you are using Elasticsearch/Kibana Monitoring.
    • The createLogStashConfigMap parameter will work only with WebLogic Operator release 4.0+. The WebLogic Operator log files can sent to a secured Elasticsearch only when using WebLogic Operator release 4.0+. With earlier releases of WebLogic Operator, log files can be sent only to a fully open Elasticsearch.
    • If you are using your own container registry, then you should add the additional argument for your registry secret:
      --set "imagePullSecrets[0].name=regcred"
    For example:
    cd /workdir/OPER/samples
    helm install weblogic-kubernetes-operator charts/weblogic-operator \
     --namespace opns \
     --set image=weblogic-kubernetes-operator:4.1.8 \
     --set serviceAccount=operadmin \
     --set "enableClusterRoleBinding=true" \
     --set "domainNamespaceSelectionStrategy=LabelSelector" \
     --set "domainNamespaceLabelSelector=weblogic-operator\=enabled" \
     --set "elkIntegrationEnabled=true" \
     --set "elasticSearchHost=https://elasticsearch-es-http.elkns.svc" \
     --set "elasticSearchPort=9200" \
     --set "logStashImage=docker.elastic.co/logstash/logstash:8.11.0" \
     --set "createLogStashConfigMap=true" \ 

    The output appears as follows:

    NAME: weblogic-kubernetes-operator
     LAST DEPLOYED: Wed Sep 23 08:04:20 2020
     NAMESPACE: opns
     STATUS: deployed
     REVISION: 1
     TEST SUITE: None
  2. Verify that the operator’s pod and services are running by using the following command:
    kubectl get all -n opns
    The output appears as follows:
    NAME                                             READY      STATUS      RESTARTS    AGE
    pod/weblogic-operator-759b7c657-8gd7g            2/2        Running     0           107s
    pod/weblogic-operator-webhook-859b5755b6-2zlq8   2/2        Running     0           24m
    NAME                                         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
    service/internal-weblogic-operator-svc       ClusterIP   <none>        8082/TCP   107s
    NAME                                         READY   UP-TO-DATE   AVAILABLE     AGE
    deployment.apps/weblogic-operator            1/1     1            1             107s
    NAME                                          DESIRED   CURRENT   READY   AGE
    replicaset.apps/weblogic-operator-759b7c657   1         1         1       107s
  3. Verify the operator's pod log:
    kubectl logs -n opns weblogic-operator-759b7c657-8gd7g
    The output appears as follows:
    {"timestamp":"09-23-2020T15:04:30.485+0000","thread":28,"fiber":"fiber-1","namespace":"opns","domainUID":"","level":"INFO","class":"oracle.kubernetes.operator.rest.RestServer",ethod":"start","timeInMillis":1600873470485,"message":"Started the internal ssl REST server on","exception":"","code":"","headers":{},"body":""}
    {"timestamp":"09-23-2020T15:04:30.487+0000","thread":28,"fiber":"fiber-1","namespace":"opns","domainUID":"","level":"INFO","class":"oracle.kubernetes.operator.Main","method":"mkReadyAndStartLivenessThread","timeInMillis":1600873470487,"message":"Starting Operator Liveness Thread","exception":"","code":"","headers":{},"body":""}
    {"timestamp":"09-23-2020T15:06:27.528+0000","thread":22,"fiber":"engine-operator-thread-5-fiber-2","namespace":"opns","domainUID":"","level":"FINE","class":"oracle.kubernetes.orator.helpers.ConfigMapHelper$ScriptConfigMapContext","method":"loadScriptsFromClasspath","timeInMillis":1600873587528,"message":"Loading scripts into domain control config mapor namespace: opns","exception":"","code":"","headers":{},"body":""}
    {"timestamp":"09-23-2020T15:06:27.529+0000","thread":22,"fiber":"engine-operator-thread-5-fiber-2","namespace":"opns","domainUID":"","level":"FINE","class":"oracle.kubernetes.orator.Main","method":"readExistingDomains","timeInMillis":1600873587529,"message":"Listing WebLogic Domains","exception":"","code":"","headers":{},"body":""}
    {"timestamp":"09-23-2020T15:06:27.576+0000","thread":20,"fiber":"fiber-2-child-1","namespace":"opns","domainUID":"","level":"FINE","class":"oracle.kubernetes.operator.helpers.CfigMapHelper$ConfigMapContext$ReadResponseStep","method":"logConfigMapExists","timeInMillis":1600873587576,"message":"Existing config map, ConfigMapHelper$ConfigMapContext$Readsponse, is correct for namespace: opns.","exception":"","code":"","headers":{},"body":""}

Updating the Elasticsearch Configuration

When the WebLogic Kubernetes Operator is deployed, it creates a configuration map called weblogic-operator-logstash-cm. This configuration map contains the details of how Logstash sends logs to the Elasticsearch cluster. This configuration map requires modifications for sending the logs successfully.

  1. Edit the configuration map using the following command:
    kubectl edit cm -n <OPERNS> weblogic-operator-logstash-cm
  2. Look for the output section and uncomment the lines as appropriate, and add values. Typically, the output section should appear as follows:
        output {
          elasticsearch {
            # Example configuration if Elasticsearch instance requires authentication and SSL:
            ssl => true
            user => "logstash_internal"
            password => "<ELK_USER_PWD>"
            cacert => '/usr/share/logstash/config/certs/ca.crt'
            index => "wkologs-000001"
          stdout { codec => rubydebug }
  3. Save the configuration map.
  4. Restart the WebLogic Kubernetes Operator by deleting the pods. For example:
    kubectl delete pod -n opns weblogic-operator-759b7c657-8gd7g
    kubectl delete pod -n opns weblogic-operator-webhook-859b5755b6-2zlq8
  5. Verify the Logstash's pod log by using the following command:
    kubectl logs -n opns weblogic-operator-759b7c657-8gd7g -c logstash