From 8c9e88058cc64547fec198a68e7b1b574bdaed58 Mon Sep 17 00:00:00 2001 From: Brandon Philips Date: Sat, 1 Apr 2017 17:02:54 +0200 Subject: [PATCH] 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. --- docs/admin.md | 16 ++++++++-------- examples/PREREQUISITES.md | 4 ++-- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/admin.md b/docs/admin.md index 4a7ea2b4d..a52b8df1e 100644 --- a/docs/admin.md +++ b/docs/admin.md @@ -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`. diff --git a/examples/PREREQUISITES.md b/examples/PREREQUISITES.md index 5881f9045..a2c12ad2a 100644 --- a/examples/PREREQUISITES.md +++ b/examples/PREREQUISITES.md @@ -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).