github/kubernetes
4
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Copy edits for typos

Browse Source
This commit is contained in:
Ed Costello
2015-10-29 14:36:29 -04:00
parent d20ab89bd6
commit f968c593e3
21 changed files with 30 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/design/aws_under_the_hood.md
View File

@@ -95,7 +95,7 @@ you with sufficient instance storage for your needs.
Note: The master uses a persistent volume ([etcd](architecture.md#etcd)) to track
its state. Similar to nodes, containers are mostly run against instance
storage, except that we repoint some important data onto the peristent volume.
storage, except that we repoint some important data onto the persistent volume.
The default storage driver for Docker images is aufs. Specifying btrfs (by passing the environment
variable `DOCKER_STORAGE=btrfs` to kube-up) is also a good choice for a filesystem. btrfs
@@ -176,7 +176,7 @@ a distribution file, and then are responsible for attaching and detaching EBS
volumes from itself.
The node policy is relatively minimal. The master policy is probably overly
permissive. The security concious may want to lock-down the IAM policies
permissive. The security conscious may want to lock-down the IAM policies
further ([#11936](http://issues.k8s.io/11936)).
We should make it easier to extend IAM permissions and also ensure that they
@@ -275,7 +275,7 @@ Salt, for example). These objects can currently be manually created:
* Set the `AWS_S3_BUCKET` environment variable to use an existing S3 bucket.
* Set the `VPC_ID` environment variable to reuse an existing VPC.
* Set the `SUBNET_ID` environemnt variable to reuse an existing subnet.
* Set the `SUBNET_ID` environment variable to reuse an existing subnet.
* If your route table has a matching `KubernetesCluster` tag, it will
be reused.
* If your security groups are appropriately named, they will be reused.

2
docs/design/daemon.md
View File

@@ -65,7 +65,7 @@ The DaemonSet supports standard API features:
- Using the pod’s nodeSelector field, DaemonSets can be restricted to operate over nodes that have a certain label. For example, suppose that in a cluster some nodes are labeled ‘app=database’. You can use a DaemonSet to launch a datastore pod on exactly those nodes labeled ‘app=database’.
- Using the pod's nodeName field, DaemonSets can be restricted to operate on a specified node.
- The PodTemplateSpec used by the DaemonSet is the same as the PodTemplateSpec used by the Replication Controller.
- The initial implementation will not guarnatee that DaemonSet pods are created on nodes before other pods.
- The initial implementation will not guarantee that DaemonSet pods are created on nodes before other pods.
- The initial implementation of DaemonSet does not guarantee that DaemonSet pods show up on nodes (for example because of resource limitations of the node), but makes a best effort to launch DaemonSet pods (like Replication Controllers do with pods). Subsequent revisions might ensure that DaemonSet pods show up on nodes, preempting other pods if necessary.
- The DaemonSet controller adds an annotation "kubernetes.io/created-by: \<json API object reference\>"
- YAML example: