diff --git a/content/rancher/v2.x/en/faq/network/cni-providers/_index.md b/content/rancher/v2.x/en/faq/network/cni-providers/_index.md index 6abb62fe8c7..3097212b54d 100644 --- a/content/rancher/v2.x/en/faq/network/cni-providers/_index.md +++ b/content/rancher/v2.x/en/faq/network/cni-providers/_index.md @@ -1,156 +1,136 @@ --- -title: CNI providers +title: CNI Providers weight: 2300 draft: true --- ---- - -### What is CNI? +## What is CNI? CNI (Container Network Interface), a [Cloud Native Computing Foundation project](https://cncf.io/), consists of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of supported plugins. CNI concerns itself only with network connectivity of containers and removing allocated resources when the container is deleted. -K8S uses CNI as an interface between network providers and k8s pods networking. +Kubernetes uses CNI as an interface between network providers and Kubernetes pod networking. CNI logo For more information visit [CNI GitHub project](https://github.com/containernetworking/cni). -### What network models are used in CNI? +### What Network Models are Used in CNI? -CNI providers implement their network fabric using either an encapsulated network model such as VXLAN or an unencapsulated network model such as BGP. +CNI providers implement their network fabric using either an encapsulated network model such as Virtual Extensible Lan ([VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)) or an unencapsulated network model such as Border Gateway Protocol ([BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)). -#### What is an encapsulated network? +#### What is an Encapsulated Network? -This network model provides a logical L2 network encapsulated over the existing L3 network topology spanning the k8s cluster nodes. With this model you have an isolated l2 network for containers without needed routing distribution, at the cost of an little overhead in terms of processing and increasing ip package size with an ip header generated by overlay encapsulation. Encapsulation information is used to be distributed by udp port between k8s workers, interchanging network control plane information about how mac addressed could be reached. Common encapsulation used in this kind of network model are vxlan, ipsec, ip-in-ip... +This network model provides a logical Layer 2 (L2) network encapsulated over the existing Layer 3 (L3) network topology that spans the Kubernetes cluster nodes. With this model you have an isolated L2 network for containers without needing routing distribution, all at the cost of minimal overhead in terms of processing and increased IP package size, which comes from an IP header generated by overlay encapsulation. Encapsulation information is distributed by UDP ports between Kubernetes workers, interchanging network control plane information about how MAC addresses can be reached. Common encapsulation used in this kind of network model is VXLAN, Internet Protocol Security (IPSec), and IP-in-IP. -Simplifying, this network model generates a kind of network bridge extended between k8s workers, where pods will be connected. +In simple terms, this network model generates a kind of network bridge extended between Kubernetes workers, where pods are connected. -This network model is indeed when a extended layer 2 bridge is preferred. This network model is sensible to layer 3 network latencies of the k8s workers. If datacenters are in distinct geo-locations, be sure to have low latencies between them to avoid eventual network segmentation. +This network model is used when an extended L2 bridge is preferred. This network model is sensible for L3 network latencies of the Kubernetes workers. If datacenters are in distinct geolocations, be sure to have low latencies between them to avoid eventual network segmentation. -CNI providers using this network model, flannel, canal, weave... +CNI providers using this network model include Flannel, Canal, and Weave. Encapsulated network -#### What is an unencapsulated network? +#### What is an Unencapsulated Network? -This network model provides a l3 network to route packets between containers. This model doesn't generate an isolated l2 network, neither generates overhead, at the cost of route distribution needed, that is managed by k8s workers. Instead of ip headers to encapsutate, it uses a network protocol between k8s workers to distribute routing information to reach pods, like [bgp](https://en.wikipedia.org/wiki/Border_Gateway_Protocol). +This network model provides an L3 network to route packets between containers. This model doesn't generate an isolated l2 network, nor generates overhead. These benefits come at the cost of Kubernetes workers having to manage any route distribution that's needed. Instead of using IP headers for encapsulation, this network model uses a network protocol between Kubernetes workers to distribute routing information to reach pods, such as [BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol). -Simplifying, this network model generates a kind of network router extended between k8s workers, that provides information how to reach pods. +In simple terms, this network model generates a kind of network router extended between Kubernetes workers, which provides information about how to reach pods. -This network model is indeed when a routed layer 3 network is preferred. This mode dinamically update routes at os level at k8s workers. It's less sensible to latency but +This network model is used when a routed L3 network is preferred. This mode dynamically updates routes at the OS level for Kubernetes workers. It's less sensible to latency. -CNI providers using this network model, calico, romana... +CNI providers using this network model include Calico and Romana. Unencapsulated network -### What CNI provides Rancher? +### What CNI Providers are Supported by Rancher? -Rancher supports three different CNI providers for k8s clusters. They could be choosed when you create new k8s cluster from Rancher. +Out-of-the-box, Rancher supports three different CNI providers for Kubernetes clusters: Canal, Flannel, and Calico. You can choose your CNI when you create new Kubernetes clusters from Rancher. -#### What is canal? +#### Canal Canal logo -Canal is a CNI provider that gives you the best of Flannel and Calico. It allows users to easily deploy Calico and flannel networking together as a unified networking solution, combining Calico’s network policy enforcement with the rich superset of Calico (unencapsulated) and/or flannel (encapsulated) network connectivity options. +Canal is a CNI provider that gives you the best of Flannel and Calico. It allows users to easily deploy Calico and Flannel networking together as a unified networking solution, combining Calico’s network policy enforcement with the rich superset of Calico (unencapsulated) and/or Flannel (encapsulated) network connectivity options. -On Rancher, canal is the default CNI provider combined with flannel and vxlan encapsulation. +In Rancher, Canal is the default CNI provider combined with Flannel and VXLAN encapsulation. -K8S workers should open udp port 8472 (vxlan) and 9099 (healthcheck) +Kubernetes workers should open UDP port `8472` (VXLAN) and `9099` (healthcheck). Canal diagram -More info: -https://github.com/projectcalico/canal +For more information, see the [Canal GitHub Page](https://github.com/projectcalico/canal). - -#### What is flannel? +#### Flannel Flannel logo -Flannel is a simple and easy way to configure a layer 3 network fabric designed for Kubernetes. Flannel runs a single binary agent called flanneld on each host, that is responsible for allocating a subnet lease to each host out of a larger, preconfigured address space. Flannel uses either the Kubernetes API or etcd directly to store the network configuration, the allocated subnets, and any auxiliary data (such as the host's public IP). Packets are forwarded using one of several backend mechanisms, being the default encapsulation [vxlan](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan). -Encapsulated traffic is clear by default, flannel provides experimental backend for cipher it, [ipsec](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#ipsec), that make use of strongswam to stablish ciphered ipsec tunnels between k8s workers. +Flannel is a simple and easy way to configure L3 network fabric designed for Kubernetes. Flannel runs a single binary agent named flanneld on each host, which is responsible for allocating a subnet lease to each host out of a larger, preconfigured address space. Flannel uses either the Kubernetes API or etcd directly to store the network configuration, the allocated subnets, and any auxiliary data (such as the host's public IP). Packets are forwarded using one of several backend mechanisms, with the default encapsulation being [VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan). -K8S workers should open udp port 8472 (vxlan) and 9099 (healthcheck) +Encapsulated traffic is unencrypted by default. Threfore, flannel provides an experimental backend for encryption, [IPSec](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#ipsec), which makes use of [strongSwan](https://www.strongswan.org/) to establish encrypted IPSec tunnels between Kubernetes workers. -Flannel diagram +Kubernetes workers should open UDP port `8472` (VXLAN) and `9099` (healthcheck). -More info: -https://github.com/coreos/flannel +Flannel Diagram -#### What is calico? +For more information, see the [Flannel GitHub Page](https://github.com/coreos/flannel). -Calico logo +#### Calico -Calico enables networking and network policy in k8s clusters across the cloud. Calico uses a pure unencapsulated IP network fabric and policy engine to provide networking solution to your k8s workloads. K8S workloads are able to peer with cloud infrastructure such as on-premise, using BGP. -Calico also provides a stateless IP-in-IP encapsulation mode that can be used, if necessary. -Calico also offers policy isolation, allowing you to secure and govern your k8s workloads using advanced ingress and egress policies. +Calico Logo -K8S workers should open tcp port 179 (bgp) +Calico enables networking and network policy in Kubernetes clusters across the cloud. Calico uses a pure, unencapsulated IP network fabric and policy engine to provide networking for your Kubernetes workloads. Workloads are able to communicate over both cloud infrastructure and on-premise using BGP. -Calico diagram +Calico also provides a stateless IP-in-IP encapsulation mode that can be used, if necessary. Calico also offers policy isolation, allowing you to secure and govern your Kubernetes workloads using advanced ingress and egress policies. -More info: -https://www.projectcalico.org/ -https://github.com/projectcalico/calico +Kubernetes workers should open TCP port `179` (BGP). + +Calico Diagram + +For more information, see the following pages: + +- [Project Calico Official Site](https://www.projectcalico.org/) +- [Project Calico GitHub Page](https://github.com/projectcalico/calico) -### What can I find out more about the different network projects? +### CNI Features by Provider -Once 3 distinct CNI providers are presented, it's time to see summarize features and popularity activity on github projects. - -#### What are CNI features? - -Here is a summary of different features of each of the CNI providers supported on Rancher. +The following table summarizes the different features available for each CNI provider supported by Rancher. | Provider | Network Model | Route Distribution | Network Policies | Mesh | External Datastore | Encryption | Ingress/Egress Policies | Commercial Support | | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | -| Canal | Encapsulated (vxlan) | No | Yes | No | K8S api | No | Yes | No | -| flannel | Encapsulated (vxlan) | No | No | No | K8S api | No | No | No | +| Canal | Encapsulated (VXLAN) | No | Yes | No | K8S API | No | Yes | No | +| Flannel | Encapsulated (VXLAN) | No | No | No | K8S API | No | No | No | | Calico | Unencapsulated | Yes | Yes | Yes | Etcd | Yes | Yes | Yes | -- Network Model: ecnapsulated or unencapsulated. More info at CNI network model section +- Network Model: Encapsulated or unencapsulated. For more information, see [What Network Models are Used in CNI?](#what-network-models-are-used-in-cni) -- Route Distribution: It is a must on Unencapsulated CNI providers, and it is typically done by BGP. Route distribution is a nice to have a feature with CNI, if you plan to build clusters split across network segments. It is an exterior gateway protocol designed to exchange routing and reachability information on the Internet. BGP can assist with pod to pod networking between clusters. +- Route Distribution: An exterior gateway protocol designed to exchange routing and reachability information on the Internet. BGP can assist with pod-to-pod networking between clusters. This feature is a must on unencapsulated CNI providers, and it is typically done by BGP. If you plan to build clusters split across network segments, route distribution is a feature that's nice-to-have. -- Network Policies: K8S offers functionality to enforce rules about which service can communicate with each other using network policies. This feature is stable from k8s 1.7 and is ready to use with supported networking plugins. +- Network Policies: Kubernetes offers functionality to enforce rules about which services can communicate with each other using network policies. This feature is stable as of Kubernetes v1.7 and is ready to use with supported networking plugins. -- Mesh: This feature allows service to service networking communication between distinct k8s clusters. +- Mesh: This feature allows service-to-service networking communication between distinct Kubernetes clusters. -- External Datastore: if CNI provider needs an external datastore to persist own data. +- External Datastore: CNI providers with this feature need an external datastore for its data. -- Encyption: This feature allows cypher and secure network control and data planes. +- Encyption: This feature allows cyphered and secure network control and data planes. -- Ingress/Egress Policies: This feature allows manage routing control for k8s and Non-k8s communications. +- Ingress/Egress Policies: This feature allows you to manage routing control for both Kubernetes and non-Kubernetes communications. -#### What are Github projects? +#### CNI Community Popularity -Here is a summary of different github metics to take an idea of projects popularity and activity about of each of the CNI providers supported on Rancher. +The following table summarizes different GitHub metrics to give you an idea of each supported project's popularity and activity. This data was collected in July 2018. | Provider | Project | Stars | Forks | Contributors | | ---- | ---- | ---- | ---- | ---- | | Canal | https://github.com/projectcalico/canal | 536 | 75 | 19 | | flannel | https://github.com/coreos/flannel | 3.279 | 774 | 107 | | Calico | https://github.com/projectcalico/calico | 572 | 225 | 82 | +
+### Which CNI Provider Should I Use? -- Project: main url of the project -- Stars: Likes on GitHub -- Contributors: number of people maintaining the code base and documentation. -- Forks: number of copies of the repo. Contributors typically have to fork the repo. Other people will fork the project to build a custom copy, push code to a feature branch that they own, or for various reasons. - -Note: Tables is updated with 26th july 2018 data - -### Which CNI provider? - -The above question doesn't have a trivial answer. There are many different providers, which have various features and options. There isn't one provider that meets everyones needs, and there are many different options. By the moment, at rancher v2.0.x we are supporting 3 of the major CNI providers that could be used by every user. - -At rancher v2.0.x, canal is the default CNI provider. We recommend to use it in most cases. It provides encapsulated networking for containers with flannel, adding project calico network policies that can provide project/namespace isolation in terms of networking. - -Anyway, all of 3 solutions could be a good CNI provider choose and may work perfectly fine. - - - - +It depends on your project needs. There are many different providers, which each have various features and options. There isn't one provider that meets everyone's needs. At the moment, Rancher v2.0 supports the 3 most versatile CNI providers. +As of Rancher v2.0.7, Canal is the default CNI provider. We recommend it for most use cases. It provides encapsulated networking for containers with Flannel, while adding Calico network policies that can provide project/namespace isolation in terms of networking. +All of 3 solutions are capable CNI providers and will likely suit your needs.