[Question] Right way to deploy Calico in RKE

[HectorB-2020]

RKE version: rke version v1.4.6
Docker version: 20.10.24
Operating system and kernel: CentOS 7.9, 3.10.0-1160.el7.x86_64
Type/provider of hosts: QEMU/KVM on kernel 5.10.152
Question:
I've been studying documentation and stuck at the point where Calico is to be properly configured.
Official Rancher documentation says that Calico has to be explicitly mentioned in cluster.yml. Such question is asked while running rke config.

network:
  plugin: calico

Surprisingly Tigera's point of view in their dedicated article "Rancher Kubernetes Engine (RKE)" is different, they say literally:
Configure your cluster with a Cluster Config File and specify no network plugin by setting plugin: none under network in your configuration file.
Then they suggest installing Calico separately with a manifest:

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/tigera-operator.yaml

Hence I'm wondering if any of these approaches have certain advantages and drawbacks.

[HectorB-2020]

Forgot to include a couple of issues found here. Who knows is this helps:

• Documentation on how to configure CNI options #2679
• Calico node networking errors #1606
• Refactor rke config to current behavior #2149

[manuelbuil]

Hey @HectorB-2020 sorry for the late reply. Both options are fine and most of the code is the same, however:

• We are only testing the former (using cluster.yml)
• The manifests related to that option include rke variables which make the installation of calico less manual and thus less error-prone. For example, things such as cluster-cidr

Therefore, I'd always select that option. Unless you want to use Calico Enterprise, the paying version from Tigera. In that case, you should use their manifests (but be careful with some paramters such as cluster-cidr)

[HectorB-2020]

Excellent, thanks very much!

[github-actions]

This repository uses an automated workflow to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the workflow can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the workflow will automatically close the issue in 14 days. Thank you for your contributions.