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.
• 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.
• Removing Existing Custom Resource Definitions
  Remove any custom resource definitions for WebLogic, if they exist.
• 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.

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

   Note:

   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
<WORKDIR>	/workdir/OPER	The location where you want to create the working directory for the Kubernetes Operator.
<OPERNS>	opns	The Kubernetes namespace to hold the Operator objects.
<OPER_VER>	4.1.8	The version of Kubernetes Operator.
<OPER_ACT>	operadmin	The service account for Kubernetes Operator.
<USE_ELK>	false	Set to true if you are using Elasticsearch/Kibana monitoring.
<ELK_PROTO>	https	The http or https protocol used to access the Elasticsearch cluster.
<ELK_HOST>	elasticsearch-es-http.elkns.svc	The host to which you want to send the Elasticsearch logs. This can be inside the Kubernetes cluster or external to it.
<ELK_PORT>	9200	The Elasticsearch port used to receive the log information.
<ELK_VER>	8.11.0	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
  
• Creating a Container Registry Secret
  
• Creating a Kubernetes Service Account
  
• Creating a Secret for Elasticsearch
  
• Installing and Starting the WebLogic Operator
  
• Updating the Elasticsearch Configuration
  

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/[e-mail] --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" \
    --wait

   Note:

   • 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" \ 
    --wait

   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   10.102.11.143   <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 https://0.0.0.0:8082/operator","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 {
           hosts => ["${ELASTICSEARCH_PROTOCOL}://${ELASTICSEARCH_HOST}:${ELASTICSEARCH_PORT}"]
           # 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