Copy edits for typos

This commit is contained in:
Ed Costello
2015-08-09 14:18:06 -04:00
parent 2bfa9a1f98
commit 35a5eda585
33 changed files with 42 additions and 42 deletions

View File

@@ -35,7 +35,7 @@ Documentation for other releases can be found at
This document describes several topics related to the lifecycle of a cluster: creating a new cluster,
upgrading your cluster's
master and worker nodes, performing node maintainence (e.g. kernel upgrades), and upgrading the Kubernetes API version of a
master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a
running cluster.
## Creating and configuring a Cluster
@@ -132,7 +132,7 @@ For pods with a replication controller, the pod will eventually be replaced by a
For pods with no replication controller, you need to bring up a new copy of the pod, and assuming it is not part of a service, redirect clients to it.
Perform maintainence work on the node.
Perform maintenance work on the node.
Make the node schedulable again:

View File

@@ -41,7 +41,7 @@ objects.
Access Control: give *only* kube-apiserver read/write access to etcd. You do not
want apiserver's etcd exposed to every node in your cluster (or worse, to the
internet at large), because access to etcd is equivilent to root in your
internet at large), because access to etcd is equivalent to root in your
cluster.
Data Reliability: for reasonable safety, either etcd needs to be run as a

View File

@@ -41,7 +41,7 @@ Documentation for other releases can be found at
The kubelet is the primary "node agent" that runs on each
node. The kubelet works in terms of a PodSpec. A PodSpec is a YAML or JSON object
that describes a pod. The kubelet takes a set of PodSpecs that are provided through
various echanisms (primarily through the apiserver) and ensures that the containers
various mechanisms (primarily through the apiserver) and ensures that the containers
described in those PodSpecs are running and healthy.
Other than from an PodSpec from the apiserver, there are three ways that a container

View File

@@ -84,7 +84,7 @@ TokenController runs as part of controller-manager. It acts asynchronously. It:
- observes serviceAccount creation and creates a corresponding Secret to allow API access.
- observes serviceAccount deletion and deletes all corresponding ServiceAccountToken Secrets
- observes secret addition, and ensures the referenced ServiceAccount exists, and adds a token to the secret if needed
- observes secret deleteion and removes a reference from the corresponding ServiceAccount if needed
- observes secret deletion and removes a reference from the corresponding ServiceAccount if needed
#### To create additional API tokens