In links to ref pages, use {{page.version}}.

This commit is contained in:
steveperry-53
2017-07-25 09:37:19 -07:00
committed by Andrew Chen
parent 28f3cfdd4f
commit f9ac865c5f
28 changed files with 98 additions and 98 deletions
@@ -144,9 +144,9 @@ the shared Volume is lost.
* See
[Configuring a Pod to Use a Volume for Storage](/docs/tasks/configure-pod-container/configure-volume-storage/).
* See [Volume](/docs/api-reference/v1.6/#volume-v1-core).
* See [Volume](/docs/api-reference/{{page.version}}/#volume-v1-core).
* See [Pod](/docs/api-reference/v1.6/#pod-v1-core).
* See [Pod](/docs/api-reference/{{page.version}}/#pod-v1-core).
{% endcapture %}
@@ -18,7 +18,7 @@ PersistentVolume.
## Why change reclaim policy of a PersistentVolume
`PersistentVolumes` can have various reclaim policies, including "Retain",
"Recycle", and "Delete". For dynamically provisioned `PersistentVolumes`,
"Recycle", and "Delete". For dynamically provisioned `PersistentVolumes`,
the default reclaim policy is "Delete". This means that a dynamically provisioned
volume is automatically deleted when a user deletes the corresponding
`PeristentVolumeClaim`. This automatic behavior might be inappropriate if the volume
@@ -72,9 +72,9 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to
### Reference
* [PersistentVolume](/docs/api-reference/v1.6/#persistentvolume-v1-core)
* [PersistentVolumeClaim](/docs/api-reference/v1.6/#persistentvolumeclaim-v1-core)
* See the `persistentVolumeReclaimPolicy` field of [PersistentVolumeSpec](/docs/api-reference/v1.6/#persistentvolumeclaim-v1-core).
* [PersistentVolume](/docs/api-reference/{{page.version}}/#persistentvolume-v1-core)
* [PersistentVolumeClaim](/docs/api-reference/{{page.version}}/#persistentvolumeclaim-v1-core)
* See the `persistentVolumeReclaimPolicy` field of [PersistentVolumeSpec](/docs/api-reference/{{page.version}}/#persistentvolumeclaim-v1-core).
{% endcapture %}
{% include templates/task.md %}
@@ -113,7 +113,7 @@ For information about what happens if you don't specify CPU and RAM requests, se
{% capture whatsnext %}
* Learn more about [managing compute resources](/docs/concepts/configuration/manage-compute-resources-container/).
* See [ResourceRequirements](/docs/api-reference/v1.6/#resourcerequirements-v1-core).
* See [ResourceRequirements](/docs/api-reference/{{page.version}}/#resourcerequirements-v1-core).
{% endcapture %}
@@ -84,10 +84,10 @@ unless the Pod's grace period expires. For more details, see
### Reference
* [Lifecycle](/docs/resources-reference/v1.6/#lifecycle-v1-core)
* [Container](/docs/resources-reference/v1.6/#container-v1-core)
* See `terminationGracePeriodSeconds` in [PodSpec](/docs/resources-reference/v1.6/#podspec-v1-core)
* [Lifecycle](/docs/resources-reference/{{page.version}}/#lifecycle-v1-core)
* [Container](/docs/resources-reference/{{page.version}}/#container-v1-core)
* See `terminationGracePeriodSeconds` in [PodSpec](/docs/resources-reference/{{page.version}}/#podspec-v1-core)
{% endcapture %}
@@ -199,7 +199,7 @@ will be restarted.
## Use a named port
You can use a named
[ContainerPort](/docs/api-reference/v1.6/#containerport-v1-core)
[ContainerPort](/docs/api-reference/{{page.version}}/#containerport-v1-core)
for HTTP or TCP liveness checks:
```yaml
@@ -250,7 +250,7 @@ for it, and that containers are restarted when they fail.
Eventually, some of this section could be moved to a concept topic.
{% endcomment %}
[Probes](/docs/api-reference/v1.6/#probe-v1-core) have a number of fields that
[Probes](/docs/api-reference/{{page.version}}/#probe-v1-core) have a number of fields that
you can use to more precisely control the behavior of liveness and readiness
checks:
@@ -266,7 +266,7 @@ liveness. Minimum value is 1.
* `failureThreshold`: Minimum consecutive failures for the probe to be
considered failed after having succeeded. Defaults to 3. Minimum value is 1.
[HTTP probes](/docs/api-reference/v1.6/#httpgetaction-v1-core)
[HTTP probes](/docs/api-reference/{{page.version}}/#httpgetaction-v1-core)
have additional fields that can be set on `httpGet`:
* `host`: Host name to connect to, defaults to the pod IP. You probably want to
@@ -295,9 +295,9 @@ you should not use `host`, but rather set the `Host` header in `httpHeaders`.
### Reference
* [Pod](/docs/api-reference/v1.6/#pod-v1-core)
* [Container](/docs/api-reference/v1.6/#container-v1-core)
* [Probe](/docs/api-reference/v1.6/#probe-v1-core)
* [Pod](/docs/api-reference/{{page.version}}/#pod-v1-core)
* [Container](/docs/api-reference/{{page.version}}/#container-v1-core)
* [Probe](/docs/api-reference/{{page.version}}/#probe-v1-core)
{% endcapture %}
@@ -57,7 +57,7 @@ PersistentVolume uses a file or directory on the Node to emulate network-attache
In a production cluster, you would not use hostPath. Instead a cluster administrator
would provision a network resource like a Google Compute Engine persistent disk,
an NFS share, or an Amazon Elastic Block Store volume. Cluster administrators can also
use [StorageClasses](/docs/resources-reference/v1.6/#storageclass-v1-storage)
use [StorageClasses](/docs/resources-reference/{{page.version}}/#storageclass-v1-storage)
to set up
[dynamic provisioning](http://blog.kubernetes.io/2016/10/dynamic-provisioning-and-storage-in-kubernetes.html).
@@ -202,10 +202,10 @@ PersistentVolume are not present on the Pod resource itself.
### Reference
* [PersistentVolume](/docs/resources-reference/v1.6/#persistentvolume-v1-core)
* [PersistentVolumeSpec](/docs/resources-reference/v1.6/#persistentvolumespec-v1-core)
* [PersistentVolumeClaim](/docs/resources-reference/v1.6/#persistentvolumeclaim-v1-core)
* [PersistentVolumeClaimSpec](/docs/resources-reference/v1.6/#persistentvolumeclaimspec-v1-core)
* [PersistentVolume](/docs/resources-reference/{{page.version}}/#persistentvolume-v1-core)
* [PersistentVolumeSpec](/docs/resources-reference/{{page.version}}/#persistentvolumespec-v1-core)
* [PersistentVolumeClaim](/docs/resources-reference/{{page.version}}/#persistentvolumeclaim-v1-core)
* [PersistentVolumeClaimSpec](/docs/resources-reference/{{page.version}}/#persistentvolumeclaimspec-v1-core)
{% endcapture %}
@@ -82,7 +82,7 @@ you will see something like this:
At this point, the Container has terminated and restarted. This is because the
redis Pod has a
[restartPolicy](/docs/api-reference/v1.6/#podspec-v1-core)
[restartPolicy](/docs/api-reference/{{page.version}}/#podspec-v1-core)
of `Always`.
1. Get a shell into the restarted Container:
@@ -95,9 +95,9 @@ of `Always`.
{% capture whatsnext %}
* See [Volume](/docs/api-reference/v1.6/#volume-v1-core).
* See [Volume](/docs/api-reference/{{page.version}}/#volume-v1-core).
* See [Pod](/docs/api-reference/v1.6/#pod-v1-core).
* See [Pod](/docs/api-reference/{{page.version}}/#pod-v1-core).
* In addition to the local disk storage provided by `emptyDir`, Kubernetes
supports many different network-attached storage solutions, including PD on
@@ -42,7 +42,7 @@ The output contains a section similar to this:
}
}
}
NOTE: If you use a Docker credentials store, you won't see that `auth` entry but a `credsStore` entry with the name of the store as value.
## Create a Secret that holds your authorization token
@@ -127,9 +127,9 @@ Create a Pod that uses your Secret, and verify that the Pod is running:
* Learn more about
[using a private registry](/docs/concepts/containers/images/#using-a-private-registry).
* See [kubectl create secret docker-registry](/docs/user-guide/kubectl/v1.6/#-em-secret-docker-registry-em-).
* See [Secret](/docs/api-reference/v1.6/#secret-v1-core)
* See [Secret](/docs/api-reference/{{page.version}}/#secret-v1-core)
* See the `imagePullSecrets` field of
[PodSpec](/docs/api-reference/v1.6/#podspec-v1-core).
[PodSpec](/docs/api-reference/{{page.version}}/#podspec-v1-core).
{% endcapture %}
@@ -6,7 +6,7 @@ assignees:
title: Configure a Security Context for a Pod or Container
redirect_from:
- "/docs/user-guide/security-context/"
- "/docs/concepts/policy/container-capabilities/"
- "/docs/concepts/policy/container-capabilities/"
---
{% capture overview %}
@@ -44,7 +44,7 @@ For more information about security mechanisms in Linux, see
To specify security settings for a Pod, include the `securityContext` field
in the Pod specification. The `securityContext` field is a
[PodSecurityContext](/docs/api-reference/v1.6/#podsecuritycontext-v1-core) object.
[PodSecurityContext](/docs/api-reference/{{page.version}}/#podsecuritycontext-v1-core) object.
The security settings that you specify for a Pod apply to all Containers in the Pod.
Here is a configuration file for a Pod that has a `securityContext` and an `emptyDir` volume:
@@ -134,7 +134,7 @@ exit
To specify security settings for a Container, include the `securityContext` field
in the Container manifest. The `securityContext` field is a
[SecurityContext](/docs/api-reference/v1.6/#securitycontext-v1-core) object.
[SecurityContext](/docs/api-reference/{{page.version}}/#securitycontext-v1-core) object.
Security settings that you specify for a Container apply only to
the individual Container, and they override settings made at the Pod level when
there is overlap. Container settings do not affect the Pod's Volumes.
@@ -291,7 +291,7 @@ Compare the capabilities of the two Containers:
```
00000000a80425fb
00000000aa0435fb
00000000aa0435fb
```
In the capability bitmap of the first container, bits 12 and 25 are clear. In the second container,
@@ -308,7 +308,7 @@ to add `CAP_SYS_TIME`, include `SYS_TIME` in your list of capabilities.
To assign SELinux labels to a Container, include the `seLinuxOptions` field in
the `securityContext` section of your Pod or Container manifest. The
`seLinuxOptions` field is an
[SELinuxOptions](/docs/api-reference/v1.6/#selinuxoptions-v1-core)
[SELinuxOptions](/docs/api-reference/{{page.version}}/#selinuxoptions-v1-core)
object. Here's an example that applies an SELinux level:
```yaml
@@ -346,8 +346,8 @@ protection, you must ensure each Pod is assigned a unique MCS label.
{% capture whatsnext %}
* [PodSecurityContext](/docs/api-reference/v1.6/#podsecuritycontext-v1-core)
* [SecurityContext](/docs/api-reference/v1.6/#securitycontext-v1-core)
* [PodSecurityContext](/docs/api-reference/{{page.version}}/#podsecuritycontext-v1-core)
* [SecurityContext](/docs/api-reference/{{page.version}}/#securitycontext-v1-core)
* [Tuning Docker with the newest security enhancements](https://opensource.com/business/15/3/docker-security-tuning)
* [Security Contexts design document](https://git.k8s.io/community/contributors/design-proposals/security_context.md)
* [Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/volume-ownership-management.md)
@@ -100,7 +100,7 @@ Set `terminationMessagePath` as shown here:
{% capture whatsnext %}
* See the `terminationMessagePath` field in
[Container](/docs/api-reference/v1.6/#container-v1-core).
[Container](/docs/api-reference/{{page.version}}/#container-v1-core).
* Learn about [retrieving logs](/docs/concepts/cluster-administration/logging/).
* Learn about [Go templates](https://golang.org/pkg/text/template/).
@@ -16,7 +16,7 @@ redirect_from:
*Node problem detector* is a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) monitoring the
node health. It collects node problems from various daemons and reports them
to the apiserver as [NodeCondition](/docs/concepts/architecture/nodes/#condition)
and [Event](/docs/api-reference/v1.6/#event-v1-core).
and [Event](/docs/api-reference/{{page.version}}/#event-v1-core).
It supports some known kernel issue detection now, and will detect more and
more node problems over time.
@@ -248,4 +248,4 @@ resource overhead on each node. Usually this is fine, because:
* The kernel log is generated relatively slowly.
* Resource limit is set for node problem detector.
* Even under high load, the resource usage is acceptable.
(see [benchmark result](https://github.com/kubernetes/node-problem-detector/issues/2#issuecomment-220255629))
(see [benchmark result](https://github.com/kubernetes/node-problem-detector/issues/2#issuecomment-220255629))
@@ -134,7 +134,7 @@ Here are some examples:
* Learn more about [containers and commands](/docs/user-guide/containers/).
* Learn more about [configuring containers](/docs/user-guide/configuring-containers/).
* Learn more about [running commands in a container](/docs/tasks/kubectl/get-shell-running-container/).
* See [Container](/docs/api-reference/v1.6/#container-v1-core).
* See [Container](/docs/api-reference/{{page.version}}/#container-v1-core).
{% endcapture %}
@@ -72,7 +72,7 @@ Pod:
* Learn more about [environment variables](/docs/tasks/configure-pod-container/environment-variable-expose-pod-information/).
* Learn about [using secrets as environment variables](/docs/user-guide/secrets/#using-secrets-as-environment-variables).
* See [EnvVarSource](/docs/api-reference/v1.6/#envvarsource-v1-core).
* See [EnvVarSource](/docs/api-reference/{{page.version}}/#envvarsource-v1-core).
{% endcapture %}
@@ -167,9 +167,9 @@ Here is a configuration file you can use to create a Pod:
### Reference
* [Secret](/docs/api-reference/v1.6/#secret-v1-core)
* [Volume](/docs/api-reference/v1.6/#volume-v1-core)
* [Pod](/docs/api-reference/v1.6/#pod-v1-core)
* [Secret](/docs/api-reference/{{page.version}}/#secret-v1-core)
* [Volume](/docs/api-reference/{{page.version}}/#volume-v1-core)
* [Pod](/docs/api-reference/{{page.version}}/#pod-v1-core)
{% endcapture %}
@@ -47,10 +47,10 @@ In the configuration file, you can see that the Pod has a `downwardAPI` Volume,
and the Container mounts the Volume at `/etc`.
Look at the `items` array under `downwardAPI`. Each element of the array is a
[DownwardAPIVolumeFile](/docs/resources-reference/v1.6/#downwardapivolumefile-v1-core).
[DownwardAPIVolumeFile](/docs/resources-reference/{{page.version}}/#downwardapivolumefile-v1-core).
The first element specifies that the value of the Pod's
`metadata.labels` field should be stored in a file named `labels`.
The second element specifies that the value of the Pod's `annotations`
The second element specifies that the value of the Pod's `annotations`
field should be stored in a file named `annotations`.
**Note**: The fields in this example are Pod fields. They are not
@@ -149,7 +149,7 @@ Exit the shell:
## Store Container fields
The preceding exercise, you stored Pod fields in a DownwardAPIVolumeFile.
The preceding exercise, you stored Pod fields in a DownwardAPIVolumeFile.
In this next exercise, you store Container fields. Here is the configuration
file for a Pod that has one Container:
@@ -162,7 +162,7 @@ Look at the `items` array under `downwardAPI`. Each element of the array is a
DownwardAPIVolumeFile.
The first element specifies that in the Container named `client-container`,
the value of the `limits.cpu` field
the value of the `limits.cpu` field
should be stored in a file named `cpu_limit`.
Create the Pod:
@@ -238,11 +238,11 @@ inject the Pod's name into the well-known environment variable.
{% capture whatsnext %}
* [PodSpec](/docs/resources-reference/v1.6/#podspec-v1-core)
* [Volume](/docs/resources-reference/v1.6/#volume-v1-core)
* [DownwardAPIVolumeSource](/docs/resources-reference/v1.6/#downwardapivolumesource-v1-core)
* [DownwardAPIVolumeFile](/docs/resources-reference/v1.6/#downwardapivolumefile-v1-core)
* [ResourceFieldSelector](/docs/resources-reference/v1.6/#resourcefieldselector-v1-core)
* [PodSpec](/docs/resources-reference/{{page.version}}/#podspec-v1-core)
* [Volume](/docs/resources-reference/{{page.version}}/#volume-v1-core)
* [DownwardAPIVolumeSource](/docs/resources-reference/{{page.version}}/#downwardapivolumesource-v1-core)
* [DownwardAPIVolumeFile](/docs/resources-reference/{{page.version}}/#downwardapivolumefile-v1-core)
* [ResourceFieldSelector](/docs/resources-reference/{{page.version}}/#resourcefieldselector-v1-core)
{% endcapture %}
@@ -15,7 +15,7 @@ Pod fields and Container fields.
There are two ways to expose Pod and Container fields to a running Container:
environment variables and
[DownwardAPIVolumeFiles](/docs/resources-reference/v1.6/#downwardapivolumefile-v1-core).
[DownwardAPIVolumeFiles](/docs/resources-reference/{{page.version}}/#downwardapivolumefile-v1-core).
Together, these two ways of exposing Pod and Container fields are called the
*Downward API*.
@@ -36,7 +36,7 @@ Together, these two ways of exposing Pod and Container fields are called the
There are two ways to expose Pod and Container fields to a running Container:
* Environment variables
* [DownwardAPIVolumeFiles](/docs/resources-reference/v1.6/#downwardapivolumefile-v1-core)
* [DownwardAPIVolumeFiles](/docs/resources-reference/{{page.version}}/#downwardapivolumefile-v1-core)
Together, these two ways of exposing Pod and Container fields are called the
*Downward API*.
@@ -51,7 +51,7 @@ configuration file for the Pod:
In the configuration file, you can see five environment variables. The `env`
field is an array of
[EnvVars](/docs/resources-reference/v1.6/#envvar-v1-core).
[EnvVars](/docs/resources-reference/{{page.version}}/#envvar-v1-core).
The first element in the array specifies that the `MY_NODE_NAME` environment
variable gets its value from the Pod's `spec.nodeName` field. Similarly, the
other environment variables get their names from Pod fields.
@@ -128,7 +128,7 @@ container:
In the configuration file, you can see four environment variables. The `env`
field is an array of
[EnvVars](/docs/resources-reference/v1.6/#envvar-v1-core).
[EnvVars](/docs/resources-reference/{{page.version}}/#envvar-v1-core).
The first element in the array specifies that the `MY_CPU_REQUEST` environment
variable gets its value from the `requests.cpu` field of a Container named
`test-container`. Similarly, the other environment variables get their values
@@ -166,12 +166,12 @@ The output shows the values of selected environment variables:
{% capture whatsnext %}
* [Defining Environment Variables for a Container](/docs/tasks/configure-pod-container/define-environment-variable-container/)
* [PodSpec](/docs/resources-reference/v1.6/#podspec-v1-core)
* [Container](/docs/resources-reference/v1.6/#container-v1-core)
* [EnvVar](/docs/resources-reference/v1.6/#envvar-v1-core)
* [EnvVarSource](/docs/resources-reference/v1.6/#envvarsource-v1-core)
* [ObjectFieldSelector](/docs/resources-reference/v1.6/#objectfieldselector-v1-core)
* [ResourceFieldSelector](/docs/resources-reference/v1.6/#resourcefieldselector-v1-core)
* [PodSpec](/docs/resources-reference/{{page.version}}/#podspec-v1-core)
* [Container](/docs/resources-reference/{{page.version}}/#container-v1-core)
* [EnvVar](/docs/resources-reference/{{page.version}}/#envvar-v1-core)
* [EnvVarSource](/docs/resources-reference/{{page.version}}/#envvarsource-v1-core)
* [ObjectFieldSelector](/docs/resources-reference/{{page.version}}/#objectfieldselector-v1-core)
* [ResourceFieldSelector](/docs/resources-reference/{{page.version}}/#resourcefieldselector-v1-core)
{% endcapture %}
@@ -15,9 +15,9 @@ redirect_from:
## Overview
**Note**: The preferred way to create a replicated application is to use a
[Deployment](/docs/api-reference/v1.6/#deployment-v1beta1-apps),
[Deployment](/docs/api-reference/{{page.version}}/#deployment-v1beta1-apps),
which in turn uses a
[ReplicaSet](/docs/api-reference/v1.6/#replicaset-v1beta1-extensions).
[ReplicaSet](/docs/api-reference/{{page.version}}/#replicaset-v1beta1-extensions).
For more information, see
[Running a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).