The operator consists of the following parts:
The operator is packaged in a container image which you can access using the following
docker pull commands:
$ docker pull ghcr.io/oracle/weblogic-kubernetes-operator:3.3.0
For more details on acquiring the operator image and prerequisites for installing the operator, consult the Quick Start guide.
The operator registers a Kubernetes custom resource definition called
domains). More details about the Domain type defined by this CRD, including its schema, are available here.
The diagram below shows the general layout of high-level components, including optional components, in a Kubernetes cluster that is hosting WebLogic domains and the operator:
The Kubernetes cluster has several namespaces. Components may be deployed into namespaces as follows:
Every domain resource must be configured with a domain unique identifier
which is a string and may also be called a
DOMAIN_UID depending on the context.
This value is distinct and need not match the domain name from
the WebLogic domain configuration. The operator will
use this as a name prefix for the domain related resources
that it creates for you (such as services and pods).
A Domain UID is set on a domain resource using
and defaults to the value of
spec.domainUID domain resource field is usually
left unset in order to take advantage of this default.
It is recommended that a Domain UID be configured to be unique across all Kubernetes namespaces and even across different Kubernetes clusters in order to assist in future work to identify related domains in active-passive scenarios across data centers; however, it is only required that this value be unique within a namespace, similarly to the names of Kubernetes resources.
As a convention, any resource that is associated with a particular Domain UID
is typically given a Kubernetes label named
is assigned to that UID. If the operator creates a resource for
you on behalf of a particular domain, it will follow this
convention. For example, to see all pods created with
weblogic.domainUID label in a Kubernetes cluster try:
kubectl get pods -l weblogic.domainUID --all-namespaces=true --show-labels=true.
A Domain UID may be up to 45 characters long. For more details about Domain UID name requirements, see Meet Kubernetes resource name restrictions.
The diagram below shows how the various parts of a WebLogic domain are manifest in Kubernetes by the operator.
This diagram shows the following details:
applicationsdirectory, a directory for storing logs, and a directory for any file-based persistence stores.
DOMAIN_UID-wlservernameand is labeled with
weblogic.domainName. One container runs in this pod. WebLogic Node Manager and Administration Server processes are run inside this container. The Node Manager process is used as an internal implementation detail for the liveness probe which we will descibe in more detail later, for patching, and to provide monitoring and control capabilities to the Administration Console. It is not intended to be used for other purposes, and it may be removed in some future release.
ClusterIPtype service is created for the Administration Server pod. This service provides a stable, well-known network (DNS) name for the Administration Server. This name is derived from the
domainUIDand the Administration Server name as described here, and it is known before starting up any pod. The Administration Server
ListenAddressis set to this well-known name.
ClusterIPtype services are only visible inside the Kubernetes cluster. They are used to provide the well-known names that all of the servers in a domain use to communicate with each other. This service is labeled with
NodePorttype service is optionally created for the Administration Server pod. This service provides HTTP access to the Administration Server to clients that are outside the Kubernetes cluster. This service is intended to be used to access the WebLogic Server Administration Console or for the T3 protocol for WLST connections. This service is labeled with
DOMAIN_UID-wlservernameand are labeled with
weblogic.domainName. One container runs in each pod. WebLogic Node Manager and Managed Server processes are run inside each of these containers. The Node Manager process is used as an internal implementation detail for the liveness probe which we will describe in more detail later. It is not intended to be used for other purposes, and it may be removed in some future release.
ClusterIPtype service is created for each Managed Server pod as described here. These services are intended to be used to access applications running on the Managed Servers. These services are labeled with
ClusterIPtype service is also created for each WebLogic cluster as described here. Customers can expose these services using a load balancer or
NodePorttype service to expose these endpoints outside the Kubernetes cluster.
PodDisruptionBudgetis created for each WebLogic cluster. These pod disruption budgets are labeled with
Kubernetes requires that the names of some resource types follow the DNS label standard as defined in DNS Label Names and RFC 1123. Therefore, the operator enforces that the names of the Kubernetes resources do not exceed Kubernetes limits (see Meet Kubernetes resource name restrictions).
The diagram below shows the components inside the containers running WebLogic Server instances:
The Domain specifies a container image, defaulting to
container-registry.oracle.com/middleware/weblogic:126.96.36.199. All containers running WebLogic Server use this same image. Depending on the use case, this image could contain the WebLogic Server product binaries or also include the domain directory.
During a rolling event caused by a change to the Domain’s
image field, containers will be using a mix of the updated value of the
image field and its previous value.
ENTRYPOINTis configured by a script that starts up a Node Manager process, and then uses WLST to request that Node Manager start the server. Node Manager is used to start servers so that the socket connection to the server will be available to obtain server status even when the server is unresponsive. This is used by the liveness probe.
The operator deploys services with predictable well-defined DNS names
for each WebLogic server and cluster in your WebLogic configuration.
The name of a WebLogic server service is
and the name of a WebLogic server cluster is
all in lowercase, with underscores
_ converted to hyphens
The operator also automatically overrides the
ListenAddress fields in each
running WebLogic Server to match its service name in order
to ensure that the servers will always be able to find each other.
For details, see Meet Kubernetes resource name restrictions.
The operator expects (and requires) that all state that is expected to outlive the life of a pod be stored outside of the images that are used to run the domain. This means either in a persistent file system, or in a database. The WebLogic configuration, that is, the domain directory and the applications directory may come from the image or a persistent volume. However, other state, such as file-based persistent stores, and such, must be stored on a persistent volume or in a database. All of the containers that are participating in the WebLogic domain use the same image, and take on their personality; that is, which server they execute, at startup time. Each Pod mounts storage, according to the Domain, and has access to the state information that it needs to fulfill its role in the domain.
It is worth providing some background information on why this approach was adopted, in addition to the fact that this separation is consistent with other existing operators (for other products) and the Kubernetes “cattle, not pets” philosophy when it comes to containers.
The external state approach allows the operator to treat the images as essentially immutable, read-only, binary images. This means that the image needs to be pulled only once, and that many domains can share the same image. This helps to minimize the amount of bandwidth and storage needed for WebLogic Server images.
This approach also eliminates the need to manage any state created in a running container, because all of the state that needs to be preserved is written into either the persistent volume or a database backend. The containers and pods are completely throwaway and can be replaced with new containers and pods, as necessary. This makes handling failures and rolling restarts much simpler because there is no need to preserve any state inside a running container.
When users wish to apply a binary patch to WebLogic Server, it is necessary to create only a single new, patched image. If desired, any domains that are running may be updated to this new patched image with a rolling restart, because there is no state in the containers.
It is envisaged that in some future release of the operator, it will be desirable to be able to “move” or “copy” domains in order to support scenarios like Kubernetes federation, high availability, and disaster recovery. Separating the state from the running containers is seen as a way to greatly simplify this feature, and to minimize the amount of data that would need to be moved over the network, because the configuration is generally much smaller than the size of WebLogic Server images.
The team developing the operator felt that these considerations provided adequate justification for adopting the external state approach.