docs: use generic instead of OSS controller
This term was really confusing me because all of these controllers in this repo are OSS. So, instead use the term generic and define it upon first use.
This commit is contained in:
parent
c14d0d852b
commit
8c9e88058c
2 changed files with 10 additions and 10 deletions
|
@ -8,11 +8,11 @@ __GCP__: On GCE/GKE, the Ingress controller runs on the
|
|||
master. If you wish to stop this controller and run another instance on your
|
||||
nodes instead, you can do so by following this [example](/examples/deployment/gce).
|
||||
|
||||
__OSS__: You can deploy an OSS Ingress controller by simply
|
||||
__generic__: You can deploy a genric (nginx or haproxy) Ingress controller by simply
|
||||
running it as a pod in your cluster, as shown in the [examples](/examples/deployment).
|
||||
Please note that you must specify the `ingress.class`
|
||||
[annotation](/examples/PREREQUISITES.md#ingress-class) if you're running on a
|
||||
cloudprovider, or the cloudprovider controller will fight the OSS controller
|
||||
cloudprovider, or the cloudprovider controller will fight the nginx controller
|
||||
for the Ingress.
|
||||
|
||||
__AWS__: Until we have an AWS ALB Ingress controller, you can deploy the nginx
|
||||
|
@ -20,10 +20,10 @@ Ingress controller behind an ELB on AWS, as shows in the [next section](#stacked
|
|||
|
||||
## Stacked deployments
|
||||
|
||||
__Behind a LoadBalancer Service__: You can deploy an OSS controller behind a
|
||||
__Behind a LoadBalancer Service__: You can deploy an generic controller behind a
|
||||
Service of `Type=LoadBalancer`, by following this [example](/examples/static-ip/nginx#acquiring-an-ip).
|
||||
More specifically, first create a LoadBalancer Service that selects the OSS
|
||||
controller pods, then start the OSS controller with the `--publish-service`
|
||||
More specifically, first create a LoadBalancer Service that selects the generic
|
||||
controller pods, then start the generic controller with the `--publish-service`
|
||||
flag.
|
||||
|
||||
|
||||
|
@ -37,8 +37,8 @@ TODO: Write an example
|
|||
|
||||
## Daemonset
|
||||
|
||||
Neither a single pod or bank of OSS controllers scales with the cluster size.
|
||||
If you create a daemonset of OSS Ingress controllers, every new node
|
||||
Neither a single pod or bank of generic controllers scales with the cluster size.
|
||||
If you create a daemonset of generic Ingress controllers, every new node
|
||||
automatically gets an instance of the controller listening on the specified
|
||||
ports.
|
||||
|
||||
|
@ -46,7 +46,7 @@ TODO: Write an example
|
|||
|
||||
## Intra-cluster Ingress
|
||||
|
||||
Since OSS Ingress controllers run in pods, you can deploy them as intra-cluster
|
||||
Since generic Ingress controllers run in pods, you can deploy them as intra-cluster
|
||||
proxies by just not exposing them on a `hostPort` and putting them behind a
|
||||
Service of `Type=ClusterIP`.
|
||||
|
||||
|
|
|
@ -10,12 +10,12 @@ Unless you're running on a cloudprovider that supports Ingress out of the box
|
|||
|
||||
## Firewall rules
|
||||
|
||||
If you're using a bare-metal controller (eg the nginx ingress controller), you
|
||||
If you're using a generic controller (eg the nginx ingress controller), you
|
||||
will need to create a firewall rule that targets port 80/443 on the specific VMs
|
||||
the nginx controller is running on. On cloudproviders, the respective backend
|
||||
will auto-create firewall rules for your Ingress.
|
||||
|
||||
If you'd like to auto-create firewall rules for an OSS Ingress controller,
|
||||
If you'd like to auto-create firewall rules for an Ingress controller,
|
||||
you can put it behind a Service of `Type=Loadbalancer` as shown in
|
||||
[this example](/examples/static-ip/nginx#acquiring-an-ip).
|
||||
|
||||
|
|
Loading…
Reference in a new issue