Merge branch 'master' into patch-1
This commit is contained in:
@@ -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.
|
||||
|
||||
|
||||
@@ -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]` |
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
@@ -7,30 +7,52 @@ assignees:
|
||||
|
||||
To deploy and manage applications on Kubernetes, you’ll 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)
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user