Shulou(Shulou.com)06/02 Report--

In the hybrid and cloudy world, Kubernetes is so popular that it has become the de facto standard for unified deployment and management of applications, and the integration of Tungsten Fabric and Kubernetes enhances the network performance and security of the latter, and helps to achieve business landing.

On April 28th, during the online live broadcast of TF Chinese Community [TF Live], the community technical representative Yang Yu communicated with you online to see what kind of spark TF and K8s could collide with.

The live broadcast is jointly organized by TF Chinese Community and SDNLAB.

[download pdf document]

Https://tungstenfabric.org.cn/assets/uploads/files/kubernetes-sdn-tungsten-fabric.pdf

[HD video download link]

Https://pan.baidu.com/s/1cnwFJ3pmoY7HPnLCH37hbw

Extraction code: guxu

Yang Yu has been responsible for the construction of several large financial cloud platforms and enterprise cloud platforms, focusing on operation and maintenance automation, SDN and distributed storage. As a veteran who came into contact with Tungsten Fabric in 2016, he exported a lot of hard-core practical information during the live broadcast and interaction on April 28th, sharing years of technology accumulation and practice with you.

TF is the VPN based on BGP MPLS.

Tungsten Fabric, formerly known as OpenContrail, moved to the Linux Foundation in March 2018. In a word, the core technology of TF is based on BGP MPLS VPN technology.

BGP MPLS VPN technology has been applied in the wide area network of operators for more than 20 years, and it is a relatively mature technology. Based on BGP MPLS VPN technology and based on the same set of network infrastructure and lines, operators provide virtual private line services across wide area networks for different network tenants.

The core of BGP MPLS VPN technology is to use BGP protocol as the control plane to realize the routing between different sites and the interaction of VPN information. BGP protocol is a distributed controller. The data plane is the tunnel with MPLS tags to achieve transmission, to achieve traffic isolation, but also with the help of ECMP and other technologies to do link load balancing. Tungsten Fabric applies the BGP MPLS VPN technology of WAN to the data center. In a virtualized environment, the PE that was originally deployed at the operator endpoint is now the vRouter deployed on each compute node. In other words, vRouter takes on the role of PE. The virtual machines of different virtual networks are isolated after connecting to different VRF, and the data transmission is realized through the tunnel protocol. In the control plane, the communication between MAC address An and B is through the BGP protocol to achieve information distribution and interaction.

In terms of multi-cloud interconnection, performance and scalability, Tungsten Fabric has promoted SDN to a new level, easily implementing a unified SDN environment for virtual machines, containers and physical machines in different data centers (including public and private clouds). In terms of performance, Tungsten Fabric supports native Kernel forwarding, which can run over a 10-gigabit network card with a speed limit. Through the cluster formed by the controller and the adoption of distributed database, Tungsten Fabric has very good scale scalability. In the current actual deployment, there are basically more than 200 computing nodes to thousands of computing nodes. Through different controllers, EBGP neighbors can also be established to realize the interconnection of virtual networks across multiple clusters.

Figure: the TF function provides an overview of the load types of tungsten Fabric docking, including virtual machines, Linux virtual machines, containers, bare metal, etc., all interconnected through TF's unified SDN controller. The upper cloud management platforms, including OpenStack, K8s, VMware, and some public cloud platforms, can also achieve multi-cloud unified SDN management. More importantly, Tungsten Fabric can provide rich network functions. On different virtual networks (such as VS stack virtual network or GRE virtual network), isolation is achieved based on different layer 3 lists and layer 2 routing tables. At the same time, it also provides functions such as DHCP, DNS, and IP address management, as well as firewall, security policy, load balancing, service chain, monitoring, analysis and other functions. How do you achieve so many functions? Is through the Tungsten Fabric controller.

Based on BGP as the control plane of SDN, the controller realizes the management of corresponding routing entries and layer 2 forwarding table, and supports OVSDB to realize the configuration of physical devices. The physical machine can be connected to the TOR switch through VLAN, then converted into VXLAN, and interconnected with the corresponding container or virtual machine and virtual network, all of which are realized through BGP and OVSDB.

How to support K8s by TF

In fact, Tungsten Fabric initially mainly supports virtualized clusters such as Openstack, while for Kubernetes docking, some concepts need to be mapped. For example, the extension of Pod is equivalent to one virtual machine, one Interface, and five Instance-IP in TF. For example, there are many Service types in K8s, which correspond to ECMP load balancers on the TF side. How do you understand it? Traditional load balancing schemes, such as F5 devices, implement load balancing at layer 4 including layer 7, while TF uses BGP routing technology. The next virtual IP may be the IP of a real physical server, which can use multiple next-hop entries in the route to forward the equal cost path and achieve more efficient load balancing at the routing level. In addition, the Ingress of K8s, which is equivalent to a load balancer at layer 7, is implemented using the built-in HAproxy. KubernetesTungsten FabricNamespaceProjectPodVirtual-machine, Interface, Instance-ipService ECMP-based load balancing Ingress based on HAProxy layer 7 load balancing External IPFloating IPNetwork Policy based on pod selector security group (for this, netizens also raised a lot of technical problems about Tungsten Fabric and K8s)

Q: is TF used to replace the Calico network used by K8s?

First of all, the positioning of the two is the same, and the core principle of Calico is also based on BGP. However, in terms of functional implementation, Calico is based on IP TABLE, without VPN function, and is only equivalent to a subset of TF. There is a big gap between multi-cloud interconnected scenarios, including some isolated scenarios, and TF. The advantage of Calico is that it is relatively simple. This mode of applying IPinIP does not have the overhead of overlay and is more suitable for deployment on the cloud, because the cloud network is already an overlay network. Simple summary: Calico is a simple and reliable network solution suitable for small-scale clusters or K8S clusters deployed on the cloud. TF will be more scalable, multi-cloud interconnected, and network isolated.

Q: does TF replace kube-proxy in K8s?

Kube-proxy is only applied to NodePort scenarios in TF. Kube-Proxy will listen to the corresponding port in user mode and forward it to vRouter, and vRouter will implement the relevant DNAT function.

Q: TF uses BGP. Do you need to enable BGP on access switches and core switches within the enterprise?

TF's requirements for equipment can be divided into several parts:

Egress gateway Cloud Gateway, which is the main connection point between TF Overlay virtual network and physical network, needs to support MP-BGP, GRE tunnel or UDP tunnel. If TF management configuration is required, NetConf is also required.

BMS TOR switch, which is used to realize physical machine VLAN network and TF virtual network to realize layer 2 bridging device, needs to support EVPN-VXLAN protocol.

Underlay network switch is the underlying network used to connect computing nodes, control nodes, BMS TOR and Cloud Gateway. Because TF realizes the unpacking of the tunnel in vRouter, BMS TOR and Cloud Gateway, there are no special requirements for the network switch characteristics of Underlay, as long as three layers can be reached between the nodes. Static routing can be used on a small scale, OSPF or BGP can be used on a large scale

TF is not locked to the device and can be used as long as the appropriate protocol is supported. However, the degree of support of agreements from different vendors will be different. If you do not want to do a lot of testing and adaptation work, Juniper products are preferred, and products of other brands need to be tested before they are put into production.

Q: K8s Service naturally has LB function. What does this have to do with the load balancer provided by ECMP?

The LB function of K8s is also realized by TF, but it is still based on the ECMP of the routing layer to achieve balance. When it comes to controlling the URL mapping, the routing layer can not do it. TF will be implemented using Harpoxy.

(with regard to the docking of TF and K8s, Yang Yu gave a Demo demonstration in the live broadcast, showing the basic functions of Tungsten Fabric, the integrated docking with Kubernetes, and the demonstration of Service and External IP. If you are interested, click the link below to watch.)

Link: https://pan.baidu.com/s/1cnwFJ3pmoY7HPnLCH37hbw

Extraction code: guxu in the docking of the two, Tungsten Fabric provides a standard interface, the integration with K8s is based on CNI docking, requires the cooperation between several components. Including Kube-manager monitoring for K8s Pod related changes, and the corresponding events into actions, calling TF API to complete the network, interface creation and so on. After expansion, the CNI component of TF is responsible for querying the interface information of Pod, inserting the veth of Pod into vRouter and completing the docking of the network.

Q: is the resource mapping relationship between TF and K8s bi-directional synchronous?

Yes, the relationship of TF resource mapping is bi-directional synchronous. Subject to K8s, delete and delete K8s here, and create K8s accordingly.

Q: is the isolation of namespace logically isolated, the underlying network or interconnected, is VRF network-based or what?

By default, namespace is not quarantined if nothing is specified. Quarantine can be enabled, or quarantine can be specified. In security policy, there will be no communication between newly created namespace,namespace if access is not allowed. Tungsten Fabric is flexible in the access policies between different network interfaces.

Q: can TF generate traffic display information in the environment? Can you see the access relationship between services, do you support root cause analysis? It is convenient for the administrator to analyze what went wrong during the failure.

Traffic analysis is supported, you can grab packets, and you can also do image analysis, security policy and other access display through service chain. Visualization can be done based on the interface of Tungsten Fabric, or you can do secondary development through the interface.

The above is the wonderful content of this TF Live live broadcast. Here are some TF+K8s guidance articles that can be used as reference materials.

A review of TF Live (KK/): cloudy, SDN, and the theory of evolution of Internet workers

Tungsten Fabric + K8s Integration Guide Series

Part 1: deployment preparation and initial state

Part 2: creating Virtual Networks part 3: creating Security policies part 4: creating isolated Namespaces

Tungsten Fabric + K8s easy to use series

TF Carbide Evaluation Guide-preparation for basic Application Connectivity through Kubernetes Services Advanced external Application Connectivity through Kubernetes Ingress preliminary Application isolation through Kubernetes Namespace Application differentiation Segment through Kubernetes Network Policy

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.