github/kubernetes
1
0
Fork 0
mirror of https://github.com/k3s-io/kubernetes.git synced 2025-09-05 11:12:03 +00:00
Code Issues Projects Releases Wiki Activity

rename run-container to run in kubectl

Browse Source
This commit is contained in:
Anastasis Andronidis
2015-05-21 22:53:10 +02:00
parent b8a808b1ae
commit d4a47bdb9e
23 changed files with 89 additions and 82 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/.files_generated
View File

@@ -22,7 +22,7 @@ kubectl_port-forward.md
kubectl_proxy.md
kubectl_resize.md
kubectl_rolling-update.md
kubectl_run-container.md
kubectl_run.md
kubectl_stop.md
kubectl_update.md
kubectl_version.md

2
docs/cli-roadmap.md
View File

@@ -47,7 +47,7 @@ See also issues with the following labels:
1. A fairly general-purpose way to specify fields on the command line during creation and update, not just from a config file
1. Extensible API-based generator framework (i.e. invoke generators via an API/URL rather than building them into kubectl), so that complex client libraries don’t need to be rewritten in multiple languages, and so that the abstractions are available through all interfaces: API, CLI, UI, logs, ... [#5280](https://github.com/GoogleCloudPlatform/kubernetes/issues/5280)
1. Need schema registry, and some way to invoke generator (e.g., using a container)
1. Convert run-container to API-based generator
1. Convert run command to API-based generator
1. Transformation framework
1. More intelligent defaulting of fields (e.g., [#2643](https://github.com/GoogleCloudPlatform/kubernetes/issues/2643))
1. Update preconditions based on the values of arbitrary object fields.

2
docs/devel/developer-guides/vagrant.md
View File

@@ -191,7 +191,7 @@ NAME IMAGE(S SELECTOR REPLICAS
Start a container running nginx with a replication controller and three replicas
```
$ cluster/kubectl.sh run-container my-nginx --image=nginx --replicas=3 --port=80
$ cluster/kubectl.sh run my-nginx --image=nginx --replicas=3 --port=80
```
When listing the pods, you will see that three containers have been started and are in Waiting state:

2
docs/getting-started-guides/azure.md
View File

@@ -46,7 +46,7 @@ The `kubectl.sh` line below spins up two containers running
[Nginx](http://nginx.org/en/) running on port 80:
```bash
cluster/kubectl.sh run-container my-nginx --image=nginx --replicas=2 --port=80
cluster/kubectl.sh run my-nginx --image=nginx --replicas=2 --port=80
```
To stop the containers:

4
docs/getting-started-guides/docker-multinode/testing.md
View File

@@ -18,7 +18,7 @@ If the status of any node is ```Unknown``` or ```NotReady``` your cluster is bro
### Run an application
```sh
kubectl -s http://localhost:8080 run-container nginx --image=nginx --port=80
kubectl -s http://localhost:8080 run nginx --image=nginx --port=80
```
now run ```docker ps``` you should see nginx running. You may need to wait a few minutes for the image to get pulled.
@@ -31,7 +31,7 @@ kubectl expose rc nginx --port=80
This should print:
```
NAME LABELS SELECTOR IP PORT(S)
nginx <none> run-container=nginx <ip-addr> 80/TCP
nginx <none> run=nginx <ip-addr> 80/TCP
```
Hit the webserver:

4
docs/getting-started-guides/docker.md
View File

@@ -51,7 +51,7 @@ If you are running different kubernetes clusters, you may need to specify ```-s
### Run an application
```sh
kubectl -s http://localhost:8080 run-container nginx --image=nginx --port=80
kubectl -s http://localhost:8080 run nginx --image=nginx --port=80
```
now run ```docker ps``` you should see nginx running. You may need to wait a few minutes for the image to get pulled.
@@ -64,7 +64,7 @@ kubectl expose rc nginx --port=80
This should print:
```
NAME LABELS SELECTOR IP PORT(S)
nginx <none> run-container=nginx <ip-addr> 80/TCP
nginx <none> run=nginx <ip-addr> 80/TCP
```
Hit the webserver:

2
docs/getting-started-guides/locally.md
View File

@@ -47,7 +47,7 @@ You can now use any of the cluster/kubectl.sh commands to interact with your loc
cluster/kubectl.sh get pods
cluster/kubectl.sh get services
cluster/kubectl.sh get replicationcontrollers
cluster/kubectl.sh run-container my-nginx --image=nginx --replicas=2 --port=80
cluster/kubectl.sh run my-nginx --image=nginx --replicas=2 --port=80
## begin wait for provision to complete, you can monitor the docker pull by opening a new terminal

2
docs/getting-started-guides/vagrant.md
View File

@@ -164,7 +164,7 @@ NAME IMAGE(S SELECTOR REPLICAS
Start a container running nginx with a replication controller and three replicas
```sh
$ ./cluster/kubectl.sh run-container my-nginx --image=nginx --replicas=3 --port=80
$ ./cluster/kubectl.sh run my-nginx --image=nginx --replicas=3 --port=80
```
When listing the pods, you will see that three containers have been started and are in Waiting state:

2
docs/kubectl.md
View File

@@ -60,7 +60,7 @@ kubectl
* [kubectl proxy](kubectl_proxy.md) - Run a proxy to the Kubernetes API server
* [kubectl resize](kubectl_resize.md) - Set a new size for a Replication Controller.
* [kubectl rolling-update](kubectl_rolling-update.md) - Perform a rolling update of the given ReplicationController.
* [kubectl run-container](kubectl_run-container.md) - Run a particular image on the cluster.
* [kubectl run](kubectl_run.md) - Run a particular image on the cluster.
* [kubectl stop](kubectl_stop.md) - Gracefully shut down a resource by id or filename.
* [kubectl update](kubectl_update.md) - Update a resource by filename or stdin.
* [kubectl version](kubectl_version.md) - Print the client and server version information.

20
docs/kubectl_run-container.md → docs/kubectl_run.md
View File

@@ -1,4 +1,4 @@
## kubectl run-container
## kubectl run
Run a particular image on the cluster.
@@ -9,34 +9,34 @@ Create and run a particular image, possibly replicated.
Creates a replication controller to manage the created container(s).
```
kubectl run-container NAME --image=image [--port=port] [--replicas=replicas] [--dry-run=bool] [--overrides=inline-json]
kubectl run NAME --image=image [--port=port] [--replicas=replicas] [--dry-run=bool] [--overrides=inline-json]
```
### Examples
```
// Starts a single instance of nginx.
$ kubectl run-container nginx --image=nginx
$ kubectl run nginx --image=nginx
// Starts a replicated instance of nginx.
$ kubectl run-container nginx --image=nginx --replicas=5
$ kubectl run nginx --image=nginx --replicas=5
// Dry run. Print the corresponding API objects without creating them.
$ kubectl run-container nginx --image=nginx --dry-run
$ kubectl run nginx --image=nginx --dry-run
// Start a single instance of nginx, but overload the spec of the replication controller with a partial set of values parsed from JSON.
$ kubectl run-container nginx --image=nginx --overrides='{ "apiVersion": "v1beta3", "spec": { ... } }'
$ kubectl run nginx --image=nginx --overrides='{ "apiVersion": "v1beta3", "spec": { ... } }'
```
### Options
```
--dry-run=false: If true, only print the object that would be sent, without sending it.
--generator="run-container/v1": The name of the API generator to use. Default is 'run-container-controller/v1'.
-h, --help=false: help for run-container
--generator="run/v1": The name of the API generator to use. Default is 'run-controller/v1'.
-h, --help=false: help for run
--hostport=-1: The host port mapping for the container port. To demonstrate a single-machine container.
--image="": The image for the container to run.
-l, --labels="": Labels to apply to the pod(s) created by this call to run-container.
-l, --labels="": Labels to apply to the pod(s).
--no-headers=false: When using the default output, don't print headers.
-o, --output="": Output format. One of: json|yaml|template|templatefile.
--output-version="": Output the formatted object with the given version (default api-version).
@@ -80,4 +80,4 @@ $ kubectl run-container nginx --image=nginx --overrides='{ "apiVersion": "v1beta
###### Auto generated by spf13/cobra at 2015-05-21 10:33:11.189857293 +0000 UTC
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/kubectl_run-container.md?pixel)]()
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/kubectl_run.md?pixel)]()

2
docs/man/man1/.files_generated
View File

@@ -21,7 +21,7 @@ kubectl-port-forward.1
kubectl-proxy.1
kubectl-resize.1
kubectl-rolling-update.1
kubectl-run-container.1
kubectl-run.1
kubectl-stop.1
kubectl-update.1
kubectl-version.1

20
docs/man/man1/kubectl-run-container.1 → docs/man/man1/kubectl-run.1
View File

@@ -3,12 +3,12 @@
.SH NAME
.PP
kubectl run\-container \- Run a particular image on the cluster.
kubectl run \- Run a particular image on the cluster.
.SH SYNOPSIS
.PP
\fBkubectl run\-container\fP [OPTIONS]
\fBkubectl run\fP [OPTIONS]
.SH DESCRIPTION
@@ -23,12 +23,12 @@ Creates a replication controller to manage the created container(s).
If true, only print the object that would be sent, without sending it.
.PP
\fB\-\-generator\fP="run\-container/v1"
The name of the API generator to use. Default is 'run\-container\-controller/v1'.
\fB\-\-generator\fP="run/v1"
The name of the API generator to use. Default is 'run\-controller/v1'.
.PP
\fB\-h\fP, \fB\-\-help\fP=false
help for run\-container
help for run
.PP
\fB\-\-hostport\fP=\-1
@@ -40,7 +40,7 @@ Creates a replication controller to manage the created container(s).
.PP
\fB\-l\fP, \fB\-\-labels\fP=""
Labels to apply to the pod(s) created by this call to run\-container.
Labels to apply to the pod(s).
.PP
\fB\-\-no\-headers\fP=false
@@ -176,16 +176,16 @@ Creates a replication controller to manage the created container(s).
.nf
// Starts a single instance of nginx.
$ kubectl run\-container nginx \-\-image=nginx
$ kubectl run nginx \-\-image=nginx
// Starts a replicated instance of nginx.
$ kubectl run\-container nginx \-\-image=nginx \-\-replicas=5
$ kubectl run nginx \-\-image=nginx \-\-replicas=5
// Dry run. Print the corresponding API objects without creating them.
$ kubectl run\-container nginx \-\-image=nginx \-\-dry\-run
$ kubectl run nginx \-\-image=nginx \-\-dry\-run
// Start a single instance of nginx, but overload the spec of the replication controller with a partial set of values parsed from JSON.
$ kubectl run\-container nginx \-\-image=nginx \-\-overrides='\{ "apiVersion": "v1beta3", "spec": \{ ... \} \}'
$ kubectl run nginx \-\-image=nginx \-\-overrides='\{ "apiVersion": "v1beta3", "spec": \{ ... \} \}'
.fi
.RE

2
docs/man/man1/kubectl.1
View File

@@ -124,7 +124,7 @@ Find more information at
.SH SEE ALSO
.PP
\fBkubectl\-get(1)\fP, \fBkubectl\-describe(1)\fP, \fBkubectl\-create(1)\fP, \fBkubectl\-update(1)\fP, \fBkubectl\-delete(1)\fP, \fBkubectl\-namespace(1)\fP, \fBkubectl\-logs(1)\fP, \fBkubectl\-rolling\-update(1)\fP, \fBkubectl\-resize(1)\fP, \fBkubectl\-exec(1)\fP, \fBkubectl\-port\-forward(1)\fP, \fBkubectl\-proxy(1)\fP, \fBkubectl\-run\-container(1)\fP, \fBkubectl\-stop(1)\fP, \fBkubectl\-expose(1)\fP, \fBkubectl\-label(1)\fP, \fBkubectl\-config(1)\fP, \fBkubectl\-cluster\-info(1)\fP, \fBkubectl\-api\-versions(1)\fP, \fBkubectl\-version(1)\fP,
\fBkubectl\-get(1)\fP, \fBkubectl\-describe(1)\fP, \fBkubectl\-create(1)\fP, \fBkubectl\-update(1)\fP, \fBkubectl\-delete(1)\fP, \fBkubectl\-namespace(1)\fP, \fBkubectl\-logs(1)\fP, \fBkubectl\-rolling\-update(1)\fP, \fBkubectl\-resize(1)\fP, \fBkubectl\-exec(1)\fP, \fBkubectl\-port\-forward(1)\fP, \fBkubectl\-proxy(1)\fP, \fBkubectl\-run(1)\fP, \fBkubectl\-stop(1)\fP, \fBkubectl\-expose(1)\fP, \fBkubectl\-label(1)\fP, \fBkubectl\-config(1)\fP, \fBkubectl\-cluster\-info(1)\fP, \fBkubectl\-api\-versions(1)\fP, \fBkubectl\-version(1)\fP,
.SH HISTORY

2
docs/replication-controller.md
View File

@@ -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 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, rolling-update) 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, stop, resize, rolling-update) 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