Fix docs

duda · Mar 29, 2015 · f35dc54 · f35dc54
1 parent 8a7a127
commit f35dc54
Show file tree

Hide file tree

Showing 3 changed files with 6 additions and 8 deletions.
diff --git a/docs/replication-controller.md b/docs/replication-controller.md
@@ -34,7 +34,7 @@ Similarly, deleting a replication controller does not affect the pods it created
 
 The replication controller simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](https://github.com/GoogleCloudPlatform/kubernetes/issues/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies.
 
-The replication controller is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](https://github.com/GoogleCloudPlatform/kubernetes/issues/492)), which would change its `replicas` field. We will not add scheduling policies (e.g., [spreading](https://github.com/GoogleCloudPlatform/kubernetes/issues/367#issuecomment-48428019)) to replication controller. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsehwere. We even plan to factor out the mechanism for bulk pod creation ([#170](https://github.com/GoogleCloudPlatform/kubernetes/issues/170)).
+The replication controller is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](https://github.com/GoogleCloudPlatform/kubernetes/issues/492)), which would change its `replicas` field. We will not add scheduling policies (e.g., [spreading](https://github.com/GoogleCloudPlatform/kubernetes/issues/367#issuecomment-48428019)) to replication controller. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](https://github.com/GoogleCloudPlatform/kubernetes/issues/170)).
 
 The replication controller is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run-container, stop, resize, rollingupdate) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing replication controllers, auto-scalers, services, scheduling policies, canaries, etc.
 

diff --git a/examples/guestbook-go/README.md b/examples/guestbook-go/README.md
@@ -1,8 +1,6 @@
 ## GuestBook example
 
-This example shows how to build a simple multi-tier web application using Kubernetes and Docker.
-
-The example combines a web frontend, a redis master for storage and a replicated set of redis slaves.
+This example shows how to build a simple multi-tier web application using Kubernetes and Docker. It consists of a web frontend, a redis master for storage and a replicated set of redis slaves.
 
 ### Step Zero: Prerequisites
 
@@ -51,7 +49,7 @@ d5c458dabe50        gurpartap/redis:latest                 "/usr/local/bin/redi
 (Note that initial `docker pull` may take a few minutes, depending on network conditions.)
 
 ### Step Two: Turn up the master service.
-A Kubernetes 'service' is a named load balancer that proxies traffic to one or more containers. The services in a Kubernetes cluster are discoverable inside other containers via environment variables. Services find the containers to load balance based on pod labels.
+A Kubernetes 'service' is a named load balancer that proxies traffic to one or more containers. The services in a Kubernetes cluster are discoverable inside other containers via environment variables or DNS. Services find the containers to load balance based on pod labels.
 
 The pod that you created in Step One has the label `name=redis` and `role=master`. The selector field of the service determines which pods will receive the traffic sent to the service.  Use the file `examples/guestbook-go/redis-master-service.json` to create the service in the `kubectl` cli:
 
@@ -63,7 +61,7 @@ NAME                    LABELS                                    SELECTOR
 redis-master            <none>                                    name=redis,role=master       10.0.186.234        6379
 ```
 
-This will cause all new pods to see the redis master apparently running on $REDIS_MASTER_SERVICE_HOST at port 6379. Once created, the service proxy on each node is configured to set up a proxy on the specified port (in this case port 6379).
+This will cause all new pods to see the redis master apparently running on $REDIS_MASTER_SERVICE_HOST at port 6379, or running on 'redis-master:6379'. Once created, the service proxy on each node is configured to set up a proxy on the specified port (in this case port 6379).
 
 ### Step Three: Turn up the replicated slave pods.
 Although the redis master is a single pod, the redis read slaves are a 'replicated' pod. In Kubernetes, a replication controller is responsible for managing multiple instances of a replicated pod.
@@ -79,7 +77,7 @@ redis-master-controller                redis-master            gurpartap/redis
 redis-slave-controller                 redis-slave             gurpartap/redis                     name=redis,role=slave        2
 ```
 
-The redis slave configures itself by looking for the Kubernetes service environment variables in the container environment. In particular, the redis slave is started with the following command:
+The redis slave configures itself by looking for the redis-master service name:port pair. In particular, the redis slave is started with the following command:
 
 ```shell
 redis-server --slaveof redis-master 6379

diff --git a/examples/update-demo/README.md b/examples/update-demo/README.md
@@ -110,7 +110,7 @@ To use your custom docker image in the above examples, you will need to change t
 
 ### Image Copyright
 
-Note that he images included here are public domain.
+Note that the images included here are public domain.
 
 * [kitten](http://commons.wikimedia.org/wiki/File:Kitten-stare.jpg)
 * [nautilus](http://commons.wikimedia.org/wiki/File:Nautilus_pompilius.jpg)