calico should not watch the non-calico pods

[cyclinder]

Expected Behavior

calico should not watch the non-calico pods

Current Behavior

when a pod has only attached an ipvlan interface, I found this pod can be fetched by calicoctl get wep, and

apiVersion: v1
kind: Pod
metadata:
  annotations:
    ipam.spidernet.io/ippools: '[{"interface":"eth0","ipv4":["abc"]}]'
    k8s.v1.cni.cncf.io/network-status: |-
      [{
          "name": "spiderpool/ipvlan1-enp5s0f0np0",
          "interface": "eth0",
          "ips": [
              "172.17.9.101"
          ],
          "mac": "e8:eb:d3:93:7d:18",
          "default": true,
          "dns": {}
      }]
    v1.multus-cni.io/default-network: spiderpool/ipvlan1-enp5s0f0np0  --》 using ipvlan cni
  creationTimestamp: "2025-12-09T08:21:21Z"
  generateName: gfr-7c9b699654-
  generation: 1
  labels:
    app: gfr
    pod-template-hash: 7c9b699654
  name: gfr-7c9b699654-2hmlf
  namespace: default
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: gfr-7c9b699654
    uid: 1c5352c2-8c90-4547-88c5-295e12ec75e7
  resourceVersion: "50432428"
  uid: 4df5af38-640f-4a5d-82bb-10c107dec804

calicoctl get workloadendpoints -n default --allow-version-mismatch 
NAMESPACE   WORKLOAD                       NODE         NETWORKS            INTERFACE         
default     gfr-7c9b699654-2hmlf           10-20-1-60   172.17.9.101/32     cali003dacf0dee  

kubectl logs -n kube-system calico-node-pnvtr | grep gfr-7c9b699654-2hmlf
Defaulted container "calico-node" out of: calico-node, upgrade-ipam (init), install-cni (init), mount-bpffs (init)
2025-12-09 08:22:11.561 [INFO][103] felix/calc_graph.go 568: Local endpoint updated id=WorkloadEndpoint(node=10-20-1-60, orchestrator=k8s, workload=default/gfr-7c9b699654-2hmlf, name=eth0)
2025-12-09 08:22:11.561 [INFO][103] felix/int_dataplane.go 2201: Received *proto.WorkloadEndpointUpdate update from calculation graph. msg=id:{orchestrator_id:"k8s" workload_id:"default/gfr-7c9b699654-2hmlf" endpoint_id:"eth0"} endpoint:{state:"active" name:"cali003dacf0dee" profile_ids:"kns.default" profile_ids:"ksa.default.default" ipv4_nets:"172.17.9.101/32" annotations:{key:"k8s.v1.cni.cncf.io/network-status" value:"[{\n    \"name\": \"spiderpool/ipvlan1-enp5s0f0np0\",\n    \"interface\": \"eth0\",\n    \"ips\": [\n        \"172.17.9.101\"\n    ],\n    \"mac\": \"e8:eb:d3:93:7d:18\",\n    \"default\": true,\n    \"dns\": {}\n}]"}}
2025-12-09 08:22:11.561 [INFO][103] felix/endpoint_mgr.go 756: Updating per-endpoint chains. id=types.WorkloadEndpointID{OrchestratorId:"k8s", WorkloadId:"default/gfr-7c9b699654-2hmlf", EndpointId:"eth0"}
2025-12-09 08:22:11.562 [INFO][103] felix/endpoint_mgr.go 789: Updating endpoint routes. id=types.WorkloadEndpointID{OrchestratorId:"k8s", WorkloadId:"default/gfr-7c9b699654-2hmlf", EndpointId:"eth0"}
2025-12-09 08:22:11.562 [INFO][103] felix/endpoint_mgr.go 843: Updating QoS bandwidth state if changed id=types.WorkloadEndpointID{OrchestratorId:"k8s", WorkloadId:"default/gfr-7c9b699654-2hmlf", EndpointId:"eth0"}
2025-12-09 08:22:11.563 [INFO][103] felix/endpoint_mgr.go 631: Re-evaluated workload endpoint status adminUp=true failed=false known=true operUp=false status="down" workloadEndpointID=types.WorkloadEndpointID{OrchestratorId:"k8s", WorkloadId:"default/gfr-7c9b699654-2hmlf", EndpointId:"eth0"}
2025-12-09 08:22:11.563 [INFO][103] felix/status_combiner.go 62: Storing endpoint status update ipVersion=0x4 status="down" workload=types.WorkloadEndpointID{OrchestratorId:"k8s", WorkloadId:"default/gfr-7c9b699654-2hmlf", EndpointId:"eth0"}
2025-12-09 08:22:11.605 [INFO][103] felix/status_combiner.go 92: Endpoint down for at least one IP version id=types.WorkloadEndpointID{OrchestratorId:"k8s", WorkloadId:"default/gfr-7c9b699654-2hmlf", EndpointId:"eth0"} ipVersion=0x4 status="down"
2025-12-09 08:22:11.605 [INFO][103] felix/status_combiner.go 114: Reporting combined status. id=types.WorkloadEndpointID{OrchestratorId:"k8s", WorkloadId:"default/gfr-7c9b699654-2hmlf", EndpointId:"eth0"} status="down"

In our environment, we have a large number of Pods using ipvlan, which causes high resource consumption by calico-kube-controller and eventually leads to OOM and restarts. If Calico could only focus on Pods that use Calico networking, this would reduce resource consumption.

If you think this is reasonable, I can fix it.

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

• Calico version
• Calico dataplane (bpf, nftables, iptables, windows etc.)
• Orchestrator version (e.g. kubernetes, openshift, etc.):
• Operating System and version:
• Link to your project (optional):

[caseydavenport]

@cyclinder I'm not completely sure what you're proposing - how would Calico know which pods belong to it without watching them?

which causes high resource consumption by calico-kube-controller and eventually leads to OOM and restarts

I think it would be better to dig into this issue - why is there a high resource consumption and how can we reduce it?

[cyclinder]

@caseydavenport sorry for my explanation, For pods running in the cluster that do not use Calico networking (I think we should have some annotations to distinguish them), none of our components (controller, calico-node) should process them, and should not store information about these pods in memory. I can see that we can view information about these pods from calicoctl get weps, and a calixxxx virtual network interface is allocated for this pod, although it is not actually created. I think we should not process it. This can reduce some CPU and memory resource overhead.

As for the issue you mentioned about needing to investigate resource consumption, I think that's another problem.

[caseydavenport]

I think even if they aren't hooked up with Calico CNI, we'd still want Felix to know about them for policy enforcement purposes right (e.g., if they are selected in a policy rule and we need to learn the pod's IP)?

At a fundamental level, I'd rather fix the scale issues that come with having tons of pods than try to filter out certain pods. What if someone gets the annotation wrong? Or can someone use the annotation maliciously to impact application availability? It feels a bit scary to me.

I can see that we can view information about these pods from calicoctl get weps, and a calixxxx virtual network interface is allocated for this pod

We don't actually allocate an interface, we simply can predict deterministically what interface this pod would be assigned if it were created with Calico.