Productspublished

Oracle Adds AMD GPU Operator to OKE for Broader GPU Lifecycle Management

The optional enhanced-cluster add-on broadens Oracle’s earlier device-plugin support into driver, health and configuration management, while leaving teams responsible for supported stack combinations and component sizing.

By 3 min read
Oracle Adds AMD GPU Operator to OKE for Broader GPU Lifecycle Management

Listen to this story

The audio brief

About 1:47
0:001:47
Read transcript
Oracle Kubernetes Engine is adding AMD’s GPU Operator as an optional add-on for enhanced clusters, giving platform teams a more complete way to manage AMD Instinct GPUs across their lifecycle. The important shift is from a device-plugin layer to a broader control plane. OKE previously supported AMD hardware through an AMD GPU Plugin add-on, but teams still had to handle more of the surrounding operations themselves. Now, the operator can coordinate hardware discovery, driver installation and upgrades, scheduling, monitoring, health checks, validation, and GPU configuration through OKE. Node Feature Discovery labels nodes with their AMD capabilities, while Kernel Module Management and the Controller Manager prepare the right driver modules before workloads are placed. Kubernetes exposes available capacity through the resource name “amd.com/gpu,” so applications can request GPUs in their pod specifications. Selectors, taints, and tolerations can further target or reserve specific nodes. On the operations side, the Device Metrics Exporter sends Prometheus metrics on utilization, temperature, and health. Unhealthy GPUs can then be withheld from schedulable capacity. Teams can also apply partitioning profiles and run diagnostics, stress, memory, PCIe bandwidth, or burn-in tests. But managed does not mean automatically compatible. The add-on only supports enhanced clusters, and administrators still need to verify OKE versions, node images, hardware, drivers, and add-on versions, then size the operator’s components. The constraint worth watching is whether that validation and sizing work remains manageable as GPU fleets grow.

Story brief

3 key points

Oracle has added AMD’s GPU Operator as an optional add-on for enhanced Oracle Kubernetes Engine (OKE) clusters, extending management beyond the earlier device-plugin integration. The operator can coordinate drivers, node discovery, scheduling, telemetry, health gating, configuration, and validation for AMD Instinct workloads. That reduces per-cluster installation and lifecycle work, but it is not a compatibility...

  1. 01

    Node Feature Discovery labels AMD Instinct capabilities; driver modules are installed and managed before workloads are scheduled.

  2. 02

    Kubernetes exposes GPUs through amd.com/gpu, while selectors, taints, and tolerations help target or reserve capacity.

  3. 03

    Prometheus metrics and health checks can keep unhealthy GPUs out of schedulable capacity.

Oracle Kubernetes Engine now offers the AMD GPU Operator as an optional add-on for enhanced clusters. The change gives platform teams an OKE-managed route to coordinate the drivers, discovery, scheduling, monitoring, validation and configuration needed around AMD Instinct GPU workloads.

More than a device-plugin layer

OKE previously supported AMD Instinct hardware through an AMD GPU Plugin add-on that managed the AMD Device Plugin for Kubernetes. The operator expands that foundation: rather than leaving teams to separately install and operate the operator in each cluster, its lifecycle can be managed through OKE.

Preparing nodes before workloads land

The operator uses Node Feature Discovery to detect AMD Instinct hardware and publish each node’s capabilities as Kubernetes labels. Kernel Module Management and the Controller Manager support installing, upgrading and removing GPU driver kernel modules according to the chosen configuration, helping ready worker nodes before GPU workloads are scheduled.

How workloads find capacity

  • The AMD GPU Device Plugin registers AMD Instinct GPUs as Kubernetes resources, including amd.com/gpu.
  • Application teams request those resources in pod specifications, allowing Kubernetes to place work on nodes with available GPU capacity.
  • Node selectors, taints, tolerations and GPU-specific labels can reserve or target nodes for particular hardware requirements.

Health checks and fleet-level configuration

The Device Metrics Exporter produces Prometheus-format data on GPU utilization, temperature and health. The operator can use health information with the device plugin so unhealthy GPUs are not offered as schedulable capacity.

For supported AMD Instinct environments, the Device Config Manager applies GPU-partitioning profiles stored in Kubernetes ConfigMaps to labeled nodes. The operator also includes a test runner for validation, diagnostics and benchmarking; depending on the selected test tooling, scenarios can include stress, PCIe bandwidth, memory and burn-in tests. It can run pre-start checks as init containers for GPU workload pods.

Managed does not mean automatic compatibility

The add-on is limited to enhanced clusters. Oracle directs teams to check supported combinations of OKE Kubernetes versions, AMD GPU worker-node images, hardware, drivers and add-on versions before enabling it. Administrators can select a supported add-on version, choose automatic updates or retain the deployed version, and apply supported configuration arguments.

Teams must also size operator-managed components for their environment. Oracle says requirements vary with GPU-node count, GPUs per node, monitoring frequency and workload intensity. The new add-on centralizes more of the software control plane, but it does not remove the need to validate the cluster stack and allocate operational resources for it.

Sources

  1. blogs.oracle.comSimplify AMD GPU Workloads on Oracle Kubernetes Engine with the AMD GPU Operator