Cloud Native Computing Foundation Kubernetes on Edge Day EU 2022, 19 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Join the Cloud Native Journey to Shuttle Back and Forth Ap... Ruoyu Ying & Qiang Ren

Description

Lightning Talk: Join the Cloud Native Journey to Shuttle Back and Forth Applications Across Edges - Ruoyu Ying & Qiang Ren, Intel

SD-WAN handles the network connectivity issues between distributed applications in a seamless, secure and efficient manner through replacing traditional branch routers with virtualized or appliance-based software. However, as the concept of edge prevails recently, distributed applications are usually deployed across multiple resource-constrained k8s edges. Then how to expose the services and manage the connections between in a cloud native way becomes a critical issue for users. The open-source project SD-EWAN under the Akraino community’s ICN blueprint is definitely a comprehensive solution. Its CNF, which integrated with multiple network functions based on OpenWRT, is able to serve the distributed applications with secure connections and easy management against networking and the CNF can be automatically thru the overlay controller within SD-EWAN to achieve multi-edge collaboration. This session will show the basic architecture how SDEWAN utilizing k8s to help with the network connections across applications live in different edges, and a demo to showcase its usage for cross-edge collaboration (e.g. advanced load-balancing with service mesh).

A

Hi everyone welcome to join the cloud native journey to shuttle back and forth applications across address.

A

This is roy and chang from intel we're going to introduce you a brilliant project on how to establish, secure and reliable connections between the applications which reside in different badges and me will you will first talk about the background and give a brief on the project architecture as well as three significant merits of the project, and then xiao will show us a very concrete demo on how we use the project in an actual scenario.

A

We all know that now the applications and service have been moved to the cloud. They are usually packed in the cloud native way as containers or service served on the kubernetes cluster. I benefit from the characteristic of cloud. The applications can be distributed everywhere, depending on the user's need they could be located in the traditional center data center on the public cloud or on the az clusters reside in the telecast branch office or even in the local device.

A

The dynamic deployment really gives a lot more good to the users, to reduce latency and to like get a some hardware from the cloud or to lower the cost, but it also brings huge problems with operators.

A

So here listed several challenges. We may met in networking first of all management complexity, since the applications are now distributed in different networks. It brings huge problem for management. Second, security risks. Data are now flowing on different lengths, so there could be more chances to face the security threats, such as data breach or data loss.

A

Third application performance unpredictability, so the client may need to go several rounds to actually finally reach the application any trouble. We find in the route will trigger an inconsistency in the application of performance. Fourth configuration conflicts. This is usually seen in the ad scenario. Like the private cloud.

A

It will be more likely that the private cloud will set up identical, subnets or ip address, so it could be hard for them to talk to each other fifth monitoring and maintenance, since the applications are now distributed everywhere. It's very hard for the operator to maintain the code flow here. I also listed several solutions targeting on these challenges such as sd1, secure, internet gateway, zero trust, network access and our project sde one. You could see that our project could be the most suitable solution.

A

So what's sde one.

A

Apparently it's an enhanced version of sd1 is short for software defined at one. It is a project targeting on bring up reliable, secure and fully functional network connections for applications which reside on different edges. The project itself consists of three components: the overlay controller, which manages the configuration generation and distribution in the central cloud. The crd controller, which utilized the kubernetes custom resource to study configuration setup.

A

The cnf, which includes multiple network functions such as firewall to actually bring up the alternate.

A

The three components will help to set up the network connections to allow the applications to talk to each other smoothly and securely, even they are residing on different ash edges.

A

I will then use three as three of its critical merits to elaborate more first ease of use, the sde-1 manages the network configurations in automated manner. Utilizing the overlay controller in the cloud. The clusters reside in same overlay can easily establish network connections with a simple registration to the overlay api.

A

This greatly reduces the burdens of operator 4 operators to manage the connections between the building slbs will also guarantees the stable performance for the applications.

A

As I mentioned before, the security risks are big concern for both users and operators, using ipsec to set up turners between guarantees and say secure data transfer, kit, protection and crypto support are integrated inside to address physically insecure edge.

A

The cnf also provides a fully functional firewall to do the content filtering to meet the common security needs flexibility. All three components are atomic. They can be used totally as an overall solution or it can be used separately with other frameworks. This is mainly because they are based on the kubernetes custom resource. Any free work that can adopt this kind of mechanism is able to use the cnf or the crd controller separately.

A

So speaking of flexibility, we do have an example. Let me hand over to chao for the demo.

B

Okay, let me see a simple case in this case. The sdm project will have to extend the usage of this mesh to provide the load balance worker across the edges.

B

This regards to the details of the cross edge collaborations. The requests come from. The client will transmit through the hub and use the application reset on the edge with proper load balancing in strategies diagram.

B

We have s1 and h2 isolated, kubernetes clusters, but the difference here is that we have cluster come with a public ip and the h1 and s2 are residing in a private network with no public ip address.

B

Every cluster contains at least one sd1cf to build up the external connection. Sd1 only controller generates and manages the configuration to set up ipsec turnoff between the cf in the edge and hub for data transmission.

B

So the clients requested to the application will pass through the hub to the edge properly.

B

In this scenario, we integrated sd1 with service mesh, in our case, if he's too, to accomplish load, balancing and use mutual ts for authentication the sample application. Hello host use easter to expose a service hardened by mutual tls, which will retain a response include the class name on the top side.

B

This includes console app to have the edge application involved in the hub mesh and do load balancing using virtual service.

B

An actual sd1cf is using hubside to expose the service.

B

The client request first comes into export cf on github and redirect to the etho ingredient gateway through d-net. Then the request will enter the configuration of auto-service and select one of the service entries.

B

Let's assume its choice at one. Next, the data will redirect to the cf port using the router on the host and pass it to h1cf through f6200, then hitting the youtube gateway inside the edge and finally arrive at the application port and retain the response.

B

This flow involves two things: they have configured mutual ts authentication. The first is from client to the hub is to increase gateway and, second is from the half service entry to the edge extreme english gateway.

B

I have already described the whole architecture and next, let me show the demo.

B

The left pane is a machine simulating the client that would like to access the application through the hub and the right type is s1 cluster and the below is attitude cluster. We do several tests on the client side.

B

Now we could see the request is almost equal. Listen to two edges.

B

That's all! Thanks for your attention.

A

Hopefully you enjoy our journey and can utilize our work in more scenarios.