From 98acba1ffbc906f06c7bb45a756291e79f70db72 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Thu, 3 May 2018 07:48:01 +0000 Subject: [PATCH] Remove docs related to in-tree support to GPU The in-tree support to GPU is completely removed in release 1.11. This PR removes the related docs in release-1.11 branch. xref: kubernetes/kubernetes#61498 --- .../manage-compute-resources-container.md | 48 ++++++-------- .../extended-resource-node.md | 25 ++++--- .../docs/tasks/manage-gpus/scheduling-gpus.md | 65 ------------------- 3 files changed, 31 insertions(+), 107 deletions(-) diff --git a/content/en/docs/concepts/configuration/manage-compute-resources-container.md b/content/en/docs/concepts/configuration/manage-compute-resources-container.md index decd1f6e60eba..92d90918bad27 100644 --- a/content/en/docs/concepts/configuration/manage-compute-resources-container.md +++ b/content/en/docs/concepts/configuration/manage-compute-resources-container.md @@ -1,9 +1,8 @@ --- title: Managing Compute Resources for Containers -content_template: templates/concept --- -{{% capture overview %}} +{% capture overview %} When you specify a [Pod](/docs/concepts/workloads/pods/pod/), you can optionally specify how much CPU and memory (RAM) each Container needs. When Containers have resource @@ -13,10 +12,10 @@ resources on a node can be handled in a specified manner. For more details about the difference between requests and limits, see [Resource QoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md). -{{% /capture %}} +{% endcapture %} -{{% capture body %}} +{% capture body %} ## Resource types @@ -143,9 +142,8 @@ When using Docker: multiplied by 100. The resulting value is the total amount of CPU time that a container can use every 100ms. A container cannot use more than its share of CPU time during this interval. - {{< note >}} **Note**: The default quota period is 100ms. The minimum resolution of CPU quota is 1ms. - {{< /note >}} + {: .note} - The `spec.containers[].resources.limits.memory` is converted to an integer, and used as the value of the @@ -170,7 +168,7 @@ resource limits, see the The resource usage of a Pod is reported as part of the Pod status. -If [optional monitoring](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/README.md) +If [optional monitoring](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/cluster-monitoring/README.md) is configured for your cluster, then Pod resource usage can be retrieved from the monitoring system. @@ -208,12 +206,10 @@ $ kubectl describe nodes e2e-test-minion-group-4lw4 Name: e2e-test-minion-group-4lw4 [ ... lines removed for clarity ...] Capacity: - alpha.kubernetes.io/nvidia-gpu: 0 cpu: 2 memory: 7679792Ki pods: 110 Allocatable: - alpha.kubernetes.io/nvidia-gpu: 0 cpu: 1800m memory: 7474992Ki pods: 110 @@ -241,7 +237,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/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core) +[NodeStatus](/docs/reference/generated/kubernetes-api/{{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/node-allocatable.md). @@ -299,25 +295,24 @@ Container in the Pod was terminated and restarted five times. You can call `kubectl get pod` with the `-o go-template=...` option to fetch the status of previously terminated Containers: -```shell +```shell{% raw %} [13:59:01] $ kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99 Container Name: simmemleak -LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]] +LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]]{% endraw %} ``` You can see that the Container was terminated because of `reason:OOM Killed`, where `OOM` stands for Out Of Memory. ## Local ephemeral storage -{{< feature-state state="beta" >}} +{% include feature-state-beta.md %} Kubernetes version 1.8 introduces a new resource, _ephemeral-storage_ for managing local ephemeral storage. In each Kubernetes node, kubelet's root directory (/var/lib/kubelet by default) and log directory (/var/log) are stored on the root partition of the node. This partition is also shared and consumed by pods via EmptyDir volumes, container logs, image layers and container writable layers. This partition is “ephemeral” and applications cannot expect any performance SLAs (Disk IOPS for example) from this partition. Local ephemeral storage management only applies for the root partition; the optional partition for image layer and writable layer is out of scope. -{{< note >}} **Note:** If an optional runtime partition is used, root partition will not hold any image layer or writable layers. -{{< /note >}} +{: .note} ### Requests and limits setting for local ephemeral storage Each Container of a Pod can specify one or more of the following: @@ -416,12 +411,11 @@ curl --header "Content-Type: application/json-patch+json" \ http://k8s-master:8080/api/v1/nodes/k8s-node-1/status ``` -{{< note >}} **Note**: In the preceding request, `~1` is the encoding for the character `/` in the patch path. The operation path value in JSON-Patch is interpreted as a JSON-Pointer. For more details, see [IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3). -{{< /note >}} +{: .note} #### Cluster-level extended resources @@ -471,18 +465,16 @@ The API server restricts quantities of Extended Resources to whole numbers. Examples of _valid_ quantities are `3`, `3000m` and `3Ki`. Examples of _invalid_ quantities are `0.5` and `1500m`. -{{< note >}} **Note:** Extended Resources replace Opaque Integer Resources. Users can use any domain name prefix other than "`kubernetes.io`" which is reserved. -{{< /note >}} +{: .note} To consume an Extended Resource in a Pod, include the resource name as a key in the `spec.containers[].resources.limits` map in the container spec. -{{< note >}} **Note:** Extended resources cannot be overcommitted, so request and limit must be equal if both are present in a container spec. -{{< /note >}} +{: .note} A Pod is scheduled only if all of the resource requests are satisfied, including CPU, memory and any Extended Resources. The Pod remains in the `PENDING` state @@ -519,7 +511,7 @@ all Containers in a Pod, such as Kubernetes version 1.5 only supports Container requests and limits for CPU and memory. It is planned to add new resource types, including a node disk space resource, and a framework for adding custom -[resource types](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/scheduling/resources.md). +[resource types](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/scheduling/resources.md). Kubernetes supports overcommitment of resources by supporting multiple levels of [Quality of Service](http://issue.k8s.io/168). @@ -531,19 +523,19 @@ For example, on AWS, the capacity of a node is reported in cores. We plan to revise the definition of the cpu resource to allow for more consistency across providers and platforms. -{{% /capture %}} +{% endcapture %} -{{% capture whatsnext %}} +{% capture whatsnext %} * Get hands-on experience [assigning Memory resources to containers and pods](/docs/tasks/configure-pod-container/assign-memory-resource/). * Get hands-on experience [assigning CPU resources to containers and pods](/docs/tasks/configure-pod-container/assign-cpu-resource/). -* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) - -* [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) +* [Container](/docs/reference/generated/kubernetes-api/{{page.version}}/#container-v1-core) -{{% /capture %}} +* [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{page.version}}/#resourcerequirements-v1-core) +{% endcapture %} +{% include templates/concept.md %} diff --git a/content/en/docs/tasks/administer-cluster/extended-resource-node.md b/content/en/docs/tasks/administer-cluster/extended-resource-node.md index 5c2419f061675..dd9409261f140 100644 --- a/content/en/docs/tasks/administer-cluster/extended-resource-node.md +++ b/content/en/docs/tasks/administer-cluster/extended-resource-node.md @@ -1,28 +1,27 @@ --- title: Advertise Extended Resources for a Node -content_template: templates/task --- -{{% capture overview %}} +{% capture overview %} This page shows how to specify extended resources for a Node. Extended resources allow cluster administrators to advertise node-level resources that would otherwise be unknown to Kubernetes. -{{< feature-state state="stable" >}} +{% include feature-state-stable.md %} -{{% /capture %}} +{% endcapture %} -{{% capture prerequisites %}} +{% capture prerequisites %} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{% include task-tutorial-prereqs.md %} -{{% /capture %}} +{% endcapture %} -{{% capture steps %}} +{% capture steps %} ## Get the names of your Nodes @@ -83,7 +82,6 @@ The output shows that the Node has a capacity of 4 dongles: ``` "capacity": { - "alpha.kubernetes.io/nvidia-gpu": "0", "cpu": "2", "memory": "2049008Ki", "example.com/dongle": "4", @@ -99,7 +97,6 @@ Once again, the output shows the dongle resource: ```yaml Capacity: - alpha.kubernetes.io/nvidia-gpu: 0 cpu: 2 memory: 2049008Ki example.com/dongle: 4 @@ -189,10 +186,10 @@ Verify that the dongle advertisement has been removed: kubectl describe node | grep dongle ``` -{{% /capture %}} +{% endcapture %} -{{% capture whatsnext %}} +{% capture whatsnext %} ### For application developers @@ -204,7 +201,7 @@ kubectl describe node | grep dongle * [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/) -{{% /capture %}} - +{% endcapture %} +{% include templates/task.md %} diff --git a/content/en/docs/tasks/manage-gpus/scheduling-gpus.md b/content/en/docs/tasks/manage-gpus/scheduling-gpus.md index 5f548e435269b..1059de12f511c 100644 --- a/content/en/docs/tasks/manage-gpus/scheduling-gpus.md +++ b/content/en/docs/tasks/manage-gpus/scheduling-gpus.md @@ -143,68 +143,3 @@ spec: This will ensure that the pod will be scheduled to a node that has the GPU type you specified. - -## v1.6 and v1.7 -To enable GPU support in 1.6 and 1.7, a special **alpha** feature gate -`Accelerators` has to be set to true across the system: -`--feature-gates="Accelerators=true"`. It also requires using the Docker -Engine as the container runtime. - -Further, the Kubernetes nodes have to be pre-installed with NVIDIA drivers. -Kubelet will not detect NVIDIA GPUs otherwise. - -When you start Kubernetes components after all the above conditions are true, -Kubernetes will expose `alpha.kubernetes.io/nvidia-gpu` as a schedulable -resource. - -You can consume these GPUs from your containers by requesting -`alpha.kubernetes.io/nvidia-gpu` just like you request `cpu` or `memory`. -However, there are some limitations in how you specify the resource requirements -when using GPUs: -- GPUs are only supposed to be specified in the `limits` section, which means: - * You can specify GPU `limits` without specifying `requests` because - Kubernetes will use the limit as the request value by default. - * You can specify GPU in both `limits` and `requests` but these two values - must be equal. - * You cannot specify GPU `requests` without specifying `limits`. -- Containers (and pods) do not share GPUs. There's no overcommitting of GPUs. -- Each container can request one or more GPUs. It is not possible to request a - fraction of a GPU. - -When using `alpha.kubernetes.io/nvidia-gpu` as the resource, you also have to -mount host directories containing NVIDIA libraries (libcuda.so, libnvidia.so -etc.) to the container. - -Here's an example: - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: cuda-vector-add -spec: - restartPolicy: OnFailure - containers: - - name: cuda-vector-add - # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile - image: "k8s.gcr.io/cuda-vector-add:v0.1" - resources: - limits: - alpha.kubernetes.io/nvidia-gpu: 1 # requesting 1 GPU - volumeMounts: - - name: "nvidia-libraries" - mountPath: "/usr/local/nvidia/lib64" - volumes: - - name: "nvidia-libraries" - hostPath: - path: "/usr/lib/nvidia-375" -``` - -The `Accelerators` feature gate and `alpha.kubernetes.io/nvidia-gpu` resource -works on 1.8 and 1.9 as well. It will be deprecated in 1.10 and removed in -1.11. - -## Future -- Support for hardware accelerators in Kubernetes is still in alpha. -- Better APIs will be introduced to provision and consume accelerators in a scalable manner. -- Kubernetes will automatically ensure that applications consuming GPUs get the best possible performance.