"kubectl run" and "kubectl get" behavior in 1.2.0

[Brian Grant]

kubectl is the main "user interface" to Kubernetes, so we are continuously working on improving it. Kubernetes 1.2 contains some significant improvements to both "kubectl run" and "kubectl get".

kubectl run

With kubectl run, you can easily deploy containers onto Kubernetes. For example:

kubectl run my-nginx --image=nginx --replicas=2 --port=80

In 1.0 and 1.1, kubectl run generated a ReplicationController by default, since we assumed most users would want to launch a continuously running application.

For an example, see:

https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/quick-start.md

In 1.2, it now creates a deployment resource, which is easier to update. You can read about Deployment in the user guide:

http://kubernetes.io/docs/user-guide/deployments/

This is documented in our release notes:

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md

Our documentation has also been updated to reflect this change. For example, the app. management quick start:

http://kubernetes.io/docs/user-guide/quick-start/

“kubectl run” always output the type and name of the resource(s) it creates, but we have clarified and simplified the output in 1.2:

deployment "my-nginx" created

You can use that in subsequent commands, such as "kubectl get deployment my-nginx", or "kubectl expose deployment my-nginx". 

If you want to write a script to do that automatically, in a forward-compatible manner, use "-o name" flag with "kubectl run", and it will generate short output "deployments/<name>", which can also be used on subsequent kubectl command lines, such as "kubectl delete deployments/my-nginx"

The "--generator" flag can be used with "kubectl run" to generate other types of resources, for example, set it to "run/v1" to create a Replication Controller, which was the default in 1.1 and 1.0, and to "run-pod/v1" to create a Pod, such as for --restart=Never pods. This flag has existed as long as "kubectl run" has existed, and can be used to pin to a specific behavior forever, which you might want to do in scripts. More generally, use it if you require a specific type of resource to be generated. You can find more information using --help and in our run documentation:

http://kubernetes.io/docs/user-guide/kubectl/kubectl_run/

kubectl get

We have also made a number of improvements to the output of "kubectl get", mostly to make it more concise and more consistent. 

http://kubernetes.io/docs/user-guide/kubectl/kubectl_get/

Variable-length fields, such as selectors and images have been moved from the default output to "wide" output, specified with "-o wide". Similarly, all labels can be requested with "--show-labels" and individual label values can be requested using "-L key".

If you need stable output in a script, you should request one of the machine-oriented output forms, such as "-o name", "-o json", "-o yaml", "-o go-template", or "-o jsonpath". 

For example:

kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services

Since those output forms (other than "-o name") output the resource using a particular API version, you should also specify the version you want, using --output-version.