anchor.diff:  
   When setting up a cluster you have two options on how the nodes in the cluster communicate:
   
  -. <<Create a DNS-based Kubernetes cluster, Using DNS>> - Creating a Kubernetes cluster that uses DNS for node discovery requires your own domain (or subdomain) and setting up Route 53 hosted zones. This allows the various Kubernetes components to find and communicate with each other. This is also necessary for kubectl to be able to talk directly with the master.
  -. <<Create a gossip-based Kubernetes cluster, Using the gossip protocol>> - kops has experimental support for a gossip-based cluster. This does not require a  domain, subdomain, or Route53 hosted zone to be registered. A gossip-based cluster is therefore easier and quicker to setup.
  -
  -You'll need to choose one of the two options. Instructions for both options are provided below, and the examples in the workshop should work with either option. Creating a gossip-based cluster requires less setup and will be used in this workshop, unless otherwise specified.
  +. <<Create a gossip-based Kubernetes cluster, Using the gossip protocol>> - kops has experimental support for a gossip-based cluster. This does not require a domain, subdomain, or Route53 hosted zone to be registered. A gossip-based cluster is therefore easier and quicker to setup, and is the preferred method for creating a cluster for use with this workshop.
  +. <<Create a DNS-based Kubernetes cluster, Using DNS>> - Creating a Kubernetes cluster that uses DNS for node discovery requires your own domain (or subdomain) and setting up Route 53 hosted zones. This allows the various Kubernetes components to use DNS resolutions find and communicate with each other, and for kubectl to be able to talk directly with the master node(s).
  +
  +Instructions for creating a gossip-baed cluster are provided below, however, the examples in the workshop should work with either option. Instructions for creating a DNS-based cluster are provided as an addendum at the bottom of this page.
   
   NOTE: If you're using London region (`eu-west-2`) you need to add `--cloud aws` as kops is not identifying that `eu-west-2` indicates AWS. Further info https://github.com/kubernetes/kops/issues/1267
   
  
positive.code:     aws ec2 detach-internet-gateway --internet $IGW --vpc $VPCID
      aws ec2 delete-internet-gateway --internet-gateway-id $IGW
      aws ec2 delete-vpc --vpc-id $VPCID
  
negative.code: Your cluster example.cluster.k8s.local is ready
  ```
  
  It is also possible to create a DNS-based cluster (see Appendix: Create a DNS-based Kubernetes cluster below) where the master and worker nodes are in private subnets. A `--dns-zone` argument is required to specify the domain. If `--dns private` is also specified, a Route53 private hosted zone is created for routing the traffic for the domain within one or more VPCs. The Kubernetes API can therefore only be accessed from within the VPC. This is a current issue with kops (see https://github.com/kubernetes/kops/issues/2032). A possible workaround is to mirror the private Route53 hosted zone with a public hosted zone that exposes only the API server ELB endpoint. This workaround is discussed http://kubecloud.io/setup-ha-k8s-kops/[here].
  
  Although most of the exercises in this workshop should work on a cluster with a private VPC, some commands won't, specifically those that use a proxy to access internally hosted services.
  
  == Kubernetes cluster context
  
  You may create multiple Kubernetes clusters. The configuration for each cluster is stored in a configuration file, referred to as "`kubeconfig file`". By default, kubectl looks for a file named `config` in the directory `~/.kube`. The kubectl CLI uses kubeconfig file to find the information it needs to choose a cluster and communicate with the API server of a cluster.
  
  This allows you to deploy your applications to different environments by just changing the context. For example, here is a typical flow for application development:
  
  . Build your application using minikube (See Set up Local Development Environment for more information)
  . Change the context to a test cluster created on AWS
  . Use the same command to deploy to test environment
  . Once satisfied, change the context again to a production cluster on AWS
  