This is a cache of https://docs.okd.io/latest/machine_management/cluster_api_machine_management/cluster-api-disabling.html. It is a snapshot of the page at 2025-07-01T18:51:24.530+0000.
Disabling the Cluster <strong>api</strong> - Managing machines with the Cluster <strong>api</strong> | Machine management | OKD 4
×

To stop using the Cluster api to automate the management of infrastructure resources on your OKD cluster, convert any Cluster api resources on your cluster to equivalent Machine api resources.

Managing machines with the Cluster api is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

Migrating Cluster api resources to Machine api resources

On clusters that support migrating between Machine api and Cluster api resources, the two-way synchronization controller supports converting a Cluster api resource to a Machine api resource.

The two-way synchronization controller only operates on clusters with the MachineapiMigration feature gate in the TechPreviewNoUpgrade feature set enabled.

You can migrate resources that you originally migrated from the Machine api to the Cluster api, or resources that you created as Cluster api resources initially. Migrating an original Machine api resource to a Cluster api resource and then migrating it back provides an opportunity to verify that the migration process works as expected.

You can only migrate some resources on supported infrastructure types.

Table 1. Supported resource conversions
Infrastructure Compute machine Compute machine set Machine health check Control plane machine set Cluster autoscaler

AWS

Technology Preview

Technology Preview

Not Available

Not Available

Not Available

All other infrastructure types

Not Available

Not Available

Not Available

Not Available

Not Available

Migrating a Cluster api resource to use the Machine api

You can migrate individual Cluster api objects to equivalent Machine api objects.

Migrating a Cluster api resource to use the Machine api is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

Prerequisites
  • You have deployed an OKD cluster on a supported infrastructure type.

  • You have enabled the MachineapiMigration feature gate in the TechPreviewNoUpgrade feature set.

  • You have access to the cluster using an account with cluster-admin permissions.

  • You have installed the OpenShift CLI (oc).

Procedure
  1. Identify the Cluster api resource that you want to migrate to a Machine api resource by running the following command:

    $ oc get <resource_kind> -n openshift-cluster-api

    where <resource_kind> is one of the following values:

    machine.cluster.x-k8s.io

    The fully qualified name of the resource kind for a compute or control plane machine.

    machineset.cluster.x-k8s.io

    The fully qualified name of the resource kind for a compute machine set.

  2. Edit the resource specification by running the following command:

    $ oc edit <resource_kind>/<resource_name> -n openshift-machine-api

    where:

    <resource_kind>

    Specifies a compute machine with machine.machine.openshift.io or compute machine set with machineset.machine.openshift.io.

    <resource_name>

    Specifies the name of the Machine api resource that corresponds to the Cluster api resource that you want to migrate to the Machine api.

  3. In the resource specification, update the value of the spec.authoritativeapi field:

    apiVersion: machine.openshift.io/v1beta1
    kind: <resource_kind> (1)
    metadata:
      name: <resource_name> (2)
      [...]
    spec:
      authoritativeapi: Machineapi (3)
      [...]
    status:
      authoritativeapi: Clusterapi (4)
      [...]
    1 The resource kind varies depending on the resource kind. For example, the resource kind for a compute machine set is MachineSet and the resource kind for a compute machine is Machine.
    2 The name of the resource that you want to migrate.
    3 Specify the authoritative api that you want this resource to use. For example, to start migrating a Cluster api resource to the Machine api, specify Machineapi.
    4 The value for the current authoritative api. This value indicates which api currently manages this resource. Do not change the value in this part of the specification.
Verification
  • Check the status of the conversion by running the following command:

    $ oc -n openshift-machine-api get <resource_kind>/<resource_name> -o json | jq .status.authoritativeapi

    where:

    <resource_kind>

    Specifies a compute machine with machine.machine.openshift.io or compute machine set with machineset.machine.openshift.io.

    <resource_name>

    Specifies the name of the Machine api resource that corresponds to the Cluster api resource that you want to migrate to the Machine api.

    • While the conversion progresses, this command returns a value of Migrating. If this value persists for a long time, check the logs for the cluster-capi-operator deployment in the openshift-cluster-api namespace for more information and to identify potential issues.

    • When the conversion is complete, this command returns a value of Machineapi.

    Do not delete any nonauthoritative resource that does not use the current authoritative api unless you want to delete the corresponding resource that does use the current authoritative api.

    When you delete a nonauthoritative resource that does not use the current authoritative api, the synchronization controller deletes the corresponding resource that does use the current authoritative api.