Skip to content

Commit 974bfc8

Browse files
authored
Merge pull request #724 from oracle/final-final-doc-review
final doc review
2 parents 076047a + d50fc28 commit 974bfc8

File tree

12 files changed

+270
-517
lines changed

12 files changed

+270
-517
lines changed

site/apache.md

Lines changed: 0 additions & 49 deletions
This file was deleted.

site/database.md

Lines changed: 6 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,14 @@
1-
**TODO** finish this page - make sure we tell people how to run
2-
a db in a pod with persistent storage, and how to configure the
3-
persistent store/leases etc in there
41

52
# Running the Oracle Database in Kubernetes
63

74
If you wish to run the Oracle Database inside your Kubernetes cluster, in order to place
85
your state store, leasing tables, etc., in that database, then you can use this
96
sample to install the database.
107

8+
You must configure your database to store its DB files
9+
on persistent storage. Refer to your cloud vendor's documentation for details of
10+
available storage providers and how to create a persistent volume and attach it to a pod.
11+
1112
First create a namespace for the database:
1213

1314
```
@@ -43,6 +44,7 @@ spec:
4344
- name: dshm
4445
emptyDir:
4546
medium: Memory
47+
# add your volume mount for your persistent storage here
4648
containers:
4749
- name: database
4850
command:
@@ -58,6 +60,7 @@ spec:
5860
volumeMounts:
5961
- mountPath: /dev/shm
6062
name: dshm
63+
# add your persistent storage for DB files here
6164
env:
6265
- name: DB_SID
6366
value: OraDoc

site/elk.md

Lines changed: 0 additions & 57 deletions
This file was deleted.

site/ingress.md

Lines changed: 38 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -1,41 +1,62 @@
1-
**TODO** review and udpate - link into [lb](load-balancing.md)
2-
31
# Load balancing with Ingress
4-
Ingress is a approach provided by k8s to hook up and run a load balancer. Pls see detail in [the Ingress doc](https://kubernetes.io/docs/concepts/services-networking/ingress/).
2+
Ingresses are one approach provided by Kubernetes to configure load balancers.
3+
Depending on the version of Kubernetes you are using, and your cloud provider, you may need to use Ingresses.
4+
Please refer to [the Ingress documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/)
5+
for more information about Ingresses.
6+
7+
## WebLogic clusters as backends of Ingress
58

6-
## WebLogic domains as backends of Ingress
9+
In an Ingress object, a list of backends are provided for each target that will be load balanced. Each backend is typically
10+
[a Kubernetes service](https://kubernetes.io/docs/concepts/services-networking/service/), more specifically, a combination of a `serviceName` and a `servicePort`.
711

8-
In Ingress a backend is defined as [a k8s service](https://kubernetes.io/docs/concepts/services-networking/service/), more specifically, a combination of a `serviceName` and a `servicePort`. A WebLogic domain is a backend of the load balancer. When the WebLogic operator creates a WebLogic domain, it always creates a k8s service for each WebLogic cluster in the domain. With the proper label selector defined in the generated service, the service contains all-and-only the running WebLogic server pods within the WebLogic cluster.
12+
When the WebLogic operator creates a WebLogic domain, it also creates a service for each WebLogic cluster in the domain.
13+
The operator defines the service such that its selector will match all WebLogic server pods within the WebLogic cluster
14+
which are in the "ready" state.
915

10-
The name of the k8s service generated for a WebLogic cluster follows the pattern '<domainUID>-cluster-<clusterName>'. For instance, if the doaminUID is 'domain1' and the cluster name is 'cluster-1', the corresponding k8s service name generated by WebLogic operator will be 'domain1-cluster-cluster-1'.
16+
The name of the service created for a WebLogic cluster follows the pattern `<domainUID>-cluster-<clusterName>`.
17+
For example, if the `domainUID` is `domain1` and the cluster name is `cluster-1`, the corresponding service
18+
will be named `domain1-cluster-cluster-1`.
1119

12-
The service name has the following limitation in k8s:
20+
The service name must comply with standard Kubernetes rules for naming of object and in particular with DNS-1035:
1321
> A DNS-1035 label must consist of lower case alphanumeric characters or '-', start with an alphabetic character, and end with an alphanumeric character (e.g. 'my-name', or 'abc-123', regex used for validation is '[a-z]([-a-z0-9]*[a-z0-9])?').
1422
15-
To meet the limitation, if the domainUID or the cluster name contains some upper-case characters or `_` , in the generated service name the upper-case characters will be converted to lower-case and `_` will be converted to `-` . For instance, if the doaminUID is 'myDomain_1' and the cluster name is 'myCluster_1', the corresponding k8s service name generated by WebLogic operator will be 'mydomain-1-cluster-mycluster-1'.
23+
To comply with these requirements, if the `domainUID` or the cluster name contains some upper-case characters or underscores, then
24+
in the service name the upper-case characters will be converted to lower-case and underscores will be converted to hyphens.
25+
For example, if the `domainUID` is `myDomain_1` and the cluster name is `myCluster_1`, the corresponding service will be named
26+
`mydomain-1-cluster-mycluster-1`.
1627

17-
The service, `serviceName` and `servicePort`, of a WebLogic cluster will be used in the routing rules defined in Ingress resources and the load balancer will route traffic to the WebLogic servers within the cluster based on the rules. Note that eac traffic load, redirected by the load balancer, is not sent to the service directly, but instead, to one endpoint of the service based on its load-balancing algorithm. The load balancer depends on the k8s platform to maintain the live endpoint list of the service.
28+
The service, `serviceName` and `servicePort`, of a WebLogic cluster will be used in the routing rules defined in the Ingress
29+
object and the load balancer will route traffic to the WebLogic servers within the cluster based on the rules.
30+
31+
**Note** Most common ingress controllers, for example Traefik, Voyager and nginx,
32+
understand that there are zero or more actual pods behind the service, and they actually
33+
build their backend list and route requests to those backends directly, not through the service. This means that
34+
requests are properly balanced across the pods, according to the load balancing algorithm
35+
in use. Most ingress controllers also
36+
subscribe to updates on the service and adjust their internal backend sets when
37+
additional pods become ready, or pods enter a non-ready state.
1838

1939
## Steps to setup an Ingress load balancer
2040

2141
1. Install the Ingress controller.
2242
After the Ingress controller is running, it monitors Ingress resources in given namespace(s) and acts accordingly.
2343

24-
1. Install Ingress Resource(s)
25-
Ingress resources contain routing rules to one or more backends. And Ingress controller is responsible to apply the rules to the underline load balancer.
44+
1. Create Ingress Resource(s)
45+
Ingress resources contain routing rules to one or more backends. An Ingress controller is responsible to apply the rules to the underlying load balancer.
2646
There are two approaches to create the Ingress resource:
2747
1. Use the helm chart [ingress-per-domain](../kubernetes/samples/charts/ingress-per-domain).
28-
Each Ingress provider support a bunch of different annotations in Ingress resources. This helm chart allows you to define the routing rules without dealing with the detailed provider-specific annotations. Currently we support two Ingress providers: Traefik and Voyager. The limitation of the helm chart is that it only support one WebLogic cluster as the backend.
29-
30-
1. Create and install the Ingress yaml manually.
31-
Manually edit the Ingress yaml file and then install it to the k8s cluster.
48+
Each Ingress provider supports a number of annotations in Ingress resources. This helm chart allows you to define the routing rules without dealing with the detailed provider-specific annotations. Currently we support two Ingress providers: Traefik and Voyager.
49+
50+
1. Create the Ingress resource manually from a YAML file.
51+
Manually create an Ingress YAML file and then apply it to the Kubernetes cluster.
3252

3353
## Guide and samples for Traefik and Voyager/HAProxy
34-
Traefik and Voyager/HAProxy are both popular Ingress providers. We provide detail guide to install and configure these two Ingress providers, specially in front of WebLogic domain(s).
54+
Traefik and Voyager/HAProxy are both popular Ingress controllers.
55+
Information about how to install and configure these to load balance WebLogic clusters is provided here:
3556
- [Treafik guide](../kubernetes/samples/charts/traefik/README.md)
3657
- [Voyager guide](../kubernetes/samples/charts/voyager/README.md)
3758

38-
We also provide Ingress samples for these two Ingress providers, with multiple WebLogic clusters as the backends and covering different routing rules, host-routing and path-routing, and TLS termination.
59+
Samples are also provided for these two Ingress controllers, showing how to manage multiple WebLogic clusters as the backends, using different routing rules, host-routing and path-routing; and TLS termination:
3960
- [Treafik samples](../kubernetes/samples/charts/traefik/samples)
4061
- [Voyager samples](../kubernetes/samples/charts/voyager/samples)
4162

0 commit comments

Comments
 (0)