anchor.diff:  == Using Virtual IPs
   
   All of the approaches can expose
  -xref:../admin_guide/high_availability.adoc#admin-guide-high-availability[VIPs] (virtual IPs). The Virtual
  -IPs are generated from the VRRP protocol.
  +xref:../admin_guide/high_availability.adoc#admin-guide-high-availability[VIPs].
  +The VIPs are generated from the VRRP protocol.
   
   
   [[edge-load-balancer]]
  -== Edge LoadBalancer
  +== Edge Load Balancer
   
   An edge xref:../install_config/routing_from_edge_lb.adoc#install-config-routing-from-edge-lb[load balancer]
   can be used to accept traffic from outside networks and proxy the traffic
   to pods inside the cluster.
   
  -In this configuration the internal pod network is visible to the outside.
  -
  +In this configuration, the internal pod network is visible to the outside.
  
positive.code: 
  The recommendation is:
  
  - If you have HTTP/HTTPS -- Use the
  xref:../dev_guide/getting_traffic_into_cluster.adoc#using-a-router[Router],
  - If you have a TLS-encrypted protocol other than HTTPS (i.e., TLS with
  the SNI header) --
  Use the xref:../dev_guide/getting_traffic_into_cluster.adoc#using-a-router[Router],
  - Otherwise -- Use
  xref:../dev_guide/getting_traffic_into_cluster.adoc#using-the-loadbalancer[LoadBalancer],
  xref:../dev_guide/getting_traffic_into_cluster.adoc#using-externalIP[ExternalIP], or
  xref:../dev_guide/getting_traffic_into_cluster.adoc#using-nodeport[NodePort].
  
  TCP or UDP offers several approaches:
  
  - Use the non-cloud
  xref:../dev_guide/getting_traffic_into_cluster.adoc#using-the-loadbalancer[LoadBalancer],
  but that limits you to a single ingress IP (can be a VIP, but still will be
  a single machine for initial load balancing). It simplifies the admin job,
  but uses one IP per service.
  - Manually assign
  xref:../dev_guide/getting_traffic_into_cluster.adoc#using-externalIP[ExternalIPs]
  to the service. Here you can assign a set of IPs, so can have multiple
  machines for the incoming load balancing. But this requires elevated
  permissions to assign, and manual tracking of what IP:ports that have been used.
  - Use xref:../dev_guide/getting_traffic_into_cluster.adoc#using-nodeport[NodePorts]
  to expose the service on ALL nodes in the cluster. This is more wasteful
  of scarce port resources. However, it is a little easier to set up multiple.
  Again, this requires more privilege.
  
  The router is the most common way to access the cluster.
  This is limited to HTTP/HTTPS(SNI)/TLS(SNI) which covers web applications.
  
  ExternalIP or NodePort is useful when the HTTP protocol is not being used or
  non-standard ports are in use. There is more manual setup and monitoring
  involved.
  
  The admin needs to set up the external to the cluster networking environment
  so that requests can reach the cluster. For example, names can be configured
  into 
  xref:../install_config/install/prerequisites.adoc#prereq-dns[DNS]
  to point to specific nodes or other IP addresses in the cluster.
  The DNS wildcard feature can be used to confiugre a subset of names to an
  IP address in the cluster.  This is convenient when using routers because
  it allows the users to set up routes within the cluster without further
  admin attention.
  
  The admin must make sure the local firewall on each node permits the
  request to reach the IP address.
  
  The xref:../admin_guide/high_availability.adoc#admin-guide-high-availability[High Availability] section
  describes how to make this highly available using replicated services.
  
  endif::[]
  
  
  [[using-a-router]]
  == Using a Router
  
negative.code: This is the most common way to access the cluster. A
  xref:../install_config/configuring_routing.adoc#install-config-configuring-routing[router]
  is configured to accept external requests and proxy them based on the
  configured routes. This is limited to HTTP/HTTPS(SNI)/TLS(SNI), which
  covers web applications.
  
  An administrator can create a
  xref:../install_config/install/prerequisites.adoc#prereq-dns[wildcard DNS]
  entry, and then set up a router. Afterward, the users can self-service the
  ingress without having to contact the administrators. The router has controls to
  allow the administrator to specify whether the users can self-provision host
  names, or if they must fit a pattern the administrator defines. The other
  solutions require the administrator to do the provisioning, or they require that
  the administrator delegates a lot of privilege.
  
  A set of routes can be created in the various projects. The overall set of
  routes is available to the set of routers. Each router selects from the set of
  routes. All routers see all routes unless restricted by labels on the router,
  which is called router
  xref:../architecture/core_concepts/routes.adoc#router-sharding[sharding].
  
  The
  xref:../admin_guide/high_availability.adoc#admin-guide-high-availability[High
  Availability] section describes how to configure a router for high availability
  service using multiple replicas.
  
  [[using-the-loadbalancer]]
  == Using a Load Balancer Service
  
  link:http://kubernetes.io/docs/user-guide/services/#type-loadbalancer[Load balancers] are available on
  xref:../install_config/configuring_aws.adoc#install-config-configuring-aws[AWS]
  and
  xref:../install_config/configuring_gce.adoc#install-config-configuring-gce[GCE]
  clouds, and
  xref:../admin_guide/tcp_ingress_external_ports.adoc#admin-guide-expose-external-ports[non-cloud]
  options are also available.
  
  The non-cloud
  xref:../admin_guide/tcp_ingress_external_ports.adoc#admin-guide-expose-external-ports[load
  balancer] allocates a unique IP from a configured pool. This limits you to a
  single ingress IP, which can be a VIP, but still will be a single machine for
  initial load balancing. The non-cloud load balancer simplifies the
  administrator's job by providing the needed IP address, but uses one IP per
  service.
  
  [[using-externalIP]]
  == Using a Service ExternalIP
  