Ingresses are one approach provided by Kubernetes to configure load balancers. Depending on the version of Kubernetes you are using, and your cloud provider, you may need to use Ingresses. For more information about Ingresses, see the Kubernetes Ingress documentation.
In an Ingress object, a list of backends are provided for each target that will be load balanced. Each backend is typically
a Kubernetes Service, more specifically, a combination of a serviceName and a servicePort.
When the operator creates a WebLogic domain, it also creates a service for each WebLogic cluster in the domain. The operator defines the service such that its selector will match all WebLogic Server pods within the WebLogic cluster which are in the “ready” state.
The name of the service created for a WebLogic cluster follows the pattern <domainUID>-cluster-<clusterName>.
For example, if the domainUID is domain1 and the cluster name is cluster-1, the corresponding service
will be named domain1-cluster-cluster-1.
The service name must comply with standard Kubernetes rules for naming of objects and in particular with DNS-1035:
A DNS-1035 label must consist of lowercase alphanumeric characters or ‘-’, start with an alphabetic character, and end with an alphanumeric character (e.g.
my-name, orabc-123, regex used for validation is[a-z]([-a-z0-9]*[a-z0-9])?).
To comply with these requirements, if the domainUID or the cluster name contains some upper-case characters or underscores, then
in the service name the upper-case characters will be converted to lower-case and underscores will be converted to hyphens.
For example, if the domainUID is myDomain_1 and the cluster name is myCluster_1, the corresponding service will be named
mydomain-1-cluster-mycluster-1.
The service, serviceName and servicePort, of a WebLogic cluster will be used in the routing rules defined in the Ingress
object and the load balancer will route traffic to the WebLogic Servers within the cluster based on the rules.
Most common ingress controllers, for example Traefik and NGINX, understand that there are zero or more actual pods behind the service, and they actually build their backend list and route requests to those backends directly, not through the service. This means that requests are properly balanced across the pods, according to the load balancing algorithm in use. Most ingress controllers also subscribe to updates on the service and adjust their internal backend sets when additional pods become ready, or pods enter a non-ready state.
Install the ingress controller.
After the ingress controller is running, it monitors Ingress resources in a given namespace and acts accordingly.
Create Ingress resources.
Ingress resources contain routing rules to one or more backends. An ingress controller is responsible to apply the rules to the underlying load balancer. There are two approaches to create the Ingress resource:
Use the Helm chart.
Each ingress provider supports a number of annotations in Ingress resources. The Helm chart allows you to define the routing rules without dealing with the detailed provider-specific annotations.
Create the Ingress resource manually from a YAML file.
Manually create an Ingress YAML file and then apply it to the Kubernetes cluster.
Information about how to install and configure these ingress controllers to load balance WebLogic clusters is provided here:
For production environments, we recommend NGINX, Traefik (2.2.1 or later) ingress controllers or the load balancer provided by your cloud provider.
Samples are also provided for the Traefik ingress controller, showing how to manage multiple WebLogic clusters as the backends, using different routing rules, host-routing and path-routing; and TLS termination: Traefik samples.
NOTE the following Known Limitation, NGINX SSL passthrough ingress service does not work with Kubernetes headless service.