anchor.diff:  == Debugging Kubernetes
   
   Check `iptables -t nat -L` to make sure that the service is being
  -natted to the right port on the local machine for the `kubeproxy`.
  +NAT'd to the right port on the local machine for the `kubeproxy`.
   
   WARNING: This is all changing soon... Kubeproxy is being eliminated and
   replaced with an `iptables`-only solution.
  
positive.code: network.  Only reachable from the client nodes.
  Service Address:: An IP address that represents the service, and is
  mapped to a pod address internally.  These are assigned and managed by
  Openshift.  By default they are assigned out of the 172.30.0.0/16
  network.  Only reachable from the client nodes.
  
  The following diagram shows all of the pieces involved with external access.
  
negative.code: 10.1.0.0/16 dev tun0  proto kernel  scope link                          # This sends all pod traffic into OVS
  10.1.1.0/24 dev tun0  proto kernel  scope link  src 10.1.1.1            # This is traffic going to local pods, overriding the above
  169.254.0.0/16 dev ens3  scope link  metric 1002                        # This is for Zeroconf (may not be present)
  172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.42.1    # Docker's private IPs... used only by things directly configured by docker; not OpenShift
  192.168.122.0/24 dev ens3  proto kernel  scope link  src 192.168.122.46 # The physical interface on the local subnet
  ....
  
  You should see the 10.1.x.x lines (assuming you have your pod network set to the default range in your configuration).  If you do not, check the OpenShift logs (see the <<reading-the-logs>> section)
  
  === Is the Open vSwitch confured correctly?
  
  