Advanced practice of Container network calico

Absrtact: The authors share the calico changes (including components, documents, and CALICOCTL) that are seen by the user, Demo some simple examples, and Macvlan to do a comparison to explain the principle of the summary of the appropriate calico to use the scene.

Good evening, I am a few people cloud Shangxiangyang, next to share with you the theme is "Container Network calico Advanced Practice."

Distance last chat calico has been over the past half a year, several people cloud has been trying to apply the container network solution to the Enterprise customer environment, Calico V2.0 will soon be released, this time with you feel the new version.

Need to explain, I have no direct relationship with Calico, also just a "eat melon masses", as users, want to chat with you.

This sharing includes: a brief summary of the calico changes I've seen as a user, including components, documents, and CALICOCTL; Demo Some simple examples, and Macvlan to do a comparison of the principles, and finally summed up suitable for the calico of the use of the scene;

Calico Brief Review

First of all, it is simple to review the Calico architecture and key components to facilitate understanding.

Calico Architecture

Calico is a three-tier data center network solution and facilitates integrated OpenStack, an IaaS cloud architecture that delivers highly efficient and controllable communication between VMS, containers, and bare-metal.

Combined with this picture above, we've been through Calico's core components: Felix,calico agent, running on each node that needs to run workload, is mainly responsible for configuring routing and ACLs information to ensure endpoint connectivity; Etcd, distributed key-value storage , mainly responsible for the consistency of network metadata to ensure the accuracy of calico network status, BGP Client (BIRD) is mainly responsible for distributing Felix write kernel routing information to the current Calico network to ensure the validity of communication between workload; BGP R Oute Reflector (BIRD), the use of large-scale deployment, discard all nodes interconnected mesh mode, through one or more BGP Route Reflector to complete the centralized routing distribution;

By compressing the entire Internet's extensible IP Network principles to the data center level, Calico uses Linux kernel to implement an efficient vrouter for data forwarding in each compute node, and each vrouter is responsible for running it through a BGP protocol Workl Oad routing information is spread across the calico network-small deployments can be directly interconnected and can be done on a large scale through the specified BGP route reflector.

This ensures that all the data traffic between the workload ends up being interconnected via IP packets.

Calico node networks can directly utilize the network structure of the data center (support L2 or L3) without the need for additional NAT, tunnels or Vxlan overlay network.

As shown in the figure above, this ensures that the scheme is simple and controllable, and there is no packet solution, which saves CPU computing resources while improving the performance of the whole network.

In addition, Calico provides a rich and flexible network policy based on Iptables, guaranteeing workload multi-tenant isolation, security groups, and other accessibility restrictions through ACLs on each node.

A more detailed introduction you can refer to the previous share:

Http://edgedef.com/docker-networking.html

Or

http://dockone.io/article/1489

New changes in Calico

Next, let's briefly introduce the changes in the Calico New Edition.

Component level:

First look at the list of components included in V2.0.0-RC2: V2.0.0-rc2 Felix 2.0.0-rc4 calicoctl v1.0.0-rc2 calico/node v1.0.0-rc2 calico/cni v1.5.3 Libcali Co v0.19.0 libcalico-go V1.0.0-RC4 calico-bird v0.2.0-rc1 calico-bgp-daemon v0.1.1-rc2 libnetwork-plugin v1.0.0-rc3 Calico/kube-policy-controller v0.5.1 Networking-calico 889cfff

Compare v1.5 or Previous versions: v1.5.0 Felix v1.4.1b2 calicoctl v0.22.0 calico/node v0.22.0 calico/node-libnetwork v0.9.0 calico/cni. 4.2 Ibcalico v0.17.0 Calico-bird v0.1.0

Calico/kube-policy-controller v0.3.0

You can see that the component level calico has also changed a lot, with the addition of: Libcalico-go (Golang Calico library function, used by both Calicoctl, CALICO-CNI and Feli x) Calico-bgp-daemon (GOBGP based Calico BGP daemon,alternative to BIRD) Libnetwork-plugin (Docker libnetwork, plugin for P Roject Calico, integrated with the Calico/node image) Networking-calico (Openstack/neutron integration for Calico Networki Ng

In summary, the component language stack turns to Golang, including the original Python Calicoctl, which is also rewritten with Golang, which, incidentally, is the same as the language stack from Python to Golang, which can be seen in the same cycle as Golan G has a large impact on the container rim, and also for open source, providing users with better scalability (compatible GOBGP) and integration capabilities (Openstack/neutron).

Use level:

Better documentation and positive response to slack:

http://docs.projectcalico.org/v2.0/introduction/

Open source documents are important to users, and calico documents are getting better, making sure that each usage scenario (Docker,mesos, CoreOS, k8s, OpenStack, etc.) can be found as useful references.

In addition, Calico maintains a quick response to the slack, and there are questions that can be asked at any time, and this interaction is also a good experience for open-source users.

Re-oriented Calicoctl UX model for kubernetes rewriting

There is no doubt that this is Calico's effort and change to better integrate into Kubernetes, and is also good news for users who are increasingly using the k8s while trying to calico the network, so that you can define the C by k8s file as you would define a resource model in YAML. These models are pool,policy in Alico, and the label&selector mode is also supported, which guarantees the consistency of usage. Examples of specific calico-defined resource models will be reflected in later demos.

Calico CNI and Canal

Another change is the presence of the Canal, a CNI-oriented container network based on access control.

Container Network Interface CNI Container Network spec was proposed by CoreOS, which was introduced by Mesos, Kubernetes and Rkt.

While providing better support for the CNM and libnetwork of the Docker family, and for more affinity with kubernetes and better support for CNI, Metaswitch and CoreOS have formed a new company Tigera (HTTP Calico s://www.tigera.io/), the main push Canal adds Calico's policy function to the flannel network, providing better ACL control for and k8s networks.

Calico Component Principle Demo

In order to understand the calico work principle, incidentally experience new version calico, we prepared two Demo environment, one is the new version of Calico, the other is the contrast environment Macvlan.

Calico to test for the purpose of the cluster set up, the steps are very simple, here does not unfold, you can directly refer to Http://docs.projectcalico.org/master/getting-started/docker/installation/manual

Macvlan cluster Construction, the steps are relatively simple, reference: Https://github.com/alfredhuang211/study-docker-doc/blob/master/docker Macvlan network configuration across the host. MD

Here default already has two sets of Docker Demo cluster: Calico network cluster, respectively: 10.1.1.103 (CALICO01) and 10.1.1.104 (calico02) Macvlan cluster, respectively: 10.1.1.105 and 10.1. 1.106

Demo 1:calico three-layer interconnection

CALICOCTL Node Status screenshot:

At the same time, already have IP Pool created well, is: 192.168.0.0/16

Calicoctl Get Pool screenshot:

The current cluster has also created different Docker network by using Calico Driver and IPAM, and this demo only needs to use the Net1

Docker Network LS screenshot:

Calicoctl Get Profile screenshot:

Here we use the NET1 network to start a container on both machines:

On the calico01:

Docker run--net net1--name workload-a-tid busybox

On the calico02:

Docker run--net net1--name workload-b-tid busybox

Test screenshot of Container connectivity:

Demo 2:macvlan Two-layer interconnection

Create a Macvlan network with the same command on both hosts

Docker network create-d Macvlan--subnet=192.168.1.0/24--gateway=192.168.1.1-o parent=enp0s3-o Macvlan_mode=bridge 19 2_1

To create a container:

10.1.1.105:

Docker run--net=192_1--ip=192.168.1.168-id--name test01 busybox sh

10.1.1.106:

Docker run--net=192_1--ip=192.168.1.188-id--name test11 busybox sh

Test network connectivity:

Docker exec test01 ping-c 4 192.168.1.188

Calico IP Routing Implementation and Wireshark grasping package

Based on the above Calico data plane concept diagram, combined with our example, let's look at how calico is interoperable across hosts:

Two slave route screenshots:

By comparing the routing tables of the two hosts, we know that if the container on Host 1 (192.168.147.195) wants to send data to the container on Host 2 (192.168.38.195), it will match the routing rule to the response 192.168.38.192/26 Via 10.1.1.104, the packet is forwarded to host 2, host 2 in accordance with 192.168.38.195 Dev cali2f648c3dc3f to the corresponding Veth pair, to kernel.

The whole data stream is:

Container-> calico01-> One or more hops-> calico02->

Finally, let's take a look at the screenshot of the Wireshark grab package:

Calico:

Macvlan:

As can be seen from the comparison above, it is a feature of Calico as a three-layer program that the packet of packets in the Macvlan,calico network uses the MAC address of the node between nodes, so that there is no additional ARP broadcast.

But it also shows that the network section between nodes does not work if you want to do filter or control the communication between the containers in the two-layer calico scheme.

In this way, a simple cross-host calico three layer of communication on the Demo finished, the other calico features here on one by one, encourage you to use VMs to put up their own try, encounter problems at any time to slack to chat.

Calico Use scenes

Calico can be used either in the public cloud or in a private environment, we will focus on the next calico use Scenario 2 in the private cloud.

Two-tier network

Calico for the two-tier network, the first reason is not because the number of containers to bring ARP broadcast storm, above the Demo, we have seen, calico in the container in the relevant communications in the two-tier use of the node's MAC address, so that is to say, The growth on the radio is just an increase or decrease in the host layer, this is inherently controllable in the data center; second, the network disturbances, the same reason, the use of Calico also do not have to worry because of the frequent start of the container caused by the network disturbance; Finally, Calico's IP space use is relatively free, so that sufficient IP Resource usage.

Of course, everything is two sides, use calico to understand, Calico IP is a cluster, that is, if you need to use the container IP and the external Internet for communication, you need to configure the appropriate. For example: If you have external communication needs, you want to open nat-outgoing, if you need to be able to, to configure and maintain the corresponding routing rules or through the support of BGP external exchange/routing equipment, can refer to 3.

In addition, the above Demo also shows that, if there is a need for communication between containers two-tier data packet analysis and control of the Calico is also no way, so that if the DC has integrated some commercial network control module or SDN, it is necessary to consider comprehensively, whether appropriate to introduce calico.

Finally, to mention a small, calico data store, you need to specify a unique label for each calico node, use hostname by default, or specify by--name when Calicoctl node run, and if you use the default hostname, you should To plan the hostname of each host before initializing the calico cluster.

Three-tier network

Calico can also be used in the three-layer network, but compared to the two layer is to be complex, need more net-eng intervention, the individual level is limited, do not start to say, interested can directly refer to: http://docs.projectcalico.org/master/ Reference/private-cloud/l3-interconnect-fabric

Summarize:

With the development of the container network, several people will pay more and more attention to how to put the Advanced container network technology better "landing" enterprises, a few people cloud at the end of the new version will also be added to the appropriate number of people cloud Calico installation configuration manual to end users.

We will always focus on open source, including Calico, Cisco Contiv, DPDK, and so on, I believe that the next open source solution will be in ease of use, easy to maintain the promotion, but also will strengthen the various container layout program support.

Looking back at the development of the new version of Calico, these requirements are also confirmed:

Ease of use, compatible with k8s Calicoctl UX;