How to perform a CNI Live Migration from Flannel+Calico to Cilium

How to perform a CNI Live Migration from Flannel+Calico to Cilium

  • October 15, 2020
Table of Contents

How to perform a CNI Live Migration from Flannel+Calico to Cilium

Container Network Interface (CNI) is a big topic, but in short, CNI is a set of specifications that define an interface used by container orchestrators to set up networking between containers. In the Kubernetes space, the Kubelet is responsible for calling the CNI installed on the cluster so Pods are attached to the Kubernetes cluster network during creation, and its resources are properly released during deletion. CNIs can also be responsible for more advanced features than just setting up routes in the cluster, such as network policy enforcement, encryption, load balancing, etc.

There are many implementations of CNI for various use cases, each having their own advantages and disadvantages. Flannel is one such implementation, backed by iptables, and it is perhaps the most simple and popular in Kubernetes. Flannel is solely concerned with setting up routing between Pods in the Kubernetes cluster, which is achieved by creating an overlay network using the Virtual Extensible LAN (VXLAN) protocol.

Another project, Calico, can be run as either a standalone CNI solution or on top of Flannel (called Canal) to provide network policy enforcement.

Source: cilium.io

Share :
comments powered by Disqus

Related Posts

New Kubernetes 1.18 Extends Ingress

New Kubernetes 1.18 Extends Ingress

Last month, the Kubernetes team released Kubernetes 1.18, which extended Ingress. The two most exciting features include a new IngressClass resource and the new pathType field. To minimize the risk for our users who want to try out these exciting new features, the Ambassador Edge Stack supports the latest version of the Kubernetes Ingress specifications.

Read More
Ingress for Anthos—Multi-cluster Ingress and Global Service Load Balancing

Ingress for Anthos—Multi-cluster Ingress and Global Service Load Balancing

Ingress for Anthos is a Google cloud-hosted multi-cluster ingress controller for Anthos GKE clusters. Ingress for Anthos supports deploying shared load balancing resources across clusters and across regions enabling users to use a same load balancer with an anycast IP for applications running in a multi-cluster and multi-region topology. In simpler terms this allows users to place multiple GKE clusters located in different regions under one LoadBalancer.

Read More
Introducing PodTopologySpread

Introducing PodTopologySpread

Managing Pods distribution across a cluster is hard. The well-known Kubernetes features for Pod affinity and anti-affinity, allow some control of Pod placement in different topologies. However, these features only resolve part of Pods distribution use cases: either place unlimited Pods to a single topology, or disallow two Pods to co-locate in the same topology.

Read More