follow up from https://github.com/kubernetes/website/pull/10958 (#11039)

* follow up from https://github.com/kubernetes/website/pull/10958

and a bit of additional example work

Signed-off-by: Joe Heck <heckj@mac.com>

* Update ingress.md

content/en/docs/concepts/services-networking/ingress.md

@@ -84,19 +84,24 @@ Additional controllers include:
   ([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket), and it also comes with commercial
   support by [Containous](https://containo.us/services).
 
-{{< note >}}
-Review the documentation for your controller to find its specific support policy.
-{{< /note >}}
-
 You may deploy [any number of ingress controllers](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers) within a cluster.
 When you create an ingress, you should annotate each ingress with the appropriate
 [`ingress-class`](https://git.k8s.io/ingress-gce/examples/PREREQUISITES.md#ingress-class) to indicate which ingress
 controller should be used if more than one exists within your cluster.
 If you do not define a class, your cloud provider may use a default ingress provider.
 
+### Before you begin
+
+Ideally, all ingress controllers should fulfill this specification, but the various ingress
+controllers operate slightly differently.
+
+{{< note >}}
+Make sure you review your ingress controller's documentation to understand the caveats of choosing it.
+{{< /note >}}
+
 ## The Ingress Resource
 
-A minimal ingress example:
+A minimal ingress resource example:
 
 ```yaml
 apiVersion: extensions/v1beta1
@@ -115,42 +120,43 @@ spec:
           servicePort: 80
 ```
 
- __Lines 1-6__: As with all other Kubernetes resources, an ingress needs `apiVersion`, `kind`, and `metadata` fields.  
+ As with all other Kubernetes resources, an ingress needs `apiVersion`, `kind`, and `metadata` fields.  
  For general information about working with config files, see [deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configuring containers](/docs/tasks/configure-pod-container/configure-pod-configmap/), [managing resources](/docs/concepts/cluster-administration/manage-deployment/).
  Ingress frequently uses annotations to configure some options depending on the ingress controller, an example of which
  is the [rewrite-target annotation](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).
  Different [ingress controller](#ingress-controllers) support different annotations. Review the documentation for
- the ingress controller you are using to learn which annotations are supported and valid options.
+ your choice of ingress controller to learn which annotations are supported.
 
-__Lines 7-9__: Ingress [spec](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status)
+The ingress [spec](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status)
 has all the information needed to configure a loadbalancer or proxy server. Most importantly, it
 contains a list of rules matched against all incoming requests. Ingress resource only supports rules
-for directing http traffic.
+for directing HTTP traffic.
 
-__Lines 10-11__: Each http rule contains the following information:
+### Ingress rules
+
+Each http rule contains the following information:
 
 * An optional host. In this example, no host is specified, so the rule will apply to all inbound
   HTTP traffic through the IP address that will be connected. If a host is provided, for example:
-  foo.bar.com, the rules will apply on to that host)
+  foo.bar.com, the rules will apply on to that host.
 * a list of paths (e.g.: /testpath) each of which has an associated backend defined with a `serivceName`
   and `servicePort`. Both the host and path must match the content of an incoming request before the
-  loadbalancer directs traffic to the referenced service.
+  loadbalancer will direct traffic to the referenced service.
+* A backend is a combination of service and port names as described in the
+  [services doc](/docs/concepts/services-networking/service/). HTTP (and HTTPS) requests to the
+  ingress matching the host and path of the rule will be sent to the listed backend.
 
-__Lines 12-14__: A backend is a service:port combination as described in the [services doc](/docs/concepts/services-networking/service/).
+A default backend is often configured in an ingress controller that will service any requests that do not
-Ingress traffic is typically sent directly to the endpoints matching a backend.
+match a path in the spec.
 
-A default backend is often configured in an ingress controller that will service any requests that don't match a path in the spec.
+### Default Backend
 
-## Before you begin
+An ingress with no rules sends all traffic to a single default backend. The default
+backend is typically a configuration option of the [ingress controller](#ingress-controllers)
+and is not specified in your ingress resources.
 
-Ideally, all ingress controllers should fulfill this specification, but the various ingress
+If none of the hosts or paths match the HTTP request in the ingress objects, the traffic is
-controllers operate slightly differently. The Kubernetes project supports and maintain
+routed to your default backend.
-[GCE](https://git.k8s.io/ingress-gce/README.md) and [nginx](https://git.k8s.io/ingress-nginx/README.md)
-ingress controllers.
-
-{{< note >}}
-Make sure you review your [ingress controller](#ingress-controllers)'s specific docs to understand the caveats.
-{{< /note >}}
 
 ## Types of Ingress
 
@@ -177,15 +183,15 @@ Where `107.178.254.228` is the IP allocated by the ingress controller to satisfy
 this ingress.
 
 {{< note >}}
-Ingress controllers and load balancers may take a minute or two to allocate an IP address. Until that time you 
+Ingress controllers and load balancers may take a minute or two to allocate an IP address.
-will often see the address listed as `<pending>`.
+Until that time you will often see the address listed as `<pending>`.
 {{< /note >}}
 
 ### Simple fanout
 
-A fanout configuration routes traffic from a single IP address to more than one service, based on the HTTP URI being requested.
+A fanout configuration routes traffic from a single IP address to more than one service,
- An ingress allows you to keep the number of loadbalancers down
+based on the HTTP URI being requested. An ingress allows you to keep the number of loadbalancers
-to a minimum. For example, a setup like:
+down to a minimum. For example, a setup like:
 
 ```shell
 foo.bar.com -> 178.91.123.132 -> / foo    service1:4200
@@ -285,12 +291,38 @@ spec:
           servicePort: 80
 ```
 
-__Default Backends__: An ingress with no rules, like the one shown in the previous
+If you create an ingress resource without any hosts defined in the rules, then any
-section, sends all traffic to a single default backend. You can use the same
+web traffic to the IP address of your ingress controller can be matched without a name based
-technique to tell a loadbalancer where to find your website's 404 page, by
+virtual host being required. For example, the following ingress resource will route traffic 
-specifying a set of rules *and* a default backend. Traffic is routed to your
+requested for `first.bar.com` to `service1`, `second.bar.com` to `service2`, and any traffic
-default backend if none of the Hosts in your ingress match the Host in the
+to the IP address without a hostname defined in request (that is, without a request header being
-request header, and/or none of the paths match the URL of the request.
+presented) to `service3`.
+
+```yaml
+apiVersion: extensions/v1beta1
+kind: Ingress
+metadata:
+  name: name-virtual-host-ingress
+spec:
+  rules:
+  - host: first.bar.com
+    http:
+      paths:
+      - backend:
+          serviceName: service1
+          servicePort: 80
+  - host: second.foo.com
+    http:
+      paths:
+      - backend:
+          serviceName: service2
+          servicePort: 80
+  - http:
+      paths:
+      - backend:
+          serviceName: service3
+          servicePort: 80
+```
 
 ### TLS