calico: don't set calico-node cpu limits by default

[VannTen]

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
Upstream calico isn't doing that, and:

• this can cause throttling
• the cpu needed by calico is very cluster / workload dependent
• missing cpu limits will not starve other pods (unlike missing memory
  requests), because the kernel scheduler will still gives priority to
  other process in pods not exceeding their requests

See the slack thread for further details: https://kubernetes.slack.com/archives/C2V9WJSJD/p1737468771207299

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

calico-node pods no longer have a cpu limit by default

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: VannTen

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [VannTen]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[HoKim98]

In my personal opinion, according to "https://docs.tigera.io/calico/latest/getting-started/kubernetes/hardway/install-node#install-daemon-set", there seems to be no memory constraints (requests, limits). I think it would be nice to do the same for constraints other than calico_node_cpu_limit!

[VannTen]

I would agree, if not for the potential of breaking stuff. Removing the CPU limit is unlikely to have bad effects: - when there is CPU contention on a node, the containers are guaranteed their requests in CPU (module kube/system_reserved, that's another story), by throttling those exceeding their requests (by the kernel) - there is no node-pressure signal for CPU, because CPU is compressible. Concretely, that means that the only impact of that change should be: - pods exceeding their CPU requests might get throttled instead of Calico. OTOH, memory is not compressible. So an increased memory usage of calico could result in memory node pressure eviction, which is more disruptive than simply throttling. In the future, I'd like to be way closer to upstream (not just for calico), and when we do that we'll reconsider. But this needs extensive refactoring of the way kubespray deploy k8s objects, and this is not happening any time soon...

[yankay]

Thanks @VannTen @HoKim98
/lgtm