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: link:http://kubernetes.io/docs/user-guide/services/#external-ips[ExternalIPs]
  to the service. The supplied list of IP addresses are used for load balancing
  incoming requests. The service port is opened on all nodes running kube-proxy.
  ExternalIPs require elevated permissions to assign, and manual tracking of the
  IP:ports that are in use.
  
  An externally visible IP can be configured in one of several ways:
  
  - Manually configure the ExternalIP with a known external IP address.
  - Configure ExternalIP to a
  xref:../admin_guide/high_availability.adoc#admin-guide-high-availability[VIP]
  that is generated from (VRRP).
  - In a cloud (xref:../install_config/configuring_aws.adoc#install-config-configuring-aws[AWS] or
  xref:../install_config/configuring_gce.adoc#install-config-configuring-gce[GCE])
  use `type=LoadBalancer`
  - In a non-cloud environment, configure an ingressIP range (IngressIPNetworkCIDR),
  `service.type=LoadBalancer` and `service.port.ingressIP`.
  
  The administrator must ensure the external IPs are routed to the nodes and local
  firewall rules on all nodes allow access to the open port.
  
  Use the same nodes as the router, but advertise them with VRRP and use
  the DNS address of the router nodes.
  
  [[using-nodeport]]
  == Using a Service NodePort
  
  Use NodePorts to expose the service nodePort on all nodes in the cluster.
  NodePorts are in the 30-60k range by default, which means a NodePort is
  unlikely to match a service's intended port (for example, 8080 may be exposed
  as 31020). This use of ports is wasteful of scarce port resources.
  However, it is slightly easier to set up. Again, this requires more privileges.
  
  The administrator must ensure the external IPs are routed to the nodes and local
  firewall rules on all nodes allow access to the open port.
  
  NodePorts and externalIP are independent and both can be used concurrently.
  