Merge branch 'master' into patch-1

This commit is contained in:
Chris Riviere
2016-12-09 13:16:15 -05:00
committed by GitHub
53 changed files with 816 additions and 1250 deletions
+1 -1
View File
@@ -21,7 +21,7 @@ This document is meant to highlight and consolidate in one place configuration b
- Don't specify default values unnecessarily, in order to simplify and minimize configs, and to
reduce error. For example, omit the selector and labels in a `ReplicationController` if you want
them to be the same as the labels in its `podTemplate`, since those fields are populated from the
`podTemplate` labels by default. See the [guestbook app's](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/) .yaml files for some [examples](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/frontend-controller.yaml) of this.
`podTemplate` labels by default. See the [guestbook app's](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/) .yaml files for some [examples](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/frontend-deployment.yaml) of this.
- Put an object description in an annotation to allow better introspection.
+12 -12
View File
@@ -14,8 +14,8 @@ should run in a container. In this case, Kubernetes runs the image's default co
to run a particular command or override the image's defaults, there are two additional fields that
we can use:
1. `Command`: Controls the actual command run by the image
2. `Args`: Controls the arguments passed to the command
1. `command`: Controls the actual command run by the image
2. `args`: Controls the arguments passed to the command
### How docker handles command and arguments
@@ -28,20 +28,20 @@ fields as either a string array or a string and there are subtle differences in
handled. We encourage the curious to check out Docker's documentation for this feature.
Kubernetes allows you to override both the image's default command (docker `Entrypoint`) and args
(docker `Cmd`) with the `Command` and `Args` fields of `Container`. The rules are:
(docker `Cmd`) with the `command` and `args` fields of `container`. The rules are:
1. If you do not supply a `Command` or `Args` for a container, the defaults defined by the image
will be used
2. If you supply a `Command` but no `Args` for a container, only the supplied `Command` will be
used; the image's default arguments are ignored
3. If you supply only `Args`, the image's default command will be used with the arguments you
supply
4. If you supply a `Command` **and** `Args`, the image's defaults will be ignored and the values
you supply will be used
1. If you do not supply a `command` or `args` for a container, the defaults defined by the image
will be used.
2. If you supply a `command` but no `args` for a container, only the supplied `command` will be
used; the image's default arguments are ignored.
3. If you supply only `args`, the image's default command will be used with the arguments you
supply.
4. If you supply a `command` **and** `args`, the image's defaults will be ignored and the values
you supply will be used.
Here are examples for these rules in table format
| Image `Entrypoint` | Image `Cmd` | Container `Command` | Container `Args` | Command Run |
| Image `Entrypoint` | Image `Cmd` | Container `command` | Container `args` | Command Run |
|--------------------|------------------|---------------------|--------------------|------------------|
| `[/ep-1]` | `[foo bar]` | <not set> | <not set> | `[ep-1 foo bar]` |
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | <not set> | `[ep-2]` |
+2 -2
View File
@@ -50,7 +50,7 @@ a matching secret in all underlying kubernetes clusters.
You can verify this by checking each of the underlying clusters, for example:
``` shell
kubectl --context=gce-asia-east1a get rs myrs
kubectl --context=gce-asia-east1a get secret mysecret
```
The above assumes that you have a context named 'gce-asia-east1a'
@@ -77,7 +77,7 @@ the federation apiserver instead of sending it to a specific Kubernetes cluster.
For example, you can do that using kubectl by running:
```shell
kubectl --context=federation-cluster delete rs myrs
kubectl --context=federation-cluster delete secret mysecret
```
Note that at this point, deleting a federated secret will not delete the
+1 -1
View File
@@ -5,7 +5,7 @@ assignees:
---
Each container in a pod has its own image. Currently, the only type of image supported is a [Docker Image](https://docs.docker.com/userguide/dockerimages/).
Each container in a pod has its own image. Currently, the only type of image supported is a [Docker Image](https://docs.docker.com/engine/tutorials/dockerimages/).
You create your Docker image and push it to a registry before referring to it in a Kubernetes pod.
+1 -1
View File
@@ -178,7 +178,7 @@ $ KUBE_EDITOR="nano" kubectl edit svc/docker-registry # Use an alternative edi
## Scaling Resources
```console
$ kubectl scale --replicas=3 rs/foo # Scale a replicaset named 'foo' to
$ kubectl scale --replicas=3 rs/foo # Scale a replicaset named 'foo' to 3
$ kubectl scale --replicas=3 -f foo.yaml # Scale a resource specified in "foo.yaml" to 3
$ kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # If the deployment named mysql's current size is 2, scale mysql to 3
$ kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Scale multiple replication controllers
+3 -3
View File
@@ -99,10 +99,10 @@ _Set-based_ requirements can be mixed with _equality-based_ requirements. For ex
### LIST and WATCH filtering
LIST and WATCH operations may specify label selectors to filter the sets of objects returned using a query parameter. Both requirements are permitted:
LIST and WATCH operations may specify label selectors to filter the sets of objects returned using a query parameter. Both requirements are permitted (presented here as they would appear in a URL query string):
* _equality-based_ requirements: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
* _set-based_ requirements: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
* _equality-based_ requirements: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
* _set-based_ requirements: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
Both label selector styles can be used to list or watch resources via a REST client. For example, targeting `apiserver` with `kubectl` and using _equality-based_ one may write:
+36 -14
View File
@@ -7,30 +7,52 @@ assignees:
To deploy and manage applications on Kubernetes, youll use the Kubernetes command-line tool, [kubectl](/docs/user-guide/kubectl/). It lets you inspect your cluster resources, create, delete, and update components, and much more. You will use it to look at your new cluster and bring up example apps.
## Installing kubectl
## Install kubectl Binary Via curl
If you downloaded a pre-compiled [release](https://github.com/kubernetes/kubernetes/releases), kubectl should be under `platforms/<os>/<arch>` from the tar bundle.
If you built from source, kubectl should be either under `_output/local/bin/<os>/<arch>` or `_output/dockerized/bin/<os>/<arch>`.
The kubectl binary doesn't have to be installed to be executable, but the rest of the walkthrough will assume that it's in your PATH.
The simplest way to install is to copy or move kubectl into a dir already in PATH (e.g. `/usr/local/bin`). For example:
Download the latest release with the command:
```shell
# OS X
$ sudo cp kubernetes/platforms/darwin/amd64/kubectl /usr/local/bin/kubectl
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl
# Linux
$ sudo cp kubernetes/platforms/linux/amd64/kubectl /usr/local/bin/kubectl
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
```
You also need to ensure it's executable:
If you want to download a specific version of kubectl you can replace the nested curl command from above with the version you want. (e.g. v1.4.6, v1.5.0-beta.2)
Make the kubectl binary executable and move it to your PATH (e.g. `/usr/local/bin`):
```shell
$ sudo chmod +x /usr/local/bin/kubectl
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
```
If you prefer not to copy kubectl, you need to ensure the tool is in your path:
## Extract kubectl from Release .tar.gz or Compiled Source
If you downloaded a pre-compiled [release](https://github.com/kubernetes/kubernetes/releases), kubectl will be under `platforms/<os>/<arch>` from the tar bundle.
If you compiled kubernetes from source, kubectl should be either under `_output/local/bin/<os>/<arch>` or `_output/dockerized/bin/<os>/<arch>`.
Copy or move kubectl into a directory already in your PATH (e.g. `/usr/local/bin`). For example:
```shell
# OS X
sudo cp platforms/darwin/amd64/kubectl /usr/local/bin/kubectl
# Linux
sudo cp platforms/linux/amd64/kubectl /usr/local/bin/kubectl
```
Next make it executable with the following command:
```shell
sudo chmod +x /usr/local/bin/kubectl
```
The kubectl binary doesn't have to be installed to be executable, but the rest of the walkthrough will assume that it's in your PATH.
If you prefer not to copy kubectl, you need to ensure it is in your path:
```shell
# OS X
@@ -57,4 +79,4 @@ If you see a url response, you are ready to go.
## What's next?
[Learn how to launch and expose your application.](/docs/user-guide/quick-start)
[Learn how to launch and expose your application.](/docs/user-guide/quick-start)
+1 -1
View File
@@ -204,7 +204,7 @@ The status of the init containers is returned as another annotation - `pod.beta.
Init containers support all of the same features as normal containers, including resource limits, volumes, and security settings. The resource requests and limits for an init container are handled slightly different than normal containers since init containers are run one at a time instead of all at once - any limits or quotas will be applied based on the largest init container resource quantity, rather than as the sum of quantities. Init containers do not support readiness probes since they will run to completion before the pod can be ready.
[Complete Init Container Documentation](/docs/user-guide/pods/init-containers.md)
[Complete Init Container Documentation](/docs/user-guide/pods/init-container/)
## Lifecycle hooks and termination notice
+1 -1
View File
@@ -176,7 +176,7 @@ its pods, add appropriate selectors or endpoints and change the service `type`.
## Virtual IPs and service proxies
Every node in a Kubernetes cluster runs a `kube-proxy`. `kube-proxy` is
responsible for implementing a form of virtual IP for `Service`s of type other
responsible for implementing a form of virtual IP for `Services` of type other
than `ExternalName`.
In Kubernetes v1.0 the proxy was purely in userspace. In Kubernetes v1.1 an
iptables proxy was added, but was not the default operating mode. Since