Hello everyone, this is Jin Wei. I'm very happy to introduce the Apache API six Ingress project. This is a simpler and easier kubernetes ingress have something about myself. I'm Apache API six PMC, Apache Skywalking committee, and the founder of Apache API Six Ingress controller. So what is Apache API six Ingress controller? It is another ingress controller implementation based on Apache API six, and it supports declarative configuration which can be configured through native ingress results or through custom results definition. We call it CRD. This picture tells us that the Apache API six Ingress controller is usually deployed at the age of the cluster, serving as a cluster entry and forwarding business request to the services. Well, we also need to introduce Apache API six. It is a high performance four dynamic real time API gateway and it is also a top level project of Apache foundation. This is the architecture diagram of Apache API six, and the left part show us Apache API six how to process business traffic with rich plugin functions. On the right is the controller plan of Apache API six. Here we mainly focus on admin APIs, through which ingress controller synchronize results to Apache API six. Okay, let's talk about the working mechanism of Apache API six Ingress controller. The Apache API six Ingress controller watches events from the Kubernetes API server, something like secret endpoints and Ingress in kubernetes, as well as custom results definition such as API six root API six, upstream API six tls and so on. And then the channel resource objects are covered, compared, and finally the results are synchronized to a patch API six cluster by invoking admin APIs. So this diagram fully shows the relationship between Ingress controller and Apache API six. Apache API six Ingress controller is used as a controller plan to calculate and synchronize restores configuration between Kubernetes and Apisix cluster. Well, what can we do with Apache Apisix in grace? I list many important features here such as dynamic configuration service discovery, flexible load balancing strategies, out of the box, health checks, traffic split and more than 70 official plugins, as well as the configuration of custom plugins, ability and so on. Welcome to watch the project and get more future information. Let me show the path of Apache API six Ingress controller in 2019. I wrote the first line of project and donated to the Apache foundation in December 2020 after half a year of community polishing. The first GA version was released in June 2021. Until the last version 1.4 release, Apache API Six Ingress has been used by more and more enterprises and working in production environments. Much has been learned along the way and soon we will be raising version 1.5 in midmain. This is contribute growth curve of the Apache API Six Ingress controller and its steady growth shows that the project has maintained a good level of activity. Well, there is a question I think you will ask. We know that there are many ingress implementations in kubernetes, but why we still create another ingress based on API six? Of course, as a gateway with excellent performance, Apache API six is necessary to implement ingress in order to help users to use it on Kubernetes platform. Apart from that, we certainly have other reasons that are why I recommend API six ingress to you. First. All configurations of API six take effect dynamically and there is no need to reload when the configuration is changed. Compared with some other ingress implementations, using API six ingredients has nature advantages. Apache API six ingredients is easier to use, the declarative configuration is more readable and complex scenarios can be defined in a single result. This example shows that an API is assigned to different upstream according to weights. Of course that certain condition must be made. Here we can see that the complete traffic split configuration are delivered into two parts, match and back end. The match part defines the root matching rules and the backend part defines the weight between upstreams. The whole configuration is very easy to read. Third, API six have strong scalability following the above configuration. If you want to add some features to this API, such as the ability to support cross domain and URIW, we can use plugins to empower the API. If you want to add more features, just add plugins. I'd like to say that the design of the plugin is very compatible with the declarative configuration and because of the in cap solution of plugin, you do not need to write code slaved in declarative configuration and no longer need to pay attention to these code logics. The only thing need to be case about is some simple variables which is more general and more readable. Okay, let's come back and talk about the flexibility of the architecture of Apache API six. Ingress controller Apache API six ingress does not combine controller and proxy like other ingresses. The advantage of this is that you can deploy them together or separately. When Ingress controller and API six are deployed together, they are used to handle ingress requests to a single Kubernetes cluster, no different from traditional Kubernetes ingress. You can also deploy them separately. This is awesome. As shown on the right, API six cluster is deployed outside the Kubernetes clusters and can manage the traffic on multiple Kubernetes clusters. In this way all resources be managed in unified API cluster and also reduce one traffic forwarding. The only thing you need to care about is the networking between the Kubernetes clusters. Here are some complaints using Apache API six more and more enterprise customers are using Apache API six for production environments. More and more user are adopting Apache API six Ingress solutions. That's what keeps our open source project going. Okay, I'd like to share with you the future plans of Apache API six Ingress controller. We are supporting the Kubernetes Gateway API and we are also preparing to support a new scenarios which is to support cluster deployment without etCD. I think users who mind etcd being stateful will be happy to hear about that. Why we made such changes because this needs from the community are very reasonable and this is the driving force for the project to continue. Okay, the above is the whole content of this sharing. Looking forward to build a patch API six community together with you. See you next time.