diff --git a/docs/concepts/configuration/manage-compute-resources-container.md b/docs/concepts/configuration/manage-compute-resources-container.md index 12c0a30180..da0b5175bf 100644 --- a/docs/concepts/configuration/manage-compute-resources-container.md +++ b/docs/concepts/configuration/manage-compute-resources-container.md @@ -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 %} diff --git a/docs/concepts/services-networking/connect-applications-service.md b/docs/concepts/services-networking/connect-applications-service.md index b530f587fb..551ea80bb2 100644 --- a/docs/concepts/services-networking/connect-applications-service.md +++ b/docs/concepts/services-networking/connect-applications-service.md @@ -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 @@ -181,7 +181,7 @@ secret "nginxsecret" created $ kubectl get secrets NAME TYPE DATA AGE default-token-il9rc kubernetes.io/service-account-token 1 1d -nginxsecret Opaque 2 1m +nginxsecret Opaque 2 1m ``` Now modify your nginx replicas to start an https server using the certificate in the secret, and the Service, to expose both ports (80 and 443): diff --git a/docs/concepts/services-networking/network-policies.md b/docs/concepts/services-networking/network-policies.md index b57c04a7d0..63d464f8e0 100644 --- a/docs/concepts/services-networking/network-policies.md +++ b/docs/concepts/services-networking/network-policies.md @@ -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: diff --git a/docs/concepts/workloads/pods/disruptions.md b/docs/concepts/workloads/pods/disruptions.md index 79aa38bb9f..f0b460282e 100644 --- a/docs/concepts/workloads/pods/disruptions.md +++ b/docs/concepts/workloads/pods/disruptions.md @@ -102,7 +102,7 @@ voluntary disruptions. For example, a quorum-based application would like to ensure that the number of replicas running is never brought below the number needed for a quorum. A web front end might want to ensure that the number of replicas serving load never falls below a certain -percentage of the total. +percentage of the total. Cluster managers and hosting providers should use tools which respect Pod Disruption Budgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api) @@ -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 @@ -200,7 +200,7 @@ The cluster state now looks like this: | | pod-d *available* | pod-y | Now, the cluster admin tries to drain `node-2`. -The drain command will try to evict the two pods in some order, say +The drain command will try to evict the two pods in some order, say `pod-b` first and then `pod-d`. It will succeed at evicting `pod-b`. But, when it tries to evict `pod-d`, it will be refused because that would leave only one pod available for the deployment. @@ -234,7 +234,7 @@ and Application Owner as separate roles with limited knowledge of each other. This separation of responsibilities may make sense in these scenarios: -- when there are many application teams sharing a Kubernetes cluster, and +- when there are many application teams sharing a Kubernetes cluster, and there is natural specialization of roles - when third-party tools or services are used to automate cluster management @@ -249,7 +249,7 @@ you may not need to use Pod Disruption Budgets. If you are a Cluster Administrator, and you need to perform a disruptive action on all the nodes in your cluster, such as a node or system software upgrade, here are some options: -- Accept downtime during the upgrade. +- Accept downtime during the upgrade. - Fail over to another complete replica cluster. - No downtime, but may be costly both for the duplicated nodes, and for human effort to orchestrate the switchover. @@ -270,7 +270,7 @@ the nodes in your cluster, such as a node or system software upgrade, here are s * Learn more about [draining nodes](/docs/tasks/administer-cluster//safely-drain-node.md) -{% endcapture %} +{% endcapture %} {% include templates/concept.md %} diff --git a/docs/concepts/workloads/pods/init-containers.md b/docs/concepts/workloads/pods/init-containers.md index 50dfe247b2..f18583fd13 100644 --- a/docs/concepts/workloads/pods/init-containers.md +++ b/docs/concepts/workloads/pods/init-containers.md @@ -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). @@ -185,7 +185,7 @@ pod "myapp-pod" created $ kubectl get -f myapp.yaml NAME READY STATUS RESTARTS AGE myapp-pod 0/1 Init:0/2 0 6m -$ kubectl describe -f myapp.yaml +$ kubectl describe -f myapp.yaml Name: myapp-pod Namespace: default [...] diff --git a/docs/concepts/workloads/pods/pod-lifecycle.md b/docs/concepts/workloads/pods/pod-lifecycle.md index ea478e377d..9b7400e6f0 100644 --- a/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/docs/concepts/workloads/pods/pod-lifecycle.md @@ -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 diff --git a/docs/concepts/workloads/pods/pod.md b/docs/concepts/workloads/pods/pod.md index 17decef946..f49d4b12b2 100644 --- a/docs/concepts/workloads/pods/pod.md +++ b/docs/concepts/workloads/pods/pod.md @@ -153,7 +153,7 @@ Pod is exposed as a primitive in order to facilitate: * clean composition of Kubelet-level functionality with cluster-level functionality — Kubelet is effectively the "pod controller" * high-availability applications, which will expect pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions, image prefetching, or live pod migration [#3949](http://issue.k8s.io/3949) -There is new first-class support for stateful pods with the [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/) controller (currently in beta). The feature was alpha in 1.4 and was called [PetSet](/docs/concepts/workloads/controllers/petset/). For prior versions of Kubernetes, best practice for having stateful pods is to create a replication controller with `replicas` equal to `1` and a corresponding service, see [this MySQL deployment example](/docs/tutorials/stateful-application/run-stateful-application/). +There is new first-class support for stateful pods with the [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/) controller (currently in beta). The feature was alpha in 1.4 and was called [PetSet](/docs/concepts/workloads/controllers/petset/). For prior versions of Kubernetes, best practice for having stateful pods is to create a replication controller with `replicas` equal to `1` and a corresponding service, see [this MySQL deployment example](/docs/tutorials/stateful-application/run-stateful-application/). ## Termination of Pods @@ -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). diff --git a/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md index 4435b8c626..3350b90536 100644 --- a/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md +++ b/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md @@ -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 %} diff --git a/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/docs/tasks/administer-cluster/change-pv-reclaim-policy.md index 3ee13ff261..5b18dd7820 100644 --- a/docs/tasks/administer-cluster/change-pv-reclaim-policy.md +++ b/docs/tasks/administer-cluster/change-pv-reclaim-policy.md @@ -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 %} diff --git a/docs/tasks/configure-pod-container/assign-cpu-ram-container.md b/docs/tasks/configure-pod-container/assign-cpu-ram-container.md index 0f7dcf3185..8208c934b5 100644 --- a/docs/tasks/configure-pod-container/assign-cpu-ram-container.md +++ b/docs/tasks/configure-pod-container/assign-cpu-ram-container.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 %} diff --git a/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md index 84451b06f2..bac9c7fe4e 100644 --- a/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md +++ b/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md @@ -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 %} diff --git a/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md b/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md index 3d75725c91..51d44e6a02 100644 --- a/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md +++ b/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md @@ -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 %} diff --git a/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md index 1d8503caac..114d9a9588 100644 --- a/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md +++ b/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -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 %} diff --git a/docs/tasks/configure-pod-container/configure-volume-storage.md b/docs/tasks/configure-pod-container/configure-volume-storage.md index a0374272e1..7fad341494 100644 --- a/docs/tasks/configure-pod-container/configure-volume-storage.md +++ b/docs/tasks/configure-pod-container/configure-volume-storage.md @@ -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 diff --git a/docs/tasks/configure-pod-container/pull-image-private-registry.md b/docs/tasks/configure-pod-container/pull-image-private-registry.md index 6504824873..ef2058e3ab 100644 --- a/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -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 %} diff --git a/docs/tasks/configure-pod-container/security-context.md b/docs/tasks/configure-pod-container/security-context.md index fe00e519c4..85fcf20818 100644 --- a/docs/tasks/configure-pod-container/security-context.md +++ b/docs/tasks/configure-pod-container/security-context.md @@ -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) diff --git a/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md index 770b676f61..15932527ae 100644 --- a/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md +++ b/docs/tasks/debug-application-cluster/determine-reason-pod-failure.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/). diff --git a/docs/tasks/debug-application-cluster/monitor-node-health.md b/docs/tasks/debug-application-cluster/monitor-node-health.md index 49e2a2f0c9..fa4dde3532 100644 --- a/docs/tasks/debug-application-cluster/monitor-node-health.md +++ b/docs/tasks/debug-application-cluster/monitor-node-health.md @@ -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)) diff --git a/docs/tasks/inject-data-application/define-command-argument-container.md b/docs/tasks/inject-data-application/define-command-argument-container.md index 4dc1386c13..f9796c0b82 100644 --- a/docs/tasks/inject-data-application/define-command-argument-container.md +++ b/docs/tasks/inject-data-application/define-command-argument-container.md @@ -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 %} diff --git a/docs/tasks/inject-data-application/define-environment-variable-container.md b/docs/tasks/inject-data-application/define-environment-variable-container.md index e58867b205..8c44a145cc 100644 --- a/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -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 %} diff --git a/docs/tasks/inject-data-application/distribute-credentials-secure.md b/docs/tasks/inject-data-application/distribute-credentials-secure.md index 53e4abcf87..950d702bc3 100644 --- a/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -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 %} diff --git a/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md b/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md index b6abc3e7f4..3c64967cd7 100644 --- a/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md +++ b/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md @@ -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 %} diff --git a/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md index db23b2935f..4416852005 100644 --- a/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md +++ b/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md @@ -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 %} diff --git a/docs/tasks/run-application/rolling-update-replication-controller.md b/docs/tasks/run-application/rolling-update-replication-controller.md index 1eb797bee2..187b41496c 100644 --- a/docs/tasks/run-application/rolling-update-replication-controller.md +++ b/docs/tasks/run-application/rolling-update-replication-controller.md @@ -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/). diff --git a/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md b/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md index c7b52f005f..a2abda7455 100644 --- a/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md +++ b/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md @@ -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 %} diff --git a/docs/tutorials/object-management-kubectl/imperative-object-management-command.md b/docs/tutorials/object-management-kubectl/imperative-object-management-command.md index d4a0837e1c..b1e58854fd 100644 --- a/docs/tutorials/object-management-kubectl/imperative-object-management-command.md +++ b/docs/tutorials/object-management-kubectl/imperative-object-management-command.md @@ -83,7 +83,7 @@ The `kubectl` tool supports these additional ways to update a live object direct however they require a better understanding of the Kubernetes object schema. - `edit`: Directly edit the raw configuration of a live object by opening its configuration in an editor. -- `patch`: Directly modify specific fields of a live object by using a patch string. +- `patch`: Directly modify specific fields of a live object by using a patch string. For more details on patch strings, see the patch section in [API Conventions](https://git.k8s.io/community/contributors/devel/api-conventions.md#patch-operations). @@ -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 %} diff --git a/docs/tutorials/object-management-kubectl/imperative-object-management-configuration.md b/docs/tutorials/object-management-kubectl/imperative-object-management-configuration.md index a4c5557a7d..a6846e7fcd 100644 --- a/docs/tutorials/object-management-kubectl/imperative-object-management-configuration.md +++ b/docs/tutorials/object-management-kubectl/imperative-object-management-configuration.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 ` @@ -61,7 +61,7 @@ described in a configuration file. - `kubectl get -f -o yaml` -The `-o yaml` flag specifies that the full object configuration is printed. +The `-o yaml` flag specifies that the full object configuration is printed. Use `kubectl get -h` to see a list of options. ## Limitations @@ -71,7 +71,7 @@ configuration is fully defined and recorded in its configuration file. However when a live object is updated, and the updates are not merged into its configuration file, the updates will be lost the next time a `replace` is executed. This can happen if a controller, such as -a HorizontalPodAutoscaler, makes updates directly to a live object. Here's +a HorizontalPodAutoscaler, makes updates directly to a live object. Here's an example: 1. You create an object from a configuration file. @@ -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 %} diff --git a/docs/tutorials/object-management-kubectl/object-management.md b/docs/tutorials/object-management-kubectl/object-management.md index c87b36e508..38bb586e52 100644 --- a/docs/tutorials/object-management-kubectl/object-management.md +++ b/docs/tutorials/object-management-kubectl/object-management.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 %}