Fix capitalization of Kubernetes in the documentation.

docs/design/access.md

@@ -200,7 +200,7 @@ Namespaces versus userAccount vs Labels:
 
 Goals for K8s authentication:
 - Include a built-in authentication system with no configuration required to use in single-user mode, and little configuration required to add several user accounts, and no https proxy required.
-- Allow for authentication to be handled by a system external to Kubernetes, to allow integration with existing to enterprise authorization systems.  The kubernetes namespace itself should avoid taking contributions of multiple authorization schemes.  Instead, a trusted proxy in front of the apiserver can be used to authenticate users.
+- Allow for authentication to be handled by a system external to Kubernetes, to allow integration with existing to enterprise authorization systems.  The Kubernetes namespace itself should avoid taking contributions of multiple authorization schemes.  Instead, a trusted proxy in front of the apiserver can be used to authenticate users.
   - For organizations whose security requirements only allow FIPS compliant implementations (e.g. apache) for authentication.
   - So the proxy can terminate SSL, and isolate the CA-signed certificate from less trusted, higher-touch APIserver.
   - For organizations that already have existing SaaS web services (e.g. storage, VMs) and want a common authentication portal.

docs/design/clustering.md

@@ -36,7 +36,7 @@ Documentation for other releases can be found at
 
 ## Overview
 
-The term "clustering" refers to the process of having all members of the kubernetes cluster find and trust each other.  There are multiple different ways to achieve clustering with different security and usability profiles.  This document attempts to lay out the user experiences for clustering that Kubernetes aims to address.
+The term "clustering" refers to the process of having all members of the Kubernetes cluster find and trust each other.  There are multiple different ways to achieve clustering with different security and usability profiles.  This document attempts to lay out the user experiences for clustering that Kubernetes aims to address.
 
 Once a cluster is established, the following is true:
 

docs/design/expansion.md

@@ -94,7 +94,7 @@ script that sets up the environment and runs the command.  This has a number of
 
 1.  Solutions that require a shell are unfriendly to images that do not contain a shell
 2.  Wrapper scripts make it harder to use images as base images
-3.  Wrapper scripts increase coupling to kubernetes
+3.  Wrapper scripts increase coupling to Kubernetes
 
 Users should be able to do the 80% case of variable expansion in command without writing a wrapper
 script or adding a shell invocation to their containers' commands.

docs/design/secrets.md

@@ -81,7 +81,7 @@ Goals of this design:
     the kubelet implement some reserved behaviors based on the types of secrets the service account
     consumes:
     1.  Use credentials for a docker registry to pull the pod's docker image
-    2.  Present kubernetes auth token to the pod or transparently decorate traffic between the pod
+    2.  Present Kubernetes auth token to the pod or transparently decorate traffic between the pod
         and master service
 4.  As a user, I want to be able to indicate that a secret expires and for that secret's value to
     be rotated once it expires, so that the system can help me follow good practices
@@ -112,7 +112,7 @@ other system components to take action based on the secret's type.
 #### Example: service account consumes auth token secret
 
 As an example, the service account proposal discusses service accounts consuming secrets which
-contain kubernetes auth tokens.  When a Kubelet starts a pod associated with a service account
+contain Kubernetes auth tokens.  When a Kubelet starts a pod associated with a service account
 which consumes this type of secret, the Kubelet may take a number of actions:
 
 1.  Expose the secret in a `.kubernetes_auth` file in a well-known location in the container's

docs/design/security.md

@@ -55,14 +55,14 @@ While Kubernetes today is not primarily a multi-tenant system, the long term evo
 
 We define "user" as a unique identity accessing the Kubernetes API server, which may be a human or an automated process.  Human users fall into the following categories:
 
-1. k8s admin - administers a kubernetes cluster and has access to the underlying components of the system
+1. k8s admin - administers a Kubernetes cluster and has access to the underlying components of the system
 2. k8s project administrator - administrates the security of a small subset of the cluster
-3. k8s developer - launches pods on a kubernetes cluster and consumes cluster resources
+3. k8s developer - launches pods on a Kubernetes cluster and consumes cluster resources
 
 Automated process users fall into the following categories:
 
 1. k8s container user - a user that processes running inside a container (on the cluster) can use to access other cluster resources independent of the human users attached to a project
-2. k8s infrastructure user - the user that kubernetes infrastructure components use to perform cluster functions with clearly defined roles
+2. k8s infrastructure user - the user that Kubernetes infrastructure components use to perform cluster functions with clearly defined roles
 
 
 ### Description of roles

docs/design/service_accounts.md

@@ -76,7 +76,7 @@ type ServiceAccount struct {
 ```
 
 The name ServiceAccount is chosen because it is widely used already (e.g. by Kerberos and LDAP)
-to refer to this type of account.  Note that it has no relation to kubernetes Service objects.
+to refer to this type of account.  Note that it has no relation to Kubernetes Service objects.
 
 The ServiceAccount object does not include any information that could not be defined separately:
   - username can be defined however users are defined.
@@ -90,12 +90,12 @@ These features are explained later.
 
 ### Names
 
-From the standpoint of the Kubernetes API, a `user` is any principal which can authenticate to kubernetes API.
+From the standpoint of the Kubernetes API, a `user` is any principal which can authenticate to Kubernetes API.
 This includes a human running `kubectl` on her desktop and a container in a Pod on a Node making API calls.
 
-There is already a notion of a username in kubernetes, which is populated into a request context after authentication.
+There is already a notion of a username in Kubernetes, which is populated into a request context after authentication.
 However, there is no API object representing a user.  While this may evolve, it is expected that in mature installations,
-the canonical storage of user identifiers will be handled by a system external to kubernetes.
+the canonical storage of user identifiers will be handled by a system external to Kubernetes.
 
 Kubernetes does not dictate how to divide up the space of user identifier strings.  User names can be
 simple Unix-style short usernames, (e.g. `alice`), or may be qualified to allow for federated identity (
@@ -104,7 +104,7 @@ accounts (e.g. `alice@example.com` vs `build-service-account-a3b7f0@foo-namespac
 but Kubernetes does not require this.
 
 Kubernetes also does not require that there be a distinction between human and Pod users.  It will be possible
-to setup a cluster where Alice the human talks to the kubernetes API as username `alice` and starts pods that
+to setup a cluster where Alice the human talks to the Kubernetes API as username `alice` and starts pods that
 also talk to the API as user `alice` and write files to NFS as user `alice`.  But, this is not recommended.
 
 Instead, it is recommended that Pods and Humans have distinct identities, and reference implementations will
@@ -153,7 +153,7 @@ get a `Secret` which allows them to authenticate to the Kubernetes APIserver as
 policy that is desired can be applied to them.
 
 A higher level workflow is needed to coordinate creation of serviceAccounts, secrets and relevant policy objects.
-Users are free to extend kubernetes to put this business logic wherever is convenient for them, though the
+Users are free to extend Kubernetes to put this business logic wherever is convenient for them, though the
 Service Account Finalizer is one place where this can happen (see below).
 
 ### Kubelet