Merge pull request #262 from janetkuo/update-kubectl-run

Update references to "kubectl run" in docs
This commit is contained in:
Brian Grant
2016-03-28 14:21:22 -07:00
7 changed files with 108 additions and 110 deletions
+2 -2
View File
@@ -79,7 +79,7 @@ This document is meant to highlight and consolidate in one place configuration b
controller 'version names'. A desired state of an object is described by a Deployment, and if
changes to that spec are _applied_, the deployment controller changes the actual state to the
desired state at a controlled rate. (Deployment objects are currently part of the [`extensions`
API Group](/docs/api/#api-groups), and are not enabled by default.)
API Group](/docs/api/#api-groups).)
- You can manipulate labels for debugging. Because Kubernetes replication controllers and services
match to pods using labels, this allows you to remove a pod from being considered by a
@@ -108,6 +108,6 @@ This document is meant to highlight and consolidate in one place configuration b
- Use kubectl bulk operations (via files and/or labels) for get and delete. See [label selectors](/docs/user-guide/labels/#label-selectors) and [using labels effectively](/docs/user-guide/managing-deployments/#using-labels-effectively).
- Use `kubectl run` and `expose` to quickly create and expose single container replication controllers. See the [quick start guide](/docs/user-guide/quick-start/) for an example.
- Use `kubectl run` and `expose` to quickly create and expose single container Deployments. See the [quick start guide](/docs/user-guide/quick-start/) for an example.
+13 -14
View File
@@ -3,7 +3,7 @@
An issue that comes up rather frequently for new installations of Kubernetes is
that `Services` are not working properly. You've run all your `Pod`s and
`ReplicationController`s, but you get no response when you try to access them.
`Deployment`s, but you get no response when you try to access them.
This document will hopefully help you to figure out what's going wrong.
* TOC
@@ -85,16 +85,15 @@ $ kubectl run hostnames --image=gcr.io/google_containers/serve_hostname \
--labels=app=hostnames \
--port=9376 \
--replicas=3
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS
hostnames hostnames gcr.io/google_containers/serve_hostname app=hostnames 3
deployment "hostnames" created
```
Note that this is the same as if you had started the `ReplicationController` with
Note that this is the same as if you had started the `Deployment` with
the following YAML:
```yaml
apiVersion: v1
kind: ReplicationController
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: hostnames
spec:
@@ -118,10 +117,10 @@ Confirm your `Pod`s are running:
```shell
$ kubectl get pods -l app=hostnames
NAME READY STATUS RESTARTS AGE
hostnames-0uton 1/1 Running 0 12s
hostnames-bvc05 1/1 Running 0 12s
hostnames-yp2kp 1/1 Running 0 12s
NAME READY STATUS RESTARTS AGE
hostnames-632524106-bbpiw 1/1 Running 0 2m
hostnames-632524106-ly40y 1/1 Running 0 2m
hostnames-632524106-tlaok 1/1 Running 0 2m
```
## Does the Service exist?
@@ -156,7 +155,7 @@ So we have a culprit, let's create the `Service`. As before, this is for the
walk-through - you can use your own `Service`'s details here.
```shell
$ kubectl expose rc hostnames --port=80 --target-port=9376
$ kubectl expose deployment hostnames --port=80 --target-port=9376
service "hostnames" exposed
```
@@ -164,8 +163,8 @@ And read it back, just to be sure:
```shell
$ kubectl get svc hostnames
NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGE
hostnames 10.0.0.1 <none> 80/TCP run=hostnames 1h
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hostnames 10.0.0.226 <none> 80/TCP 5s
```
As before, this is the same as if you had started the `Service` with YAML:
@@ -580,4 +579,4 @@ Contact us on
## More information
Visit [troubleshooting document](/docs/troubleshooting/) for more information.
Visit [troubleshooting document](/docs/troubleshooting/) for more information.
+19 -19
View File
@@ -8,7 +8,7 @@ In this doc, we introduce the Kubernetes command line for interacting with the a
#### docker run
How do I run an nginx container and expose it to the world? Checkout [kubectl run](/docs/user-guide/kubectl/kubectl_run).
How do I run an nginx Deployment and expose it to the world? Checkout [kubectl run](/docs/user-guide/kubectl/kubectl_run).
With docker:
@@ -25,12 +25,13 @@ With kubectl:
```shell
# start the pod running nginx
$ kubectl run --image=nginx nginx-app --port=80 --env="DOMAIN=cluster"
replicationcontroller "nginx-app" created
deployment "nginx-app" created
# expose a port through with a service
$ kubectl expose rc nginx-app --port=80 --name=nginx-http
$ kubectl expose deployment nginx-app --port=80 --name=nginx-http
service "nginx-http" exposed
```
With kubectl, we create a [replication controller](/docs/user-guide/replication-controller) which will make sure that N pods are running nginx (where N is the number of replicas stated in the spec, which defaults to 1). We also create a [service](/docs/user-guide/services) with a selector that matches the replication controller's selector. See the [Quick start](/docs/user-guide/quick-start) for more information.
With kubectl, we create a [Deployment](/docs/user-guide/deployments) which will make sure that N pods are running nginx (where N is the number of replicas stated in the spec, which defaults to 1). We also create a [service](/docs/user-guide/services) with a selector that matches the Deployment's selector. See the [Quick start](/docs/user-guide/quick-start) for more information.
By default images are run in the background, similar to `docker run -d ...`, if you want to run things in the foreground, use:
@@ -40,8 +41,8 @@ kubectl run [-i] [--tty] --attach <name> --image=<image>
Unlike `docker run ...`, if `--attach` is specified, we attach to `stdin`, `stdout` and `stderr`, there is no ability to control which streams are attached (`docker -a ...`).
Because we start a replication controller for your container, it will be restarted if you terminate the attached process (e.g. `ctrl-c`), this is different than `docker run -it`.
To destroy the replication controller (and it's pods) you need to run `kubectl delete rc <name>`
Because we start a Deployment for your container, it will be restarted if you terminate the attached process (e.g. `ctrl-c`), this is different than `docker run -it`.
To destroy the Deployment (and its pods) you need to run `kubectl delete deployment <name>`
#### docker ps
@@ -180,20 +181,19 @@ a9ec34d98787
With kubectl:
```shell
$ kubectl get rc nginx-app
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS
nginx-app nginx-app nginx run=nginx-app 1
$ kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-app-aualv 1/1 Running 0 16s
$ kubectl delete rc nginx-app
NAME READY STATUS RESTARTS AGE
nginx-app-aualv 1/1 Running 0 16s
$ kubectl get po
NAME READY STATUS RESTARTS AGE
$ kubectl get deployment nginx-app
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-app 1 1 1 1 2m
$ kubectl get po -l run=nginx-app
NAME READY STATUS RESTARTS AGE
nginx-app-2883164633-aklf7 1/1 Running 0 2m
$ kubectl delete deployment nginx-app
deployment "nginx-app" deleted
$ kubectl get po -l run=nginx-app
# Return nothing
```
Notice that we don't delete the pod directly. With kubectl we want to delete the replication controller that owns the pod. If we delete the pod directly, the replication controller will recreate the pod.
Notice that we don't delete the pod directly. With kubectl we want to delete the Deployment that owns the pod. If we delete the pod directly, the Deployment will recreate the pod.
#### docker login
@@ -263,4 +263,4 @@ KubeUI is running at https://108.59.85.141/api/v1/proxy/namespaces/kube-system/s
Grafana is running at https://108.59.85.141/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana
Heapster is running at https://108.59.85.141/api/v1/proxy/namespaces/kube-system/services/monitoring-heapster
InfluxDB is running at https://108.59.85.141/api/v1/proxy/namespaces/kube-system/services/monitoring-influxdb
```
```
+19 -19
View File
@@ -14,11 +14,11 @@ as storage volumes and IP addresses.
Single-container pods can be created with the `run` command. The
pod's properties are specified with flags on the command line.
The `run` command creates a replication controller to monitor the pod(s).
The controller watches for failed pods and will start up new pods as required
The `run` command creates a Deployment to monitor the pod(s).
The Deployment watches for failed pods and will start up new pods as required
to maintain the specified number.
Note: If you don't want a replication controller to monitor your pod (e.g. your pod
Note: If you don't want a Deployment to monitor your pod (e.g. your pod
is writing non-persistent data which won't survive a restart, or your pod is
intended to be very short-lived), you can
[create a pod directly with the `create` command](/docs/user-guide/pods/multi-container/).
@@ -36,16 +36,16 @@ $ kubectl run NAME
Where:
* `NAME` (required) is the name of the container to create. This value is also
applied as the name of the replication controller, and as the prefix of the
applied as the name of the Deployment, and as the prefix of the
pod name. For example:
```shell
$ kubectl run example --image=nginx
replicationcontroller "example" created
deployment "example" created
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
example-xypvc 1/1 Running 0 13s
$ kubectl get pods -l run=example
NAME READY STATUS RESTARTS AGE
example-1934187764-scau1 1/1 Running 0 13s
```
* `--image=IMAGE` (required) is the Docker container image to use for this
container.
@@ -54,7 +54,7 @@ Where:
one pod will be created.
* `--labels=key=value` specifies one or more labels to attach to the pod. In
addition to any labels specified here, `run` attaches a label of
the format `run=NAME`. This is used by the replication controller
the format `run=NAME`. This is used by the Deployment
to target the pods created by the command.
There are additional flags that can be specified. For a complete list, run:
@@ -68,21 +68,21 @@ There are additional flags that can be specified. For a complete list, run:
## Deleting a pod
If your pod was created using the `run` command, kubernetes creates a
[replication controller](/docs/user-guide/replication-controller/)
to manage the pod. Pods managed by a replication controller are rescheduled if
[Deployment](/docs/user-guide/deployments/)
to manage the pod. Pods managed by a Deployment are rescheduled if
they go away, including being deleted by `kubectl delete pod`. To permanently
delete the pod, delete its replication controller.
delete the pod, delete its Deployment.
First, find the controller's name:
First, find the Deployment's name:
```shell
$ kubectl get rc
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS
example example busybox run=example 1
$ kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
example 1 1 1 1 1m
```
Then, `delete` the controller:
Then, `delete` the Deployment:
```shell
$ kubectl delete rc CONTROLLER_NAME
```
$ kubectl delete deployment DEPLOYMENT_NAME
```