Merge branch 'master' of https://github.com/kubernetes/kubernetes.github.io into release-1.6
* 'master' of https://github.com/kubernetes/kubernetes.github.io: (22 commits) Revert "Document new optional support for ConfigMap and Secret" Revert "mend" modify one word fix typo Fix typos in running zookeeper article Add note about moved content. (#2563) Move Guide topic to Tasks: Downward API (#2439) modify typora fix etcd disaster-recovery hyperlink replace kubernetes.d with kubelet.d remove its name from file content Let's put kubectl in ~/bin. Move Guide toic to Tasks: kubectl exec. Fix travis and add comments Move Pod Lifecycle to Concepts. (#2420) Update deployment completeness documentation rollback PR #2522 kubectl_apply.md-change it for label key Update the links of Deployment User Guide #2534 mark openstack-heat as standalone-salt-conf ... # Conflicts: # docs/user-guide/configmap/index.md
This commit is contained in:
Andrew Chen
@@ -579,6 +579,7 @@ Kubernetes marks a Deployment as _complete_ when it has the following characteri
|
||||
equals or exceeds the number required by the Deployment strategy.
|
||||
* All of the replicas associated with the Deployment have been updated to the latest version you've specified, meaning any
|
||||
updates you've requested have been completed.
|
||||
* No old pods for the Deployment are running.
|
||||
|
||||
You can check if a Deployment has completed by using `kubectl rollout status`. If the rollout completed successfully, `kubectl rollout status` returns a zero exit code.
|
||||
|
||||
@@ -616,7 +617,7 @@ the Deployment's `status.conditions`:
|
||||
* Status=False
|
||||
* Reason=ProgressDeadlineExceeded
|
||||
|
||||
See the [Kubernetes API conventions](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/devel/api-conventions.md#typical-status-properties) for more information on status conditions.
|
||||
See the [Kubernetes API conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#typical-status-properties) for more information on status conditions.
|
||||
|
||||
Note that in version 1.5, Kubernetes will take no action on a stalled Deployment other than to report a status condition with
|
||||
`Reason=ProgressDeadlineExceeded`.
|
||||
@@ -726,7 +727,7 @@ As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, a
|
||||
`metadata` fields. For general information about working with config files,
|
||||
see [deploying applications](/docs/user-guide/deploying-applications), [configuring containers](/docs/user-guide/configuring-containers), and [using kubectl to manage resources](/docs/user-guide/working-with-resources) documents.
|
||||
|
||||
A Deployment also needs a [`.spec` section](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status).
|
||||
A Deployment also needs a [`.spec` section](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#spec-and-status).
|
||||
|
||||
### Pod Template
|
||||
|
||||
|
||||
@@ -5,137 +5,6 @@ assignees:
|
||||
title: Using the Downward API to Convey Pod Properties
|
||||
---
|
||||
|
||||
It is sometimes useful for a container to have information about itself, but we
|
||||
want to be careful not to over-couple containers to Kubernetes. The downward
|
||||
API allows containers to consume information about themselves or the system and
|
||||
expose that information how they want it, without necessarily coupling to the
|
||||
Kubernetes client or REST API.
|
||||
{% include user-guide-content-moved.md %}
|
||||
|
||||
An example of this is a "legacy" app that is already written assuming
|
||||
that a particular environment variable will hold a unique identifier. While it
|
||||
is often possible to "wrap" such applications, this is tedious and error prone,
|
||||
and violates the goal of low coupling. Instead, the user should be able to use
|
||||
the Pod's name, for example, and inject it into this well-known variable.
|
||||
|
||||
|
||||
## Capabilities
|
||||
|
||||
The following information is available to a `Pod` through the downward API:
|
||||
|
||||
* The node's name
|
||||
* The pod's name
|
||||
* The pod's namespace
|
||||
* The pod's IP
|
||||
* The pod's service account name
|
||||
* A container's cpu limit
|
||||
* A container's cpu request
|
||||
* A container's memory limit
|
||||
* A container's memory request
|
||||
|
||||
More information will be exposed through this same API over time.
|
||||
|
||||
|
||||
## Exposing pod information into a container
|
||||
|
||||
Containers consume information from the downward API using environment
|
||||
variables or using a volume plugin.
|
||||
|
||||
|
||||
## Environment variables
|
||||
|
||||
Most environment variables in the Kubernetes API use the `value` field to carry
|
||||
simple values. However, the alternate `valueFrom` field allows you to specify
|
||||
a `fieldRef` to select fields from the pod's definition, and a `resourceFieldRef`
|
||||
to select fields from one of its container's definition.
|
||||
|
||||
The `fieldRef` field is a structure that has an `apiVersion` field and a `fieldPath`
|
||||
field. The `fieldPath` field is an expression designating a field of the pod. The
|
||||
`apiVersion` field is the version of the API schema that the `fieldPath` is
|
||||
written in terms of. If the `apiVersion` field is not specified it is
|
||||
defaulted to the API version of the enclosing object.
|
||||
|
||||
The `fieldRef` is evaluated and the resulting value is used as the value for
|
||||
the environment variable. This allows users to publish their pod's name in any
|
||||
environment variable they want.
|
||||
|
||||
The `resourceFieldRef` is a structure that has a `containerName` field, a `resource`
|
||||
field, and a `divisor` field. The `containerName` is the name of a container,
|
||||
whose resource (cpu or memory) information is to be exposed. The `containerName` is
|
||||
optional for environment variables and defaults to the current container. The
|
||||
`resource` field is an expression designating a resource in a container, and the `divisor`
|
||||
field specifies an output format of the resource being exposed. If the `divisor`
|
||||
is not specified, it defaults to "1" for cpu and memory. The table shows possible
|
||||
values for cpu and memory resources for `resource` and `divisor` settings:
|
||||
|
||||
|
||||
| Setting | Cpu | Memory |
|
||||
| ------------- |-------------| -----|
|
||||
| resource | limits.cpu, requests.cpu| limits.memory, requests.memory|
|
||||
| divisor | 1(cores), 1m(millicores) | 1(bytes), 1k(kilobytes), 1M(megabytes), 1G(gigabytes), 1T(terabytes), 1P(petabytes), 1E(exabytes), 1Ki(kibibyte), 1Mi(mebibyte), 1Gi(gibibyte), 1Ti(tebibyte), 1Pi(pebibyte), 1Ei(exbibyte)|
|
||||
|
||||
|
||||
### Example
|
||||
|
||||
This is an example of a pod that consumes its name and namespace via the
|
||||
downward API:
|
||||
|
||||
{% include code.html language="yaml" file="dapi-pod.yaml" ghlink="/docs/user-guide/downward-api/dapi-pod.yaml" %}
|
||||
|
||||
This is an example of a pod that consumes its container's resources via the downward API:
|
||||
|
||||
{% include code.html language="yaml" file="dapi-container-resources.yaml" ghlink="/docs/user-guide/downward-api/dapi-container-resources.yaml" %}
|
||||
|
||||
## Downward API volume
|
||||
|
||||
Using a similar syntax it's possible to expose pod information to containers using plain text files.
|
||||
Downward API are dumped to a mounted volume. This is achieved using a `downwardAPI`
|
||||
volume type and the different items represent the files to be created. `fieldPath` references the field to be exposed.
|
||||
For exposing a container's resources limits and requests, `containerName` must be specified with `resourceFieldRef`.
|
||||
|
||||
Downward API volume permits to store more complex data like [`metadata.labels`](/docs/user-guide/labels) and [`metadata.annotations`](/docs/user-guide/annotations). Currently key/value pair set fields are saved using `key="value"` format:
|
||||
|
||||
```conf
|
||||
key1="value1"
|
||||
key2="value2"
|
||||
```
|
||||
|
||||
In future, it will be possible to specify an output format option.
|
||||
|
||||
Downward API volumes can expose:
|
||||
|
||||
* The node's name
|
||||
* The pod's name
|
||||
* The pod's namespace
|
||||
* The pod's labels
|
||||
* The pod's annotations
|
||||
* The pod's service account name
|
||||
* A container's cpu limit
|
||||
* A container's cpu request
|
||||
* A container's memory limit
|
||||
* A container's memory request
|
||||
|
||||
The downward API volume refreshes its data in step with the kubelet refresh loop. When labels will be modifiable on the fly without respawning the pod containers will be able to detect changes through mechanisms such as [inotify](https://en.wikipedia.org/wiki/Inotify).
|
||||
|
||||
In future, it will be possible to specify a specific annotation or label.
|
||||
|
||||
#### Projecting keys to specific paths and file permissions
|
||||
|
||||
You can project keys to specific paths and specific permissions on a per-file
|
||||
basis. The [Secrets](/docs/user-guide/secrets/) user guide explains the syntax.
|
||||
|
||||
### Example
|
||||
|
||||
This is an example of a pod that consumes its labels and annotations via the downward API volume, labels and annotations are dumped in `/etc/labels` and in `/etc/annotations`, respectively:
|
||||
|
||||
{% include code.html language="yaml" file="volume/dapi-volume.yaml" ghlink="/docs/user-guide/downward-api/volume/dapi-volume.yaml" %}
|
||||
|
||||
This is an example of a pod that consumes its container's resources via the downward API volume.
|
||||
|
||||
{% include code.html language="yaml" file="volume/dapi-volume-resources.yaml" ghlink="/docs/user-guide/downward-api/volume/dapi-volume-resources.yaml" %}
|
||||
|
||||
For a more thorough example, see
|
||||
[environment variables](/docs/user-guide/environment-guide/).
|
||||
|
||||
## Default values for container resource limits
|
||||
|
||||
If cpu and memory limits are not specified for a container, the downward API will default to the node allocatable value for cpu and memory.
|
||||
[Exposing Pod Information to Containers Using a DownwardAPIVolumeFile](/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information/)
|
||||
|
||||
@@ -2,118 +2,6 @@
|
||||
title: Downward API Volumes
|
||||
---
|
||||
|
||||
Following this example, you will create a pod with a downward API volume.
|
||||
A downward API volume is a k8s volume plugin with the ability to save some pod information in a plain text file. The pod information can be for example some [metadata](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#metadata) or a container's [resources](/docs/user-guide/compute-resources).
|
||||
{% include user-guide-content-moved.md %}
|
||||
|
||||
Supported metadata fields:
|
||||
|
||||
1. `metadata.annotations`
|
||||
2. `metadata.namespace`
|
||||
3. `metadata.name`
|
||||
4. `metadata.labels`
|
||||
|
||||
Supported container's resources:
|
||||
|
||||
1. `limits.cpu`
|
||||
2. `limits.memory`
|
||||
3. `requests.cpu`
|
||||
4. `requests.memory`
|
||||
|
||||
### Step Zero: Prerequisites
|
||||
|
||||
This example assumes you have a Kubernetes cluster installed and running, and the `kubectl` command line tool somewhere in your path. Please see the [gettingstarted](/docs/getting-started-guides/) for installation instructions for your platform.
|
||||
|
||||
### Step One: Create the pod
|
||||
|
||||
Use the [dapi-volume.yaml](/docs/user-guide/downward-api/volume/dapi-volume.yaml) file to create a Pod with a downward API volume which stores pod labels and pod annotations to `/etc/labels` and `/etc/annotations` respectively.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/downward-api/volume/dapi-volume.yaml
|
||||
```
|
||||
|
||||
### Step Two: Examine pod/container output
|
||||
|
||||
The pod displays (every 5 seconds) the content of the dump files which can be executed via the usual `kubectl log` command
|
||||
|
||||
```shell
|
||||
$ kubectl logs kubernetes-downwardapi-volume-example
|
||||
cluster="test-cluster1"
|
||||
rack="rack-22"
|
||||
zone="us-est-coast"
|
||||
build="two"
|
||||
builder="john-doe"
|
||||
kubernetes.io/config.seen="2015-08-24T13:47:23.432459138Z"
|
||||
kubernetes.io/config.source="api"
|
||||
```
|
||||
|
||||
### Internals
|
||||
|
||||
In pod's `/etc` directory one may find the file created by the plugin (system files elided):
|
||||
|
||||
```shell
|
||||
$ kubectl exec kubernetes-downwardapi-volume-example -i -t -- sh
|
||||
/ # ls -laR /etc
|
||||
/etc:
|
||||
total 4
|
||||
drwxrwxrwt 3 0 0 120 Jun 1 19:55 .
|
||||
drwxr-xr-x 17 0 0 4096 Jun 1 19:55 ..
|
||||
drwxr-xr-x 2 0 0 80 Jun 1 19:55 ..6986_01_06_15_55_10.473583074
|
||||
lrwxrwxrwx 1 0 0 31 Jun 1 19:55 ..data -> ..6986_01_06_15_55_10.473583074
|
||||
lrwxrwxrwx 1 0 0 18 Jun 1 19:55 annotations -> ..data/annotations
|
||||
lrwxrwxrwx 1 0 0 13 Jun 1 19:55 labels -> ..data/labels
|
||||
|
||||
/etc/..6986_01_06_15_55_10.473583074:
|
||||
total 8
|
||||
drwxr-xr-x 2 0 0 80 Jun 1 19:55 .
|
||||
drwxrwxrwt 3 0 0 120 Jun 1 19:55 ..
|
||||
-rw-r--r-- 1 0 0 129 Jun 1 19:55 annotations
|
||||
-rw-r--r-- 1 0 0 59 Jun 1 19:55 labels
|
||||
/ #
|
||||
```
|
||||
|
||||
The file `labels` is stored in a temporary directory (`..6986_01_06_15_55_10.473583074` in the example above) which is symlinked to by `..data`. Symlinks for annotations and labels in `/etc` point to files containing the actual metadata through the `..data` indirection. This structure allows for dynamic atomic refresh of the metadata: updates are written to a new temporary directory, and the `..data` symlink is updated atomically using `rename(2)`.
|
||||
|
||||
## Example of downward API volume with container resources
|
||||
|
||||
Use the `docs/user-guide/downward-api/volume/dapi-volume-resources.yaml` file to create a Pod with a downward API volume which stores its container's limits and requests in /etc.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/downward-api/volume/dapi-volume-resources.yaml
|
||||
```
|
||||
|
||||
### Examine pod/container output
|
||||
|
||||
In pod's `/etc` directory one may find the files created by the plugin:
|
||||
|
||||
```shell
|
||||
$ kubectl exec kubernetes-downwardapi-volume-example -i -t -- sh
|
||||
/ # ls -alR /etc
|
||||
/etc:
|
||||
total 4
|
||||
drwxrwxrwt 3 0 0 160 Jun 1 19:47 .
|
||||
drwxr-xr-x 17 0 0 4096 Jun 1 19:48 ..
|
||||
drwxr-xr-x 2 0 0 120 Jun 1 19:47 ..6986_01_06_15_47_23.076909525
|
||||
lrwxrwxrwx 1 0 0 31 Jun 1 19:47 ..data -> ..6986_01_06_15_47_23.076909525
|
||||
lrwxrwxrwx 1 0 0 16 Jun 1 19:47 cpu_limit -> ..data/cpu_limit
|
||||
lrwxrwxrwx 1 0 0 18 Jun 1 19:47 cpu_request -> ..data/cpu_request
|
||||
lrwxrwxrwx 1 0 0 16 Jun 1 19:47 mem_limit -> ..data/mem_limit
|
||||
lrwxrwxrwx 1 0 0 18 Jun 1 19:47 mem_request -> ..data/mem_request
|
||||
|
||||
/etc/..6986_01_06_15_47_23.076909525:
|
||||
total 16
|
||||
drwxr-xr-x 2 0 0 120 Jun 1 19:47 .
|
||||
drwxrwxrwt 3 0 0 160 Jun 1 19:47 ..
|
||||
-rw-r--r-- 1 0 0 1 Jun 1 19:47 cpu_limit
|
||||
-rw-r--r-- 1 0 0 1 Jun 1 19:47 cpu_request
|
||||
-rw-r--r-- 1 0 0 8 Jun 1 19:47 mem_limit
|
||||
-rw-r--r-- 1 0 0 8 Jun 1 19:47 mem_request
|
||||
|
||||
/ # cat /etc/cpu_limit
|
||||
1
|
||||
/ # cat /etc/mem_limit
|
||||
67108864
|
||||
/ # cat /etc/cpu_request
|
||||
1
|
||||
/ # cat /etc/mem_request
|
||||
33554432
|
||||
```
|
||||
[Exposing Pod Information to Containers Using a DownwardAPIVolumeFile](/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information/)
|
||||
|
||||
@@ -5,70 +5,6 @@ assignees:
|
||||
title: Running Commands in a Container with kubectl exec
|
||||
---
|
||||
|
||||
Developers can use `kubectl exec` to run commands in a container. This guide demonstrates two use cases.
|
||||
{% include user-guide-content-moved.md %}
|
||||
|
||||
## Using kubectl exec to check the environment variables of a container
|
||||
|
||||
Kubernetes exposes [services](/docs/user-guide/services/#environment-variables) through environment variables. It is convenient to check these environment variables using `kubectl exec`.
|
||||
|
||||
We first create a pod and a service,
|
||||
|
||||
```shell
|
||||
$ kubectl create -f examples/guestbook/redis-master-controller.yaml
|
||||
$ kubectl create -f examples/guestbook/redis-master-service.yaml
|
||||
```
|
||||
wait until the pod is Running and Ready,
|
||||
|
||||
```shell
|
||||
$ kubectl get pod
|
||||
NAME READY REASON RESTARTS AGE
|
||||
redis-master-ft9ex 1/1 Running 0 12s
|
||||
```
|
||||
|
||||
then we can check the environment variables of the pod,
|
||||
|
||||
```shell
|
||||
$ kubectl exec redis-master-ft9ex env
|
||||
...
|
||||
REDIS_MASTER_SERVICE_PORT=6379
|
||||
REDIS_MASTER_SERVICE_HOST=10.0.0.219
|
||||
...
|
||||
```
|
||||
|
||||
We can use these environment variables in applications to find the service.
|
||||
|
||||
|
||||
## Using kubectl exec to check the mounted volumes
|
||||
|
||||
It is convenient to use `kubectl exec` to check if the volumes are mounted as expected.
|
||||
We first create a Pod with a volume mounted at /data/redis,
|
||||
|
||||
```shell
|
||||
kubectl create -f docs/user-guide/walkthrough/pod-redis.yaml
|
||||
```
|
||||
|
||||
wait until the pod is Running and Ready,
|
||||
|
||||
```shell
|
||||
$ kubectl get pods
|
||||
NAME READY REASON RESTARTS AGE
|
||||
storage 1/1 Running 0 1m
|
||||
```
|
||||
|
||||
we then use `kubectl exec` to verify that the volume is mounted at /data/redis,
|
||||
|
||||
```shell
|
||||
$ kubectl exec storage ls /data
|
||||
redis
|
||||
```
|
||||
|
||||
## Using kubectl exec to open a bash terminal in a pod
|
||||
|
||||
After all, open a terminal in a pod is the most direct way to introspect the pod. Assuming the pod/storage is still running, run
|
||||
|
||||
```shell
|
||||
$ kubectl exec -ti storage -- bash
|
||||
root@storage:/data#
|
||||
```
|
||||
|
||||
This gets you a terminal.
|
||||
[Getting a Shell to a Running Container](/docs/tasks/kubectl/get-shell-running-container/)
|
||||
|
||||
@@ -32,7 +32,7 @@ kubectl apply -f FILENAME
|
||||
# Apply the configuration in manifest.yaml that matches label app=nginx and delete all the other resources that are not in the file and match label app=nginx.
|
||||
kubectl apply --prune -f manifest.yaml -l app=nginx
|
||||
|
||||
# Apply the configuration in manifest.yaml and delete all the other configmaps that are not in the file.
|
||||
# Apply the configuration in manifest.yaml and delete all the other configmaps with the same label key that are not in the file.
|
||||
kubectl apply --prune -f manifest.yaml --all --prune-whitelist=core/v1/ConfigMap
|
||||
```
|
||||
|
||||
|
||||
@@ -4,168 +4,6 @@ assignees:
|
||||
title: The Lifecycle of a Pod
|
||||
---
|
||||
|
||||
Updated: 4/14/2015
|
||||
|
||||
This document covers the lifecycle of a pod. It is not an exhaustive document, but an introduction to the topic.
|
||||
|
||||
## Pod Phase
|
||||
|
||||
As consistent with the overall [API convention](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#typical-status-properties), phase is a simple, high-level summary of the phase of the lifecycle of a pod. It is not intended to be a comprehensive rollup of observations of container-level or even pod-level conditions or other state, nor is it intended to be a comprehensive state machine.
|
||||
|
||||
The number and meanings of `PodPhase` values are tightly guarded. Other than what is documented here, nothing should be assumed about pods with a given `PodPhase`.
|
||||
|
||||
* Pending: The pod has been accepted by the system, but one or more of the container images has not been created. This includes time before being scheduled as well as time spent downloading images over the network, which could take a while.
|
||||
* Running: The pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting.
|
||||
* Succeeded: All containers in the pod have terminated in success, and will not be restarted.
|
||||
* Failed: All containers in the pod have terminated, at least one container has terminated in failure (exited with non-zero exit status or was terminated by the system).
|
||||
* Unknown: For some reason the state of the pod could not be obtained, typically due to an error in communicating with the host of the pod.
|
||||
|
||||
## Pod Conditions
|
||||
|
||||
A pod containing containers that specify readiness probes will also report the Ready condition. Condition status values may be `True`, `False`, or `Unknown`.
|
||||
|
||||
## Container Probes
|
||||
|
||||
A [Probe](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Probe) is a diagnostic performed periodically by the kubelet on a container. Specifically the diagnostic is one of three [Handlers](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler):
|
||||
|
||||
* `ExecAction`: executes a specified command inside the container expecting on success that the command exits with status code 0.
|
||||
* `TCPSocketAction`: performs a tcp check against the container's IP address on a specified port expecting on success that the port is open.
|
||||
* `HTTPGetAction`: performs an HTTP Get against the container's IP address on a specified port and path expecting on success that the response has a status code greater than or equal to 200 and less than 400.
|
||||
|
||||
Each probe will have one of three results:
|
||||
|
||||
* `Success`: indicates that the container passed the diagnostic.
|
||||
* `Failure`: indicates that the container failed the diagnostic.
|
||||
* `Unknown`: indicates that the diagnostic failed so no action should be taken.
|
||||
|
||||
The kubelet can optionally perform and react to two kinds of probes on running containers:
|
||||
|
||||
* `LivenessProbe`: indicates whether the container is *live*, i.e. running. If the LivenessProbe fails, the kubelet will kill the container and the container will be subjected to its [RestartPolicy](#restartpolicy). The default state of Liveness before the initial delay is `Success`. The state of Liveness for a container when no probe is provided is assumed to be `Success`.
|
||||
* `ReadinessProbe`: indicates whether the container is *ready* to service requests. If the ReadinessProbe fails, the endpoints controller will remove the pod's IP address from the endpoints of all services that match the pod. The default state of Readiness before the initial delay is `Failure`. The state of Readiness for a container when no probe is provided is assumed to be `Success`.
|
||||
|
||||
### When should I use liveness or readiness probes?
|
||||
|
||||
If the process in your container is able to crash on its own whenever it encounters an issue or becomes unhealthy, you do not necessarily need a liveness probe - the kubelet will automatically perform the correct action in accordance with the RestartPolicy when the process crashes.
|
||||
|
||||
If you'd like your container to be killed and restarted if a probe fails, then specify a LivenessProbe and a RestartPolicy of `Always` or `OnFailure`.
|
||||
|
||||
If you'd like to start sending traffic to a pod only when a probe succeeds, specify a ReadinessProbe. In this case, the ReadinessProbe may be the same as the LivenessProbe, but the existence of the ReadinessProbe in the spec means that the pod will start without receiving any traffic and only start receiving traffic once the probe starts succeeding.
|
||||
|
||||
If a container wants the ability to take itself down for maintenance, you can specify a ReadinessProbe that checks an endpoint specific to readiness which is different than the LivenessProbe.
|
||||
|
||||
Note that if you just want to be able to drain requests when the pod is deleted, you do not necessarily need a ReadinessProbe - on deletion, the pod automatically puts itself into an unready state regardless of whether the ReadinessProbe exists or not while it waits for the containers in the pod to stop.
|
||||
|
||||
## Container Statuses
|
||||
|
||||
More detailed information about the current (and previous) container statuses can be found in [ContainerStatuses](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#PodStatus). The information reported depends on the current [ContainerState](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#ContainerState), which may be Waiting, Running, or Terminated.
|
||||
|
||||
## RestartPolicy
|
||||
|
||||
The possible values for RestartPolicy are `Always`, `OnFailure`, or `Never`. If RestartPolicy is not set, the default value is `Always`. RestartPolicy applies to all containers in the pod. RestartPolicy only refers to restarts of the containers by the Kubelet on the same node. Failed containers that are restarted by Kubelet, are restarted with an exponential back-off delay, the delay is in multiples of sync-frequency 0, 1x, 2x, 4x, 8x ... capped at 5 minutes and is reset after 10 minutes of successful execution. As discussed in the [pods document](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof), once bound to a node, a pod will never be rebound to another node. This means that some kind of controller is necessary in order for a pod to survive node failure, even if just a single pod at a time is desired.
|
||||
|
||||
Three types of controllers are currently available:
|
||||
|
||||
- Use a [`Job`](/docs/user-guide/jobs/) for pods which are expected to terminate (e.g. batch computations).
|
||||
- Use a [`ReplicationController`](/docs/user-guide/replication-controller/) or [`Deployment`](/docs/user-guide/deployments/)
|
||||
for pods which are not expected to terminate (e.g. web servers).
|
||||
- Use a [`DaemonSet`](/docs/admin/daemons/): Use for pods which need to run 1 per machine because they provide a
|
||||
machine-specific system service.
|
||||
If you are unsure whether to use ReplicationController or Daemon, then see [Daemon Set versus
|
||||
Replication Controller](/docs/admin/daemons/#daemon-set-versus-replication-controller).
|
||||
|
||||
`ReplicationController` is *only* appropriate for pods with `RestartPolicy = Always`.
|
||||
`Job` is *only* appropriate for pods with `RestartPolicy` equal to `OnFailure` or `Never`.
|
||||
|
||||
All 3 types of controllers contain a PodTemplate, which has all the same fields as a Pod.
|
||||
It is recommended to create the appropriate controller and let it create pods, rather than to
|
||||
directly create pods yourself. That is because pods alone are not resilient to machine failures,
|
||||
but Controllers are.
|
||||
|
||||
## Pod lifetime
|
||||
|
||||
In general, pods which are created do not disappear until someone destroys them. This might be a human or a `ReplicationController`, or another controller. The only exception to this rule is that pods with a `PodPhase` of `Succeeded` or `Failed` for more than some duration (determined by the master) will expire and be automatically reaped.
|
||||
|
||||
If a node dies or is disconnected from the rest of the cluster, some entity within the system (call it the NodeController for now) is responsible for applying policy (e.g. a timeout) and marking any pods on the lost node as `Failed`.
|
||||
|
||||
## Examples
|
||||
|
||||
### Advanced livenessProbe example
|
||||
|
||||
Liveness probes are executed by `kubelet`, so all requests will be made within kubelet network namespace.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
labels:
|
||||
test: liveness
|
||||
name: liveness-http
|
||||
spec:
|
||||
containers:
|
||||
- args:
|
||||
- /server
|
||||
image: gcr.io/google_containers/liveness
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
# when "host" is not defined, "PodIP" will be used
|
||||
# host: my-host
|
||||
# when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed
|
||||
# scheme: HTTPS
|
||||
path: /healthz
|
||||
port: 8080
|
||||
httpHeaders:
|
||||
- name: X-Custom-Header
|
||||
value: Awesome
|
||||
initialDelaySeconds: 15
|
||||
timeoutSeconds: 1
|
||||
name: liveness
|
||||
```
|
||||
|
||||
### Example states
|
||||
|
||||
* Pod is `Running`, 1 container, container exits success
|
||||
* Log completion event
|
||||
* If RestartPolicy is:
|
||||
* Always: restart container, pod stays `Running`
|
||||
* OnFailure: pod becomes `Succeeded`
|
||||
* Never: pod becomes `Succeeded`
|
||||
|
||||
* Pod is `Running`, 1 container, container exits failure
|
||||
* Log failure event
|
||||
* If RestartPolicy is:
|
||||
* Always: restart container, pod stays `Running`
|
||||
* OnFailure: restart container, pod stays `Running`
|
||||
* Never: pod becomes `Failed`
|
||||
|
||||
* Pod is `Running`, 2 containers, container 1 exits failure
|
||||
* Log failure event
|
||||
* If RestartPolicy is:
|
||||
* Always: restart container, pod stays `Running`
|
||||
* OnFailure: restart container, pod stays `Running`
|
||||
* Never: pod stays `Running`
|
||||
* When container 2 exits...
|
||||
* Log failure event
|
||||
* If RestartPolicy is:
|
||||
* Always: restart container, pod stays `Running`
|
||||
* OnFailure: restart container, pod stays `Running`
|
||||
* Never: pod becomes `Failed`
|
||||
|
||||
* Pod is `Running`, container becomes OOM
|
||||
* Container terminates in failure
|
||||
* Log OOM event
|
||||
* If RestartPolicy is:
|
||||
* Always: restart container, pod stays `Running`
|
||||
* OnFailure: restart container, pod stays `Running`
|
||||
* Never: log failure event, pod becomes `Failed`
|
||||
|
||||
* Pod is `Running`, a disk dies
|
||||
* All containers are killed
|
||||
* Log appropriate event
|
||||
* Pod becomes `Failed`
|
||||
* If running under a controller, pod will be recreated elsewhere
|
||||
|
||||
* Pod is `Running`, its node is segmented out
|
||||
* NodeController waits for timeout
|
||||
* NodeController marks pod `Failed`
|
||||
* If running under a controller, pod will be recreated elsewhere
|
||||
{% include user-guide-content-moved.md %}
|
||||
|
||||
[Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
|
||||
@@ -375,41 +375,6 @@ However, it is using its local ttl-based cache for getting the current value of
|
||||
As a result, the total delay from the moment when the secret is updated to the moment when new keys are
|
||||
projected to the pod can be as long as kubelet sync period + ttl of secrets cache in kubelet.
|
||||
|
||||
#### Optional Secrets as Files from a Pod
|
||||
|
||||
Volumes and files provided by a Secret can be also be marked as optional.
|
||||
The Secret or the key within a Secret does not have to exist. The mount path for
|
||||
such items will always be created.
|
||||
|
||||
```json
|
||||
{
|
||||
"apiVersion": "v1",
|
||||
"kind": "Pod",
|
||||
"metadata": {
|
||||
"name": "mypod",
|
||||
"namespace": "myns"
|
||||
},
|
||||
"spec": {
|
||||
"containers": [{
|
||||
"name": "mypod",
|
||||
"image": "redis",
|
||||
"volumeMounts": [{
|
||||
"name": "foo",
|
||||
"mountPath": "/etc/foo"
|
||||
}]
|
||||
}],
|
||||
"volumes": [{
|
||||
"name": "foo",
|
||||
"secret": {
|
||||
"secretName": "mysecret",
|
||||
"defaultMode": 256,
|
||||
"optional": true
|
||||
}
|
||||
}]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### Using Secrets as Environment Variables
|
||||
|
||||
To use a secret in an environment variable in a pod:
|
||||
@@ -456,30 +421,6 @@ $ echo $SECRET_PASSWORD
|
||||
1f2d1e2e67df
|
||||
```
|
||||
|
||||
#### Optional Secrets from Environment Variables
|
||||
|
||||
You may not want to require all your secrets to exist. They can be marked as
|
||||
optional as shown in the pod:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: optional-secret-env-pod
|
||||
spec:
|
||||
containers:
|
||||
- name: mycontainer
|
||||
image: redis
|
||||
env:
|
||||
- name: OPTIONAL_SECRET
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: mysecret
|
||||
key: username
|
||||
optional: true
|
||||
restartPolicy: Never
|
||||
```
|
||||
|
||||
#### Using imagePullSecrets
|
||||
|
||||
An imagePullSecret is a way to pass a secret that contains a Docker (or other) image registry
|
||||
@@ -511,8 +452,7 @@ can be automatically attached to pods based on their service account.
|
||||
|
||||
Secret volume sources are validated to ensure that the specified object
|
||||
reference actually points to an object of type `Secret`. Therefore, a secret
|
||||
needs to be created before any pods that depend on it, unless it is marked as
|
||||
optional.
|
||||
needs to be created before any pods that depend on it.
|
||||
|
||||
Secret API objects reside in a namespace. They can only be referenced by pods
|
||||
in that same namespace.
|
||||
@@ -532,12 +472,12 @@ not common ways to create pods.)
|
||||
|
||||
When a pod is created via the API, there is no check whether a referenced
|
||||
secret exists. Once a pod is scheduled, the kubelet will try to fetch the
|
||||
secret value. If a required secret cannot be fetched because it does not
|
||||
exist or because of a temporary lack of connection to the API server, the
|
||||
kubelet will periodically retry. It will report an event about the pod
|
||||
explaining the reason it is not started yet. Once the secret is fetched, the
|
||||
kubelet will create and mount a volume containing it. None of the pod's
|
||||
containers will start until all the pod's volumes are mounted.
|
||||
secret value. If the secret cannot be fetched because it does not exist or
|
||||
because of a temporary lack of connection to the API server, kubelet will
|
||||
periodically retry. It will report an event about the pod explaining the
|
||||
reason it is not started yet. Once the secret is fetched, the kubelet will
|
||||
create and mount a volume containing it. None of the pod's containers will
|
||||
start until all the pod's volumes are mounted.
|
||||
|
||||
## Use cases
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ title: Kubernetes 101
|
||||
|
||||
For Kubernetes 101, we will cover kubectl, pods, volumes, and multiple containers
|
||||
|
||||
In order for the kubectl usage examples to work, make sure you have an examples directory locally, either from [a release](https://github.com/kubernetes/kubernetes/releases) or [the source](https://github.com/kubernetes/kubernetes).
|
||||
In order for the kubectl usage examples to work, make sure you have an example directory locally, either from [a release](https://github.com/kubernetes/kubernetes/releases) or [the source](https://github.com/kubernetes/kubernetes).
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
Reference in New Issue
Block a user