Releases: NVIDIA/k8s-device-plugin
Releases · NVIDIA/k8s-device-plugin
v0.7.0
- Promote v0.7.0-rc.8 to v0.7.0
v0.7.0-rc.8
- Permit configuration of alternative container registry through environment variables.
- Add an alternate set of gitlab-ci directives under .nvidia-ci.yml
- Update all k8s dependencies to v1.19.1
- Update vendoring for NVML Go bindings
- Move restart loop to force recreate of plugins on SIGHUP
v0.7.0-rc.7
- Fix bug which only allowed running the plugin on machines with CUDA 10.2+ installed
v0.7.0-rc.6
- Add logic to skip / error out when unsupported MIG device encountered
- Fix bug treating memory as multiple of 1000 instead of 1024
- Switch to using CUDA base images
- Add a set of standard tests to the .gitlab-ci.yml file
v0.7.0-rc.5
- Add deviceListStrategyFlag to allow device list passing as volume mounts
v0.7.0-rc.4
- Allow one to override selector.matchLabels in the helm chart
- Allow one to override the udateStrategy in the helm chart
v0.7.0-rc.3
- Fail the plugin if NVML cannot be loaded
- Update logging to print to stderr on error
- Add best effort removal of socket file before serving
- Add logic to implement GetPreferredAllocation() call from kubelet
v0.7.0-rc.2
- Add the ability to set 'resources' as part of a helm install
- Add overrides for name and fullname in helm chart
- Add ability to override image related parameters helm chart
- Add conditional support for overriding securityContext in helm chart
v0.7.0-rc.1
- Added migStrategy as a parameter to select the MIG strategy to the helm chart
- Add support for MIG with different strategies {none, single, mixed}
- Update vendored NVML bindings to latest (to include MIG APIs)
- Add license in UBI image
- Update UBI image with certification requirements
v0.7.0-rc.8
- Permit configuration of alternative container registry through environment variables.
- Add an alternate set of gitlab-ci directives under .nvidia-ci.yml
- Update all k8s dependencies to v1.19.1
- Update vendoring for NVML Go bindings
- Move restart loop to force recreate of plugins on SIGHUP
v0.7.0-rc.7
- Fix bug which only allowed running the plugin on machines with CUDA 10.2+ installed
v0.7.0-rc.6
- Add logic to skip / error out when unsupported MIG device encountered
- Fix bug treating memory as multiple of 1000 instead of 1024
- Switch to using CUDA base images
- Add a set of standard tests to the .gitlab-ci.yml file
v0.7.0-rc.5
- Add deviceListStrategyFlag to allow device list passing as volume mounts
v0.7.0-rc.4
- Allow one to override selector.matchLabels in the helm chart
- Allow one to override the udateStrategy in the helm chart
v0.7.0-rc.3
- Fail the plugin if NVML cannot be loaded
- Update logging to print to stderr on error
- Add best effort removal of socket file before serving
- Add logic to implement GetPreferredAllocation() call from kubelet
v0.7.0-rc.2
- Add the ability to set 'resources' as part of a helm install
- Add overrides for name and fullname in helm chart
- Add ability to override image related parameters helm chart
- Add conditional support for overriding securityContext in helm chart
v0.7.0-rc.1
- Added
migStrategy
as a parameter to select the MIG strategy to the helm chart - Add support for MIG with different strategies {none, single, mixed}
- Update vendored NVML bindings to latest (to include MIG APIs)
- Add license in UBI image
- Update UBI image with certification requirements
MIG support in this release has some known limitations when running under the mixed
strategy:
- Only one device type can be requested by a container at a time. If more than one device type is requested, it is undefined which one the container will actually get access to. For example, a container cannot request both an
nvidia.com/gpu
and annvidia.com/mig-3g.20gb
at the same time. However, it can request multiple instances of the same resource type (e.g.nvidia.com/gpu: 2
ornvidia.com/mig-3g.20gb: 2
) without problems. - If you do happen to request multiple resource types, kubernetes will still allocate / bill all of the resources to your container. You just wont be able to see / access any of them except one.
In practice, this shouldn't be a problem because CUDA wouldn't be able to leverage more than one of these resource types at a time anyway. That said, we plan to fix this problem by the time the full v0.7.0
release of this plugin becomes available. So stay tuned.