Introduction

Removing Calico from a Kubernetes cluster is not a routine cleanup step. It is a cluster networking change, which means pod networking, network policy behavior, and even node readiness can be disrupted if you remove Calico before another CNI is ready. The safest approach is to identify how Calico was installed, preserve the networking settings you need, and install or prepare the replacement before tearing Calico out.

First Decide What “Remove Calico” Means

There are two very different scenarios:

1. you want to uninstall Calico completely and accept downtime
2. you want to replace Calico with another CNI and keep the cluster usable

The second case is harder. Kubernetes normally expects exactly one active CNI configuration per node, so replacement must be planned carefully.

Before touching anything, inspect the current state:

1kubectl get pods -A | grep -i calico
2kubectl get ds -A | grep -i calico
3kubectl get deployment -A | grep -i tigera
4kubectl get installation.operator.tigera.io -A

This tells you whether Calico was installed through:

• raw manifests
• the Tigera operator
• a custom platform workflow

The uninstall steps depend on that.

Back Up What Calico Owns

Before deletion, export anything you may need later:

kubectl get ippools.crd.projectcalico.org -o yaml > calico-ippools.yaml
kubectl get felixconfigurations.crd.projectcalico.org -o yaml > calico-felix.yaml
kubectl get networkpolicies -A -o yaml > k8s-networkpolicies.yaml

If you use Calico-specific resources such as global network policies, back those up too. Even if your replacement CNI supports network policy, the policy model may not map one-to-one.

If Calico Was Installed With the Operator

Operator-managed installs usually include Tigera resources such as an Installation custom resource. In that case, do not start by randomly deleting daemonsets. Remove the operator-managed resources in the order that matches your environment.

A typical path is:

1kubectl get installation default -o yaml
2kubectl delete installation default
3kubectl delete apiserver default
4kubectl delete -f tigera-operator.yaml

The exact names can differ, so inspect the actual objects in the cluster before deleting.

The key point is that operator installs should be removed through operator-managed resources first, not by manually deleting only the pods.

If Calico Was Installed From Manifests

For manifest-based installs, removal usually means deleting the same manifest set that created Calico:

kubectl delete -f calico.yaml

or, if your cluster used split manifests, deleting those exact files in reverse order.

This removes cluster resources such as:

• 'calico-node'
• 'calico-kube-controllers'
• Calico CRDs and RBAC
• ConfigMaps and service accounts

Again, use the same source manifest that was applied originally if possible. That is safer than trying to delete pieces one by one from memory.

Clean Up CNI Files on the Nodes

Even after Kubernetes resources are deleted, node-level CNI files may still point to Calico. Check the standard locations on each node:

ls /etc/cni/net.d
ls /opt/cni/bin

Calico commonly leaves:

• a CNI config file in /etc/cni/net.d
• binaries such as calico and calico-ipam in /opt/cni/bin

Do not remove these blindly until the replacement CNI is ready. If Calico is the only active CNI configuration and you delete those files first, new pods will not get networking.

Replacing Calico With Another CNI

If your real goal is migration, the broad workflow is:

1. understand the current pod CIDR and service CIDR
2. install the replacement CNI according to its migration guidance
3. make sure its CNI config becomes the active node config
4. only then remove Calico resources and leftover node files

This step is highly CNI-specific. Flannel, Cilium, Weave, and others do not all migrate the same way. The most important rule is simple: do not uninstall the current CNI before the cluster has a viable replacement path.

Validate After Removal

After removal or migration, check node and pod networking:

1kubectl get nodes
2kubectl get pods -A
3kubectl run netcheck --image=busybox --restart=Never -- sleep 3600
4kubectl exec -it netcheck -- ping -c 3 kubernetes.default.svc.cluster.local

Also verify:

• DNS resolution
• pod-to-pod traffic
• service access
• network policy behavior if you still use it

A cluster can look superficially healthy while networking is only partially functional.

Common Pitfalls

The biggest pitfall is deleting Calico before another CNI is installed and active. That usually breaks pod networking immediately.

Another common mistake is removing only the Calico pods and forgetting the node-level CNI files in /etc/cni/net.d and /opt/cni/bin.

People also often forget that Calico may manage more than basic networking. IP pools, policy resources, and BGP configuration can all matter to the cluster design.

Finally, do not assume every Calico install was manifest-based. Operator-managed clusters should be uninstalled through the operator resources, not by deleting a few workloads manually.

Summary

• Identify whether Calico was installed via manifests or the Tigera operator.
• Back up Calico-specific resources and any policies you care about.
• Do not remove node-level CNI files before a replacement CNI is ready.
• If you are migrating, install and validate the new CNI before fully removing Calico.
• Always test node and pod networking after the change.