Update a couple of references to kube-dns; and cosmetic tweaks

slides/kube/concepts-k8s.md

@@ -239,7 +239,11 @@ Yes!
   - namespace (more-or-less isolated group of things)
   - secret (bundle of sensitive data to be passed to a container)
  
-  And much more! (We can see the full list by running `kubectl api-resources`)
+  And much more!
+
+- We can see the full list by running `kubectl api-resources`
+
+  (Up until Kubernetes 1.10, the command to list API resources was `kubectl get`)
 
 ---
 

slides/kube/kubectlget.md

@@ -83,7 +83,9 @@
 
 - `kubectl` has pretty good introspection facilities
 
-- We can list all available resource types by running `kubectl api-resources` (this used to be `kubectl get`)
+- We can list all available resource types by running `kubectl api-resources`
+  <br/>
+  (up to Kubernetes 1.10, this command used to be `kubectl get`)
 
 - We can view details about a resource with:
   ```bash

slides/kube/namespaces.md

@@ -151,7 +151,7 @@ Note: it might take a minute or two for the app to be up and running.
 
 - A pod in the `default` namespace can communicate with a pod in the `kube-system` namespace
 
-- `kube-dns` uses a different subdomain for each namespace
+- CoreDNS uses a different subdomain for each namespace
 
 - Example: from any pod in the cluster, you can connect to the Kubernetes API with:
 

slides/kube/whatsnext.md

@@ -28,7 +28,7 @@ And *then* it is time to look at orchestration!
 
 - Each of the two `redis` services has its own `ClusterIP`
 
-- `kube-dns` creates two entries, mapping to these two `ClusterIP` addresses:
+- CoreDNS creates two entries, mapping to these two `ClusterIP` addresses:
 
   `redis.blue.svc.cluster.local` and `redis.green.svc.cluster.local`