To upgrade the WebLogic Kubernetes operator, use the helm upgrade
command with new Helm chart and operator image. See the steps here to pull the operator image and set up the Oracle SOA Suite repository that contains the operator chart. To upgrade the operator run the following command:
$ cd ${WORKDIR}
$ helm upgrade \
--reuse-values \
--set image=ghcr.io/oracle/weblogic-kubernetes-operator:4.1.0 \
--namespace weblogic-operator-namespace \
--wait \
weblogic-kubernetes-operator \
charts/weblogic-operator
Note: When the WebLogic Kubernetes Operator is upgraded from release version 3.2.1 to 3.3.0 or later, it may be expected that the Administration Server pod in the domain gets restarted.
When you upgrade a 3.x operator to 4.0, the upgrade process creates a WebLogic Domain resource conversion webhook deployment and its associated resources in the same namespace. If the conversion webhook deployment already exists in another namespace, then a new conversion webhook deployment is not created. The webhook automatically and transparently upgrades the existing WebLogic Domains from the 3.x schema to the 4.0 schema. For more information, see WebLogic Domain resource conversion webhook.
If you have a single WebLogic Kubernetes Operator per Kubernetes cluster (most common use case), you can upgrade directly from any 3.x operator release to 4.1.0. The Helm chart for 4.1.0 automatically installs the schema conversion webhook.
If there is more than one WebLogic Kubernetes Operator in a single Kubernetes cluster:
--reuse-values
option during the Helm upgrade, the installations will continue to use the values from their original installation.If you are still using an older operator version (from 3.1.1) the T3 channel Kubernetes service name extension is changed from -external
to -ext
. If the Administration Server was configured to expose a T3 channel in your domain, then follow these steps to recreate the Kubernetes service (for T3 channel) with the new name -ext
.
Note: If these steps are not performed, then the domain restart using
spec.serverStartPolicy
fails to bring up the servers.
Get the existing Kubernetes service name for the T3 channel from the domain namespace. For example, if the domainUID
is soainfra
, and the Administration Server name is adminserver
, then the service is:
soainfra-adminserver-external
Delete the existing Kubernetes service for T3 channel, so that operator 3.1.1 creates a new one:
$ kubectl delete service <T3 channel service> --namespace <domain-namespace>
For example, if the domainUID
is soainfra
, the Administration Server name is adminserver
and domain namespace is soans
, then the command is:
$ kubectl delete service soainfra-adminserver-external --namespace soans
Now, the operator automatically creates a new Kubernetes service with -ext
instead of -external
:
soainfra-adminserver-ext