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:
Brandon Philips 2017-04-01 17:02:54 +02:00
parent c14d0d852b
commit 8c9e88058c
2 changed files with 10 additions and 10 deletions

View file

@ -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`.

View file

@ -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).