weave VS flannel

Despite having been the main maintainer of Weave Net for ~4 years, I have no idea what you are talking about. Weave Net used Google's NaCL library from day 1; later adding optional AES using the in-kernel implementation.

https://github.com/weaveworks/weave/blob/master/site/concept...

FluxCD is a GitOps tool developed by Weaveworks that allows you to implement continuous and progressive delivery of your applications on Kubernetes. It is a CNCF graduated project that offers a set of controllers to monitor Git repositories and reconciles the cluster's actual state with the desired state defined by manifests committed in the repo.

16.kubectl apply -f https://github.com/weaveworks/weave/releases/download/v2.8.1/weave-daemonset-k8s.yaml

more links: - https://deploy.live/blog/kubernetes-networking-problems-due-to-the-conntrack/ - https://github.com/weaveworks/weave/issues/3287

$ kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

--pod-network=10.244.0.0/16: This is the default CIDR for flannel, and also avoids a conflict with my internal network if calico is used (which is the plan)

The installation of K8s id done by kubeadm. In this installation Containerd is used as CRI and flannel is used as CNI.

K8s is installed through kubeadm ad uses Containerd as CRI and Flannel as CNI. You can also install longhorn for the persistent storage and nginx ingress controller for the ingress rules.

This terraform module will deploy a high available Kubernetes (K8s) cluster on Amazon AWS, using mixed on-demand and spot instances. K8s is installed through kubeadm ad usesContainerd as CRI and Flannel as CNI. You can also install longhorn for the persistent storage and nginx ingress controller for the ingress rules. Please note, this is only an example on how to Deploy a Kubernetes cluster. For a production environment you should use EKS or ECS.

I don't use flannel but perhaps check this old issue: https://github.com/flannel-io/flannel/issues/663

It is definitively not normal behaviour. Cluster-internal subnets should be reachable from any node. Not being able to do so is a typical symptom of missing or misconfigured CNI. For flannel did you check this page?

Ask on Github.

I have Ubuntu 20.x and 21.x installed in my cluster, mostly because I am familiar with Ubuntu and figured the latest LTS versions would be a good idea to use for docker swarm and now kubernetes.... But there is a kernel bug, (k3s issue link and flannel issue link) with VXLAN that makes the default flannel container networking interface not work..... So I decided to Calico as the CNI to experiment with it, but I have been running to issues with BIRD is not ready: errors on only 2 of my nodes..... Which is an improvement then all of my nodes having the error like a couple of days ago.... but it is frustrating that only 2 have the error....