Use the deregisterjob.yaml file that is included with the antrea-interworking-version.zip file to deregister an Antrea container cluster from NSX-T Data Center.

Prerequisites

Open the deregisterjob.yaml file in a text editor and replace the image URLs with any one these container images that are hosted on VMware Harbor Registry.

  • projects.registry.vmware.com/antreainterworking/interworking-debian:version
  • projects.registry.vmware.com/antreainterworking/interworking-ubuntu:version
  • projects.registry.vmware.com/antreainterworking/interworking-photon:version

For version information, see the VMware Container Networking with Antrea release notes at https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/index.html.

If your Kubernetes cluster does not have Internet access, you can find the container images in the antrea-interworking-version.zip file, which you downloaded before registering the container cluster. If the interworking Deployment is running in the container cluster, the container images are already loaded on the cluster nodes. The deregister job and the interworking Deployment use the same container images.

Procedure

  1. Run the following kubectl command to submit the deregisterjob.yaml file to the Kubernetes API server.
    $ kubectl apply -f deregisterjob.yaml
    This job takes some time to complete. The following actions happen in the background:
    • Deletes the interworking Deployment.
    • Deletes the resources of the Antrea container cluster from the NSX-T inventory. The resources include Pods, Services, Ingress Rules, Nodes, and Network Policies.
    • Removes references to the Antrea container cluster in the Distributed Firewall policies and groups (if any).
    • Deletes the Antrea custom resources, which were managed by NSX-T from the Kubernetes cluster. These custom resources include: Traceflow, ClusterNetworkPolicy, ClusterGroup, and Tier.
    Note: If you deregister an Antrea container cluster by using the following NSX-T API, the Kubernetes resources are not deleted. But, the references to the container cluster in the NSX-managed Distributed Firewall policies and groups are deleted: 
    DELETE https://{nsx-mgr-ip}/policy/api/v1/infra/sites/{siteid}/enforcement-points/{enforcementpoint-id}/cluster-control-planes/{cluster-name}?cascade=true

    For more information about this API, see the NSX-T Data Center API Guide.

  2. Check the status of the deregister job by running the following kubectl command:
    kubectl get job -o wide deregister -n vmware-system-antrea

    Wait for the job to complete. You might have to run this command a few times to check the status of the job.

  3. After the deregister job is completed, run the following kubectl command to delete the vmware-system-antrea namespace and the role-based access control (RBAC) resources.
    kubectl delete -f interworking.yaml --ignore-not-found

    The ignore-not-found flag is used in this command to avoid the Resource Not Found error in the command output if some resources are not found for deletion.

    RBAC resources, such as ServiceAccount, ClusterRole, and ClusterRoleBinding are deleted.

What to do next

Verify that the Antrea container cluster is not shown in the NSX-T inventory.
  1. In the NSX Manager UI, navigate to Inventory > Containers > Clusters.
  2. Observe that the Antrea container cluster is not shown in the inventory.
Optional: After deregistering the container cluster, delete the principal identity (PI) user and the self-signed certificate.
  • To delete the PI user account, navigate to System > User Management > User Role Assignment. Next to the PI user name, click Actions menu, and then click Delete.
  • To delete the self-signed certificate, navigate to System > Certificates. Next to the certificate name, click Actions menu, and then click Delete.
If required, you can re-register the same Antrea container cluster. However, before re-registering the container cluster, ensure that you have run the following kubectl command: 
kubectl delete -f interworking.yaml --ignore-not-found
To re-register the same container cluster, do any one of the following:
  • If you want to reuse the same PI user account and self-signed certificate for re-registering the container cluster, do not delete PI user account and the self-signed certificate from NSX-T. In this case, no changes are required in the bootstrap-config.yaml.
  • If you want to use a new PI user account and self-signed certificate for re-registering the container cluster, delete the old PI user account and the self-signed certificate. Begin the process by creating a self-signed certificate and use this new certificate to create a PI user account. Edit the tls.crt and tsl.key arguments in the bootstrap-config.yaml with the information of this new PI user.