Merge branch 'master' into release-1.8

2017-08-21 17:02:22 -07:00
parent 5b4ef96268 eb84048739
commit f5cddc78dd
143 changed files with 948 additions and 832 deletions
@@ -200,7 +200,7 @@ You have several options for connecting to nodes, pods and services from outside
      or it may expose it to the internet.  Think about whether the service being exposed is secure.
      Does it do its own authentication?
    - Place pods behind services.  To access one specific pod from a set of replicas, such as for debugging,
-      place a unique label on the pod it and create a new service which selects this label.
+      place a unique label on the pod and create a new service which selects this label.
    - In most cases, it should not be necessary for application developer to directly access
      nodes via their nodeIPs.
  - Access services, nodes, or pods using the Proxy Verb.
@@ -202,15 +202,15 @@ The rules for loading and merging the kubeconfig files are straightforward, but

      Otherwise, use HomeDirectoryLocation (`~/.kube/config`) with no merging.
  1.  Determine the context to use based on the first hit in this chain
-      1.  command line argument - the value of the `context` command line option
+      1.  Command line argument - the value of the `context` command line option
      1.  `current-context` from the merged kubeconfig file
      1.  Empty is allowed at this stage
  1.  Determine the cluster info and user to use.  At this point, we may or may not have a context.  They are built based on the first hit in this chain.  (run it twice, once for user, once for cluster)
-      1.  command line argument - `user` for user name and `cluster` for cluster name
+      1.  Command line argument - `user` for user name and `cluster` for cluster name
      1.  If context is present, then use the context's value
      1.  Empty is allowed
  1.  Determine the actual cluster info to use.  At this point, we may or may not have a cluster info.  Build each piece of the cluster info based on the chain (first hit wins):
-      1.  command line arguments - `server`, `api-version`, `certificate-authority`, and `insecure-skip-tls-verify`
+      1.  Command line arguments - `server`, `api-version`, `certificate-authority`, and `insecure-skip-tls-verify`
      1.  If cluster info is present and a value for the attribute is present, use it.
      1.  If you don't have a server location, error.
  1.  Determine the actual user info to use. User is built using the same rules as cluster info, EXCEPT that you can only have one authentication technique per user.
@@ -16,7 +16,7 @@ well as any provider specific details that may be necessary.
 by using `spec.loadBalancerSourceRanges`. This field takes a list of IP CIDR ranges, which Kubernetes will use to configure firewall exceptions.
 This feature is currently supported on Google Compute Engine, Google Container Engine and AWS. This field will be ignored if the cloud provider does not support the feature.

- Assuming 10.0.0.0/8 is the internal subnet. In the following example, a load balancer will be created that is only accessible to cluster internal ips.
+ Assuming 10.0.0.0/8 is the internal subnet. In the following example, a load balancer will be created that is only accessible to cluster internal IPs.
 This will not allow clients from outside of your Kubernetes cluster to access the load balancer.

 ```yaml
@@ -26,8 +26,8 @@ metadata:
  name: myapp
 spec:
  ports:
-    - port: 8765
-      targetPort: 9376
+  - port: 8765
+    targetPort: 9376
  selector:
    app: example
  type: LoadBalancer
@@ -44,8 +44,8 @@ metadata:
  name: myapp
 spec:
  ports:
-    - port: 8765
-      targetPort: 9376
+  - port: 8765
+    targetPort: 9376
  selector:
    app: example
  type: LoadBalancer
@@ -65,7 +65,7 @@ kubectl expose rc example --port=8765 --target-port=9376 \

 This command creates a new service using the same selectors as the referenced
 resource (in the case of the example above, a replication controller named
-`example`.)
+`example`).

 For more information, including optional flags, refer to the
 [`kubectl expose` reference](/docs/user-guide/kubectl/v1.6/#expose).
@@ -7,9 +7,9 @@ spec:
    app: hello
    tier: frontend
  ports:
-    - protocol: "TCP"
-      port: 80
-      targetPort: 80
+  - protocol: "TCP"
+    port: 80
+    targetPort: 80
  type: LoadBalancer
 ---
 apiVersion: apps/v1beta1
@@ -26,9 +26,9 @@ spec:
        track: stable
    spec:
      containers:
-        - name: nginx
-          image: "gcr.io/google-samples/hello-frontend:1.0"
-          lifecycle:
-            preStop:
-              exec:
-                command: ["/usr/sbin/nginx","-s","quit"]
+      - name: nginx
+        image: "gcr.io/google-samples/hello-frontend:1.0"
+        lifecycle:
+          preStop:
+            exec:
+              command: ["/usr/sbin/nginx","-s","quit"]
@@ -7,6 +7,6 @@ spec:
    app: hello
    tier: backend
  ports:
-    - protocol: TCP
-      port: 80
-      targetPort: http
+  - protocol: TCP
+    port: 80
+    targetPort: http
@@ -34,7 +34,7 @@ You can access Dashboard using the kubectl command-line tool by running the foll
 $ kubectl proxy
 ```

-kubectl will handle authentication with apiserver and make Dashboard available at http://localhost:8001/ui
+Kubectl will handle authentication with apiserver and make Dashboard available at http://localhost:8001/ui.

 The UI can _only_ be accessed from the machine where the command is executed. See `kubectl proxy --help` for more options.

@@ -13,7 +13,7 @@ This page shows how to use an HTTP proxy to access the Kubernetes API.
 * If you do not already have an application running in your cluster, start
  a Hello world application by entering this command:

-       kubectl run node-hello --image=gcr.io/google-samples/node-hello:1.0 --port=8080
+      kubectl run node-hello --image=gcr.io/google-samples/node-hello:1.0 --port=8080

 {% endcapture %}

@@ -100,11 +100,11 @@ If you haven't specified a name for your port, you don't have to specify *port_n

 #### Using web browsers to access services running on the cluster

-You may be able to put an apiserver proxy url into the address bar of a browser. However:
+You may be able to put an apiserver proxy URL into the address bar of a browser. However:

  - Web browsers cannot usually pass tokens, so you may need to use basic (password) auth.  Apiserver can be configured to accept basic auth,
    but your cluster may not be configured to accept basic auth.
-  - Some web apps may not work, particularly those with client side javascript that construct urls in a
+  - Some web apps may not work, particularly those with client side javascript that construct URLs in a
    way that is unaware of the proxy path prefix.

 {% endcapture %}
@@ -43,7 +43,7 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to
   This list also includes the name of the claims that are bound to each volume
   for easier identification of dynamically provisioned volumes.

-1. Chose one of your PersistentVolumes and change its reclaim policy:
+1. Choose one of your PersistentVolumes and change its reclaim policy:

       kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

@@ -0,0 +1,78 @@
+---
+assignees:
+- danwent
+title: Use Cilium for NetworkPolicy
+---
+
+{% capture overview %}
+This page shows how to use Cilium for NetworkPolicy.
+
+For background on Cilium, read the [Introduction to Cilium](http://cilium.readthedocs.io/en/latest/intro/).
+{% endcapture %}
+
+{% capture prerequisites %}
+
+{% include task-tutorial-prereqs.md %}
+
+{% endcapture %}
+
+{% capture steps %}
+## Deploying Cilium on Minikube for Basic Testing
+
+To get familiar with Cilium easily you can follow the
+[Cilium Kubernetes Getting Started Guide](http://www.cilium.io/try)
+to perform a basic DaemonSet installation of Cilium in minikube.
+
+Installation in a minikube setup uses a simple ''all-in-one'' YAML
+file that includes DaemonSet configurations for Cilium and a key-value store
+(consul) as well as appropriate RBAC settings:
+
+```shell
+$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/master/examples/minikube/cilium-ds.yaml
+clusterrole "cilium" created
+serviceaccount "cilium" created
+clusterrolebinding "cilium" created
+daemonset "cilium-consul" created
+daemonset "cilium" created
+```
+
+The remainder of the Getting Started Guide explains how to enforce both L3/L4 (i.e., IP address + port) security
+policies, as well as L7 (e.g., HTTP) security policies using an example application.
+
+## Deploying Cilium for Production Use
+
+For detailed instructions around deploying Cilium for production, see:
+[Cilium Administrator Guide](http://cilium.readthedocs.io/en/latest/admin/) This
+documentation includes detailed requirements, instructions and example production DaemonSet files.
+
+{% endcapture %}
+
+{% capture discussion %}
+##  Understanding Cilium components
+
+Deploying a cluster with Cilium adds Pods to the `kube-system` namespace.  To see this list of Pods run:
+
+```shell
+kubectl get pods --namespace=kube-system
+```
+
+You'll see a list of Pods similar to this:
+
+```console
+NAME            DESIRED   CURRENT   READY     NODE-SELECTOR   AGE
+cilium          1         1         1         <none>          2m
+...
+```
+
+There are two main components to be aware of:
+
+- One `cilium` Pod runs on each node in your cluster and enforces network policy on the traffic to/from Pods on that node using Linux BPF.
+- For production deployments, Cilium should leverage the key-value store cluster (e.g., etcd) used by Kubernetes, which typically runs on the Kubernetes master nodes.   The [Cilium Administrator Guide](http://cilium.readthedocs.io/en/latest/admin/) includes an example DaemonSet which can be customized to point to this key-value store cluster.   The simple ''all-in-one'' DaemonSet for minikube requires no such configuration because it automatically deploys a `cilium-consul` Pod to provide a key-value store.
+
+{% endcapture %}
+
+{% capture whatsnext %}
+Once your cluster is running, you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy with Cilium.  Have fun, and if you have questions, contact us using the [Cilium Slack Channel](https://cilium.herokuapp.com/).
+{% endcapture %}
+
+{% include templates/task.md %}
@@ -194,7 +194,7 @@ If the majority of etcd members have permanently failed, the etcd cluster is con

 The upgrade procedure described in this document assumes that either:

-1. The etcd cluster has only a single node
+1. The etcd cluster has only a single node.
 2. The etcd cluster has multiple nodes.

   In this case, the upgrade procedure requires shutting down the
@@ -243,7 +243,7 @@ kubectl delete namespace constraints-cpu-example

 * [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)

-* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
+* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)

 * [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)

@@ -5,13 +5,14 @@ approvers:
 title: Declare Network Policy
 ---
 {% capture overview %}
-This document helps you get started using using the Kubernetes [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) to declare network policies that govern how pods communicate with each other.
+This document helps you get started using the Kubernetes [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) to declare network policies that govern how pods communicate with each other.
 {% endcapture %}

 {% capture prerequisites %}
 You'll need to have a Kubernetes cluster in place, with network policy support. There are a number of network providers that support NetworkPolicy, including:

 * [Calico](/docs/tasks/configure-pod-container/calico-network-policy/)
+* [Cilium](/docs/tasks/configure-pod-container/cilium-network-policy/)
 * [Romana](/docs/tasks/configure-pod-container/romana-network-policy/)
 * [Weave Net](/docs/tasks/configure-pod-container/weave-network-policy/)

@@ -93,7 +93,7 @@ routed according to the following flow:

 ## ConfigMap options

-Options for the kube-dns `kube-system:kube-dns` ConfigMap
+Options for the kube-dns `kube-system:kube-dns` ConfigMap:

 | Field | Format | Description |
 | ----- | ------ | ----------- |
@@ -107,7 +107,7 @@ Options for the kube-dns `kube-system:kube-dns` ConfigMap
 In this example, the user has a Consul DNS service discovery system that they wish to
 integrate with kube-dns. The consul domain server is located at 10.150.0.1, and
 all consul names have the suffix “.consul.local”.  To configure Kubernetes, the
-cluster administrator simply creates a ConfigMap object as shown below.  
+cluster administrator simply creates a ConfigMap object as shown below.

 ```yaml
 apiVersion: v1
@@ -83,7 +83,7 @@ is the first provider, the first key is used for encryption.

 ## Encrypting your data

-Create a new encryption config file
+Create a new encryption config file:

 ```yaml
 kind: EncryptionConfig
@@ -107,9 +107,9 @@ To create a new secret perform the following steps:
    head -c 32 /dev/urandom | base64
    ```

-2. Place that value in the secret field.  
-3. Set the `--experimental-encryption-provider-config` flag on the `kube-apiserver` to point to the location of the config file 
-4. Restart your API server. 
+2. Place that value in the secret field.
+3. Set the `--experimental-encryption-provider-config` flag on the `kube-apiserver` to point to the location of the config file.
+4. Restart your API server.

 **IMPORTANT:** Your config file contains keys that can decrypt content in etcd, so you must properly restrict permissions on your masters so only the user who runs the kube-apiserver can read it.

@@ -168,7 +168,7 @@ the presence of a highly available deployment where multiple `kube-apiserver` pr
 5. Run `kubectl get secrets -o json | kubectl replace -f -` to encrypt all existing secrets with the new key
 6. Remove the old decryption key from the config after you back up etcd with the new key in use and update all secrets

-With a single `kube-apiserver`, step 2 may be skipped
+With a single `kube-apiserver`, step 2 may be skipped.


 ## Decrypting all data
@@ -7,7 +7,7 @@ This page shows how to configure and enable the ip-masq-agent.
 {% endcapture %}

 {% capture prerequisites %}
-Kubernetes 1.7
+
 {% include task-tutorial-prereqs.md %}

 {% endcapture %}
@@ -195,7 +195,7 @@ resources:
 ```

 Because your Container did not specify its own memory request and limit, it was given the
-[default memory request and limit](/docs/tasks/administer-cluster/default-memory-request-limit/)
+[default memory request and limit](/docs/tasks/administer-cluster/memory-default-namespace/)
 from the LimitRange.

 At this point, your Container might be running or it might not be running. Recall that a prerequisite
@@ -245,7 +245,7 @@ kubectl delete namespace constraints-mem-example

 * [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)

-* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
+* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)

 * [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/)

@@ -166,7 +166,7 @@ it can be allowed to run in a namespace that is restricted by a quota.

 ### For cluster administrators

-* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
+* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)

 * [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)

@@ -205,7 +205,7 @@ $ kubectl config current-context
 lithe-cocoa-92103_kubernetes
 ```

-The next step is to define a context for the kubectl client to work in each namespace. The value of "cluster" and "user" fields are copied from the current context.
+The next step is to define a context for the kubectl client to work in each namespace. The values of "cluster" and "user" fields are copied from the current context.

 ```shell
 $ kubectl config set-context dev --namespace=development --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes
@@ -205,7 +205,7 @@ it will begin evicting pods.

 The `kubelet` ranks pods for eviction as follows:

-* by their quality of service
+* by their quality of service.
 * by the consumption of the starved compute resource relative to the pods scheduling request.

 As a result, pod eviction occurs in the following order:
@@ -147,7 +147,7 @@ kubectl delete namespace quota-object-example

 * [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)

-* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
+* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)

 * [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)

@@ -152,7 +152,7 @@ kubectl delete namespace quota-mem-cpu-example

 * [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)

-* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
+* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)

 * [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)

@@ -113,7 +113,7 @@ kubectl delete namespace quota-pod-example

 * [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)

-* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
+* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)

 * [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)

@@ -16,8 +16,8 @@ In future Kubernetes releases, cloud vendors should link code that satisfies the

 To build cloud-controller-manager for your cloud, follow these steps:

-* Write a cloudprovider that satisfies the [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go).
-* Link the cloudprovider to cloud-controller-manager
+1. Write a cloudprovider that satisfies the [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go).
+2. Link the cloudprovider to cloud-controller-manager.

 The methods in [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go) are self-explanatory. All of the
 [existing providers](https://git.k8s.io/kubernetes/pkg/cloudprovider/providers) satisfy this interface. If your cloud is already a part
@@ -34,7 +34,7 @@ You can use `kubectl drain` to safely evict all of your pods from a
 node before you perform maintenance on the node (e.g. kernel upgrade,
 hardware maintenance, etc.). Safe evictions allow the pod's containers
 to
-[gracefully terminate](/docs/user-guide/production-pods.md#lifecycle-hooks-and-termination-notice) and
+[gracefully terminate](/docs/tasks/#lifecycle-hooks-and-termination-notice) and
 will respect the `PodDisruptionBudgets` you have specified.

 **Note:** By default `kubectl drain` will ignore certain system pods on the node
@@ -107,7 +107,7 @@ policy.

 The [network policies](/docs/tasks/administer-cluster/declare-network-policy/) for a namespace 
 allows application authors to restrict which pods in other namespaces may access pods and ports 
-within their namespace. Many of the supported [Kubernetes networking providers](/docs/concepts/cluster-administration/networking/)
+within their namespaces. Many of the supported [Kubernetes networking providers](/docs/concepts/cluster-administration/networking/)
 now respect network policy.

 Quota and limit ranges can also be used to control whether users may request node ports or
@@ -94,7 +94,7 @@ $ export KUBECONFIG=/path/to/standalone/.kube/config

 * The ca_file, key_file, and cert_file referenced above are generated on the
 kube master at cluster turnup. They can be found on the master under
-`/srv/kubernetes`. Bearer token/basic auth are also generated on the kube master.
+`/srv/kubernetes`. Bearer token/basic auth is also generated on the kube master.

 For more details on `kubeconfig` see [Authenticating Across Clusters with kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/),
 and/or run `kubectl config -h`.
@@ -84,7 +84,6 @@ If we look at our Kubernetes API server (running on host `my-master`), we see th
 [joe@my-master ~] $ kubectl get pods
 NAME                       READY     STATUS    RESTARTS   AGE
 static-web-my-node1        1/1       Running   0          2m
-
 ```

 Labels from the static pod are propagated into the mirror-pod and can be used as usual for filtering.
@@ -97,7 +96,6 @@ pods/static-web-my-node1
 [joe@my-master ~] $ kubectl get pods
 NAME                       READY     STATUS    RESTARTS   AGE
 static-web-my-node1        1/1       Running   0          12s
-
 ```

 Back to our `my-node1` host, we can try to stop the container manually and see, that kubelet automatically restarts it in a while:
@@ -78,7 +78,7 @@ kubectl --context=rivendell label cluster gondor key1=value1 key2=value2

 Starting in Kubernetes 1.7, there is alpha support for directing objects across the federated clusters with the annotation `federation.alpha.kubernetes.io/cluster-selector`. The *ClusterSelector* is conceptually similar to `nodeSelector`, but instead of selecting against labels on nodes, it selects against labels on federated clusters.

-The annotation value must be json formatted and must be parsable into the [ClusterSelector API type](/docs/reference/federation/v1beta1/definitions/#_v1beta1_clusterselector). For example: `[{"key": "load", "operator": "Lt", "values": ["10"]}]`. Content that doesn't parse correctly will throw an error and prevent distribution of the object to any federated clusters. Objects of type Configmap, Secret, Daemonset, Service and Ingress are included in the alpha implementation.
+The annotation value must be JSON formatted and must be parsable into the [ClusterSelector API type](/docs/reference/federation/v1beta1/definitions/#_v1beta1_clusterselector). For example: `[{"key": "load", "operator": "Lt", "values": ["10"]}]`. Content that doesn't parse correctly will throw an error and prevent distribution of the object to any federated clusters. Objects of type ConfigMap, Secret, Daemonset, Service and Ingress are included in the alpha implementation.

 Here is an example ClusterSelector annotation, which will only select clusters WITH the label `pci=true` and WITHOUT the label `environment=test`:

@@ -102,7 +102,7 @@ Currently, only integers are supported with `Gt` or `Lt`.

 ## Clusters API reference

-The full clusters API reference is currently in `federation/v1beta1` and more details can be found in details in the
+The full clusters API reference is currently in `federation/v1beta1` and more details can be found in the
 [Federation API reference page](/docs/reference/federation/).

 {% endcapture %}
@@ -78,7 +78,7 @@ You can create a federated ingress in any of the usual ways, for example, using
 ``` shell
 kubectl --context=federation-cluster create -f myingress.yaml
 ```
-For example ingress YAML configurations, see the [Ingress User Guide](/docs/concepts/services-networking/ingress/)
+For example ingress YAML configurations, see the [Ingress User Guide](/docs/concepts/services-networking/ingress/).
 The '--context=federation-cluster' flag tells kubectl to submit the
 request to the Federation API endpoint, with the appropriate
 credentials. If you have not yet configured such a context, see the
@@ -183,7 +183,7 @@ services need to be identical.  If you're using a federated service
 this is easy to do.  Simply pick a node port that is not already
 being used in any of your clusters, and add that to the spec of your
 federated service.  If you do not specify a node port for your
-federated service, each cluster will choose it's own node port for
+federated service, each cluster will choose its own node port for
 its cluster-local shard of the service, and these will probably end
 up being different, which is not what you want.

@@ -253,7 +253,7 @@ how to bring up a cluster federation correctly (or have your cluster administrat

 Check that:

-1. Your clusters are correctly registered in the Cluster Federation API (`kubectl describe clusters`)
+1. Your clusters are correctly registered in the Cluster Federation API. (`kubectl describe clusters`)
 2. Your clusters are all 'Active'.  This means that the cluster
   Federation system was able to connect and authenticate against the
   clusters' endpoints.  If not, consult the event logs of the federation-controller-manager pod to ascertain what the failure might be. (`kubectl --namespace=federation logs $(kubectl get pods --namespace=federation -l module=federation-controller-manager -o name`)
@@ -276,7 +276,7 @@ Check that:
 2. The load balancer controllers in each of your clusters are of the
   correct type ("GLBC") and have been correctly reconfigured by the
   federation control plane to share a global GCE load balancer (this
-   should happen automatically).  If they of the correct type, and
+   should happen automatically).  If they are of the correct type, and
   have been correctly reconfigured, the UID data item in the GLBC
   configmap in each cluster will be identical across all clusters.
   See
@@ -291,9 +291,9 @@ Check that:
    your GLBC will interfere with the behavior of your federated
    ingresses created after the reconfiguration (see
    [the GLBC docs](https://github.com/kubernetes/ingress/blob/7dcb4ae17d5def23d3e9c878f3146ac6df61b09d/controllers/gce/README.md)
-    for further information. To remedy this,
+    for further information). To remedy this,
    delete any ingresses created before the cluster joined the
-    federation (and had it's GLBC reconfigured), and recreate them if
+    federation (and had its GLBC reconfigured), and recreate them if
    necessary.
 {% endcapture %}

@@ -56,7 +56,7 @@ federation ReplicaSet.

 ### Spreading Replicas in Underlying Clusters

-By default, replicas are spread equally in all the underlying clusters. For ex:
+By default, replicas are spread equally in all the underlying clusters. For example:
 if you have 3 registered clusters and you create a federated ReplicaSet with
 `spec.replicas = 9`, then each ReplicaSet in the 3 clusters will have
 `spec.replicas=3`.
@@ -119,10 +119,11 @@ Recall that by setting `-cpu "2"`, you configured the Container to attempt to us
 But the Container is only being allowed to use about 1 cpu. The Container's CPU use is being
 throttled, because the Container is attempting to use more CPU resources than its limit.

-Note: There's another possible explanation for the CPU throttling. The Node might not have
+**Note:** There's another possible explanation for the CPU throttling. The Node might not have
 enough CPU resources available. Recall that the prerequisites for this exercise require that each of
 your Nodes has at least 1 cpu. If your Container is running on a Node that has only 1 cpu, the Container
 cannot use more than 1 cpu regardless of the CPU limit specified for the Container.
+{: .note}

 ## CPU units

@@ -255,7 +256,7 @@ kubectl delete namespace cpu-example

 * [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)

-* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
+* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)

 * [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)

@@ -211,7 +211,6 @@ The output shows that the Container starts and fails repeatedly:
 ```
 ... Normal  Created   Created container with id 66a3a20aa7980e61be4922780bf9d24d1a1d8b7395c09861225b0eba1b1f8511
 ... Warning BackOff   Back-off restarting failed container
-
 ```

 View detailed information about your cluster's Nodes:
@@ -223,7 +223,8 @@ metadata:
 ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable.
 The ConfigMap API resource stores configuration data as key-value pairs. The data can be consumed in pods or provide the configurations for system components such as controllers. ConfigMap is similar to [Secrets](/docs/concepts/configuration/secret/), but provides a means of working with strings that don't contain sensitive information. Users and system components alike can store configuration data in ConfigMap.

-Note: ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume.
+**Note:** ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume.
+{: .note}

 The ConfigMap's `data` field contains the configuration data. As shown in the example below, this can be simple -- like individual properties defined using `--from-literal` -- or complex -- like configuration files or JSON blobs defined using `--from-file`.

@@ -180,7 +180,7 @@ can’t it is considered a failure.

 {% include code.html language="yaml" file="tcp-liveness-readiness.yaml" ghlink="/docs/tasks/configure-pod-container/tcp-liveness-readiness.yaml" %}

-As you can see, configuration for a TCP check is quite similar to a HTTP check.
+As you can see, configuration for a TCP check is quite similar to an HTTP check.
 This example uses both readiness and liveness probes. The kubelet will send the
 first readiness probe 5 seconds after the container starts. This will attempt to
 connect to the `goproxy` container on port 8080. If the probe succeeds, the pod
@@ -188,6 +188,7 @@ each Container.

 **Note**: When a Pod consumes a PersistentVolume, the GIDs associated with the
 PersistentVolume are not present on the Pod resource itself.
+{: .note}

 {% endcapture %}

@@ -108,7 +108,8 @@ This page provides a series of usage examples demonstrating how to configure Pod

 ## Configure all key-value pairs in a ConfigMap as Pod environment variables 

-Note: This functionality is available to users running Kubernetes v1.6 and later.
+   **Note:** This functionality is available to users running Kubernetes v1.6 and later.
+   {: .note}

 1. Create a ConfigMap containing multiple key-value pairs. 

@@ -299,7 +300,10 @@ When a ConfigMap already being consumed in a volume is updated, projected keys a

 1. Kubelet doesn't support the use of ConfigMaps for pods not found on the API server. 
   This includes every pod created using kubectl or indirectly via a replication controller. 
-   It does not include pods created via the Kubelet's `--manifest-url` flag, `--config` flag, or the Kubelet REST API. (Note: these are not commonly-used ways to create pods.)
+   It does not include pods created via the Kubelet's `--manifest-url` flag, `--config` flag, or the Kubelet REST API. 
+   
+   **Note:** These are not commonly-used ways to create pods.
+   {: .note}
   
 {% endcapture %}

@@ -34,7 +34,7 @@ shared Volume at `/work-dir`, and the application container mounts the shared
 Volume at `/usr/share/nginx/html`. The init container runs the following command
 and then terminates:

-     wget -O /work-dir/index.html http://kubernetes.io
+    wget -O /work-dir/index.html http://kubernetes.io

 Notice that the init container writes the `index.html` file in the root directory
 of the nginx server.
@@ -43,8 +43,8 @@ the Pod:

    The output looks like this:

-        NAME                    READY     STATUS    RESTARTS   AGE
-        test-projected-volume   1/1       Running   0          14s
+       NAME                    READY     STATUS    RESTARTS   AGE
+       test-projected-volume   1/1       Running   0          14s

 1. In another terminal, get a shell to the running Container:

@@ -11,10 +11,11 @@ A service account provides an identity for processes that run in a Pod.
 *This is a user introduction to Service Accounts.  See also the
 [Cluster Admin Guide to Service Accounts](/docs/admin/service-accounts-admin).*

-*Note: This document describes how service accounts behave in a cluster set up
+**Note:** This document describes how service accounts behave in a cluster set up
 as recommended by the Kubernetes project.  Your cluster administrator may have
 customized the behavior in your cluster, in which case this documentation may
-not apply.*
+not apply.
+{: .note}

 When you (a human) access the cluster (e.g. using `kubectl`), you are
 authenticated by the apiserver as a particular User Account (currently this is
@@ -159,7 +160,8 @@ token: ...
 namespace: 7 bytes
 ```

-> Note that the content of `token` is elided here.
+**Note:** The content of `token` is elided here.
+{: .note}

 ## Add ImagePullSecrets to a service account

@@ -176,10 +178,10 @@ Next, modify the default service account for the namespace to use this secret as

 ```shell
 kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'
-
 ```

 Interactive version requiring manual edit:
+
 ```shell
 $ kubectl get serviceaccounts default -o yaml > ./sa.yaml
 $ cat sa.yaml
@@ -81,10 +81,11 @@ spec:
  qosClass: Guaranteed
 ```

-**Note**: If a Container specifies its own memory limit, but does not specify a memory request, Kubernetes
+**Note:** If a Container specifies its own memory limit, but does not specify a memory request, Kubernetes
 automatically assigns a memory request that matches the limit. Similarly, if a Container specifies its own
 cpu limit, but does not specify a cpu request, Kubernetes automatically assigns a cpu request that matches
 the limit.
+{: .note}

 Delete your Pod:

@@ -246,7 +247,7 @@ kubectl delete namespace qos-example

 * [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)

-* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
+* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)

 * [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)

@@ -294,9 +294,8 @@ bits 12 and 25 are set. Bit 12 is `CAP_NET_ADMIN`, and bit 25 is `CAP_SYS_TIME`.
 See [capability.h](https://github.com/torvalds/linux/blob/master/include/uapi/linux/capability.h)
 for definitions of the capability constants.

-**Note**: Linux capability constants have the form `CAP_XXX`. But when you list capabilities
-in your Container manifest, you must omit the `CAP_` portion of the constant. For example,
-to add `CAP_SYS_TIME`, include `SYS_TIME` in your list of capabilities.
+**Note:** Linux capability constants have the form `CAP_XXX`. But when you list capabilities in your Container manifest, you must omit the `CAP_` portion of the constant. For example, to add `CAP_SYS_TIME`, include `SYS_TIME` in your list of capabilities.
+{: .note}

 ## Assign SELinux labels to a Container

@@ -313,8 +312,8 @@ securityContext:
    level: "s0:c123,c456"
 ```

-**Note**: To assign SELinux labels, the SELinux security module must be loaded
-on the host operating system.
+**Note:** To assign SELinux labels, the SELinux security module must be loaded on the host operating system.
+{: .note}

 ## Discussion

@@ -333,9 +332,8 @@ need to set the `level` section. This sets the
 [Multi-Category Security (MCS)](https://selinuxproject.org/page/NB_MLS)
 label given to all Containers in the Pod as well as the Volumes.

-**Warning**: After you specify an MCS label for a Pod, all Pods with the same
-label will able to access the Volume. So if you need inter-Pod
-protection, you must ensure each Pod is assigned a unique MCS label.
+**Warning:** After you specify an MCS label for a Pod, all Pods with the same label can access the Volume. If you need inter-Pod protection, you must assign a unique MCS label to each Pod.
+{: .warning}

 {% endcapture %}

@@ -48,7 +48,7 @@ for configuring where and how audit logs are handled:
 - `audit-log-path` - enables the audit log pointing to a file where the requests are being logged to, '-' means standard out.
 - `audit-log-maxage` - specifies maximum number of days to retain old audit log files based on the timestamp encoded in their filename.
 - `audit-log-maxbackup` - specifies maximum number of old audit log files to retain.
- `audit-log-maxsize` - specifies maximum size in megabytes of the audit log file before it gets rotated. Defaults to 100MB
+- `audit-log-maxsize` - specifies maximum size in megabytes of the audit log file before it gets rotated. Defaults to 100MB.

 If an audit log file already exists, Kubernetes appends new audit logs to that file.
 Otherwise, Kubernetes creates an audit log file at the location you specified in
@@ -80,13 +80,13 @@ webhooks.
 The structure of audit events changes when enabling the `AdvancedAuditing` feature
 flag. This includes some cleanups, such as the `method` reflecting the verb evaluated
 by the [authorization layer](/docs/admin/authorization/) instead of the [HTTP verb](/docs/admin/authorization/#determine-the-request-verb).
-Also, instead of always generating two events per request, events are recorded with an associated "stage."
+Also, instead of always generating two events per request, events are recorded with an associated "stage".
 The known stages are:

 - `RequestReceived` - The stage for events generated as soon as the audit handler receives the request.
 - `ResponseStarted` - Once the response headers are sent, but before the response body is sent. This stage is only generated for long-running requests (e.g. watch).
 - `ResponseComplete` - Once the response body has been completed.
- `Panic` - Events generated when a panic occured.
+- `Panic` - Events generated when a panic occurred.

 ### Audit Policy

@@ -107,7 +107,7 @@ The policy file holds rules that determine the level of an event. Known audit le
 - `Request` - log event metadata and request body but not response body.
 - `RequestResponse` - log event metadata, request and response bodies.

-When an event is processed it's compared against the list of rules in order.
+When an event is processed, it's compared against the list of rules in order.
 The first matching rule sets the audit level of the event. The audit policy is
 defined by the [`audit.k8s.io` API group][audit-api].

@@ -102,7 +102,7 @@ Events:
  53s		53s		1	{kubelet kubernetes-node-wul5}	spec.containers{nginx}	Normal		Started		Started container with docker id 90315cc9f513
 ```

-Here you can see configuration information about the container(s) and Pod (labels, resource requirements, etc.), as well as status information about the container(s) and Pod (state, readiness, restart count, events, etc.)
+Here you can see configuration information about the container(s) and Pod (labels, resource requirements, etc.), as well as status information about the container(s) and Pod (state, readiness, restart count, events, etc.).

 The container state is one of Waiting, Running, or Terminated. Depending on the state, additional information will be provided -- here you can see that for a container in Running state, the system tells you when the container started.

@@ -7,14 +7,14 @@ title: Troubleshoot Applications

 This guide is to help users debug applications that are deployed into Kubernetes and not behaving correctly.
 This is *not* a guide for people who want to debug their cluster.  For that you should check out
-[this guide](/docs/admin/cluster-troubleshooting)
+[this guide](/docs/admin/cluster-troubleshooting).

 * TOC
 {:toc}

 ## FAQ

-Users are highly encouraged to check out our [FAQ](https://github.com/kubernetes/kubernetes/wiki/User-FAQ)
+Users are highly encouraged to check out our [FAQ](https://github.com/kubernetes/kubernetes/wiki/User-FAQ).

 ## Diagnosing the problem

@@ -57,7 +57,7 @@ scheduled.  In most cases, `hostPort` is unnecessary, try using a Service object
 If a Pod is stuck in the `Waiting` state, then it has been scheduled to a worker node, but it can't run on that machine.
 Again, the information from `kubectl describe ...` should be informative.  The most common cause of `Waiting` pods is a failure to pull the image.  There are three things to check:

-* Make sure that you have the name of the image correct
+* Make sure that you have the name of the image correct.
 * Have you pushed the image to the repository?
 * Run a manual `docker pull <image>` on your machine to see if the image can be pulled.

@@ -184,8 +184,8 @@ in the endpoints list, it's likely that the proxy can't contact your pods.
 There are three things to
 check:

-   * Are your pods working correctly?  Look for restart count, and [debug pods](#debugging-pods)
-   * Can you connect to your pods directly?  Get the IP address for the Pod, and try to connect directly to that IP
+   * Are your pods working correctly?  Look for restart count, and [debug pods](#debugging-pods).
+   * Can you connect to your pods directly?  Get the IP address for the Pod, and try to connect directly to that IP.
   * Is your application serving on the port that you configured?  Kubernetes doesn't do port remapping, so if your application serves on 8080, the `containerPort` field needs to be 8080.

 #### More information
@@ -193,7 +193,7 @@ will have log names `container_1` and `container_2` respectively.

 System components have resource type `compute`, which is named
 `GCE VM Instance` in the interface. Log names for system components are fixed.
-For a GKE node, every log entry from a system component has one the following
+For a GKE node, every log entry from a system component has one of the following
 log names:

 * docker
@@ -234,9 +234,9 @@ the Stackdriver [Exporting Logs page](https://cloud.google.com/logging/docs/expo

 ## Configuring Stackdriver Logging Agents

-Sometimes the default installation of Stackdriver Logging may not suite your needs, for example:
+Sometimes the default installation of Stackdriver Logging may not suit your needs, for example:

-* You may want to add more resources because default performance doesn't suite your needs.
+* You may want to add more resources because default performance doesn't suit your needs.
 * You may want to introduce additional parsing to extract more metadata from your log messages,
 like severity or source code reference.
 * You may want to send logs not only to Stackdriver or send it to Stackdriver only partially.
@@ -16,7 +16,7 @@ Let's look at some of the other components in more detail.

 ### cAdvisor

-cAdvisor is an open source container resource usage and performance analysis agent. It is purpose-built for containers and supports Docker containers natively. In Kubernetes, cadvisor is integrated into the Kubelet binary. cAdvisor auto-discovers all containers in the machine and collects CPU, memory, filesystem, and network usage statistics. cAdvisor also provides the overall machine usage by analyzing the 'root'? container on the machine.
+cAdvisor is an open source container resource usage and performance analysis agent. It is purpose-built for containers and supports Docker containers natively. In Kubernetes, cAdvisor is integrated into the Kubelet binary. cAdvisor auto-discovers all containers in the machine and collects CPU, memory, filesystem, and network usage statistics. cAdvisor also provides the overall machine usage by analyzing the 'root' container on the machine.

 On most Kubernetes clusters, cAdvisor exposes a simple UI for on-machine containers on port 4194. Here is a snapshot of part of cAdvisor's UI that shows the overall machine usage:

@@ -227,8 +227,8 @@ due to caching by intermediate DNS servers.

 1. Notice that there is a normal ('A') record for each service shard that has at least one healthy backend endpoint. For example, in us-central1-a, 104.197.247.191 is the external IP address of the service shard in that zone, and in asia-east1-a the address is 130.211.56.221.
 2. Similarly, there are regional 'A' records which include all healthy shards in that region. For example, 'us-central1'.  These regional records are useful for clients which do not have a particular zone preference, and as a building block for the automated locality and failover mechanism described below.
-2. For zones where there are currently no healthy backend endpoints, a CNAME ('Canonical Name') record is used to alias (automatically redirect) those queries to the next closest healthy zone.  In the example, the service shard in us-central1-f currently has no healthy backend endpoints (i.e. Pods), so a CNAME record has been created to automatically redirect queries to other shards in that region (us-central1 in this case).
-3. Similarly, if no healthy shards exist in the enclosing region, the search progresses further afield. In the europe-west1-d availability zone, there are no healthy backends, so queries are redirected to the broader europe-west1 region (which also has no healthy backends), and onward to the global set of healthy addresses (' nginx.mynamespace.myfederation.svc.example.com.')
+3. For zones where there are currently no healthy backend endpoints, a CNAME ('Canonical Name') record is used to alias (automatically redirect) those queries to the next closest healthy zone.  In the example, the service shard in us-central1-f currently has no healthy backend endpoints (i.e. Pods), so a CNAME record has been created to automatically redirect queries to other shards in that region (us-central1 in this case).
+4. Similarly, if no healthy shards exist in the enclosing region, the search progresses further afield. In the europe-west1-d availability zone, there are no healthy backends, so queries are redirected to the broader europe-west1 region (which also has no healthy backends), and onward to the global set of healthy addresses (' nginx.mynamespace.myfederation.svc.example.com.').

 The above set of DNS records is automatically kept in sync with the
 current state of health of all service shards globally by the
@@ -355,7 +355,7 @@ how to bring up a cluster federation correctly (or have your cluster administrat
 #### I can create a federated service successfully against the cluster federation API, but no matching services are created in my underlying clusters
 Check that:

-1. Your clusters are correctly registered in the Cluster Federation API (`kubectl describe clusters`)
+1. Your clusters are correctly registered in the Cluster Federation API (`kubectl describe clusters`).
 2. Your clusters are all 'Active'.  This means that the cluster Federation system was able to connect and authenticate against the clusters' endpoints.  If not, consult the logs of the federation-controller-manager pod to ascertain what the failure might be. (`kubectl --namespace=federation logs $(kubectl get pods --namespace=federation -l module=federation-controller-manager -o name`)
 3. That the login credentials provided to the Cluster Federation API for the clusters have the correct authorization and quota to create services in the relevant namespace in the clusters.  Again you should see associated error messages providing more detail in the above log file if this is not the case.
 4. Whether any other error is preventing the service creation operation from succeeding (look for `service-controller` errors in the output of `kubectl logs federation-controller-manager --namespace federation`).
@@ -365,7 +365,7 @@ Check that:

 1. Your federation name, DNS provider, DNS domain name are configured correctly.  Consult the [federation admin guide](/docs/admin/federation/) or  [tutorial](https://github.com/kelseyhightower/kubernetes-cluster-federation) to learn
 how to configure your Cluster Federation system's DNS provider (or have your cluster administrator do this for you).
-2. Confirm that the Cluster Federation's service-controller is successfully connecting to and authenticating against your selected DNS provider (look for `service-controller` errors or successes in the output of `kubectl logs federation-controller-manager --namespace federation`)
+2. Confirm that the Cluster Federation's service-controller is successfully connecting to and authenticating against your selected DNS provider (look for `service-controller` errors or successes in the output of `kubectl logs federation-controller-manager --namespace federation`).
 3. Confirm that the Cluster Federation's service-controller is successfully creating DNS records in your DNS provider (or outputting errors in its logs explaining in more detail what's failing).

 #### Matching DNS records are created in my DNS provider, but clients are unable to resolve against those names
@@ -8,10 +8,10 @@ title: Set up Cluster Federation with Kubefed
 {:toc}

 Kubernetes version 1.5 and above includes a new command line tool called
-`kubefed` to help you administrate your federated clusters.
-`kubefed` helps you to deploy a new Kubernetes cluster federation
-control plane, and to add clusters to or remove clusters from an
-existing federation control plane.
+[`kubefed`](/docs/admin/kubefed/) to help you administrate your federated
+clusters. `kubefed` helps you to deploy a new Kubernetes cluster federation
+control plane, and to add clusters to or remove clusters from an existing
+federation control plane.

 This guide explains how to administer a Kubernetes Cluster Federation
 using `kubefed`.
@@ -69,7 +69,7 @@ kubefed is available as a [snap](https://snapcraft.io/) application.

       sudo snap install kubefed --classic

-2. Run `kubefed version` to verify that the version you've installed is sufficiently up-to-date.
+2. Run [`kubefed version`](/docs/admin/kubefed_version/) to verify that the version you've installed is sufficiently up-to-date.

 ## Choosing a host cluster.

@@ -101,8 +101,8 @@ control plane.
 ## Deploying a federation control plane

 To deploy a federation control plane on your host cluster, run
-`kubefed init` command. When you use `kubefed init`, you must provide
-the following:
+[`kubefed init`](/docs/admin/kubefed_init/) command. When you use
+`kubefed init`, you must provide the following:

 * Federation name
 * `--host-cluster-context`, the `kubeconfig` context for the host cluster
@@ -262,7 +262,7 @@ kubefed init fellowship \
 [service](/docs/concepts/services-networking/service/) on the host cluster. By default,
 this service is exposed as a
 [load balanced service](/docs/user-guide/services/#type-loadbalancer).
-Most on-premises and bare-metal enviroments, and some cloud
+Most on-premises and bare-metal environments, and some cloud
 environments lack support for load balanced services. `kubefed init`
 allows exposing the federation API server as a
 [`NodePort` service](/docs/user-guide/services/#type-nodeport) on
@@ -367,13 +367,14 @@ kubefed init fellowship \
 ```

 For more information see
-[Setting up CoreDNS as DNS provider for Cluster Federation](/docs/tutorials/federation/set-up-coredns-provider-federation/)
+[Setting up CoreDNS as DNS provider for Cluster Federation](/docs/tutorials/federation/set-up-coredns-provider-federation/).

 ## Adding a cluster to a federation

 Once you've deployed a federation control plane, you'll need to make
 that control plane aware of the clusters it should manage. You can add
-a cluster to your federation by using the `kubefed join` command.
+a cluster to your federation by using the [`kubefed join`](/docs/admin/kubefed_join)
+command.

 To use `kubefed join`, you'll need to provide the name of the cluster
 you want to add to the federation, and the `--host-cluster-context`
@@ -463,11 +464,11 @@ commands.

 In all other cases, you must update `kube-dns` configuration manually
 as described in the
-[Updating KubeDNS section of the admin guide](/docs/admin/federation/)
+[Updating KubeDNS section of the admin guide](/docs/admin/federation/).

 ## Removing a cluster from a federation

-To remove a cluster from a federation, run the `kubefed unjoin`
+To remove a cluster from a federation, run the [`kubefed unjoin`](/docs/admin/kubefed_unjoin)
 command with the cluster name and the federation's
 `--host-cluster-context`:

@@ -13,7 +13,7 @@ DNS provider for Cluster Federation.
 {% capture objectives %}

 * Configure and deploy CoreDNS server
-* Bringup federation with CoreDNS as dns provider
+* Bring up federation with CoreDNS as dns provider
 * Setup CoreDNS server in nameserver lookup chain

 {% endcapture %}
@@ -77,8 +77,9 @@ the techniques available for defining environment variables, including
 and
 [Secrets](/docs/concepts/configuration/secret/).

-NOTE: The environment variable appears in parentheses, `"$(VAR)"`. This is
+**Note:** The environment variable appears in parentheses, `"$(VAR)"`. This is
 required for the variable to be expanded in the `command` or `args` field.
+{: .note}

 ## Run a command in a shell

@@ -51,7 +51,7 @@ Pod:

 1. In your shell, run the `printenv` command to list the environment variables.

-        root@envar-demo:/# printenv
+       root@envar-demo:/# printenv

    The output is similar to this:

@@ -41,6 +41,7 @@ username and password:

    **Note:** If you want to skip the Base64 encoding step, you can create a Secret
    by using the `kubectl create secret` command:
+    {: .note}

       kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb'

@@ -46,8 +46,9 @@ The first element specifies that the value of the Pod's
 The second element specifies that the value of the Pod's `annotations`
 field should be stored in a file named `annotations`.

-**Note**: The fields in this example are Pod fields. They are not
+**Note:** The fields in this example are Pod fields. They are not
 fields of the Container in the Pod.
+{: .note}

 Create the Pod:

@@ -204,8 +205,9 @@ DownwardAPIVolumeFiles.
 * The Pod's labels
 * The Pod's annotations

-**Note**: If CPU and memory limits are not specified for a Container, the
+**Note:** If CPU and memory limits are not specified for a Container, the
 Downward API defaults to the node allocatable value for CPU and memory.
+{: .note}

 ## Project keys to specific paths and file permissions

@@ -51,8 +51,9 @@ The first element in the array specifies that the `MY_NODE_NAME` environment
 variable gets its value from the Pod's `spec.nodeName` field. Similarly, the
 other environment variables get their names from Pod fields.

-**Note**: The fields in this example are Pod fields. They are not fields of the
+**Note:** The fields in this example are Pod fields. They are not fields of the
 Container in the Pod.
+{: .note}

 Create the Pod:

@@ -50,7 +50,7 @@ If you're not working from the source tree, you could also download [`redis-pod.
 Now let's fill the queue with some "tasks".  In our example, our tasks are just strings to be
 printed.

-Start a temporary interactive pod for running the Redis CLI
+Start a temporary interactive pod for running the Redis CLI.

 ```shell
 $ kubectl run -i --tty temp --image redis --command "/bin/sh"
@@ -16,7 +16,7 @@ This page shows how to perform a rollback on a DaemonSet.
 * The DaemonSet rollout history and DaemonSet rollback features are only
  supported in `kubectl` in Kubernetes version 1.7 or later.
 * Make sure you know how to [perform a rolling update on a
-  DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/)
+  DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/).

 {% endcapture %}

@@ -147,7 +147,7 @@ have revision 1 and 2 in the system, and roll back from revision 2 to revision
 ## Troubleshooting

 * See [troubleshooting DaemonSet rolling
-  update](/docs/tasks/manage-daemon/update-daemon-set/#troubleshooting)
+  update](/docs/tasks/manage-daemon/update-daemon-set/#troubleshooting).

 {% endcapture %}

@@ -13,7 +13,7 @@ This page describes how users can consume GPUs and the current limitations.

 {% capture prerequisites %}

-1. Kubernetes nodes have to be pre-installed with Nvidia drivers. Kubelet will not detect Nvidia GPUs otherwise. Try to re-install nvidia drivers if kubelet fails to expose Nvidia GPUs as part of Node Capacity.
+1. Kubernetes nodes have to be pre-installed with Nvidia drivers. Kubelet will not detect Nvidia GPUs otherwise. Try to re-install Nvidia drivers if kubelet fails to expose Nvidia GPUs as part of Node Capacity. After installing the driver, run `nvidia-docker-plugin` to confirm that all drivers have been loaded.
 2. A special **alpha** feature gate `Accelerators` has to be set to true across the system: `--feature-gates="Accelerators=true"`.
 3. Nodes must be using `docker engine` as the container runtime.

@@ -14,8 +14,8 @@ nodes.
 {% capture prerequisites %}
 * You are the owner of an application running on a Kubernetes cluster that requires
  high availability.
-* You should know how to deploy [Replicated Stateless Applications](/docs/tasks/run-application/run-stateless-application-deployment.md)
-  and/or [Replicated Stateful Applications](/docs/tasks/run-application/run-replicated-stateful-application.md).
+* You should know how to deploy [Replicated Stateless Applications](/docs/tasks/run-application/run-stateless-application-deployment/)
+  and/or [Replicated Stateful Applications](/docs/tasks/run-application/run-replicated-stateful-application/).
 * You should have read about [Pod Disruptions](/docs/concepts/workloads/pods/disruptions/).
 * You should confirm with your cluster owner or service provider that they respect
  Pod Disruption Budgets.
@@ -26,7 +26,7 @@ nodes.
 ## Protecting an Application with a PodDisruptionBudget

 1. Identify what application you want to protect with a PodDisruptionBudget (PDB).
-1. Think about how your application reacts to disruptions
+1. Think about how your application reacts to disruptions.
 1. Create a PDB definition as a YAML file.
 1. Create the PDB object from the YAML file.

@@ -57,22 +57,22 @@ described in [Arbitrary Controllers and Selectors](#arbitrary-controllers-and-se
 Decide how many instances can be down at the same time for a short period
 due to a voluntary disruption.

- Stateless frontends
+- Stateless frontends:
  - Concern: don't reduce serving capacity by more than 10%. 
    - Solution: use PDB with minAvailable 90% for example.
- Single-instance Stateful Application
+- Single-instance Stateful Application:
  - Concern: do not terminate this application without talking to me.
    - Possible Solution 1: Do not use a PDB and tolerate occasional downtime.
    - Possible Solution 2: Set PDB with maxUnavailable=0.  Have an understanding
      (outside of Kubernetes) that the cluster operator needs to consult you before
      termination.  When the cluster operator contacts you, prepare for downtime,
      and then delete the PDB to indicate readiness for disruption.  Recreate afterwards.
- Multiple-instance Stateful application such as Consul, ZooKeeper, or etcd  
+- Multiple-instance Stateful application such as Consul, ZooKeeper, or etcd:
  - Concern: Do not reduce number of instances below quorum, otherwise writes fail.
    - Possible Solution 1: set maxUnavailable to 1 (works with varying scale of application).
    - Possible Solution 2: set minAvailable to quorum-size (e.g. 3 when scale is 5).  (Allows more disruptions at once).
 - Restartable Batch Job:
-  - Concern: Job needs to complete in case of voluntary disruption
+  - Concern: Job needs to complete in case of voluntary disruption.
    - Possible solution: Do not create a PDB.  The Job controller will create a replacement pod.

 ## Specifying a PodDisruptionBudget
@@ -134,7 +134,7 @@ by making use of the `autoscaling/v2alpha1` API version.
 First, get the YAML of your HorizontalPodAutoscaler in the `autoscaling/v2alpha1` form:

 ```shell
-$ kubectl get hpa.autoscaling.v2alpha1 -o yaml > /tmp/hpa-v2.yaml
+$ kubectl get hpa.v2alpha1.autoscaling -o yaml > /tmp/hpa-v2.yaml
 ```

 Open the `/tmp/hpa-v2.yaml` file in an editor, and you should see YAML which looks like this:
@@ -294,7 +294,7 @@ Conditions:
  ----                  ------  ------                  -------
  AbleToScale           True    ReadyForNewScale        the last scale time was sufficiently old as to warrant a new scale
  ScalingActive         True    ValidMetricFound        the HPA was able to successfully calculate a replica count from pods metric http_requests
-  ScalingLimited        False   DesiredWithinRange      the desired replica count is within the acceptible range
+  ScalingLimited        False   DesiredWithinRange      the desired replica count is within the acceptable range
 Events:
 ```

@@ -4,7 +4,7 @@ metadata:
  name: mysql
 spec:
  ports:
-    - port: 3306
+  - port: 3306
  selector:
    app: mysql
  clusterIP: None
@@ -20,13 +20,13 @@ Here are a few methods to install kubectl.
 {% capture macos %}
 1. Download the latest release with the command:

-        curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl
+       curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl

    To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.

    For example, to download version {{page.fullversion}} on MacOS, type:

-        curl -LO https://storage.googleapis.com/kubernetes-release/release/{{page.fullversion}}/bin/darwin/amd64/kubectl
+       curl -LO https://storage.googleapis.com/kubernetes-release/release/{{page.fullversion}}/bin/darwin/amd64/kubectl

 2. Make the kubectl binary executable.

@@ -44,13 +44,13 @@ Here are a few methods to install kubectl.
 {% capture linux %}
 1. Download the latest release with the command:

-        curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
+       curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl

    To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.

    For example, to download version {{page.fullversion}} on Linux, type:

-        curl -LO https://storage.googleapis.com/kubernetes-release/release/{{page.fullversion}}/bin/linux/amd64/kubectl
+       curl -LO https://storage.googleapis.com/kubernetes-release/release/{{page.fullversion}}/bin/linux/amd64/kubectl

 2. Make the kubectl binary executable.

@@ -70,7 +70,7 @@ Here are a few methods to install kubectl.

    Or if you have `curl` installed, use this command:

-        curl -LO https://storage.googleapis.com/kubernetes-release/release/{{page.fullversion}}/bin/windows/amd64/kubectl.exe
+       curl -LO https://storage.googleapis.com/kubernetes-release/release/{{page.fullversion}}/bin/windows/amd64/kubectl.exe

    To find out the latest stable version (for example, for scripting), take a look at https://storage.googleapis.com/kubernetes-release/release/stable.txt

@@ -90,9 +90,9 @@ kubectl can be installed as part of the Google Cloud SDK.
 1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/).
 2. Run the following command to install `kubectl`:

-        gcloud components install kubectl
+       gcloud components install kubectl

-3. Run `kubectl version` to verify that the verison you've installed is sufficiently up-to-date.
+3. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.

 ## Install with snap on Ubuntu

@@ -100,31 +100,31 @@ kubectl is available as a [snap](https://snapcraft.io/) application.

 1. If you are on Ubuntu or one of other Linux distributions that support [snap](https://snapcraft.io/docs/core/install) package manager, you can install with:

-        sudo snap install kubectl --classic
+       sudo snap install kubectl --classic

-2. Run `kubectl version` to verify that the verison you've installed is sufficiently up-to-date.
+2. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.

 ## Install with Homebrew on macOS

 1. If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you can install with:

-        brew install kubectl
+       brew install kubectl

-2. Run `kubectl version` to verify that the verison you've installed is sufficiently up-to-date.
+2. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.

 ## Install with Chocolatey on Windows

 1. If you are on Windows and using [Chocolatey](https://chocolatey.org) package manager, you can install with:

-        choco install kubernetes-cli
+       choco install kubernetes-cli

-2. Run `kubectl version` to verify that the verison you've installed is sufficiently up-to-date.
+2. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
 3. Configure kubectl to use a remote Kubernetes cluster:

-        cd C:\users\yourusername (Or wherever your %HOME% directory is)
-        mkdir .kube
-        cd .kube
-        touch config
+       cd C:\users\yourusername (Or wherever your %HOME% directory is)
+       mkdir .kube
+       cd .kube
+       touch config

 Edit the config file with a text editor of your choice, such as Notepad for example.

@@ -137,7 +137,7 @@ By default, kubectl configuration is located at `~/.kube/config`.
 Check that kubectl is properly configured by getting the cluster state:

 ```shell
-$ kubectl cluster-info
+kubectl cluster-info
 ```
 If you see a URL response, kubectl is correctly configured to access your cluster.