This is an automated email from the ASF dual-hosted git repository.
sunyi pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/apisix-website.git
The following commit(s) were added to refs/heads/master by this push:
new f60c3fd docs: add en doc for ingress (#689)
f60c3fd is described below
commit f60c3fd39944c322ddd1cd536d69bb74693f6765
Author: yilinzeng <[email protected]>
AuthorDate: Fri Oct 29 14:40:20 2021 +0800
docs: add en doc for ingress (#689)
---
.../12/18/first-look-at-kubernetes-service-api.md | 8 +-
.../blog/2021/05/25/Apache APISIX 2.6.0-Release.md | 2 +-
...s-Mesh-helps-Apache-APISIX-improve-stability.md | 2 +-
...ss-Control-Bypass-Vulnerability-Announcement.md | 2 +-
...of-Apache-APISIX-Ingress-Controller-released.md | 4 +-
website/blog/2021/07/25/apachecon-asia.md | 2 +-
website/blog/2021/10/27/APISIX Ingress.md | 170 ---------------------
website/blog/2021/10/27/APISIX-Ingress.md | 167 ++++++++++++++++++++
.../10/27/{APISIX Ingress.md => APISIX-Ingress.md} | 6 +-
9 files changed, 179 insertions(+), 184 deletions(-)
diff --git a/website/blog/2020/12/18/first-look-at-kubernetes-service-api.md
b/website/blog/2020/12/18/first-look-at-kubernetes-service-api.md
index a60c614..020f842 100644
--- a/website/blog/2020/12/18/first-look-at-kubernetes-service-api.md
+++ b/website/blog/2020/12/18/first-look-at-kubernetes-service-api.md
@@ -14,7 +14,7 @@ tags: [Technology]
> This article provides a basic introduction to the Kubernetes Service APIs by
> asking questions. As a whole, the Kubernetes Service APIs refine many
> ingress best practices, such as expression enhancements that actually extend
> the capabilities of Route, and BackendPolicy objects that can specify almost
> any Kubernetes backend resource for upstream.
-<! --truncate -->
+<!--truncate-->
> Source:
>
@@ -53,9 +53,9 @@ matches:
version: "2"
- path:
value: "/v2/foo"
-```` 2.
+```
-The Service APIs propose the concept of multi-layer APIs, each layer exposes
its interface independently to facilitate other custom resources to interface
with the APIs and achieve finer granularity (API granularity) control.
+2. The Service APIs propose the concept of multi-layer APIs, each layer
exposes its interface independently to facilitate other custom resources to
interface with the APIs and achieve finer granularity (API granularity) control.
! [api-model](https://gateway-api.sigs.k8s.io/images/api-model.png)
@@ -151,8 +151,6 @@ Currently, the Kubernetes Service APIs are focused on Route.
This article provides a basic introduction to the Kubernetes Service APIs by
asking questions. As a whole, the Kubernetes Service APIs refine a lot of
ingress best practices, such as the enhancement of expression capabilities,
which actually extends the capabilities of the Route, and the BackendPolicy
object The Kubernetes Service APIs as a whole refine a lot of ingress best
practices, such as the enhanced expressiveness, which actually extends the
capabilities of Route, and the BackendP [...]
----
-
Reference:
- https://gateway-api.sigs.k8s.io/
diff --git a/website/blog/2021/05/25/Apache APISIX 2.6.0-Release.md
b/website/blog/2021/05/25/Apache APISIX 2.6.0-Release.md
index 253f498..702c465 100644
--- a/website/blog/2021/05/25/Apache APISIX 2.6.0-Release.md
+++ b/website/blog/2021/05/25/Apache APISIX 2.6.0-Release.md
@@ -14,7 +14,7 @@ tags: [Release]
> Apache APISIX 2.6.0-Release is officially released! Welcome to download and
> use.
-<! --truncate -->
+<!--truncate-->
## Release Notes
diff --git
a/website/blog/2021/06/16/Chaos-Mesh-helps-Apache-APISIX-improve-stability.md
b/website/blog/2021/06/16/Chaos-Mesh-helps-Apache-APISIX-improve-stability.md
index 011e5dc..849ecd7 100644
---
a/website/blog/2021/06/16/Chaos-Mesh-helps-Apache-APISIX-improve-stability.md
+++
b/website/blog/2021/06/16/Chaos-Mesh-helps-Apache-APISIX-improve-stability.md
@@ -13,7 +13,7 @@ tags: [Practical Case]
> This article describes how to use Chaos Mesh in a variety of scenarios to
> improve stability for Apache APISIX.
-<! --truncate -->
+<!--truncate-->
Apache APISIX is a top-level project under the Apache Foundation and has been
tested in production environments with tens of billions of requests per day. As
the community has grown, Apache APISIX has become more and more powerful,
requiring more and more interactions with external components, and the
uncertainty that comes with it has grown exponentially. We have received some
feedback from users in the community, and here are two examples.
diff --git
a/website/blog/2021/06/17/Apache-APISIX-Dashboard-Access-Control-Bypass-Vulnerability-Announcement.md
b/website/blog/2021/06/17/Apache-APISIX-Dashboard-Access-Control-Bypass-Vulnerability-Announcement.md
index d9886db..894e5f6 100644
---
a/website/blog/2021/06/17/Apache-APISIX-Dashboard-Access-Control-Bypass-Vulnerability-Announcement.md
+++
b/website/blog/2021/06/17/Apache-APISIX-Dashboard-Access-Control-Bypass-Vulnerability-Announcement.md
@@ -13,7 +13,7 @@ tags: [Security]
> Because the application makes access control determinations by obtaining the
> value of the request header `X-Forwarded-For`, an attacker can achieve an
> access control bypass attack by simply tampering with that request header
> when invoking the API request.
-<! --truncate -->
+<!--truncate-->
## Problem Description
diff --git
a/website/blog/2021/06/18/first-GA-version-v1.0-of-Apache-APISIX-Ingress-Controller-released.md
b/website/blog/2021/06/18/first-GA-version-v1.0-of-Apache-APISIX-Ingress-Controller-released.md
index 49e6dae..4a319cc 100644
---
a/website/blog/2021/06/18/first-GA-version-v1.0-of-Apache-APISIX-Ingress-Controller-released.md
+++
b/website/blog/2021/06/18/first-GA-version-v1.0-of-Apache-APISIX-Ingress-Controller-released.md
@@ -13,13 +13,13 @@ tags: [Release]
> Apache APISIX Ingress Controller v1.0 has been released, supporting the use
> of custom resources including `ApisixRoute`, `ApisixUpstream`, and
> Kubernetes native Ingress resources to control external traffic access to
> services deployed in Kubernetes. services deployed in Kubernetes.
-<! --truncate -->
+<!--truncate-->
## About Apache APISIX Ingress Controller
The Apache APISIX Ingress Controller is a cloud-native Ingress Controller
implementation that uses Apache APISIX as a data plane to carry traffic and
extends Kubernetes using CRD.
-<! --truncate -->
+<!--truncate-->
Supports controlling external traffic access to services deployed in
Kubernetes using custom resources including ApisixRoute, ApisixUpstream, and
Kubernetes-native Ingress resources.
diff --git a/website/blog/2021/07/25/apachecon-asia.md
b/website/blog/2021/07/25/apachecon-asia.md
index f3bbe43..fd5512c 100644
--- a/website/blog/2021/07/25/apachecon-asia.md
+++ b/website/blog/2021/07/25/apachecon-asia.md
@@ -70,7 +70,7 @@ Therefore, here we use Chaos Mesh, a Kubernetes-based chaos
engineering platform
### Sharing Guests
-! Yang [Shu Yang Wu](/img/blog_img/2021-07-25-4.png)
+
Yang Wu - Committer for Apache APISIX and Chaos Mesh, he leads the integration
of Chaos Mesh with Apache APISIX CI.
diff --git a/website/blog/2021/10/27/APISIX Ingress.md
b/website/blog/2021/10/27/APISIX Ingress.md
deleted file mode 100644
index 1709283..0000000
--- a/website/blog/2021/10/27/APISIX Ingress.md
+++ /dev/null
@@ -1,170 +0,0 @@
----
-title: "从 0 到 1，APISIX Ingress 加入社区后的发展与收获"
-author: "金卫"
-authorURL: "https://github.com/gxthrj";
-authorImageURL: "https://avatars.githubusercontent.com/u/4413028?v=4";
-keywords:
-- Apache APISIX
-- APISIX Ingress Controller
-- Kubernetes
-- Apache
-description: 本文通过从代码创始人角度，为大家描述了 APISIX Ingress
的成长历程，以及加入社区后的功能提升与社区帮助等多方面细节收获。
-tags: [technology]
----
-
-> 本文通过从代码创始人角度，为大家描述了 APISIX Ingress 的成长历程，以及加入社区后的功能提升与社区帮助等多方面细节收获。
-
-<!--truncate-->
-
-## 概念篇
-
-### APISIX Ingress 概述
-
-在 K8s 生态中，Ingress 作为表示 K8s 流量入口的一种资源，想要让其生效，就需要有一个 Ingress Controller 去监听 K8s
中的 Ingress 资源，并对这些资源进行相应规则的解析和实际承载流量。
-
-APISIX Ingress 则是基于 Apache APISIX 的 Ingress Controller 实现，实现了对 Kubernetes
的扩展，同时也支持 Ingress resource 的原生资源定义。
-
-
-
-通过上图可以看到，APISIX Ingress 是在 Kubernetes 集群中部署，并代理 Kubernetes
外部集群的请求。然后将这些请求反向代理到 Kubernetes 集群 Service，同时也支持直接将服务推送到 Service Pod。
-
-### 什么是 Apache APISIX
-
-前边我们提到了 APISIX Ingress 是采用 Apache APISIX 作为实际承载业务流量的数据面，那么 Apache APISIX
项目又是做什么的呢？
-
-Apache APISIX 是 Apache
基金会旗下的顶级开源项目，也是当前最活跃的开源网关项目，目前也通过中国信通院的可信开源项目认证。作为一个动态、实时、高性能的开源 API 网关，Apache
APISIX 提供了负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。
-
-
-
-从上图框架可以看到，Apache APISIX 分为两部分，左侧数据面用来处理流量的反向代理，右侧控制面负责配置的分发。
-
-Apache APISIX Ingress Controller 采用声明式的配置，经过内部处理后，最终会通过控制面的 Admin API 将数据同步到
etcd 中并传输给 Apache APISIX，实现 Apache APISIX 集群的配置同步。
-
-更多关于 Apache APISIX Ingress Controller
特性讲解[点此查阅](https://github.com/apache/apisix-ingress-controller)。
-
-## 成长篇
-
-关于 Apache APISIX Ingress 的使用场景或者产品对比优势等，在往期的分享中大都提及了很多。这次我们换个角度，从 Apache
APISIX Ingress 的诞生及发展角度进行解析。
-
-### 加入 Apache 社区
-
-
-
-2019 年我给 APISIX Ingress Controller 项目提供了第一行代码，2020 年 12 月份该项目被正式加入到 Apache
社区。在产品更新上，今年 6 月份我们发布了第一个 GA 版本，同时在刚刚过去的 10 月份中也发布了 1.3 版本，预计在今年 11 月份将会发布 1.4
版本，保证项目的正常更新迭代。
-
-
-
-上图是 Apache APISIX Ingress Controller 的贡献者增长曲线图。结合时间轴可以看到，从 2020 年 12 月加入
Apache 社区后，贡献者的人数增加速度呈现出高速稳定增长的态势。侧面反映出 Apache APISIX Ingress
得到了越来越多小伙伴的关注，并开始逐步应用到企业生产环境中。
-
-### 在社区中成长
-
-从个人项目或企业内部孵化出的项目开始到加入社区，前后环境的转换必然会导致项目工作方式的变化。加入社区后，Apache APISIX Ingress
在功能和项目整体度上得到了更多的支持与帮助。
-
-#### 开启异步化讨论
-
-成为 Apache 软件基金会项目后，Apache APISIX Ingress Controller
项目变得更加开放。比如关于产品每一个特性的新增或者修改都必须经过一些公开的讨论，讨论的方式一般分为邮件列表讨论和 GitHub Issue 讨论。
-
-
-
-
-目前是上述两种讨论同时发起，尽可能多地让大家站在各自的使用场景以及使用角度去评判特性的合理性。因为这已不再是一个个人项目，而是一个社区项目，是多人参与的合作产出。
-
-同时，通过邮件列表和 GitHub Issue
的异步式讨论，可以更全面地收集到社区的反馈（不管是提问还是回答），在公开化的基础上为后续问题的搜索和整理提供了便利。
-
-#### 增设社区例会
-
-在互动方面，Apache APISIX Ingress 吸取了一些其他社区的经验，开放了一个每两周进行的社区例会活动。
-
-这是一个新的渠道，我们希望让项目透明化的同时，也可以为社区小伙伴提供一个更生活化的渠道来一起讨论问题。
-
-通过这个双周例会，我们会给大家详细介绍最近两周项目发生了哪些变化，有哪些新的 issue 被提出以及哪些 PR
正在等待合并。当然也会跟大家一起讨论当前项目的一些问题或建议。
-
-我们希望这不仅是一个即时讨论的过程，更是一个分享和交流多角度事物观察的互动。
-
-具体关于双周例会的会议内容[点此查阅](https://github.com/apache/apisix-ingress-controller/issues/614)，也可以点此查看[往期例会回放](https://space.bilibili.com/551921247)。
-
-#### 项目细节更合规
-
-进入 Apache 社区后，另一个比较大的变化是项目规划上变得更加规范，不管是代码、测试还是版本发布。
-
-在代码层面，目前社区采用的是 [Golang 代码规范](https://github.com/uber-go/guide)，通过 Action CI
进行一些自动化检查。
-
-为了保证项目特性能够快速合并，并且不会引入新的 bug，在测试规范上我们也进行了相关要求。比如在特性开发过程中，一定要包含单元测试或者 e2e 测试，其中
e2e 测试集成了 gruntwork-io/terratest 以及 kubernetes-sigs/kind，用来构建 Kubernetes 测试环境。
-
-同时测试框架采用的是社区中广为接纳的 Ginkgo，测试用例的完善极大地保证了项目稳定性，同时也降低了项目的维护成本。
-
-在版本发布方面，目前也是严格遵循了 Apache 社区的发版规范。同时由于 APISIX Ingress Controller 也是属于
Kubernetes 的一个扩展，所以在涉及 CRD 的迭代部分也是按照 Kubernetes 的发版规则进行。
-
-## 收获篇
-
-除了上述提到的关于项目制度上的一些规范，走向社区的过程中，我们也收获了很多小伙伴们的「技术回馈」。
-
-### 完善了更多细节功能
-
-这些贡献大都来源于社区小伙伴们平时在使用 APISIX Ingress 当中遇到的一些问题，或者场景上的一些完善，比如：
-
-- Admission Hook
-- Ingress 本身的 Prometheus Metrics
-- mTLs
-- 灰度功能的完善
-- 产品使用文档的补充
-
-更多特性[点此查看](https://github.com/apache/apisix-ingress-controller/pulls?q=is%253Apr)。
-
-同时借助社区的反馈，我们也顺应大家的需求支持了[多平台集成功能](https://github.com/apache/apisix-ingress-controller/blob/master/install.md#installation)。
-
-
-
-### 丰富了使用场景库
-
-在社区里得到功能加持的同时，也收获了关于 Apache APISIX Ingress 的使用场景上的丰富。
-
-#### 场景一：Kubernetes 集群内部
-
-最典型的一种方式是在 Kubernetes 集群内部进行部署，如下图就是一个典型的使用场景示意图。
-
-
-
-客户端经过外部 LB 后，经过 Apache APISIX 进行承接处理。Apache APISIX 作为网关也是一个反向代理，同时还可以部署在
Kubernetes 集群内外。
-
-上图的部署场景就是在 Kubernetes 内部集成 APISIX Ingress Controller，通过 APISIX Ingress
Controller 将 Kubernetes 的声明式配置同步到 Apache APISIX。这样外部的请求就可以通过 Apache APISIX
集群数据面去直接代理后续 Upstream 的业务服务。
-
-#### 场景二：跨集群部署
-
-苏州思必驰公司的用户为我们提供了关于跨集群使用场景，大体流程如下所示。
-
-
-
-在上图架构中有两个集群，即云主机正式集群和物理机集群。Apache APISIX Ingress Controller 在每一个集群内都有部署，在与
Kubernetes API server 交互的同时，通过 Apache APISIX Admin API 将配置同步到 Apache APISIX 集群。
-
-在跨集群场景时，主要是通过 Apache APISIX 来打通集群之间的互相访问。通常集群之间的访问分为专线和公网，借助 Apache APISIX
的健康检查功能，可以做到当专线或公网传输失败时自动将流量切换到其他正常通道上，保证了业务的稳定与高可用。
-
-#### 场景三：一个 Apache APISIX 集群管理多个 Kubernetes 集群
-
-
-
-该使用场景是将 APISIX Ingress Controller 部署在 Kubernetes 集群内部，与场景一不同的是这里有多个 Kubernetes
集群。但相应的 Apache APISIX 实际上是部署在所有 Kubernetes 集群外部，然后通过 Apache APISIX Ingress
Controller 将各自集群的配置同步到总的 Apache APISIX 集群中。
-
-这样做的优势是可以通过一套 SLB Cluster 去完全控制各个 Kubernetes
集群，满足一些企业架构为多集群或跨机房的使用场景，减少业务流量上的转发次数。
-
-### 总结
-
-得益于以上收获成果，Apache APISIX Ingress 也得到了越来越多的关注，越来越多的企业也开始将 APISIX Ingress
Controller 应用到自家产品中，比如中国移动、又拍云、有赞、观为智慧等多家企业。未来期待更多企业选择 Apache APISIX Ingress。
-
-## 未来规划
-
-Apache APISIX Ingress 在不断迭代的过程中，也收到了很多社区小伙伴的一些建议，比如对未来产品的一些功能规划：
-
-### 后续支持 Kubernetes gateway API
-
-目前 Kubernetes 社区里也有很多企业在做自己的 Ingress 项目支持，Kubernetes 社区为了能统一 Ingress 的设计，给出了
gateway API 的实现标准。一旦实现了这种标准，后续用户再使用 APISIX Ingress 时，就可以做到同一份配置在不同的 Ingress
里去使用，完美适配多方部署。
-
-### 后续支持 Ingress Controller 单体架构
-
-目前社区里有一些声音会认为 Apache APISIX 所依赖的 etcd
实际上是一个有状态的服务，一旦涉及到有状态的服务，就需要额外去关注存储和迁移相关的工作。
-
-大家希望在容器化的云原生场景下，让 Apache APISIX 可以无缝扩容，所以后续也会去进行 Ingress Controller
单体架构的部署规划。在这种场景下，Apache APISIX 可以脱离 etcd 单独部署，声明式配置可以被 Apache APISIX Ingress
Controller 监听并同步到 Apache APISIX。
-
-更多未来规划以及特性相关内容[点此查阅](https://github.com/apache/apisix-ingress-controller/milestones)。
-
-社区的发展是永无止境的，很感谢一路以来各位用户对 Apache APISIX Ingress Controller
的支持。希望大家在后续使用过程中，可以积极地参与和反馈关于 Apache APISIX Ingress Controller 项目的任何问题，让产品变得更优秀。
diff --git a/website/blog/2021/10/27/APISIX-Ingress.md
b/website/blog/2021/10/27/APISIX-Ingress.md
new file mode 100644
index 0000000..1ad03a0
--- /dev/null
+++ b/website/blog/2021/10/27/APISIX-Ingress.md
@@ -0,0 +1,167 @@
+---
+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
+
+Speech.ai, a company based in Suzhou, have provided us with a cross-cluster
usage scenario, and the general flow is shown below.
+
+
+There are two clusters in the above architecture, the formal cloud host
cluster and the physical machine cluster. Apache APISIX Ingress Controller is
deployed within each cluster, interacting with the Kubernetes API server while
synchronizing the configuration to the Apache APISIX Admin API. APISIX clusters.
+
+In cross-cluster scenarios, access between clusters is mainly through Apache
APISIX. Usually, the access between clusters is divided into private line and
public network. With the health check function of Apache APISIX, the traffic
can be automatically switched to other normal channels when the private line or
public network transmission fails, which ensures the stability and high
availability of business.
+
+#### 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.
diff --git a/website/i18n/zh/docusaurus-plugin-content-blog/2021/10/27/APISIX
Ingress.md
b/website/i18n/zh/docusaurus-plugin-content-blog/2021/10/27/APISIX-Ingress.md
similarity index 96%
rename from website/i18n/zh/docusaurus-plugin-content-blog/2021/10/27/APISIX
Ingress.md
rename to
website/i18n/zh/docusaurus-plugin-content-blog/2021/10/27/APISIX-Ingress.md
index 1709283..25a5141 100644
--- a/website/i18n/zh/docusaurus-plugin-content-blog/2021/10/27/APISIX
Ingress.md
+++
b/website/i18n/zh/docusaurus-plugin-content-blog/2021/10/27/APISIX-Ingress.md
@@ -8,11 +8,11 @@ keywords:
- APISIX Ingress Controller
- Kubernetes
- Apache
-description: 本文通过从代码创始人角度，为大家描述了 APISIX Ingress
的成长历程，以及加入社区后的功能提升与社区帮助等多方面细节收获。
+description: 本文描述了 APISIX Ingress 的成长历程，以及 APISIX Ingress
加入社区后的功能提升与社区帮助等多方面细节收获。
tags: [technology]
---
-> 本文通过从代码创始人角度，为大家描述了 APISIX Ingress 的成长历程，以及加入社区后的功能提升与社区帮助等多方面细节收获。
+> 本文描述了 APISIX Ingress 的成长历程，以及 APISIX Ingress 加入社区后的功能提升与社区帮助等多方面细节收获。
<!--truncate-->
@@ -109,7 +109,7 @@ Apache APISIX Ingress Controller 采用声明式的配置，经过内部处理
- 灰度功能的完善
- 产品使用文档的补充
-更多特性[点此查看](https://github.com/apache/apisix-ingress-controller/pulls?q=is%253Apr)。
+更多特性[点此查看](https://github.com/apache/apisix-ingress-controller/#readme)。
同时借助社区的反馈，我们也顺应大家的需求支持了[多平台集成功能](https://github.com/apache/apisix-ingress-controller/blob/master/install.md#installation)。
