Allow CNI networking to be set to none

[dghubble]

• Set CNI networking to "none" to skip installing any CNI provider (i.e. no flannel, Calico, or Cilium). In this mode, cluster nodes will be NotReady until you add your own CNI stack
• Motivation: I now tend to manage CNI components as addon modules just like other applications overlaid onto a cluster. It allows for faster iteration and may eventually become the recommendation

[kalmufti]

Thanks! Been looking forward to this feature.

Would this be the best way to use it:

networking = "none"

Or through the new variable from #1421? I see you included the change from #1421 in the release notes but not this #1419.

Personally I like setting up this way as it looks cleaner, and since you already checking the state of both var.networking : "none" and the new install_container_networking variable in kubernetes/bootstrap.tf

[dghubble]

You should set install_container_networking to false if you want to manage the flannel, Calico, or Cilium Kubernetes resources yourself. You will still need to have networking set to the corresponding CNI provider to configure cloud firewall / security group rules or other conditionals. The release notes guide you this direction.

[kalmufti]

Are you saying the networking variable is still important to be set for cloud providers only? I'm deploying on bare-metal clusters. I've tested 2 clusters by just setting networking = "none" and it worked as expected, meaning it deployed without CNI and was able to deploy my Cilium setup as I needed.

Looking at the <platform>/fedora-coreos/kubernetes/bootstrap.tf files I see this condition.

networking = var.install_container_networking ? var.networking : "none"

i.e what I did by setting networking = "none" it eventually achieved what I'm after.

if var.install_container_networking == true:
  networking = "CNI" # in my case I set it to "none"
else:
  networking = "none"

So wouldn't var.install_container_networking be redundant in this case, unless var.networking is still needed elsewhere?

[dghubble]

The two options serve different purposes. In the general case, deploying a CNI is more than just a bunch of Kubernetes resources, Typhoon needs to know which one you're choosing. It doesn't currently make much difference on bare-metal where host-level firewall rules aren't used, but it may in future, you're just in narrow special case. On cloud platforms it obviously matters.

Continue to use them as described in release notes