-
Notifications
You must be signed in to change notification settings - Fork 202
docs: add en doc for ingress #689
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,168 @@ | ||
| --- | ||
| title: "From 0 to 1, How APISIX Ingress Has Grown and Gained Since Joining The Community" | ||
| author: "Wei Jin" | ||
| authorURL: "https://github.com/gxthrj" | ||
| authorImageURL: "https://avatars.githubusercontent.com/u/4413028?v=4" | ||
| keywords: | ||
| - Apache APISIX | ||
| - APISIX Ingress Controller | ||
| - Kubernetes | ||
| - Apache | ||
| description: This article describes the growth of APISIX Ingress and the details of the enhancements and community help that APISIX Ingress has received since joining the community. | ||
| tags: [technology] | ||
| --- | ||
|
|
||
| > This article describes the growth of APISIX Ingress and the details of the enhancements and community help that APISIX Ingress has received since joining the community. | ||
|
|
||
| <!--truncate--> | ||
|
|
||
| ## Concepts | ||
|
|
||
| ### What is APISIX Ingress | ||
|
|
||
| In the K8s ecosystem, Ingress is a resource that represents the entry point for K8s traffic. To make it effective, an Ingress Controller is needed to listen to the Ingress resources in K8s, and to resolve the corresponding rules and actually carry the traffic. | ||
|
|
||
| APISIX Ingress is based on the Apache APISIX Ingress Controller implementation, which extends Kubernetes and also supports the native resource definition of Ingress resource. | ||
|
|
||
|  | ||
|
|
||
| As you can see in the figure above, APISIX Ingress is deployed in a Kubernetes cluster and proxies requests from a Kubernetes external cluster. These requests are then reverse proxied to the Kubernetes cluster Service, which also supports pushing services directly to the Service Pod. | ||
|
|
||
| ### What is Apache APISIX | ||
|
|
||
| We mentioned earlier that APISIX Ingress uses Apache APISIX as the actual data plane to carry business traffic, so what is Apache APISIX? | ||
|
|
||
| Apache APISIX is the top open source project of the Apache Foundation and the most active open source gateway project, and is currently certified as a trusted open source project by the China Academy of Information and Communications Technology. As a dynamic, real-time, high-performance open source API gateway, Apache APISIX provides rich traffic management features such as load balancing, dynamic upstream, grayscale publishing, service meltdown, authentication, observability, and more. | ||
|
|
||
|  | ||
|
|
||
| As you can see from the figure above, Apache APISIX is divided into two parts, data plane on the left side is used to handle the reverse proxy of traffic, and control plane on the right side is responsible for the distribution of configuration. | ||
|
|
||
| The Apache APISIX Ingress Controller uses declarative configuration, and after internal processing, the data is finally synchronized to etcd and transferred to Apache APISIX through the Admin API on the control plane to achieve configuration synchronization of the Apache APISIX cluster. | ||
|
|
||
| More information about Apache APISIX Ingress Controller features can be found [here](https://github.com/apache/apisix-ingress-controller). | ||
|
|
||
| ## Growth of APISIX Ingress | ||
|
|
||
| Most of the previous sessions have mentioned a lot about the usage scenarios or comparative advantages of Apache APISIX Ingress. This time, let's take a different perspective and analyze the birth and development of Apache APISIX Ingress. | ||
|
|
||
| ### Joining in the Apache Community | ||
|
|
||
| I provided the first lines of code for the APISIX Ingress Controller project in 2019 and the project was officially added to the Apache community in December 2020. In terms of product updates, we released the first GA version in June this year, as well as 1.3 this past October, and expect to release 1.4 in November this year to keep the project up to date. | ||
|
|
||
|  | ||
|
|
||
| The graph above shows the contributor growth curve for Apache APISIX Ingress Controller. Combined with the timeline, we can see that the number of contributors has been increasing at a high and steady rate since we joined the Apache community in December 2020. This reflects that Apache APISIX Ingress is gaining more and more attention from partners and is gradually being used in enterprise production environments. | ||
|
|
||
| ### Growing in the Apache Community | ||
|
|
||
| Starting with a personal project or a project incubated within a company and joining the community, the change of environment before and after inevitably leads to a change in the way the project works. By joining the community, Apache APISIX Ingress has received more support and assistance in terms of functionality and project integrity. | ||
|
|
||
| #### Start asynchronous discussions | ||
|
|
||
| After becoming an Apache Software Foundation project, the Apache APISIX Ingress Controller project became more open. For example, every feature added or modified to the product has to be discussed publicly, usually through a mailing list and a GitHub Issue. | ||
|
|
||
|  | ||
|  | ||
|
|
||
| At present, the two discussions are initiated at the same time, so that as many people as possible can judge the reasonableness of the features from their own use scenarios and use perspectives. This is no longer a personal project, but a community project, a collaborative effort involving multiple people. | ||
|
|
||
| At the same time, the asynchronous discussion of the mailing list and GitHub Issue allowed for a more comprehensive collection of feedback from the community (both questions and answers), and facilitated the search and organization of subsequent questions on a public basis. | ||
|
|
||
| #### Arrange Bi-weekly Meetings | ||
|
|
||
| In terms of interaction, Apache APISIX Ingress has taken the experience of some other communities and opened up a regular bi-weekly community meeting event. | ||
|
|
||
| This is a new channel that we hope to make the project transparent while also providing a more life-like channel for community members to discuss issues together. | ||
|
|
||
| Through this bi-weekly meeting, we will give you a detailed overview of what has happened in the last two weeks, what new issues have been raised and what PRs are waiting to be merged. Of course, we will also discuss any issues or suggestions for the current project. | ||
|
|
||
| We hope this will not only be an immediate discussion, but also an interaction to share and exchange observations from multiple perspectives. | ||
|
|
||
| For details on the bi-weekly meetings [click here](https://github.com/apache/apisix-ingress-controller/issues/614), you can also view the [replay of previous meetings](https://space.bilibili.com/551921247). | ||
|
|
||
| #### Become More Disciplined with Project Details | ||
|
|
||
| Another big change since entering the Apache community is that project planning has become more standardized, whether it's code, testing, or version releases. | ||
|
|
||
| At the code level, the community is currently using the [Golang Code Specification](https://github.com/uber-go/guide), with some automated checks via Action CI. | ||
|
|
||
| In order to ensure that the project features can be merged quickly and no new bugs are introduced, we also have requirements on the test specification. For example, during the feature development process, unit tests or e2e tests must be included. e2e tests integrate gruntwork-io/terratest and kubernetes-sigs/kind to build Kubernetes test environment. | ||
|
|
||
| The test framework is Ginkgo, which is widely accepted by the community. The perfect test cases greatly ensure the stability of the project and reduce the maintenance cost of the project. | ||
|
|
||
| In terms of release, we are also strictly following the Apache community release specification. Since APISIX Ingress Controller is also an extension of Kubernetes, the iterations involving CRD also follow the Kubernetes release rules. | ||
|
|
||
| ## Benefits of Joining the Apache Community | ||
|
|
||
| In addition to the above mentioned specifications on the project system, we have also received a lot of "technical feedbacks" from our partners during the process of going to the community. | ||
|
|
||
| ### Features Improvements | ||
|
|
||
| Most of these contributions come from community members using APISIX Ingress to solve problems or refine scenarios, such as | ||
|
|
||
| - Admission Hook | ||
| - Ingress' own Prometheus Metrics | ||
| - mTLs | ||
| - Improvements to the grayscale function | ||
| - Additional product documentation | ||
|
|
||
| More features [click here to view](https://github.com/apache/apisix-ingress-controller/#readme). | ||
|
|
||
| Also with feedback from the community, we have supported [multi-platform integration features](https://github.com/apache/apisix-ingress-controller/blob/master/install.md#installation) in response to popular demand. | ||
|
|
||
|  | ||
|
|
||
| ### Enriched library of usage scenarios | ||
|
|
||
| While the community was enriched with features, it was also enriched with scenarios on the use of Apache APISIX Ingress. | ||
|
|
||
| #### Scenario 1: Deploying Apache APISIX Ingress inside a Kubernetes cluster | ||
|
|
||
| One of the most typical ways is to deploy within a Kubernetes cluster, and the following diagram illustrates a typical usage scenario. | ||
|
|
||
|  | ||
|
|
||
| After the client passes through the external LB, it is processed by Apache APISIX, which acts as a gateway and a reverse proxy and can also be deployed inside and outside the Kubernetes cluster. | ||
|
|
||
| The above deployment scenario is to integrate APISIX Ingress Controller inside Kubernetes and synchronize the declarative configuration of Kubernetes to Apache APISIX through APISIX Ingress Controller. cluster data plane to directly proxy the subsequent Upstream business services. | ||
|
|
||
| #### Scenario 2: Deploying Apache APISIX Ingress Across Clusters | ||
|
|
||
| 苏州思必驰公司的用户为我们提供了关于跨集群使用场景，大体流程如下所示。 | ||
|
|
||
|  | ||
|
|
||
| 在上图架构中有两个集群，即云主机正式集群和物理机集群。Apache APISIX Ingress Controller 在每一个集群内都有部署，在与 Kubernetes API server 交互的同时，通过 Apache APISIX Admin API 将配置同步到 Apache APISIX 集群。 | ||
|
yzeng25 marked this conversation as resolved.
Outdated
|
||
|
|
||
| 在跨集群场景时，主要是通过 Apache APISIX 来打通集群之间的互相访问。通常集群之间的访问分为专线和公网，借助 Apache APISIX 的健康检查功能，可以做到当专线或公网传输失败时自动将流量切换到其他正常通道上，保证了业务的稳定与高可用。 | ||
|
yzeng25 marked this conversation as resolved.
Outdated
|
||
|
|
||
| #### Scenario 3: Manage Mutiple Kubernetes Clusters with one Apache APISIX Cluster | ||
|
|
||
|  | ||
|
|
||
| This usage scenario deploys the APISIX Ingress Controller inside a Kubernetes cluster, unlike Scenario 1 where there are multiple Kubernetes clusters. However, the corresponding Apache APISIX is actually deployed outside of all the Kubernetes clusters, and the configuration of each cluster is then synchronized to the overall Apache APISIX cluster via the Apache APISIX Ingress Controller. | ||
|
|
||
| The advantage of this is that you can fully control each Kubernetes cluster through a set of SLB Cluster, which can satisfy some enterprise architecture scenarios of multiple clusters or cross-room usage and reduce the number of forwarding on business traffic. | ||
|
|
||
| ### Conclusion | ||
|
|
||
| Thanks to the above harvest, Apache APISIX Ingress has gained more and more attention, and more and more enterprises have started to apply APISIX Ingress Controller to their own products, such as China Mobile, Youzan, Guanwei Intelligence, and many other enterprises. We expect more enterprises to choose Apache APISIX Ingress in the future. | ||
|
|
||
| ## Future Plan | ||
|
|
||
| Apache APISIX Ingress has also received some suggestions from many community partners in the process of continuous iteration, such as some feature planning for future products. | ||
|
|
||
| ### Support Kubernetes gateway API | ||
|
|
||
| The Kubernetes community has given a gateway API implementation standard to unify the design of Ingress. Once this standard is implemented, subsequent users can use the same configuration in different Ingress when using APISIX Ingress, perfectly adapting to multiple deployments. | ||
|
|
||
| ### Support Ingress Controller Monolithic Architecture | ||
|
|
||
| There are some voices in the community who believe that etcd, on which Apache APISIX relies, is actually a stateful service, and once stateful services are involved, additional attention needs to be paid to storage and migration related work. | ||
|
|
||
| We hope to make Apache APISIX seamlessly scalable in a containerized cloud-native scenario, so we will follow up with deployment planning for the Ingress Controller monolithic architecture. In this scenario, Apache APISIX can be deployed separately from etcd, and declarative configurations can be listened to by the Apache APISIX Ingress Controller and synchronized to Apache APISIX. | ||
|
|
||
| More future plans and feature-related content [click here](https://github.com/apache/apisix-ingress-controller/milestones). | ||
|
|
||
| The development of the community is never-ending, and we appreciate your support of Apache APISIX Ingress Controller along the way. We hope that you will actively participate and give us feedback on any issues regarding the Apache APISIX Ingress Controller project to make the product even better. | ||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.