In links to ref pages, use {{page.version}}.
This commit is contained in:
committed by
Andrew Chen
parent
28f3cfdd4f
commit
f9ac865c5f
+2
-2
@@ -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/).
|
||||
|
||||
|
||||
Reference in New Issue
Block a user