In links to ref pages, use {{page.version}}.
steveperry-53
Andrew Chen
parent
28f3cfdd4f
commit
f9ac865c5f
|
|
@ -241,7 +241,7 @@ the node.
|
|||
|
||||
The amount of resources available to Pods is less than the node capacity, because
|
||||
system daemons use a portion of the available resources. The `allocatable` field
|
||||
[NodeStatus](/docs/resources-reference/v1.6/#nodestatus-v1-core)
|
||||
[NodeStatus](/docs/resources-reference/{{page.version}}/#nodestatus-v1-core)
|
||||
gives the amount of resources that are available to Pods. For more information, see
|
||||
[Node Allocatable Resources](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md).
|
||||
|
||||
|
|
@ -430,9 +430,9 @@ consistency across providers and platforms.
|
|||
* Get hands-on experience
|
||||
[assigning CPU and RAM resources to a container](/docs/tasks/configure-pod-container/assign-cpu-ram-container/).
|
||||
|
||||
* [Container](/docs/api-reference/v1.6/#container-v1-core)
|
||||
* [Container](/docs/api-reference/{{page.version}}/#container-v1-core)
|
||||
|
||||
* [ResourceRequirements](/docs/resources-reference/v1.6/#resourcerequirements-v1-core)
|
||||
* [ResourceRequirements](/docs/resources-reference/{{page.version}}/#resourcerequirements-v1-core)
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ This is equivalent to `kubectl create -f` the following yaml:
|
|||
|
||||
{% include code.html language="yaml" file="nginx-svc.yaml" ghlink="/docs/concepts/services-networking/nginx-svc.yaml" %}
|
||||
|
||||
This specification will create a Service which targets TCP port 80 on any Pod with the `run: my-nginx` label, and expose it on an abstracted Service port (`targetPort`: is the port the container accepts traffic on, `port`: is the abstracted Service port, which can be any port other pods use to access the Service). View [service API object](/docs/api-reference/v1.6/#service-v1-core) to see the list of supported fields in service definition.
|
||||
This specification will create a Service which targets TCP port 80 on any Pod with the `run: my-nginx` label, and expose it on an abstracted Service port (`targetPort`: is the port the container accepts traffic on, `port`: is the abstracted Service port, which can be any port other pods use to access the Service). View [service API object](/docs/api-reference/{{page.version}}/#service-v1-core) to see the list of supported fields in service definition.
|
||||
Check your Service:
|
||||
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ Pods become isolated by having a NetworkPolicy that selects them. Once there is
|
|||
|
||||
## The `NetworkPolicy` Resource
|
||||
|
||||
See the [api-reference](/docs/api-reference/v1.7/#networkpolicy-v1-networking) for a full definition of the resource.
|
||||
See the [api-reference](/docs/api-reference/{{page.version}}/#networkpolicy-v1-networking) for a full definition of the resource.
|
||||
|
||||
An example `NetworkPolicy` might look like this:
|
||||
|
||||
|
|
|
|||
|
|
@ -136,7 +136,7 @@ during application updates is configured in the controller spec.
|
|||
(Learn about [updating a deployment](/docs/concepts/cluster-administration/manage-deployment/#updating-your-application-without-a-service-outage).)
|
||||
|
||||
When a pod is evicted using the eviction API, it is gracefully terminated (see
|
||||
`terminationGracePeriodSeconds` in [PodSpec](/docs/resources-reference/v1.6/#podspec-v1-core).)
|
||||
`terminationGracePeriodSeconds` in [PodSpec](/docs/resources-reference/{{page.version}}/#podspec-v1-core).)
|
||||
|
||||
## PDB Example
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Init Containers are exactly like regular Containers, except:
|
|||
If an Init Container fails for a Pod, Kubernetes restarts the Pod repeatedly until the Init
|
||||
Container succeeds. However, if the Pod has a `restartPolicy` of Never, it is not restarted.
|
||||
|
||||
To specify a Container as an Init Container, add the `initContainers` field on the PodSpec as a JSON array of objects of type [v1.Container](/docs/api-reference/v1.6/#container-v1-core) alongside the app `containers` array.
|
||||
To specify a Container as an Init Container, add the `initContainers` field on the PodSpec as a JSON array of objects of type [v1.Container](/docs/api-reference/{{page.version}}/#container-v1-core) alongside the app `containers` array.
|
||||
The status of the init containers is returned in `status.initContainerStatuses`
|
||||
field as an array of the container statuses (similar to the `status.containerStatuses`
|
||||
field).
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ This page describes the lifecycle of a Pod.
|
|||
## Pod phase
|
||||
|
||||
A Pod's `status` field is a
|
||||
[PodStatus](/docs/resources-reference/v1.6/#podstatus-v1-core)
|
||||
[PodStatus](/docs/resources-reference/{{page.version}}/#podstatus-v1-core)
|
||||
object, which has a `phase` field.
|
||||
|
||||
The phase of a Pod is a simple, high-level summary of where the Pod is in its
|
||||
|
|
@ -55,7 +55,7 @@ Here are the possible values for `phase`:
|
|||
## Pod conditions
|
||||
|
||||
A Pod has a PodStatus, which has an array of
|
||||
[PodConditions](/docs/resources-reference/v1.6/#podcondition-v1-core). Each element
|
||||
[PodConditions](/docs/resources-reference/{{page.version}}/#podcondition-v1-core). Each element
|
||||
of the PodCondition array has a `type` field and a `status` field. The `type`
|
||||
field is a string, with possible values PodScheduled, Ready, Initialized, and
|
||||
Unschedulable. The `status` field is a string, with possible values True, False,
|
||||
|
|
@ -63,22 +63,22 @@ and Unknown.
|
|||
|
||||
## Container probes
|
||||
|
||||
A [Probe](/docs/resources-reference/v1.6/#probe-v1-core) is a diagnostic
|
||||
A [Probe](/docs/resources-reference/{{page.version}}/#probe-v1-core) is a diagnostic
|
||||
performed periodically by the [kubelet](/docs/admin/kubelet/)
|
||||
on a Container. To perform a diagnostic,
|
||||
the kubelet calls a
|
||||
[Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) implemented by
|
||||
the Container. There are three types of handlers:
|
||||
|
||||
* [ExecAction](/docs/resources-reference/v1.6/#execaction-v1-core):
|
||||
* [ExecAction](/docs/resources-reference/{{page.version}}/#execaction-v1-core):
|
||||
Executes a specified command inside the Container. The diagnostic
|
||||
is considered successful if the command exits with a status code of 0.
|
||||
|
||||
* [TCPSocketAction](/docs/resources-reference/v1.6/#tcpsocketaction-v1-core):
|
||||
* [TCPSocketAction](/docs/resources-reference/{{page.version}}/#tcpsocketaction-v1-core):
|
||||
Performs a TCP check against the Container's IP address on
|
||||
a specified port. The diagnostic is considered successful if the port is open.
|
||||
|
||||
* [HTTPGetAction](/docs/resources-reference/v1.6/#httpgetaction-v1-core):
|
||||
* [HTTPGetAction](/docs/resources-reference/{{page.version}}/#httpgetaction-v1-core):
|
||||
Performs an HTTP Get request against the Container's IP
|
||||
address on a specified port and path. The diagnostic is considered successful
|
||||
if the response has a status code greater than or equal to 200 and less than 400.
|
||||
|
|
@ -132,11 +132,11 @@ to stop.
|
|||
## Pod and Container status
|
||||
|
||||
For detailed information about Pod Container status, see
|
||||
[PodStatus](/docs/resources-reference/v1.6/#podstatus-v1-core)
|
||||
[PodStatus](/docs/resources-reference/{{page.version}}/#podstatus-v1-core)
|
||||
and
|
||||
[ContainerStatus](/docs/resources-reference/v1.6/#containerstatus-v1-core).
|
||||
[ContainerStatus](/docs/resources-reference/{{page.version}}/#containerstatus-v1-core).
|
||||
Note that the information reported as Pod status depends on the current
|
||||
[ContainerState](/docs/resources-reference/v1.6/#containerstatus-v1-core).
|
||||
[ContainerState](/docs/resources-reference/{{page.version}}/#containerstatus-v1-core).
|
||||
|
||||
## Restart policy
|
||||
|
||||
|
|
|
|||
|
|
@ -196,4 +196,4 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'
|
|||
|
||||
Pod is a top-level resource in the Kubernetes REST API. More details about the
|
||||
API object can be found at: [Pod API
|
||||
object](/docs/api-reference/v1.6/#pod-v1-core).
|
||||
object](/docs/api-reference/{{page.version}}/#pod-v1-core).
|
||||
|
|
|
|||
|
|
@ -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 %}
|
||||
|
||||
|
|
|
|||
|
|
@ -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 %}
|
||||
|
||||
|
|
|
|||
|
|
@ -85,9 +85,9 @@ 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
|
||||
|
|
|
|||
|
|
@ -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 %}
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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,7 +47,7 @@ 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`
|
||||
|
|
@ -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/).
|
||||
|
||||
|
|
|
|||
|
|
@ -952,7 +952,7 @@ template:
|
|||
- [Managing Kubernetes Objects Using Imperative Commands](/docs/tutorials/object-management-kubectl/imperative-object-management-command/)
|
||||
- [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tutorials/object-management-kubectl/imperative-object-management-configuration/)
|
||||
- [Kubectl Command Reference](/docs/user-guide/kubectl/v1.6/)
|
||||
- [Kubernetes Object Schema Reference](/docs/resources-reference/v1.6/)
|
||||
- [Kubernetes Object Schema Reference](/docs/resources-reference/{{page.version}}/)
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/concept.md %}
|
||||
|
|
|
|||
|
|
@ -156,7 +156,7 @@ kubectl create --edit -f /tmp/srv.yaml
|
|||
- [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tutorials/object-management-kubectl/imperative-object-management-configuration/)
|
||||
- [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tutorials/object-management-kubectl/declarative-object-management-configuration/)
|
||||
- [Kubectl Command Reference](/docs/user-guide/kubectl/v1.6/)
|
||||
- [Kubernetes Object Schema Reference](/docs/resources-reference/v1.6/)
|
||||
- [Kubernetes Object Schema Reference](/docs/resources-reference/{{page.version}}/)
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/concept.md %}
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ for a discussion of the advantages and disadvantage of each kind of object manag
|
|||
## How to create objects
|
||||
|
||||
You can use `kubectl create -f` to create an object from a configuration file.
|
||||
Refer to the [kubernetes object schema reference](/docs/resources-reference/v1.6/)
|
||||
Refer to the [kubernetes object schema reference](/docs/resources-reference/{{page.version}}/)
|
||||
for details.
|
||||
|
||||
- `kubectl create -f <filename|url>`
|
||||
|
|
@ -134,7 +134,7 @@ template:
|
|||
- [Managing Kubernetes Objects Using Imperative Commands](/docs/tutorials/object-management-kubectl/imperative-object-management-command/)
|
||||
- [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tutorials/object-management-kubectl/declarative-object-management-configuration/)
|
||||
- [Kubectl Command Reference](/docs/user-guide/kubectl/{{page.version}}/)
|
||||
- [Kubernetes Object Schema Reference](/docs/resources-reference/v1.6/)
|
||||
- [Kubernetes Object Schema Reference](/docs/resources-reference/{{page.version}}/)
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/concept.md %}
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ operation (create, replace, etc.), optional flags and at least one file
|
|||
name. The file specified must contain a full definition of the object
|
||||
in YAML or JSON format.
|
||||
|
||||
See the [resource reference](https://kubernetes.io/docs/resources-reference/v1.6/)
|
||||
See the [resource reference](https://kubernetes.io/docs/resources-reference/{{page.version}}/)
|
||||
for more details on object definitions.
|
||||
|
||||
**Warning:** The imperative `replace` command replaces the existing
|
||||
|
|
@ -173,7 +173,7 @@ Disadvantages compared to imperative object configuration:
|
|||
- [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tutorials/object-management-kubectl/imperative-object-management-configuration/)
|
||||
- [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tutorials/object-management-kubectl/declarative-object-management-configuration/)
|
||||
- [Kubectl Command Reference](/docs/user-guide/kubectl/{{page.version}}/)
|
||||
- [Kubernetes Object Schema Reference](/docs/resources-reference/v1.6/)
|
||||
- [Kubernetes Object Schema Reference](/docs/resources-reference/{{page.version}}/)
|
||||
|
||||
{% comment %}
|
||||
{% endcomment %}
|
||||
|
|
|
|||
Loading…
Reference in New Issue