Update docs to refer to kubectl rather than kubecfg. Remove cli.md.

docs/README.md

@@ -46,8 +46,8 @@ Design docs are in [design](design).
 * **Kubernetes Web Interface** ([ui.md](ui.md)): Accessing the Kubernetes
   web user interface.
 
-* **Kubecfg Command Line Interface** ([cli.md](cli.md)):
-  The `kubecfg` command line reference.
+* **Kubectl Command Line Interface** ([kubectl.md](kubectl.md)):
+  The `kubectl` command line reference.
 
 * **Roadmap** ([roadmap.md](roadmap.md)): The set of supported use cases, features,
   docs, and patterns that are required before Kubernetes 1.0.

docs/overview.md

@@ -19,7 +19,7 @@ Other details:
 
 * [API](api-conventions.md)
 * [Client libraries](client-libraries.md)
-* [Command-line interface](cli.md)
+* [Command-line interface](kubectl.md)
 * [UI](ux.md)
 * [Images and registries](images.md)
 * [Container environment](container-environment.md)

docs/replication-controller.md

@@ -36,7 +36,7 @@ The replication controller simply ensures that the desired number of pods matche
 
 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 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 kubecfg (run, 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.
+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.
 
 ## Common usage patterns
 

docs/ui.md

@@ -7,7 +7,7 @@ Kubernetes currently supports a simple web user interface.
 Start the server:
 
 ```sh
-cluster/kubecfg.sh -proxy -www $PWD/www
+cluster/kubectl.sh proxy -www=$PWD/www
 ```
 
 The UI should now be running on [localhost](http://localhost:8001/static/index.html#/groups//selector)