Upgrade the WebLogic Kubernetes Operator
Published on: Author: Michel Schildmeijer Category: OracleIn my blog series concerning WebLogic, containers, and Kubernetes, I would like to tell you about "old meets new". Although… in this instance, "old" is maybe an inappropriate term. Because I want to look at WebLogic's relation to traditional infrastructure, like servers and VMs, and to container orchestrator platforms such as Kubernetes and Oracle Container Clusters (OKE).
Operators
Kubernetes as a platform knows all about its pods, services, policies, persistent volumes and so on. But when requests for what to containerize became more demanding, it simply didn’t suffice. If you have to control a stateless web app in a lightweight container, Kubernetes handles it well. But an entire database or application server platform in a container is very different. Specific tasks and details regarding all kinds of configurations and operations can never be handled by Kubernetes, similar to a VM or server; they can't do that either.
Here, operators will be implemented.
Operators:
- They extend the K8S API
- Configure & manage more complex instances
- They leverage more experience-based knowledge to Kubernetes
This schema represents the basic components of an operator’s work. An operator uses components such as:
- The Operator Framework SDK
- Custom Resource Definitions (CRD)—For adding custom objects as if they were Kubernetes objects
- ConfigMaps—Configuration properties injected to pods
- Additional built-in tools to manage, build, package and deploy an environment in Kubernetes
Operators are written for many OpenSource and commercial products. Oracle has one for Oracle WebLogic, which can do simpler WebLogic management in Kubernetes by managing an overall WebLogic environment through Kubernetes APIs, such as:
- Load Balancer, Network
- Ingress Controllers
- Security
- HA restart, upgrade, scaling
- Persistent storage
It also ensures that WebLogic’s best practices regarding configuration and administration are followed.
This schema represents some of the WebLogic Kubernetes operators’ tasks for management.
Upgrading the WebLogic Operator
The WebLogic Operator source code is available on GitHub: click here. The operator images are pushed to the docker hub and Oracle's own container registry:
Docker Hub: click here
OCR: click here
On my cluster, I was running version 2.5.0, which I installed with Helm. As you may know, Helm is a package and release management tool for Kubernetes.
First of all, check the status of the current deployed operator:
Check the deployed version in the namespace.
The newest version is 3.0.0-rc1 (released in May 2020), so let’s upgrade. In my custom-values.yaml, I map to the newest version from the container registry:
Note: this could also be from the docker hub.
Now, do the upgrade:
Where kubernetes/charts/weblogic-operator is the location of my custom values
After pulling the image, the new version was installed:
And finally, I tested some lifecycle functions, such as restarting the domain:
Which triggers the domain to stop and start. I admit it's not a great test in a production live situation, but this was just a test for me.
I haven't tested any new features yet. That may come in a later stage.
Conclusion
Operators are evident in container landscapes these days, but they don’t make life less complex. However, they are necessary in a complex environment; as a WebLogic platform can be. Hope this blog helps you a bit further in your journey.
