whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'master' into page-version

Browse Source
This commit is contained in:
Andrew Chen
2017-01-26 16:26:31 -08:00
committed by GitHub
parent 07aa716422 e3494fd143
commit 0c8c31235a
74 changed files with 1219 additions and 688 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/user-guide/configmap/index.md
+64 -3
View File
@@ -291,6 +291,34 @@ SPECIAL_LEVEL_KEY=very
SPECIAL_TYPE_KEY=charm
```
#### Optional ConfigMap in environment variables
There might be situations where environment variables are not
always required. These environment variables can be marked as optional in a
pod like so:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox
command: [ "/bin/sh", "-c", "env" ]
env:
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: a-config
key: akey
optional: true
restartPolicy: Never
```
When this pod is run, the output will be empty.
### Use-Case: Set command-line arguments with ConfigMap
ConfigMaps can also be used to set the value of the command or arguments in a container. This is
@@ -422,6 +450,38 @@ very
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.
#### Optional ConfigMap via volume plugin
Volumes and files provided by a ConfigMap can be also be marked as optional.
The ConfigMap or the key specified does not have to exist. The mount path for
such items will always be created.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox
command: [ "/bin/sh", "-c", "ls /etc/config" ]
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: no-config
optional: true
restartPolicy: Never
```
When this pod is run, the output will be:
```shell
```
## Real World Example: Configuring Redis
Let's take a look at a real-world example: configuring redis using ConfigMap. Say we want to inject
@@ -517,9 +577,10 @@ $ kubectl exec -it redis redis-cli
## Restrictions
ConfigMaps must be created before they are consumed in pods. Controllers may be written to tolerate
missing configuration data; consult individual components configured via ConfigMap on a case-by-case
basis.
ConfigMaps must be created before they are consumed in pods unless they are
marked as optional. Controllers may be written to tolerate missing
configuration data; consult individual components configured via ConfigMap on
a case-by-case basis.
ConfigMaps reside in a namespace. They can only be referenced by pods in the same namespace.
docs/user-guide/counter-pod.yaml
-12
View File
@@ -1,12 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: counter
spec:
containers:
- name: count
image: ubuntu:14.04
args: [bash, -c,
'for ((i = 0; ; i++)); do echo "$i: $(date)"; sleep 1; done']
docs/user-guide/downward-api/dapi-pod.yaml
+8
View File
@@ -8,6 +8,10 @@ spec:
image: gcr.io/google_containers/busybox
command: [ "/bin/sh", "-c", "env" ]
env:
- name: MY_NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: MY_POD_NAME
valueFrom:
fieldRef:
@@ -20,4 +24,8 @@ spec:
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: MY_POD_SERVICE_ACCOUNT
valueFrom:
fieldRef:
fieldPath: spec.serviceAccountName
restartPolicy: Never
docs/user-guide/downward-api/index.md
+5 -1
View File
@@ -22,9 +22,11 @@ the Pod's name, for example, and inject it into this well-known variable.
The following information is available to a `Pod` through the downward API:
* The pod's name
* 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
@@ -101,10 +103,12 @@ 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
docs/user-guide/images.md
+1 -1
View File
@@ -89,7 +89,7 @@ The kubelet will fetch and periodically refresh ECR credentials. It needs the f
Requirements:
- You must be using kubelet version `v1.2.0` or newer. (e.g. run `/usr/bin/kubelet --version=true`).
- Your nodes must be in the same region as the registry you are using
- If your nodes are in region A and your registry is in a different region B, you need version `v1.3.0` or newer.
- ECR must be offered in your region
Troubleshooting:
docs/user-guide/jobs/work-queue-2/index.md
+1 -1
View File
@@ -31,7 +31,7 @@ Here is an overview of the steps in this example:
## Starting Redis
For this example, for simplicitly, we will start a single instance of Redis.
See the [Redis Example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/redis/README.md) for an example
See the [Redis Example](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook) for an example
of deploying Redis scalably and redundantly.
Start a temporary Pod running Redis and a service so we can find it.
docs/user-guide/logging/counter-pod.yaml
-12
View File
@@ -1,12 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: counter
spec:
containers:
- name: count
image: ubuntu:14.04
args: [bash, -c,
'for ((i = 0; ; i++)); do echo "$i: $(date)"; sleep 1; done']
docs/user-guide/logging/examples/counter-pod.yaml
+10
View File
@@ -0,0 +1,10 @@
apiVersion: v1
kind: Pod
metadata:
name: counter
spec:
containers:
- name: count
image: busybox
args: [/bin/sh, -c,
'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done']
docs/user-guide/logging/examples/fluentd-sidecar-config.yaml
+25
View File
@@ -0,0 +1,25 @@
apiVersion: v1
data:
fluentd.conf: |
<source>
type tail
format none
path /var/log/1.log
pos_file /var/log/1.log.pos
tag count.format1
</source>
<source>
type tail
format none
path /var/log/2.log
pos_file /var/log/2.log.pos
tag count.format2
</source>
<match **>
type google_cloud
</match>
kind: ConfigMap
metadata:
name: fluentd-config
docs/user-guide/logging/examples/two-files-counter-pod-agent-sidecar.yaml
+39
View File
@@ -0,0 +1,39 @@
apiVersion: v1
kind: Pod
metadata:
name: counter
spec:
containers:
- name: count
image: busybox
args:
- /bin/sh
- -c
- >
i=0;
while true;
do
echo "$i: $(date)" >> /var/log/1.log;
echo "$(date) INFO $i" >> /var/log/2.log;
i=$((i+1));
sleep 1;
done
volumeMounts:
- name: varlog
mountPath: /var/log
- name: count-agent
image: gcr.io/google_containers/fluentd-gcp:1.30
env:
- name: FLUENTD_ARGS
value: -c /etc/fluentd-config/fluentd.conf
volumeMounts:
- name: varlog
mountPath: /var/log
- name: config-volume
mountPath: /etc/fluentd-config
volumes:
- name: varlog
emptyDir: {}
- name: config-volume
configMap:
name: fluentd-config
docs/user-guide/logging/examples/two-files-counter-pod-streaming-sidecar.yaml
+38
View File
@@ -0,0 +1,38 @@
apiVersion: v1
kind: Pod
metadata:
name: counter
spec:
containers:
- name: count
image: busybox
args:
- /bin/sh
- -c
- >
i=0;
while true;
do
echo "$i: $(date)" >> /var/log/1.log;
echo "$(date) INFO $i" >> /var/log/2.log;
i=$((i+1));
sleep 1;
done
volumeMounts:
- name: varlog
mountPath: /var/log
- name: count-log-1
image: busybox
args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log']
volumeMounts:
- name: varlog
mountPath: /var/log
- name: count-log-2
image: busybox
args: [/bin/sh, -c, 'tail -n+1 -f /var/log/2.log']
volumeMounts:
- name: varlog
mountPath: /var/log
volumes:
- name: varlog
emptyDir: {}
docs/user-guide/logging/examples/two-files-counter-pod.yaml
+26
View File
@@ -0,0 +1,26 @@
apiVersion: v1
kind: Pod
metadata:
name: counter
spec:
containers:
- name: count
image: busybox
args:
- /bin/sh
- -c
- >
i=0;
while true;
do
echo "$i: $(date)" >> /var/log/1.log;
echo "$(date) INFO $i" >> /var/log/2.log;
i=$((i+1));
sleep 1;
done
volumeMounts:
- name: varlog
mountPath: /var/log
volumes:
- name: varlog
emptyDir: {}
docs/user-guide/logging/overview.md
+117 -15
View File
@@ -19,14 +19,17 @@ The guidance for cluster-level logging assumes that a logging backend is present
## Basic logging in Kubernetes
In this section, you can see an example of basic logging in Kubernetes that outputs data to the standard output stream. This demonstration uses a [pod specification](/docs/user-guide/logging/counter-pod.yaml) with a container that writes some text to standard output once per second.
In this section, you can see an example of basic logging in Kubernetes that
outputs data to the standard output stream. This demonstration uses
a [pod specification](/docs/user-guide/logging/examples/counter-pod.yaml) with
a container that writes some text to standard output once per second.
{% include code.html language="yaml" file="counter-pod.yaml" ghlink="/docs/user-guide/counter-pod.yaml" %}
{% include code.html language="yaml" file="examples/counter-pod.yaml" ghlink="/docs/user-guide/logging/examples/counter-pod.yaml" %}
To run this pod, use the following command:
```shell
$ kubectl create -f http://k8s.io/docs/user-guide/counter-pod.yaml
$ kubectl create -f http://k8s.io/docs/user-guide/logging/examples/counter-pod.yaml
pod "counter" created
```
@@ -34,12 +37,9 @@ To fetch the logs, use the `kubectl logs` command, as follows
```shell
$ kubectl logs counter
0: Tue Jun 2 21:37:31 UTC 2015
1: Tue Jun 2 21:37:32 UTC 2015
2: Tue Jun 2 21:37:33 UTC 2015
3: Tue Jun 2 21:37:34 UTC 2015
4: Tue Jun 2 21:37:35 UTC 2015
5: Tue Jun 2 21:37:36 UTC 2015
0: Mon Jan 1 00:00:00 UTC 2001
1: Mon Jan 1 00:00:01 UTC 2001
2: Mon Jan 1 00:00:02 UTC 2001
...
```
@@ -105,17 +105,119 @@ Kubernetes doesn't specify a logging agent, but two optional logging agents are
### Using a sidecar container with the logging agent
![Using a sidecar container with the logging agent](/images/docs/user-guide/logging/logging-with-sidecar.png)
You can use a sidecar container in one of the following ways:
You can implement cluster-level logging by including a dedicated logging agent for each application on your cluster. You can include this logging agent as a _sidecar container_ in the pod spec for each application; the sidecar container should contain only the logging agent.
* The sidecar container streams application logs to its own `stdout`.
* The sidecar container runs a logging agent, which is configured to pick up logs from an application container.
The concrete implementation of the logging agent, the interface between agent and the application, and the interface between the logging agent and the logs backend are completely up to a you. For an example implementation, see the [fluentd sidecar container](https://github.com/kubernetes/contrib/tree/b70447aa59ea14468f4cd349760e45b6a0a9b15d/logging/fluentd-sidecar-gcp) for the Stackdriver logging backend.
#### Streaming sidecar container
**Note:** Using a sidecar container for logging may lead to significant resource consumption.
![Sidecar container with a streaming container](/images/docs/user-guide/logging/logging-with-streaming-sidecar.png)
By having your sidecar containers stream to their own `stdout` and `stderr`
streams, you can take advantage of the kubelet and the logging agent that
already run on each node. The sidecar containers read logs from a file, a socket,
or the journald. Each individual sidecar container prints log to its own `stdout`
or `stderr` stream.
This approach allows you to separate several log streams from different
parts of your application, some of which can lack support
for writing to `stdout` or `stderr`. The logic behind redirecting logs
is minimal, so it's hardly a significant overhead. Additionally, because
`stdout` and `stderr` are handled by the kubelet, you can use built-in tools
like `kubectl logs`.
Consider the following example. A pod runs a single container, and the container
writes to two different log files, using two different formats. Here's a
configuration file for the Pod:
{% include code.html language="yaml" file="examples/two-files-counter-pod.yaml" ghlink="/docs/user-guide/logging/examples/two-files-counter-pod.yaml" %}
It would be a mess to have log entries of different formats in the same log
stream, even if you managed to redirect both components to the `stdout` stream of
the container. Instead, you could introduce two sidecar containers. Each sidecar
container could tail a particular log file from a shared volume and then redirect
the logs to its own `stdout` stream.
Here's a configuration file for a pod that has two sidecar containers:
{% include code.html language="yaml" file="examples/two-files-counter-pod-streaming-sidecar.yaml" ghlink="/docs/user-guide/logging/examples/two-files-counter-pod-streaming-sidecar.yaml" %}
Now when you run this pod, you can access each log stream separately by
running the following commands:
```shell
$ kubectl logs counter count-log-1
0: Mon Jan 1 00:00:00 UTC 2001
1: Mon Jan 1 00:00:01 UTC 2001
2: Mon Jan 1 00:00:02 UTC 2001
...
```
```shell
$ kubectl logs counter count-log-2
Mon Jan 1 00:00:00 UTC 2001 INFO 0
Mon Jan 1 00:00:01 UTC 2001 INFO 1
Mon Jan 1 00:00:02 UTC 2001 INFO 2
...
```
The node-level agent installed in your cluster picks up those log streams
automatically without any further configuration. If you like, you can configure
the agent to parse log lines depending on the source container.
Note, that despite low CPU and memory usage (order of couple of millicores
for cpu and order of several megabytes for memory), writing logs to a file and
then streaming them to `stdout` can double disk usage. If you have
an application that writes to a single file, it's generally better to set
`/dev/stdout` as destination rather than implementing the streaming sidecar
container approach.
Sidecar containers can also be used to rotate log files that cannot be
rotated by the application itself. [An example](https://github.com/samsung-cnct/logrotate)
of this approach is a small container running logrotate periodically.
However, it's recommended to use `stdout` and `stderr` directly and leave rotation
and retention policies to the kubelet.
#### Sidecar container with a logging agent
![Sidecar container with a logging agent](/images/docs/user-guide/logging/logging-with-sidecar-agent.png)
If the node-level logging agent is not flexible enough for your situation, you
can create a sidecar container with a separate logging agent that you have
configured specifically to run with your application.
**Note**: Using a logging agent in a sidecar container can lead
to significant resource consumption. Moreover, you won't be able to access
those logs using `kubectl logs` command, because they are not controlled
by the kubelet.
As an example, you could use [Stackdriver](/docs/user-guide/logging/stackdriver/),
which uses fluentd as a logging agent. Here are two configuration files that
you can use to implement this approach. The first file contains
a [ConfigMap](/docs/user-guide/configmap/) to configure fluentd.
{% include code.html language="yaml" file="examples/fluentd-sidecar-config.yaml" ghlink="/docs/user-guide/logging/examples/fluentd-sidecar-config.yaml" %}
**Note**: The configuration of fluentd is beyond the scope of this article. For
information about configuring fluentd, see the
[official fluentd documentation](http://docs.fluentd.org/).
The second file describes a pod that has a sidecar container running fluentd.
The pod mounts a volume where fluentd can pick up its configuration data.
{% include code.html language="yaml" file="examples/two-files-counter-pod-agent-sidecar.yaml" ghlink="/docs/user-guide/logging/examples/two-files-counter-pod-agent-sidecar.yaml" %}
After some time you can find log messages in the Stackdriver interface.
Remember, that this is just an example and you can actually replace fluentd
with any logging agent, reading from any source inside an application
container.
### Exposing logs directly from the application
![Exposing logs directly from the application](/images/docs/user-guide/logging/logging-from-application.png)
You can implement cluster-level logging by exposing or pushing logs directly from every application itself; however, the implementation for such a logging mechanism is outside the scope of Kubernetes.
You can implement cluster-level logging by exposing or pushing logs directly from
every application; however, the implementation for such a logging mechanism
is outside the scope of Kubernetes.
docs/user-guide/logging/stackdriver.md
+6 -6
View File
@@ -27,16 +27,16 @@ fluentd-gcp-v1.30-f02l5 1/1 Running 0 5d
```
To understand how logging with Stackdriver works, consider the following
synthetic log generator pod specification [counter-pod.yaml](/docs/user-guide/logging/counter-pod.yaml):
synthetic log generator pod specification [counter-pod.yaml](/docs/user-guide/logging/examples/counter-pod.yaml):
{% include code.html language="yaml" file="counter-pod.yaml" ghlink="/docs/user-guide/counter-pod.yaml" %}
{% include code.html language="yaml" file="examples/counter-pod.yaml" ghlink="/docs/user-guide/logging/examples/counter-pod.yaml" %}
This pod specification has one container that runs a bash script
that writes out the value of a counter and the date once per
second, and runs indefinitely. Let's create this pod in the default namespace.
```shell
$ kubectl create -f counter-pod.yaml
$ kubectl create -f http://k8s.io/docs/user-guide/logging/examples/counter-pod.yaml
pod "counter" created
```
@@ -68,14 +68,14 @@ by deleting the currently running counter container:
```shell
$ kubectl delete pod counter
pods/counter
pod "counter" deleted
```
and then recreating it:
```shell
$ kubectl create -f counter-pod.yaml
pods/counter
$ kubectl create -f http://k8s.io/docs/user-guide/logging/examples/counter-pod.yaml
pod "counter" created
```
After some time, you can access logs from the counter pod again:
docs/user-guide/node-selection/index.md
+1 -1
View File
@@ -91,7 +91,7 @@ rather than against labels on the node itself, which allows rules about which po
The affinity feature consists of two types of affinity, "node affinity" and "inter-pod affinity/anti-affinity."
Node affinity is like the existing `nodeSelector` (but with the first two benefits listed above),
while inter-pod affinity/anti-affinity constrains against pod labels rather than node labels, as
described in the three item listed above, in addition to having the first and second properties listed above.
described in the third item listed above, in addition to having the first and second properties listed above.
`nodeSelector` continues to work as usual, but will eventually be deprecated, as node affinity can express
everything that `nodeSelector` can express.
docs/user-guide/pod-security-policy/index.md
+6 -2
View File
@@ -8,7 +8,7 @@ Objects of type `podsecuritypolicy` govern the ability
to make requests on a pod that affect the `SecurityContext` that will be
applied to a pod and container.
See [PodSecurityPolicy proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/security-context-constraints.md) for more information.
See [PodSecurityPolicy proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/security-context-constraints.md) for more information.
* TOC
{:toc}
@@ -39,7 +39,7 @@ into three categories:
restrictive value.
- *Controlled by an allowable set*: Fields of this type are checked
against the set to ensure their value is allowed.
- *Controlled by a strategy*: Items that have a strategy to generate a value provide
- *Controlled by a strategy*: Items that have a strategy to provide
a mechanism to generate the value and a mechanism to ensure that a
specified value falls into the set of allowable values.
@@ -102,6 +102,10 @@ to the volume sources that are defined when creating a volume:
1. downwardAPI
1. fc
1. configMap
1. vsphereVolume
1. quobyte
1. azureDisk
1. photonPersistentDisk
1. \* (allow all volumes)
The recommended minimum set of allowed volumes for new PSPs are
docs/user-guide/pods/pod-spec-common.json
+1 -1
View File
@@ -24,7 +24,7 @@
}
],
"resources": {
"cpu": ""
"cpu": "",
"memory": ""
}
}
docs/user-guide/prereqs.md
+3
View File
@@ -17,6 +17,9 @@ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s htt
# Linux
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
# Windows
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/windows/amd64/kubectl.exe
```
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)
docs/user-guide/quick-start.md
+2 -2
View File
@@ -13,7 +13,7 @@ This guide will help you get oriented to Kubernetes and running your first conta
## Launching a simple application, and exposing it to the Internet
Once your application is packaged into a container and pushed to an image registry, you're ready to deploy it to Kubernetes.
Through integration with some cloud providers (for example Google Compute Engine and AWS EC2), Kubernetes also enables you to request it to provision a public IP address for your application.
Through integration with some cloud providers (for example Google Compute Engine, AWS EC2, and Azure ACS), Kubernetes also enables you to request it to provision a public IP address for your application.
For example, [nginx](http://wiki.nginx.org/Main) is a popular HTTP server, with a [pre-built container on Docker hub](https://registry.hub.docker.com/_/nginx/). The [`kubectl run`](/docs/user-guide/kubectl/kubectl_run) commands below will create two nginx replicas, listening on port 80, and a public IP address for your application.
@@ -70,4 +70,4 @@ service "my-nginx" deleted
## What's next?
[Learn about how to configure common container parameters, such as commands and environment variables.](/docs/user-guide/configuring-containers)
* [Learn about how to configure common container parameters, such as commands and environment variables.](/docs/user-guide/configuring-containers)
docs/user-guide/secrets/index.md
+67 -7
View File
@@ -372,6 +372,41 @@ files.
When a secret being already consumed in a volume is updated, projected keys are eventually updated as well.
The update time depends on the kubelet syncing period.
#### 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:
@@ -418,6 +453,30 @@ $ 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
@@ -449,7 +508,8 @@ 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.
needs to be created before any pods that depend on it, unless it is marked as
optional.
Secret API objects reside in a namespace. They can only be referenced by pods
in that same namespace.
@@ -469,12 +529,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 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.
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.
## Use cases
docs/user-guide/sharing-clusters.md
+1 -2
View File
@@ -105,8 +105,7 @@ and/or run `kubectl config -h`.
1. `--kubeconfig=/path/to/.kube/config` command line flag
2. `KUBECONFIG=/path/to/.kube/config` env variable
3. `$PWD/.kube/config`
4. `$HOME/.kube/config`
3. `$HOME/.kube/config`
If you create clusters A, B on host1, and clusters C, D on host2, you can
make all four clusters available on both hosts by running
docs/user-guide/ui.md
+1 -1
View File
@@ -66,7 +66,7 @@ The deploy wizard expects that you provide the following information:
- **App name** (mandatory): Name for your application. A [label](/docs/user-guide/labels/) with the name will be added to the Deployment and Service, if any, that will be deployed.
The application name must be unique within the selected Kubernetes [namespace](/docs/admin/namespaces/). It must start and end with a lowercase character, and contain only lowercase letters, numbers and dashes (-). It is limited to 24 characters. Leading and trailing spaces are ignored.
The application name must be unique within the selected Kubernetes [namespace](/docs/admin/namespaces/). It must start with a lowercase character, and end with a lowercase character or a number, and contain only lowercase letters, numbers and dashes (-). It is limited to 24 characters. Leading and trailing spaces are ignored.
- **Container image** (mandatory): The URL of a public Docker [container image](/docs/user-guide/images/) on any registry, or a private image (commonly hosted on the Google Container Registry or Docker Hub). The container image specification must end with a colon.
docs/user-guide/update-demo/index.md
+7 -7
View File
@@ -1,9 +1,9 @@
---
assignees:
- mikedanese
title: Rolling Update Demo
---
---
assignees:
- mikedanese
title: Rolling Update Demo
---
This example demonstrates the usage of Kubernetes to perform a [rolling update](/docs/user-guide/kubectl/kubectl_rolling-update/) on a running group of [pods](/docs/user-guide/pods/). See [here](/docs/user-guide/managing-deployments/#updating-your-application-without-a-service-outage) to understand why you need a rolling update. Also check [rolling update design document](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/simple-rolling-update.md) for more information.
The files for this example are viewable in [our docs repo
@@ -67,7 +67,7 @@ The rolling-update command in kubectl will do 2 things:
Watch the [demo website](http://localhost:8001/static/index.html), it will update one pod every 10 seconds until all of the pods have the new image.
Note that the new replication controller definition does not include the replica count, so the current replica count of the old replication controller is preserved.
But if the replica count had been specified, the final replica count of the new replication controller will be equal this number.
But if the replica count had been specified, the final replica count of the new replication controller will be equal to this number.
### Step Five: Bring down the pods