From d929d7a331251b4dfeb18f7ea5b3ae489f387f4a Mon Sep 17 00:00:00 2001 From: Steve Perry Date: Tue, 3 Oct 2017 17:25:46 -0700 Subject: [PATCH] Fix broken links. (#5750) --- docs/concepts/cluster-administration/device-plugins.md | 9 +++++---- docs/concepts/storage/volumes.md | 6 ++++-- 2 files changed, 9 insertions(+), 6 deletions(-) diff --git a/docs/concepts/cluster-administration/device-plugins.md b/docs/concepts/cluster-administration/device-plugins.md index 45c6da132b..eb689f535b 100644 --- a/docs/concepts/cluster-administration/device-plugins.md +++ b/docs/concepts/cluster-administration/device-plugins.md @@ -7,7 +7,8 @@ description: Use the Kubernetes device plugin framework to implement plugins for {% include feature-state-alpha.md %} {% capture overview %} -Starting in version 1.8, Kubernetes provides a [device plugin framework](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/device-plugin.md) +Starting in version 1.8, Kubernetes provides a +[device plugin framework](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md) for vendors to advertise their resources to the kubelet without changing Kubernetes core code. Instead of writing custom Kubernetes code, vendors can implement a device plugin that can be deployed manually or as a DaemonSet. The targeted devices include GPUs, @@ -57,7 +58,7 @@ The general workflow of a device plugin includes the following steps: * Initialization. During this phase, the device plugin performs vendor specific initialization and setup to make sure the devices are in a ready state. - + * The plugin starts a gRPC service, with a Unix socket under host path `/var/lib/kubelet/device-plugins/`, that implements the following interfaces: @@ -97,7 +98,7 @@ A device plugin can be deployed manually or as a DaemonSet. Being deployed as a the benefit that Kubernetes can restart the device plugin if it fails. Otherwise, an extra mechanism is needed to recover from device plugin failures. The canonical directory `/var/lib/kubelet/device-plugins` requires privileged access, -so a device plugin must run in a privileged security context. +so a device plugin must run in a privileged security context. If a device plugin is running as a DaemonSet, `/var/lib/kubelet/device-plugins` must be mounted as a [Volume](/docs/api-reference/{{page.version}}/#volume-v1-core) @@ -107,7 +108,7 @@ in the plugin's ## Examples For an example device plugin implementation, see -[nvidia GPU device plugin for COS base OS](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/nvidia_gpu). +[nvidia GPU device plugin for COS base OS](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu). {% endcapture %} diff --git a/docs/concepts/storage/volumes.md b/docs/concepts/storage/volumes.md index bd03bb9196..7d4e3b3bcc 100644 --- a/docs/concepts/storage/volumes.md +++ b/docs/concepts/storage/volumes.md @@ -99,7 +99,7 @@ exists as long as that Pod is running on that node. As the name says, it is initially empty. Containers in the pod can all read and write the same files in the `emptyDir` volume, though that volume can be mounted at the same or different paths in each container. When a Pod is removed from a node for -any reason, the data in the `emptyDir` is deleted forever. +any reason, the data in the `emptyDir` is deleted forever. **Note:** a container crashing does *NOT* remove a pod from a node, so the data in an `emptyDir` volume is safe across container crashes. {: .note} @@ -761,7 +761,9 @@ spec: fsType: ext4 ``` -For more information including Dynamic Provisioning and Persistent Volume Claims, please see the [StorageOS examples](https://github.com/kubernetes/examples/tree/{{page.githubbranch}}/staging/volumes/storageos). +For more information including Dynamic Provisioning and Persistent Volume Claims, please see the +[StorageOS examples](https://github.com/kubernetes/kubernetes/tree/master/examples/volumes/storageos). + ### local