kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

node: devicemgr: docs: Kubelet Device Manager graduation to GA 

Signed-off-by: Swati Sehgal <swsehgal@redhat.com>
This commit is contained in:
Swati Sehgal 2022-10-11 18:55:22 +01:00
parent e11d51afdc
commit 65f244bc3a
1 changed files with 17 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
View File

@ -6,7 +6,7 @@ weight: 20
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
{{< feature-state for_k8s_version="v1.26" state="stable" >}}
Kubernetes provides a [device plugin framework](https://git.k8s.io/design-proposals-archive/resource-management/device-plugin.md)
that you can use to advertise system hardware resources to the
@ -164,16 +164,25 @@ Pod onto Nodes, to restart the daemon Pod after failure, and to help automate up
## API compatibility
Kubernetes device plugin support is in beta. The API may change before stabilization,
in incompatible ways. As a project, Kubernetes recommends that device plugin developers:
Prior to v1.10, the versioning scheme required the Device Plugin's API version to
match exactly the Kubelet's version. On graduation of this feature to Beta in v1.12
this is no longer a hard requirement. The API is versioned and has been stable since
Beta graduation of this feature. Because of this, Kubelet upgrades should be seamless
but there still may be changes in the API before stabilization making upgrades not
guaranteed to be non-breaking.
* Watch for changes in future releases.
NOTE: Graduation of Device Manager to a stable feature in v1.26 does not imply
graduation of device plugin API to a stable API.
As a project, Kubernetes recommends that device plugin developers:
* Watch for Device Plugin API changes in the future releases.
* Support multiple versions of the device plugin API for backward/forward compatibility.
If you enable the DevicePlugins feature and run device plugins on nodes that need to be upgraded to
a Kubernetes release with a newer device plugin API version, upgrade your device plugins
to support both versions before upgrading these nodes. Taking that approach will
ensure the continuous functioning of the device allocations during the upgrade.
To run device plugins on nodes that need to be upgraded to a Kubernetes release with
a newer device plugin API version, upgrade your device plugins to support both versions
before upgrading these nodes. Taking that approach will ensure the continuous functioning
of the device allocations during the upgrade.
## Monitoring device plugin resources