 All the time is up and now let's get started very soon. Thank you for coming. First of all, self introduction. I'm actually from a little bit of a cloud and what she named. And today I want to basically talk about how to use ASHO to manage the cross-functional and cross-cluster microservices. I'm now in cloud and I've got another colleague with us. He's actually one of our client and he's Lo Xiao Jun from Unicorea and fixing two parts here. First of all, I want to tell you on our cloud how are we going to use ASHO to manage the service and what exactly is the work progress in this area. And as for the second part of presentation it will be done by Lo Xiao Jun. That is in terms of reality how to use ASHO to manage the cloud and how it's implemented. And we've actually got a demo to your reference to see how exactly it can be implemented. Based on this thing, I feel like most of you might have a question about why do we need the loadable reaches of clusters such as scenario in front of Unicode cloud. We've got multiple clients and based on feedback from them I just summarise what we have to do. You can see on the screen why do they need the loadable regions in clusters management to basically three categories of responses. The first one. Business continuity as well as disaster agreement. That is to say we need to avoid as much as possible the problem in our business due to one or two non-spanier and don't go to all the actual one basket only and we do need the stability of the operation and that's the reason why we need the loadable regions clusters management. And secondly, as for our clients, as for their business or the end users, they distribute it all over the world. Some of them are in China and we've got Northern China and Southern China and America. We've got Western, as well as Eastern America and based on this clients in different locations will really have to be really covered all of the graph geographically distributed end users. We need to reduce the excess latency and also to meet local legal and data regulatory compliance and also in some of the specific use cases in the industry due to the non-characteristics. We do need to ensure that the data related work really have to be based on a specific vision so that we'll be able to ensure that we can really meet the local legal and data regulatory rules and regulations. And thirdly, we do need to take into consideration the aforementioned two demands and we do need to lower the barriers to set up the network connectivity in the past. It will cost a lot for us to do the cross-regional operation but now based on our cloud technology we do have a lot of, I would say, tremendous or exceptionally good connectivity on cloud or gateway, if you like. Therefore, all the services can be interconnected with each other that is cross-regional connectivity and I think this will be able to lower the barriers as well as the cost to do the setup of the network connectivity. In this way, the cross-regional as well as multi-cluster management can be really available to all the people and to deliver benefits to all the individuals. And as for multi-regional clusters, what is that made of ACK? What is ACK? We will basically focus on ACK in the rest of the first presentation and ACK specifically refers to Aliba as a container service for Kubernetes. And as for multi-regional or cluster service plus the main ACK output till now for ACK that is on the cloud of Aliba we basically have 18 regions where they are our services and service available. That is to say, if our clients have the overseeing business or some of them based in China or have business out for reciprocal vice versa then they will be able to have the cross-regional management service based on ACK. As for this picture you can see here on the screen for ACK, especially Israel on ACK what have we done already? First of all, Israel on ACK is actually based on communities, so in terms of the main operation we do need to do the integration with Alibaba cloud services in open source in terms of e-commerce. Before you can see that there are four aspects here. The first one we have is the integration with Alibaba cloud for the community. We have the monitoring as well as tracking all kinds of services like that and for the community version we have different components and for all of these components it cannot be applicable to the production scene for example for parameters whether it can be closely linked to the storage for the end users in Israel Tracer. If we have such a very minimal I would say backstage for antennas as well as operation and for all of this it has already been integrated and based on our other experience for the Tracer analysis and the mode turn and TSDB and all the database on cloud with Prometheus storage everything I've just mentioned can actually be integrated with Israel and basically that's the first thing we have already done and also from August last year we indeed try to provide ACK on Israel and within one year's time we've already have over 100 clients who started to use Israel and some of them are still in the market survey Facebook anyway we have collected many feedback from all of them on different channels and based on their feedback we try to constantly optimize and try to improve the user experience for example for for API we have already done some of the optimization work currently and basically that's the second priority about working through it's very important to know that we need to see some of the traditional industries will have to be moved to the cloud and we have to come across this situation for some of the traditional applications it can only be running at the physical device and we do need to move that on cloud through container or other methods we cannot just wait here I mean we cannot just bring that to ACK that we'll be able to use Israel rather we have already put mesh in place to ensure that when there's a hybrid cloud we'll be able to put all the applications as well as container service to mix with each other and in this way we'll be able to manage all the traffic and all the services all together and also for alien cloud besides traditional CASPAS and also with our service kubas and that is in the form of service we need to provide our own service and it can also be applied to several scenarios for ACK we have already providing service pod as well as KBS pod to manage them together as well that's the fourth one and you might be interested in that that is multi cluster method or approach for ACK we just provide a specific method to manage and incorporate other KBS from for example Google's GKE or other KBS we can use an anonymous way to do the management at the same time we can use ACK or other regions KBS and in this method we'll be able to use and manage all the KBS clusters and based on that we can use each tool to manage the traffic on the application as well as the operation level for example the fuel transfer and things like that and that will be the priority for us as well and as for today's theme we're going to focus on multi-region capability in here I just listed two features here and what exactly is the demand or requirement from the clients the first one is not about the candidate-based service and for this concept you can see from the picture that we got a cloud global DNS at the front end and based on the source of the demand it will be able to match the KBS gateway and at the back end for different regions we'll deploy different applications for example you can see a region 1 and region 2 have different configurations and we have to use the region for example in region 1 we got service 1 will be the priority access and a service 2 should have the priority access to service 3 and in this way we'll be able to reduce the latency of service in trying to improve the user experience in this way and also for for some of the region service for example if it just goes south or if there's a bug or any problems that is to say your service has been down then what we need to do we do need to have the capability to do with failover then you can see that after the service in region 1 is down then 3 hour service will be in fast fleece which to health check and deliver that again to some of the healthy region and later I would just demonstrate that eventually and to summarize a little bit that's actually a multi cluster pattern of Israel and for all of its patterns we'll be able to view that on our official website and just single out some of the shining points for example and in the first place we got Israel 1.0 and we got single mesh probability and we have the single control plane here and it has different requirements for example flatline work where all parts CIDRs in the open cluster must be well told to each other and also the parts of CIDR ranges must be unique and all of these demands as well as requirements make it really fun for the clients to use that in the first place and now we got region 1.1 and based on all of these demands I've just mentioned and for example before part we don't have the connectivity or if there is conflicts in terms of the parts of CIDR then we can use our service to connect each one of them and as for RSK we have already provided all the relevant services to support that and have the unanimous management of maps to that and as for mesh federation we just combine the Cooper federation probability for ISTRUAL federation and Cooper federation can be combined into one and so as to provide the capability in this way and this way we'll be able now let's just take a look at I would say this is some of the U.I. improvement and some of the feedback from our clients for ISTRUAL the parameters can be really complicated and the end users my point is really hard to understand therefore U.I. like this is actually based on the feedback from our clients and all the setup can actually be transformed into parameters and through simple configuration we'll be able to move the clients the men in the space for example all we need to do is to click all the requirements for the entry to see for example whether we'll be able to have the capability of enabling locality based service routing or should we really have the cultural impression of things like this if you want it then you just click it and everything can actually be automated in this way and it will really be user friendly then how the back end can help us to actualize implement all this and at the back end based on all this demand we have best operators in this UK ISTRUAL operators will be able to make full use of the parameters the front end to manage them and the back end and store ISTRUAL operators in order to draw some of the often used scenarios for example the access the multi management eventually we have these two CRDs within this operator and that is to use as less as possible CRD to fix them and for CRD you can see that on the screen for example if you want to put a control plan in your CRD then you will have to use ISTRUAL CRD as for ISTRUAL CRD then we do need to designate some of the parameters for example you can see the parameters in UI and you will be able to match them between these two and then you decide whether you do need the access as well as the health and health charts things like that you can define them by yourself and it's much much better and simpler compared with the traditional method and everything can actually automatically as for multi cluster mode in order to access the remote cluster we do need another CRD that is remote cluster and here we don't have that many parameters because you need to just add it to the control panel and here is a picture showing that for ACK in order to support the multicast in this picture we can see the first mode for the ISTRU operator we can see or monitor and listen CRD which we just mentioned to monitor the effect definition of the customer to see the value of the parameters and also it will coordinate the final deployment the ability of control under the multicast mode we can not only manage the function as one definition here under the multi cluster also local cluster central cluster and for other clusters there are the remote cluster so the ISTRU operator can not only manage the local cluster but also to coordinate the remote cluster and know the relationship between them how they can join together and all those background staff can be handled in this way operator can manage the ISTRU together including the life cycle once this is included in the in the past if you use the community version to install and update you might encounter a lot of problems because we have gathered similar customer to fit back before but now we use ISTRU to operate smoothly and in order to become palpable with the past version we expanded a lot and here this picture is similar with the previous one just like we mentioned if the two clusters are not connected it can only be connected by the common lab we can use UV method to connect the two and if you have opened the community version you will know that there is a very complicated parameter definition between them and the operator you used you do not need to pay attention to it anymore you can just leave it to it and here on the side we mentioned that you should pay attention to the ground region how to achieve that and that is, as we all know there are two labels on one node in the public cloud we have those labels and using those once we know currently which service will connect to the exact port and via those information you will know the end port, the location of the end port of your service and for all operators you can monitor and listen all the services in the service mesh their information regarding the region and we can handle all those information and as we all know for the access to the service he requests party and receive party how to match the two if targeting each of the request party we do not have a specific way that how to match in this case our operator just like you mentioned for example like on the Ali cloud we have 18 regions we will base on our previous accumulation we will find out the best server to match the services and via this kind of recommendation we could find the most suitable service provider so that's all for my sharing next I would like to invite Mr Liu our customer to share with you their user experience thank you I'm from Korea I'm glad to be here to share with you and my topic is our user experience in our company so in the next 10 minutes I would like to first briefly introduce the business scenarios and key problems targeting those problems I will further illustrate our solutions using Istio with a simple demo the first brief introduction to our business scenario for unicorn we are a company providing online education and the type of solutions to the global customers so covering people who in America, Europe and the structure of a professional team considering that the devil's auto the cloud and operation are combined to create a technical team based on Ali cloud and container service and on this basis we need a mature management solution and combined with Kubernetes Next, based on our scenarios I would like to talk about the people that we have encountered in the single region on the point there will be high latency across regions sometimes there are occasions due to our constrained network fluctuation and the previous part for the traffic management we will use Kubernetes Ingress and it is very weak and not very convenient quite complicated and for Kubernetes Ingress we have a certain degree of extension but it's not very compatible and for the technology of use it's not very mature and even Java their mature solutions they have a high requirement for the development and currently we will not have a very good solution to combine with the native Kubernetes So here that's the key problems we have and via this topology picture we can briefly introduce our plan So from this picture it's not that complicated I will introduce on that one first we can see we have great areas representing the current regions for the like regions for the like regions the Kubernetes clusters in that region we can see actually every two regions and the two on the left on the right all together two matches we can see now we can look at the picture and this can be combined together it's more detailed next for all the solutions we use the two on the right I think a little bit a customer I will go through the address in the middle go to the nearest region the request goes to the policy I will go to the range and it will get away to the cluster maybe let's go to the front end to the API to the API and let's go to the cache if it's targeted at the top of the pack if not then we will go to the service further layer and you may notice that there is only a service in the Hangzhou region and we will go to the site later then we go through our solution one by one first we need to go to a specific client to connect the RDR to the same layer and we go back to the previous the BFF the BFF made a request to the service in Hangzhou and for the load balancing actually it is practically in Beijing we have made sure which service we can go to and now we connect the network between the clusters so for example we can like make the request to the pod in this cluster make the request like add a multi cluster service to the specific line and we use the Ali cloud to achieve the second one use the solution we connect it to a single control and we can see this feature in Hangzhou's main cluster with Istio control and we can see the cluster in Beijing with Istio if we are in the future in this mesh we have more we only have one control plane and other data plane so for this single control plane I believe many of you have already know about it in the official documents if not you can later read about it and that is the second one and so using Istio there are different kinds of strategy and solutions like for example routing they have via their management control plane automatically go to all the clusters in the mesh and the fourth point is their request will through DNS divided by to go to the service, balance and Kubernetes clusters for example maybe it's imaging and request go via DNS and to Beijing the request come into the cluster via Istio load bandwidth the request is local local balance make the request in the local area to the certain point to the certain point then if there is a sample of the computing service then the request designate load in other regions the sixth we are now here at BFF there are simultaneously deployed in all the cluster regions the seventh point is the Japanese service because it's often communicated with the database the data sensor we deploy it in the current data sensor and the last point is the wide range of regions and for sharing the data we use cloud as our current solution and next is our demo we can now briefly see to demonstrate here to send the two clusters as an example our users are engaging cluster and user input to in Hangzhou and this is actually the history of the function of these locations let's take a look at the of history for example for the VPN application we got an API for the two locations the user input if the cluster for the API for this one the cluster will be filled to another location in the same API location application scenario and basically that's the function of Eastroll and now let's do a demo here so let's see in order to facilitate the demo we see a demo here to access the application in Hangzhou we will be able to see the application in Hangzhou and through this API we will be able to access the API and what at the same time you can see Hangzhou on the left right and now we can open up the request log of API some of the logs are actually the old ones we can just refresh it and let me check it right everything's just fine now we can take a look at here Hangzhou on the left and Beijing on the right and this is actually in the two different locations and on the left you will see the API cluster within Hangzhou and the application log is open and now it's being and on the right you will be able to see the API service there and we've already opened it up and now we can send a request for the application in Hangzhou for multiple times and API request and then we got API request log and basically that's for Hangzhou and application in Hangzhou as well and we can just empty that and if we want to access all the functions in Beijing and then on the API the application log of Beijing and we can send request multiple times just a moment we've already refreshed that and basically that's it we can see the request of Hangzhou will be able to refresh the application log in some situations in Beijing and that's actually the function of Hangzhou to demonstrate here in terms of Israel and now let's take a look at the developer of Israel for example for Beijing the API all of that all of the APIs there are down and what we expect is that the service later we can we're still up and running and maybe we can even get that here's the demo you can see the dashboard there and the first one is about the front end API and that's the health check for Beijing in Hangzhou in Beijing it's rain and everything is fine and now we just shut down the service later and now as you can see it's green now and now we can see the access for both Beijing Hangzhou is okay and now we see if there is an API but for all the API is down in Beijing now we can just turn off the app as you can see this API service is down as in Beijing and we can just open up the request log and basically that's the Beijing's API request log we need to take that and we need to time out because we don't have any further examples there and now we just send a request to the applications in Beijing and see how it really goes for the first time it will take a long period of time because internally they do need to judge the request for several times because it's a passive fill over and later you will see the five fill over and then when we do the request again right here and now we do the request again you can see the access is quite low and it's okay and the exception in Beijing and based on that log you can see the logs of hundreds and as for Beijing side everything's just time up there and here's the demo and now I would like to briefly talk about the benefits from Israel on ACK first of all in case of quirks Israel deployment and operation later secondly it can actually integrate A2E observability with alibaba transfer services but at the same time we'll be able to anticipate improved user experience for common scenarios but at the same time it can help us pinpoint several problems you can see the configuration now you can see the recovery if necessary and as of now it will be able to provide management for high quality and cloud like migration and it's quite precisely cloud native and it is very compatible with the other person's ability that's what I want to share with you and basically that's the speech today and thank you so much for coming for our research, thank you