fix typos

docs/user-guide/configmap/index.md

@@ -294,7 +294,7 @@ SPECIAL_TYPE_KEY=charm
 ### Use-Case: Set command-line arguments with ConfigMap
 
 ConfigMaps can also be used to set the value of the command or arguments in a container.  This is
-accomplished using the kubernetes substitution syntax `$(VAR_NAME)`.  Consider the ConfigMap:
+accomplished using the Kubernetes substitution syntax `$(VAR_NAME)`.  Consider the ConfigMap:
 
 ```yaml
 apiVersion: v1

docs/user-guide/federation/configmap.md

@@ -43,11 +43,11 @@ kubectl --context=federation-cluster create -f myconfigmap.yaml
 ```
 
 The `--context=federation-cluster` flag tells kubectl to submit the
-request to the Federation apiserver instead of sending it to a kubernetes
+request to the Federation apiserver instead of sending it to a Kubernetes
 cluster.
 
 Once a Federated ConfigMap is created, the federation control plane will create
-a matching ConfigMap in all underlying kubernetes clusters.
+a matching ConfigMap in all underlying Kubernetes clusters.
 You can verify this by checking each of the underlying clusters, for example:
 
 ``` shell

docs/user-guide/federation/daemonsets.md

@@ -44,11 +44,11 @@ kubectl --context=federation-cluster create -f mydaemonset.yaml
 ```
 
 The `--context=federation-cluster` flag tells kubectl to submit the
-request to the Federation apiserver instead of sending it to a kubernetes
+request to the Federation apiserver instead of sending it to a Kubernetes
 cluster.
 
 Once a Federated Daemonset is created, the federation control plane will create
-a matching DaemonSet in all underlying kubernetes clusters.
+a matching DaemonSet in all underlying Kubernetes clusters.
 You can verify this by checking each of the underlying clusters, for example:
 
 ``` shell

docs/user-guide/federation/deployment.md

@@ -47,11 +47,11 @@ kubectl --context=federation-cluster create -f mydeployment.yaml
 ```
 
 The '--context=federation-cluster' flag tells kubectl to submit the
-request to the Federation apiserver instead of sending it to a kubernetes
+request to the Federation apiserver instead of sending it to a Kubernetes
 cluster.
 
 Once a Federated Deployment is created, the federation control plane will create
-a Deployment in all underlying kubernetes clusters.
+a Deployment in all underlying Kubernetes clusters.
 You can verify this by checking each of the underlying clusters, for example:
 
 ``` shell

docs/user-guide/federation/events.md

@@ -27,7 +27,7 @@ general.
 Events in federation control plane (referred to as "federation events" in
 this guide) are very similar to the traditional Kubernetes
 Events providing the same functionality.
-Federation Events are stored only in federation control plane and are not passed on to the underlying kubernetes clusters.
+Federation Events are stored only in federation control plane and are not passed on to the underlying Kubernetes clusters.
 
 Federation controllers create events as they process API resources to surface to the
 user, the state that they are in.

docs/user-guide/federation/federated-ingress.md

@@ -277,7 +277,7 @@ where:
 
 1. `firewall-rule-name` can be any name.
 2. `[<service-nodeports>]` is the comma separated list of node ports corresponding to the services that back the Federated Ingress.
-3. [<target-tags>] is the comma separated list of the target tags assigned to the nodes in a kubernetes cluster.
+3. [<target-tags>] is the comma separated list of the target tags assigned to the nodes in a Kubernetes cluster.
 4. <network-name> is the name of the network where the firewall rule must be installed.
 
 Example:

docs/user-guide/federation/index.md

@@ -2,7 +2,7 @@
 title: Federation User Guide
 ---
 
-This guide explains how we can manage multiple kubernetes clusters using
+This guide explains how we can manage multiple Kubernetes clusters using
 federation.
 [Federation proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/federation.md)
 details the use cases motivating cluster federation.

docs/user-guide/federation/namespaces.md

@@ -43,11 +43,11 @@ kubectl --context=federation-cluster create -f myns.yaml
 ```
 
 The '--context=federation-cluster' flag tells kubectl to submit the
-request to the Federation apiserver instead of sending it to a kubernetes
+request to the Federation apiserver instead of sending it to a Kubernetes
 cluster.
 
 Once a federated namespace is created, the federation control plane will create
-a matching namespace in all underlying kubernetes clusters.
+a matching namespace in all underlying Kubernetes clusters.
 You can verify this by checking each of the underlying clusters, for example:
 
 ``` shell
@@ -64,7 +64,7 @@ the Federated Namespace that you created above.
 
 You can update a federated namespace as you would update a Kubernetes
 namespace, just send the request to federation apiserver instead of sending it
-to a specific kubernetes cluster.
+to a specific Kubernetes cluster.
 Federation control plan will ensure that whenever the federated namespace is
 updated, it updates the corresponding namespaces in all underlying clusters to
 match it.
@@ -73,7 +73,7 @@ match it.
 
 You can delete a federated namespace as you would delete a Kubernetes
 namespace, just send the request to federation apiserver instead of sending it
-to a specific kubernetes cluster.
+to a specific Kubernetes cluster.
 
 For example, you can do that using kubectl by running:
 

docs/user-guide/federation/replicasets.md

@@ -43,11 +43,11 @@ kubectl --context=federation-cluster create -f myrs.yaml
 ```
 
 The '--context=federation-cluster' flag tells kubectl to submit the
-request to the Federation apiserver instead of sending it to a kubernetes
+request to the Federation apiserver instead of sending it to a Kubernetes
 cluster.
 
 Once a federated replica set is created, the federation control plane will create
-a replica set in all underlying kubernetes clusters.
+a replica set in all underlying Kubernetes clusters.
 You can verify this by checking each of the underlying clusters, for example:
 
 ``` shell

docs/user-guide/federation/secrets.md

@@ -43,11 +43,11 @@ kubectl --context=federation-cluster create -f mysecret.yaml
 ```
 
 The '--context=federation-cluster' flag tells kubectl to submit the
-request to the Federation apiserver instead of sending it to a kubernetes
+request to the Federation apiserver instead of sending it to a Kubernetes
 cluster.
 
 Once a federated secret is created, the federation control plane will create
-a matching secret in all underlying kubernetes clusters.
+a matching secret in all underlying Kubernetes clusters.
 You can verify this by checking each of the underlying clusters, for example:
 
 ``` shell

docs/user-guide/jobs.md

@@ -24,7 +24,7 @@ A Job can also be used to run multiple pods in parallel.
 ### extensions/v1beta1.Job is deprecated
 
 Starting from version 1.5 `extensions/v1beta1.Job` is being deprecated, with a plan to be removed in
-version 1.6 of kubernetes (see this [issue](https://github.com/kubernetes/kubernetes/issues/32763)).
+version 1.6 of Kubernetes (see this [issue](https://github.com/kubernetes/kubernetes/issues/32763)).
 Please use `batch/v1.Job` instead.
 
 ## Running an example Job

docs/user-guide/jobs/expansions/index.md

@@ -188,7 +188,7 @@ If you have a large number of job objects, you may find that:
   concurrent requests to a shared resource, such as a database,
   used by all the pods in the job.
 - very large numbers of jobs created at once overload the
-  kubernetes apiserver, controller, or scheduler.
+  Kubernetes apiserver, controller, or scheduler.
 
 In this case, you can consider one of the
 other [job patterns](/docs/user-guide/jobs/#job-patterns).

docs/user-guide/kubeconfig-file.md

@@ -1,11 +1,11 @@
----
-assignees:
-- mikedanese
-- thockin
-title: Authenticating Across Clusters with kubeconfig
----
-
-Authentication in kubernetes can differ for different individuals.
+---
+assignees:
+- mikedanese
+- thockin
+title: Authenticating Across Clusters with kubeconfig
+---
+
+Authentication in Kubernetes can differ for different individuals.
 
 - A running kubelet might have one way of authenticating (i.e. certificates).
 - Users might have a different way of authenticating (i.e. tokens).
@@ -82,8 +82,8 @@ clusters:
   name: pig-cluster
 ```
 
-A `cluster` contains endpoint data for a kubernetes cluster. This includes the fully
-qualified url for the kubernetes apiserver, as well as the cluster's certificate
+A `cluster` contains endpoint data for a Kubernetes cluster. This includes the fully
+qualified url for the Kubernetes apiserver, as well as the cluster's certificate
 authority or `insecure-skip-tls-verify: true`, if the cluster's serving
 certificate is not signed by a system trusted certificate authority.
 A `cluster` has a name (nickname) which acts as a dictionary key for the cluster
@@ -103,7 +103,7 @@ users:
     client-key: path/to/my/client/key
 ```
 
-A `user` defines client credentials for authenticating to a kubernetes cluster. A
+A `user` defines client credentials for authenticating to a Kubernetes cluster. A
 `user` has a name (nickname) which acts as its key within the list of user entries
 after kubeconfig is loaded/merged. Available credentials are `client-certificate`,
 `client-key`, `token`, and `username/password`. `username/password` and `token`

docs/user-guide/kubectl/kubectl_autoscale.md

@@ -9,7 +9,7 @@ Auto-scale a Deployment, ReplicaSet, or ReplicationController
 ### Synopsis
 
 
-Creates an autoscaler that automatically chooses and sets the number of pods that run in a kubernetes cluster.
+Creates an autoscaler that automatically chooses and sets the number of pods that run in a Kubernetes cluster.
 
 Looks up a Deployment, ReplicaSet, or ReplicationController by name and creates an autoscaler that uses the given resource as a reference. An autoscaler can automatically increase or decrease number of pods deployed within the system as needed.
 

docs/user-guide/kubectl/kubectl_cluster-info_dump.md

@@ -7,7 +7,7 @@ Dump lots of relevant info for debugging and diagnosis
 ### Synopsis
 
 
-Dumps cluster info out suitable for debugging and diagnosing cluster problems.  By default, dumps everything to stdout. You can optionally specify a directory with --output-directory.  If you specify a directory, kubernetes will build a set of files in that directory.  By default only dumps things in the 'kube-system' namespace, but you can switch to a different namespace with the --namespaces flag, or specify --all-namespaces to dump all namespaces.
+Dumps cluster info out suitable for debugging and diagnosing cluster problems.  By default, dumps everything to stdout. You can optionally specify a directory with --output-directory.  If you specify a directory, Kubernetes will build a set of files in that directory.  By default only dumps things in the 'kube-system' namespace, but you can switch to a different namespace with the --namespaces flag, or specify --all-namespaces to dump all namespaces.
 
 The command also dumps the logs of all of the pods in the cluster, these logs are dumped into different directories based on namespace and pod name.
 

docs/user-guide/kubectl/kubectl_proxy.md

@@ -9,17 +9,17 @@ Run a proxy to the Kubernetes API server
 ### Synopsis
 
 
-To proxy all of the kubernetes api and nothing else, use:
+To proxy all of the Kubernetes api and nothing else, use:
 
   $ kubectl proxy --api-prefix=/
 
-To proxy only part of the kubernetes api and also some static files:
+To proxy only part of the Kubernetes api and also some static files:
 
   $ kubectl proxy --www=/my/files --www-prefix=/static/ --api-prefix=/api/
 
 The above lets you 'curl localhost:8001/api/v1/pods'.
 
-To proxy the entire kubernetes api at a different root, use:
+To proxy the entire Kubernetes api at a different root, use:
 
   $ kubectl proxy --api-prefix=/custom/
 

docs/user-guide/namespaces.md

@@ -89,7 +89,7 @@ across namespaces, you need to use the fully qualified domain name (FQDN).
 
 ## Not All Objects are in a Namespace
 
-Most kubernetes resources (e.g. pods, services, replication controllers, and others) are
+Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are
 in some namespace.  However namespace resources are not themselves in a namespace.
 And low-level resources, such as [nodes](/docs/admin/node) and
 persistentVolumes, are not in any namespace. Events are an exception: they may or may not

docs/user-guide/pods/index.md

@@ -178,9 +178,9 @@ Force deletions can be potentially dangerous for some pods and should be perform
 
 ## Privileged mode for pod containers
 
-From kubernetes v1.1, any container in a pod can enable privileged mode, using the `privileged` flag on the `SecurityContext` of the container spec. This is useful for containers that want to use linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate pods that don't need to be compiled into the kubelet.
+From Kubernetes v1.1, any container in a pod can enable privileged mode, using the `privileged` flag on the `SecurityContext` of the container spec. This is useful for containers that want to use linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate pods that don't need to be compiled into the kubelet.
 
-If the master is running kubernetes v1.1 or higher, and the nodes are running a version lower than v1.1, then new privileged pods will be accepted by api-server, but will not be launched. They will be pending state.
+If the master is running Kubernetes v1.1 or higher, and the nodes are running a version lower than v1.1, then new privileged pods will be accepted by api-server, but will not be launched. They will be pending state.
 If user calls `kubectl describe pod FooPodName`, user can see the reason why the pod is in pending state. The events table in the describe command output will say:
 `Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'`
 
@@ -191,6 +191,6 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'
 
 ## API Object
 
-Pod is a top-level resource in the kubernetes REST API. More details about the
+Pod is a top-level resource in the Kubernetes REST API. More details about the
 API object can be found at: [Pod API
 object](/docs/api-reference/v1/definitions/#_v1_pod).

docs/user-guide/pods/single-container.md

@@ -73,7 +73,7 @@ There are additional flags that can be specified. For a complete list, run:
 
 ## Deleting a pod
 
-If your pod was created using the `run` command, kubernetes creates a
+If your pod was created using the `run` command, Kubernetes creates a
 [Deployment](/docs/user-guide/deployments/)
 to manage the pod. Pods managed by a Deployment are rescheduled if
 they go away, including being deleted by `kubectl delete pod`. To permanently

docs/user-guide/prereqs.md

@@ -32,7 +32,7 @@ sudo mv ./kubectl /usr/local/bin/kubectl
 
 If you downloaded a pre-compiled [release](https://github.com/kubernetes/kubernetes/releases), kubectl will be under `platforms/<os>/<arch>` from the tar bundle.
 
-If you compiled kubernetes from source, kubectl should be either under `_output/local/bin/<os>/<arch>` or `_output/dockerized/bin/<os>/<arch>`.
+If you compiled Kubernetes from source, kubectl should be either under `_output/local/bin/<os>/<arch>` or `_output/dockerized/bin/<os>/<arch>`.
 
 Copy or move kubectl into a directory already in your PATH (e.g. `/usr/local/bin`). For example:
 

docs/user-guide/replication-controller/index.md

@@ -224,7 +224,7 @@ The ReplicationController is intended to be a composable building-block primitiv
 
 ## API Object
 
-Replication controller is a top-level resource in the kubernetes REST API. More details about the
+Replication controller is a top-level resource in the Kubernetes REST API. More details about the
 API object can be found at: [ReplicationController API
 object](/docs/api-reference/v1/definitions/#_v1_replicationcontroller).
 

docs/user-guide/secrets/index.md

@@ -486,7 +486,7 @@ Create a secret containing some ssh keys:
 $ kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub
 ```
 
-**Security Note:** think carefully before sending your own ssh keys: other users of the cluster may have access to the secret.  Use a service account which you want to have accessible to all the users with whom you share the kubernetes cluster, and can revoke if they are compromised.
+**Security Note:** think carefully before sending your own ssh keys: other users of the cluster may have access to the secret.  Use a service account which you want to have accessible to all the users with whom you share the Kubernetes cluster, and can revoke if they are compromised.
 
 
 Now we can create a pod which references the secret with the ssh key and

docs/user-guide/services/index.md

@@ -655,7 +655,7 @@ through a load-balancer, though in those cases the client IP does get altered.
 
 ## API Object
 
-Service is a top-level resource in the kubernetes REST API. More details about the
+Service is a top-level resource in the Kubernetes REST API. More details about the
 API object can be found at: [Service API
 object](/docs/api-reference/v1/definitions/#_v1_service).