Delete a cluster machine using CLI

Available since 2.21.0 for non-MOSK clusters as TechPreview

This section instructs you on how to scale down an existing management, regional, or managed cluster through the Container Cloud API. To delete a machine using the Container Cloud web UI, see Delete a cluster machine using web UI.

Using the Container Cloud API, you can delete a cluster machine using the following methods:

• Recommended. Enable the delete field in the providerSpec section of the required Machine object. It allows aborting graceful machine deletion before the node is removed from Docker Swarm.

• Not recommended. Apply the delete request to the Machine object.

You can control machine deletion steps by following a specific machine deletion policy.

Overview of machine deletion policies

The deletion policy of the Machine resource used in the Container Cloud API defines specific steps occurring before a machine deletion.

The Container Cloud API contains the following types of deletion policies: graceful, unsafe, forced.

By default, the unsafe deletion policy is used. In future Container Cloud releases, the default policy will be changed to the graceful one.

You can change the deletion policy before the machine deletion. If the deletion process has already started, you can reduce the deletion policy restrictions in the following order only: graceful > unsafe > forced.

Graceful machine deletion

During a graceful machine deletion, the cloud provider and LCM controllers perform the following steps:

1. Cordon and drain the node being deleted.

2. Remove the node from Docker Swarm.

3. Send the delete request to the corresponding Machine resource.

4. Remove the provider resources such as the VM instance, network, volume, and so on. Remove the related Kubernetes resources.

5. Remove the finalizer from the Machine resource. This step completes the machine deletion from Kubernetes resources.

Caution

You can abort a graceful machine deletion only before the corresponding node is removed from Docker Swarm.

During a graceful machine deletion, the Machine object status displays prepareDeletionPhase with the following possible values:

• started

  Cloud provider controller prepares a machine for deletion by cordoning, draining the machine, and so on.

• completed

  LCM Controller starts removing the machine resources since the preparation for deletion is complete.

• aborting

  Cloud provider controller attempts to uncordon the node. If the attempt fails, the status changes to failed.

• failed

  Error in the deletion workflow.

Unsafe machine deletion

During an unsafe machine deletion, the cloud provider and LCM controllers perform the following steps:

1. Send the delete request to the corresponding Machine resource.

2. Remove the provider resources such as the VM instance, network, volume, and so on. Remove the related Kubernetes resources.

3. Remove the finalizer from the Machine resource. This step completes the machine deletion from Kubernetes resources.

Forced machine deletion

During a forced machine deletion, the cloud provider and LCM controllers perform the following steps:

1. Send the delete request to the corresponding Machine resource.

2. Remove the provider resources such as the VM instance, network, volume, and so on. Remove the related Kubernetes resources.

3. Remove the finalizer from the Machine resource. This step completes the machine deletion from Kubernetes resources.

This policy type allows deleting a Machine resource even if the cloud provider or LCM controller gets stuck at some step. But this policy may require a manual cleanup of machine resources in case of a сontroller failure. For details, see Delete a machine from a cluster using CLI.

Caution

Consider the following precautions applied to the forced machine deletion policy:

• Use the forced machine deletion only if either graceful or unsafe machine deletion fails.

• If the forced machine deletion fails at any step, the LCM Controller removes the finalizer anyway.

• Before starting the forced machine deletion, back up the related Machine resource:

  kubectl get machine -n <projectName> <machineName> -o json > deleted_machine.json
  

Delete a machine from a cluster using CLI

1. Carefully read the machine deletion precautions.

2. Log in to the Container Cloud web UI with the m:kaas:namespace@operator or m:kaas:namespace@writer permissions.

3. Log in to the host where your management cluster kubeconfig is located and where kubectl is installed.

4. For the Equinix Metal and bare metal providers, ensure that the machine being deleted is not a Ceph Monitor. If it is, migrate the Ceph Monitor to keep the odd number quorum of Ceph Monitors after the machine deletion. For details, see Migrate a Ceph Monitor before machine replacement.

5. If the machine is assigned to a machine pool, decrease replicas count of the pool as described in Change replicas count of a machine pool.

6. Select from the following options:

   • Recommended. In the providerSpec.value section of the Machine object, set delete to true:

     kubectl patch machines.cluster.k8s.io -n <projectName> <machineName> --type=merge -p '{"spec":{"providerSpec":{"value":{"delete":true}}}}'
     

     Replace the parameters enclosed in angle brackets with the corresponding values.

   • Delete the Machine object.

     kubectl delete machines.cluster.k8s.io -n <projectName> <machineName>
     

   After a successful unsafe or graceful machine deletion, the resources allocated to the machine are automatically freed up.

7. If you applied the forced machine deletion, verify that all machine resources are freed up. Otherwise, manually clean up resources:

   1. Delete the Kubernetes Node object related to the deleted Machine object:

      Note

      Since Container Cloud 2.23.0, skip this step as the system performs it automatically.

      1. Log in to the host where your managed cluster kubeconfig is located.

      2. Verify whether the Node object for the deleted Machine object still exists:

         kubectl get node $(jq -r '"kaas-node-" + (.metadata.annotations."kaas.mirantis.com/uid")' deleted_machine.json)
         

         If the system response is positive:

         1. Log in to the host where your management cluster kubeconfig is located.

         2. Delete the LcmMachine object with same name and project name as the deleted Machine object.

            kubectl delete lcmmachines.lcm.mirantis.com -n <projectName> <machineName>
            

   2. Clean up the provider-specific resources. Select from the following options:

      AWS

      1. Log in to the host that contains the following configuration:

         • Management cluster kubeconfig

         • AWS credentials configured

         • Required tools: kubectl, jq, aws CLI

      2. Obtain the ID of the EC2 instance that relates to the deleted machine:

         INSTANCE_ID=$(jq -r ".status.providerStatus.providerInstanceState.id" deleted_machine.json)
         

      3. Verify whether the EC2 instance still exists:

         aws ec2 describe-instances --instance-ids ${INSTANCE_ID}
         

         If the system response is positive, delete the EC2 instance:

         aws ec2 terminate-instances --instance-ids ${INSTANCE_ID}
         

      Azure

      1. Log in to the host that contains the following configuration:

         • Management cluster kubeconfig

         • Azure credentials configured

         • Required tools: kubectl, jq, az CLI

      2. Obtain the VM ID that relates to the deleted machine:

         VM_ID=$(jq -r '.status.providerID | sub ("^azure://"; "")' deleted_machine.json)
         

      3. Verify whether the VM still exists:

         az vm show --ids ${VM_ID}
         

         If the system response is positive, delete the VM:

         az vm delete --ids ${VM_ID}
         

      4. Delete the VM network:

         az network nic delete --ids $(az vm show --ids ${VM_ID} | jq -r '.networkProfile.networkInterfaces[].id')
         

      5. If the deleted machine had the manager role, delete the load balancing rules:

         RG=kaas-rg-$(kubectl get cluster -n <projectName> <clusterName> -o jsonpath='{.metadata.annotations.kaas\.mirantis\.com/uid}')
         
         LB_NAME=$(kubectl get cluster -n <projectName> <clusterName> -o jsonpath='{.status.providerStatus.network.apiServerLB.name}')
         
         NODE_NAME=$(jq -r '.status.instanceName' deleted_machine.json)
         
         az network lb inbound-nat-rule delete -g ${RG} --lb-name ${LB_NAME} -n ${NODE_NAME}
         

      Bare metal

      1. Log in to the host that contains the following configuration:

         • Management cluster kubeconfig

         • vSphere credentials configured

         • jq installed

      2. If the deleted machine was located on a managed cluster, delete the Ceph node as described in High-level workflow of Ceph OSD or node removal.

      3. Obtain the BareMetalHost object that relates to the deleted machine:

         BMH=$(jq -r '.metadata.annotations."metal3.io/BareMetalHost"| split("/") | .[1]' deleted_machine.json)
         

      4. Delete the BareMetalHost credentials:

         kubectl delete secret -n <projectName> <machineName>-user-data
         

      5. Deprovision the related BareMetalHost object:

         kubectl patch baremetalhost -n <projectName> ${BMH} --type merge --patch '{"spec": {"image": null, "userData": null, "online":false}}'
         kubectl patch baremetalhost -n <projectName> ${BMH} --type merge --patch '{"spec": {"consumerRef": null}}'
         

      Equinix Metal with private networking

      1. Log in to the host that contains the following configuration:

         • Management cluster kubeconfig

         • Equinix Metal credentials configured

         • Required tools: kubectl, jq, metal-cli

      2. If the deleted machine was located on a managed cluster, delete the Ceph node as described in High-level workflow of Ceph OSD or node removal.

      3. Delete the related BareMetalHost object:

         kubectl patch baremetalhost -n <projectName> <machineName> --type merge --patch '{"spec": {"automatedCleaningMode": disabled"}}'
         kubectl delete baremetalhost -n <projectName> <machineName>
         

      4. Delete the related BareMetalHost credentials:

         kubectl delete secret -n <projectName> <machineName>-user-data
         kubectl delete secret -n <projectName> <machineName>-bm-creds
         

      5. Delete the related IpamHost object:

         kubectl delete ipamhost -n <projectName> <machineName>
         

      6. Obtain the related device ID:

         DEVICE_ID=$(jq -r '.status.providerID| sub ("^packet://"; "")' deleted_machine.json)
         

      7. Verify whether the Equinix Metal device object still exists:

         metal device get -i ${DEVICE_ID}
         

         If the system response is positive, delete the device object:

         metal device delete -f -i ${DEVICE_ID}
         

      Equinix Metal with public networking

      1. Log in to the host that contains the following configuration:

         • Management cluster kubeconfig

         • Equinix Metal credentials configured

         • Required tools: kubectl, jq, metal-cli

      2. Obtain the related device ID:

         DEVICE_ID=$(jq -r '.status.providerID| sub ("^packet://"; "")' deleted_machine.json)
         

      3. Verify whether the Equinix Metal device object still exists:

         metal device get -i ${DEVICE_ID}
         

         If the system response is positive, delete the device object:

         metal device delete -f -i ${DEVICE_ID}
         

      OpenStack

      1. Log in to the host that contains the following configuration:

         • Management cluster kubeconfig

         • OpenStack credentials configured

         • Required tools: kubectl, jq, openstack-cli

      2. Obtain the instance ID of the deleted machine:

         SERVER_ID=$(jq -r ".status.providerStatus.providerInstanceState.id" deleted_machine.json)
         

      3. Verify whether the OpenStack server still exists:

         openstack server show ${SERVER_ID}
         

         If the system response is positive, delete the OpenStack server:

         openstack server delete ${SERVER_ID}
         

      4. Delete the floating IP on the related managed cluster:

         PORT=$(openstack port list --device-id <serverID> -c ID -f value)
         
         FLOATING=$(openstack floating ip list --port ${PORT} -c ID -f value)
         
         openstack floating ip delete ${FLOATING}
         

      vSphere

      1. Log in to the host that contains the following configuration:

         • Management cluster kubeconfig

         • vSphere credentials configured

         • Required tools: kubectl, jq, govc

      2. Obtain the VM UUID that relates to the deleted machine:

         VM_UUID=$(jq -r ".status.providerStatus.providerInstanceState.id" deleted_machine.json)
         

      3. Verify whether the VM still exists:

         govc vm.info -vm.uuid ${VM_UUID}
         

         If the system response is positive, delete the VM:

         govc vm.destroy -vm.uuid ${VM_UUID}