Skip to content

Remove Ambassador CRDs

Even after the migration to HAProxy is completed and the Ambassador is not deployed anymore, the Ambassador CustomResourceDefinitions will still be present in your cluster. Helm is not uninstalling them automatically because they are considered cluster-wide resources. The following steps can be used to check if the CRDs are still in use in the cluster, and give guidance on how to remove them manually if they are found unused.

The following 19 Ambassador CRDs were deployed as part of DX deployment:

  • filters.getambassador.io
  • filterpolicies.getambassador.io
  • authservices.getambassador.io
  • consulresolvers.getambassador.io
  • devportals.getambassador.io
  • hosts.getambassador.io
  • kubernetesendpointresolvers.getambassador.io
  • kubernetesserviceresolvers.getambassador.io
  • logservices.getambassador.io
  • mappings.getambassador.io
  • modules.getambassador.io
  • ratelimitservices.getambassador.io
  • tcpmappings.getambassador.io
  • tlscontexts.getambassador.io
  • tracingservices.getambassador.io
  • projects.getambassador.io
  • projectcontrollers.getambassador.io
  • projectrevisions.getambassador.io
  • ratelimits.getambassador.io

Check the clusters CustomResourceDefinitions

To check if the definitions are on the cluster, run the following command:

kubectl get crd --selector app.kubernetes.io/name=ambassador

This should return the 19 CRDs listed previously. If more CRDs are returned, it indicates that another Ambassador instance is deployed in your cluster. This needs to be taken into consideration when removing the CRDs

Check the clusters CustomResources

To see the actual resources that are using the CRDs above, run the following command:

kubectl get ambassador-crds --all-namespaces

If HCL Digital Experience is migrated to HAProxy and Ambassador is disabled, then the previous command should return the following message:

No resources found

Remove the CustomResourceDefinitions

If no resources are using CRDs, it is safe to remove the resources from the cluster by running the following command:

kubectl delete crd \
  filters.getambassador.io \
  filterpolicies.getambassador.io \
  authservices.getambassador.io \
  consulresolvers.getambassador.io \
  devportals.getambassador.io \
  hosts.getambassador.io \
  kubernetesendpointresolvers.getambassador.io \
  kubernetesserviceresolvers.getambassador.io \
  logservices.getambassador.io \
  mappings.getambassador.io \
  modules.getambassador.io \
  ratelimitservices.getambassador.io \
  tcpmappings.getambassador.io \
  tlscontexts.getambassador.io \
  tracingservices.getambassador.io \
  projects.getambassador.io \
  projectcontrollers.getambassador.io \
  projectrevisions.getambassador.io \
  ratelimits.getambassador.io

Restore CustomResourceDefinitions as fallback

In case you want the deleted CRDs back, you can restore them from the HCL Digital Experience Helm chart. To restore CRDs, unpack the CRDs and apply them by running the following command:

tar zxvf hcl-dx-deployment-vX.X.X_XXXXXXXX-XXXX.tar.gz hcl-dx-deployment/crds
kubectl apply -f ./hcl-dx-deployment/crds