This is an automated email from the ASF dual-hosted git repository.
yilinzeng 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 8e23efcf8e6 docs:add four blogs (#1471)
8e23efcf8e6 is described below
commit 8e23efcf8e6ec97855d880acdbc73a6563d2dc60
Author: 长龙 <[email protected]>
AuthorDate: Thu Feb 2 11:23:26 2023 +0800
docs:add four blogs (#1471)
---
.../blog/2023/01/11/apisix-amesh-introduction.md | 87 ++++++
.../2023/01/11/apisix-ingress-vs-ingress-nginx.md | 328 +++++++++++++++++++++
blog/zh/blog/2023/01/12/amesh-config-plugin.md | 155 ++++++++++
blog/zh/blog/2023/01/12/serverless-auth-type.md | 119 ++++++++
4 files changed, 689 insertions(+)
diff --git a/blog/zh/blog/2023/01/11/apisix-amesh-introduction.md
b/blog/zh/blog/2023/01/11/apisix-amesh-introduction.md
new file mode 100644
index 00000000000..83caa7e82b6
--- /dev/null
+++ b/blog/zh/blog/2023/01/11/apisix-amesh-introduction.md
@@ -0,0 +1,87 @@
+---
+title: "基于 APISIX 的服务网格方案 Amesh 积极开发中！"
+authors:
+ - name: "lingsamuel"
+ title: "Author"
+ url: "https://github.com/lingsamuel";
+ image_url: "https://github.com/lingsamuel.png";
+keywords:
+- Apache APISIX
+- Amesh
+- Service Mesh
+- 服务网格
+- Kubernetes
+description: Amesh 是 Apache APISIX 的服务网格库。它适配了 xDS 协议，可以从诸如 Istio
的控制平面中接收数据，并生成 APISIX 所需的数据结构，使得 APISIX 能够在服务网格领域作为数据面发挥作用。
+tags: [Ecosystem]
+---
+
+>
在云原生快速发展的前提下，服务网格领域也开始逐渐火热。目前阶段，大家所熟知的服务网格解决方案很多，每种产品又各有其优势。因此在面对不同的行业或者业务背景时，每个人的选型想法都各不相同。
+
+<!--truncate-->
+
+> 作者 [lingsamuel](https://github.com/lingsamuel)，API7.ai 云原生技术专家，Apache APISIX
Committer。
+
+Apache APISIX 是一个动态、实时、高性能的云原生 API
网关，提供负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。基于 APISIX 的扩展道路上，除了 APISIX Ingress
在云原生领域被各大厂商开始关注外，基于 APISIX 的服务网格方案也在积极迭代中。
+
+## 基于 APISIX 的服务网格方案
+
+[Amesh](https://github.com/api7/amesh) 是 [Apache
APISIX](https://github.com/apache/apisix) 的服务网格库。它适配了 xDS 协议，可以从诸如 Istio
的控制平面中接收数据，并生成 APISIX 所需的数据结构，使得 APISIX 能够在服务网格领域作为数据面发挥作用。
+
+依靠 Amesh，APISIX 可以工作在服务网格模式下，不使用传统的 etcd 作为数据中心，而是使用 shdict 与 Amesh
库直接进行数据交换，避免了额外的性能损耗，使得大规模部署成为可能。
+
+通过使用 Amesh，可以在服务网格领域获得 APISIX 具备的高性能、丰富的流量管理功能、易扩展性等多种优势。
+
+### Amesh 的架构
+
+Amesh 通过适配 xDS 协议，可以让 APISIX 替代 Istio 所使用的 envoy 组件来接管集群流量。在实际使用中，APISIX 将作为
Pod 的 Sidecar 接管网格内的所有流量。目前 Amesh 的架构如下图所示：
+
+
+
+通过架构图可以看到，通过 xDS 协议，Amesh 可以将 Istio 作为控制面，从 Istio 侧获取配置信息，并将其转义为 APISIX 所需的配置。
+
+而网格内部的所有流量都将由 APISIX 接管。其中，APISIX 的配置中心被设置为 Amesh，这使得 APISIX 脱离 etcd 的依赖。Amesh
为 APISIX 提供了一种从 xDS 协议中获取配置信息的方式。
+
+此外，Amesh 在 v0.2 中提供了额外的可选控制面组件：`amesh-controller` ，它增加了 Amesh 专用的 CRD，可以为
APISIX 配置一些 Istio 所不支持的额外功能。额外带有 `amesh-controller` 的架构如下图所示：
+
+
+
+正如前文所提到的，`amesh controller` 是可选组件。在未安装时，Amesh 也能正常使用 Istio 的原生能力提供服务。在安装了
amesh-controller 后，Amesh 能自动检测到控制面的加入，并动态地从中获取配置，而无需重启。
+
+`amesh-controller` 为 Amesh 提供了 Istio 无法提供的 APISIX 特有功能。例如在安装
`amesh-controller` 后，用户能为服务配置 APISIX 原生具备的海量插件。
+
+## Amesh 发展状态
+
+目前 Amesh 项目正在积极开发中。在最近发布的的 v0.2 版本中，Amesh 新增了可选的控制面 `amesh-controller` 组件，为
Amesh 提供了 APISIX 所支持的强大的插件系统，大大增强了 Amesh 的可扩展性。
+
+### 扩展能力
+
+在使用 Amesh 时，如果是常规的 Istio 部署，用户则可以通过 Lua 或 Wasm 来对 Envoy 进行功能扩展。
+
+与 Envoy 原生能力相比，APISIX 官方即支持插件扩展能力，维护了 80+ 的插件可供用户使用，许多功能已经原生集成。但由于在 Istio
中，不能对这些插件进行配置，无法直接使用这些插件所提供的能力。
+
+为此，Amesh v2.0 版本新增了一个控制面组件，即前文提到的 `amesh-controller`。它为用户提供了配置 APISIX 插件的能力，使
APISIX 众多的插件在服务网格场景下也能开箱即用，而无需用户进行自定义的开发。
+
+### 应用示例
+
+在 Amesh v0.2 版本中，可以通过安装 `amesh-controller` 并使用提供的 `AmeshPluginConfig` CRD 来进行
APISIX 的插件配置。
+
+例如，我们可以为请求的响应添加特定的 header，这里可以通过配置 APISIX 的 `response-rewrite` 插件实现。
+
+假设我们需要添加的 header 为 `X-Header`，其值为 `AddedHeader`，我们可以配置如下的
`AmeshPluginConfig`，此时请求的响应中就会带上我们所需的 header。
+
+```YAML
+apiVersion: apisix.apache.org/v1alpha1
+kind: AmeshPluginConfig
+metadata:
+ name: ampc-sample
+spec:
+ plugins:
+ - name: response-rewrite
+ config: '{"headers": {"X-Header":"AddedHeader"}}'
+```
+
+## 总结
+
+在本文中，我们简单介绍了 [Amesh](https://github.com/api7/amesh) 的架构，以及在 v0.2 版本中提供的
`amesh-controller` 所带来的架构变更，可以更好地帮助用户理解 Amesh 的工作原理。
+
+在当下技术发展趋势中，服务网格势必是未来的流行趋势。虽然现在各种方案都还不太完善，但整体都属于螺旋上升的状态。当然，基于 APISIX
的服务网格也正朝着大家心目中的理想型服务网格解决方案奋进，也欢迎各位对 APISIX 服务网格方案感兴趣的朋友们进行尝鲜。
diff --git a/blog/zh/blog/2023/01/11/apisix-ingress-vs-ingress-nginx.md
b/blog/zh/blog/2023/01/11/apisix-ingress-vs-ingress-nginx.md
new file mode 100644
index 00000000000..54831c40802
--- /dev/null
+++ b/blog/zh/blog/2023/01/11/apisix-ingress-vs-ingress-nginx.md
@@ -0,0 +1,328 @@
+---
+title: "为什么 APISIX Ingress 是比 Ingress NGINX 更好的选择？"
+authors:
+ - name: "容鑫"
+ title: "Author"
+ url: "https://github.com/AlinsRan";
+ image_url: "https://github.com/AlinsRan.png";
+keywords:
+- Apache APISIX
+- Ingress
+- Ingress Controller
+- Ingress nginx
+- Kubernetes
+description: 本文将会对比两个比较流行的 Ingress controller 实现，希望能对读者进行 Ingress controller
选型中有所帮助。
+tags: [Ecosystem]
+---
+
+> 本文将会对比两个比较流行的 Ingress controller 实现，希望能对读者进行 Ingress controller 选型中有所帮助。
+
+<!--truncate-->
+
+> 作者容鑫，API7.ai 云原生技术工程师，Apache APISIX Committer。
+
+本文将会对比两个比较流行的 Ingress controller 实现，希望能对读者进行 Ingress controller 选型中有所帮助。
+
+>[Ingress NGINX](https://github.com/kubernetes/ingress-nginx) 是 Kubernetes
社区实现的 Ingress controller，在社区中被广泛使用。[Apache APISIX
Ingress](https://github.com/apache/apisix-ingress-controller) 则是 Apache
软件基金会下的开源项目，使用 APISIX 作为数据面的 Kubernetes Ingress controller。
+
+## Ingress NGINX vs APISIX Ingress
+
+### 功能对比
+
+下列表格中，对比了 Ingress NGINX 和 APISIX Ingress
基本功能，包括协议支持、鉴权方式、上游探针/策略、负载均衡策略、Kubenertes 集成等。以下表格数据取自
[learnk8s.io](https://docs.google.com/spreadsheets/d/191WWNpjJ2za6-nbG4ZoUMXMpUK8KlCIosvQB0f-oq3k)。
+
+| Product/Project | | Ingress
NGINX | Apache APISIX Ingress |
+| :---------------------------- | :----------------------------- |
:------------------------ | :-------------------- |
+| 1. General info | |
| |
+| | Based on | nginx
| nginx |
+| 2. Protocols | |
| |
+| | HTTP/HTTPS | ✔️
| ✔️ |
+| | HTTP2 | ✔️
| ✔️ |
+| | gRPC | ✔️
| ✔️ |
+| | TCP | Partial
| ✔️ |
+| | TCP+TLS | ✖︎
| ✔️ |
+| | UDP | Partial
| ✔️ |
+| | Websockets | ✔️
| ✔️ |
+| | Proxy Protocol | ✔️
| ✔️ |
+| | QUIC/HTTP3 | Preview
| Preview |
+| 3. Clients | |
| |
+| | Rate limiting (L7) | ✔️
| ✔️ |
+| | WAF | ✔️
| Partial |
+| | Timeouts | ✔️
| ✔️ |
+| | Safe-list/Block-list | ✔️
| ✔️ |
+| | Authentication | ✔️
| ✔️ |
+| | Authorisation | ✖︎
| ✔️ |
+| 4. Traffic routing | |
| |
+| | Host | ✔️
| ✔️ |
+| | Path | ✔️
| ✔️ |
+| | Headers | ✔️
| ✔️ |
+| | Querystring | ✔️
| ✔️ |
+| | Method | ✔️
| ✔️ |
+| | ClientIP | ✔️
| ✔️ |
+| 5. Upstream probes/resiliency | |
| |
+| | Healthchecks | ✖︎
| ✔️ |
+| | Retries | ✔️
| ✔️ |
+| | Circuit Breaker | ✖︎
| ✔️ |
+| 6.Load balancer strategies | |
| |
+| | Round robin | ✔️
| ✔️ |
+| | Sticky sessions | ✔️
| ✔️ |
+| | Least connections | ✖︎
| ✔️ |
+| | Ring hash | ✔️
| ✔️ |
+| | Custom load balancing | ✖︎
| ✔️ |
+| 7. Authentication | |
| |
+| | Basic auth | ✔️
| ✔️ |
+| | External Auth | ✔️
| ✔️ |
+| | Client certificate - mTLS | ✔️
| ✔️ |
+| | OAuth | ✔️
| ✔️ |
+| | OpenID | ✖︎
| ✔️ |
+| | JWT | ✖︎
| ✔️ |
+| | LDAP | ✖︎
| ✔️ |
+| | HMAC | ✖︎
| ✔️ |
+| 8. Observability | |
| |
+| | Logging | ✔️
| ✔️ |
+| | Metrics | ✔️
| ✔️ |
+| | Tracing | ✔️
| ✔️ |
+| 9. Kubernetes Integration | |
| |
+| | State | Kubernetes
| Kubernetes |
+| | CRD | ✖︎
| ✔️ |
+| | Scope |
Clusterwide<br/>namespace | namespace |
+| | Support for the Gateway API | ✖︎
| Preview |
+| | Integrates with service meshes | ✔️
| ✔️ |
+| 10. Traffic shaping | |
| |
+| | Canary | ✔️
| ✔️ |
+| | Session Affinity | ✔️
| ✔️ |
+| | Traffic Mirroring | ✔️
| ✔️ |
+| 11. Other | |
| |
+| | Hot reloading | ✔️
| ✔️ |
+| | LetsEncrypt Integration | ✔️
| ✔️ |
+| | Wildcard certificate support | ✔️
| ✔️ |
+| | Configure hot reloading | Preview
| ✔️ |
+| | Service Discovery | ✖
| ✔️ |
+
+### 功能差异
+
+通过下图，可以粗略看到 APISIX Ingress 内置的功能和特性相比 Ingress NGINX 更加丰富，其中包括服务发现、协议支持、认证鉴权等等。
+
+
+
+### 服务发现
+
+在微服务架构中，应用被拆分为很多微服务，无论是微服务故障，还是对应用服务进行扩缩容，都需要尽快的通知到调用方，以免调用失败。因此，在微服务架构中，服务注册和发现机制就显得很重要了，通常这会通过注册中心来完成。
+
+| Service Discovery | Ingress NGINX | Apache APISIX Ingress |
+| :---------------- | :------------ | :-------------------- |
+| Kubernetes | ✔️ | ✔️ |
+| DNS | ✖ | ✔️ |
+| nacos | ✖ | ✔️ |
+| exureka | ✖ | ✔️ |
+| consul_kv | ✖ | ✔️ |
+
+### 协议支持
+
+两者都对 HTTP/HTTPS 协议提供完整支持，APISIX Ingress 在协议支持上更丰富一些，能够的使用 TLS 来加密 TCP 流量，还支持
[MQTT](https://apisix.apache.org/docs/apisix/plugins/mqtt-proxy/)、[Dubbo](https://apisix.apache.org/docs/apisix/plugins/dubbo-proxy/)、[Kafka](https://apisix.apache.org/docs/apisix/plugins/kafka-proxy/)
等协议进行代理。
+
+### 服务治理能力
+
+#### 健康检查
+
+在后端节点故障或者迁移时，不可避免会出现节点不可用的情况。如果大量请求访问到了这些不可用的节点时，将会造成流量损失，导致业务中断。因此，需要对节点进行健康检查，通过探针的形式探测后端节点的可用性，将请求代理到健康的节点，从而减少或避免流量损失。
+
+健康检查的能力在 Ingress NGINX 中尚未支持，而 APISIX Ingress 提供了该能力，其中包括：
+
+* **主动健康检查**：确保后端服务中的 Pod
处于可用的状态。在应用服务进行滚动更新时，会牵扯大量的节点进行更新，不健康的节点将会被负载均衡器忽略，开启健康检查能够有效的挑选出可用的 Pod，避免流量损失。
+* **被动健康检查**：被动的方式无需发起额外的探针，每个请求就是探针，若一个健康节点连续 N
个请求都被判定为失败（取决于如何配置），则该节点将被标记为不健康。由于无法提前感知节点的状态，可能会有一定量的失败请求，在滚动更新时这种情况会相对常见，可以通过服务降级来避免失败的请求量。
+
+如下是 APISIX Ingress 为 httpbin 服务配置健康检查示例：
+
+```yaml
+apiVersion: apisix.apache.org/v2
+kind: ApisixUpstream
+metadata:
+name: httpbin
+spec:
+healthCheck:
+passive:
+unhealthy:
+httpCodes:
+- 500
+httpFailures: 3
+active:
+type: http
+httpPath: /healthz
+healthy:
+successes: 3
+interval: 2s
+httpCodes:
+- 200
+```
+
+#### 服务熔断
+
+流量高峰时，网关作为流量入口向后端服务发起调用，后端服务有可能会产生调用失败（超时或者异常），失败时不能让请求堆积在网关上，需要快速失败并返回回去，这就需要在网关上进行熔断。
+
+服务熔断的功能在 Ingress NGINX 中尚未支持。在 APISIX Ingress 中则可以通过
[api-breaker](https://apisix.apache.org/docs/apisix/plugins/api-breaker/)
熔断插件来实现。
+
+具体使用配置示例如下：
+
+```yaml
+apiVersion: apisix.apache.org/v2
+kind: ApisixRoute
+metadata:
+name: httpbin-route
+spec:
+http:
+- name: rule1
+match:
+hosts:
+- httpbin.org
+paths:
+- /status/*
+backends:
+- serviceName: httpbin
+servicePort: 80
+plugins:
+- name: api-breaker
+enable: true
+config:
+break_response_code: 502
+unhealthy:
+http_statuses:
+- 505
+failures: 2
+healthy:
+http_statuses:
+- 200
+successes: 2
+```
+
+### 插件和鉴权方式
+
+目前 Ingress NGINX 主要通过
[Annotations](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/)
和
[ConfigMap](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/)
等方式进行配置，支持的插件功能比较有限。如果想要使用 JWT、HAMC 等鉴权方式，只能自行开发。
+
+而 APISIX Ingress 得益于 APISIX 的丰富功能，原生支持 APISIX 内置的 [80+
插件](https://github.com/apache/apisix/blob/master/conf/config-default.yaml#L391-L473)，能够覆盖大部分使用场景，还支持
JWT、HMAC、wolf-rbac 等多种鉴权方式。以下仅展示 APISIX Ingress 使用 HMAC 认证并在路由上的应用示例：
+
+```yaml
+apiVersion: apisix.apache.org/v2
+kind: ApisixConsumer
+metadata:
+name: hmac-value
+spec:
+authParameter:
+hmacAuth:
+value:
+access_key: papa
+secret_key: fatpa
+algorithm: "hmac-sha256"
+clock_skew: 0
+
+---
+
+apiVersion: apisix.apache.org/v2
+kind: ApisixRoute
+metadata:
+name: httpbin-route
+spec:
+http:
+- name: rule1
+match:
+hosts:
+- httpbin.org
+paths:
+- /ip
+backends:
+- serviceName: httpbin
+servicePort: 80
+authentication:
+enable: true
+type: hmacAuth
+```
+
+## Ingress NGINX 和 APISIX Ingress 的扩展方式
+
+除了以上这些细节对比外，两者对于额外功能的扩展也有所不同。当 Ingress controller
的基础功能无法满足企业用户的需求时，只能通过扩展的方式进行定制开发。接下来将具体介绍 Ingress NGINX 和 APISIX Ingress
如何进行功能扩展。
+
+### Ingress NGINX 如何进行功能扩展
+
+Ingress NGINX 在扩展方式上比较单一，只能通过嵌入 Lua 程序的方式来扩展功能。我们以 [Ingress NGINX
插件开发](https://github.com/kubernetes/ingress-nginx/blob/main/rootfs/etc/nginx/lua/plugins/README.md)为例，大概需要以下步骤：
+
+1. 编写 Lua 程序 example-plugin
+2. 将插件安装到 ingress-nginx pod 中的 `/etc/nginx/lua/plugins/<your plugin name>` →
`/etc/nginx/lua/plugins/example-plugin`
+3. 在 ConfigMap 中启用 `example-plugin` 插件，需要在安装 Ingress NGINX 时引用此 ConfigMap 对象
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+name: ingress-nginx-controller
+namespace: ingress-nginx
+data:
+plugins: "example-plugin"
+```
+
+### APISIX Ingress 如何进行功能扩展
+
+APISIX Ingress 提供了多种扩展方式，企业用户可以根据自身情况自由选择或组合，当前支持如下拓展方式：
+
+* 通过 [Lua
进行插件开发](https://apisix.apache.org/docs/apisix/plugin-develop/)：这种方式相对简单，并且几乎没有性能损耗；
+* 通过 plugin-runner 开发：这种模式下支持 Java/Python/Go
等语言进行开发，这可以方便用户利用一些现有的业务逻辑，并且无需学习新语言；
+* 通过 Wasm 进行插件插件：这种模式下，可以使用任何支持构建出 Wasm 的语言进行插件开发。
+
+此外还可以通过 Serverless 插件来直接编写 Lua 代码，快速满足业务需求。
+
+## 为什么 APISIX Ingress 选择维护 CRD
+
+目前 APISIX Ingress 支持三种声明式配置：Ingress、CRD 和 Gateway API。这里主要对比 Ingress 和
CRD，Gateway API 将在后续展开。
+
+Ingress 比较适合从 Ingress NGINX 迁移的企业用户，其转换成本较低。但缺点也较明显，比如语义化能力弱、没有细致规范等，同时也只能通过
Annotations 方式扩展，且 Annotations 无法支撑复杂配置场景。相对的使用 CRD 主要有以下好处：
+
+* 更契合数据面的设计语义，更加简单易用；
+* 一些重要配置能够被复用，而不会存在冗余庞大的单个配置；
+* 功能性和可扩展能力有了巨大提升；
+* 数据面 APISIX 有着活跃的社区，更新和发布版本快，CRD 的方式能够轻易支持数据面的更多能力；
+
+## Ingress NGINX 的痛点：不支持配置热加载
+
+### 静态配置带来的问题
+
+Ingress NGINX 主要基于 NGINX 配置文件的方式，尽管使用 NGINX + Lua
来实现功能扩展，但没有彻底解决静态配置文件的问题。在路由能力和加载模式上稍显不足，并且存在一些明显劣势。
+
+比如添加、修改任何新的规则时，需要重新加载 NGINX 配置。随着越来越多的路由规则和证书，在触发变更时，reload
操作将会更耗时，甚至需要几秒到十几秒的时间，对线上流量的影响将会非常大的，会导致流量短暂中断、影响响应延迟、负载均衡质量（每次重新加载 NGINX
都会重置负载均衡状态）等。
+
+### 触发 NGINX 重新加载的情况
+
+以下这些情况，涵盖了 Ingress controller 大量的使用场景：
+
+* 创建新的 Ingress 资源；
+* 将TLS 部分添加到现有 Ingress；
+* Ingress Annotations 的变化可能影响上游配置（例如 load-balance 注释不需要重新加载）；
+* 在 Ingress 中添加或删除 path；
+* Ingress、Service、Secret 资源被删除；
+* Secret 发生更新。
+
+在上述场景下，具有频繁部署应用程序的集群环境中，会不断触发 Ingress、Secret 等资源的操作（创建、更新、删除等），导致 NGINX
重新加载次数剧增，给生产环境带来了极大的影响。
+
+### 小结
+
+Ingress NGINX 的架构决定了它必须生成 NGINX 配置然后通过 reload
方式完成配置更新，架构不调整是无法解决这些已知问题。比如路由的实现，APISIX Ingress 则不再依赖 NGINX
配置改为了纯内存结构，通过热更新方式实现动态路由，不再需要重启 NGINX。
+
+## 云原生新一代网关规范 Gateway API
+
+### Gateway API 优势
+
+Gateway API 相比 Ingress 的功能性更强，旨在通过由许多供应商实现并具有广泛行业支持的富有表现力、可扩展和面向角色的接口来发展
Kubernetes 服务网络。当下 Gateway API 具有如下的优势：
+
+* 面向角色：Gateway 是由一组 API 资源组成的。不同的 API 资源代表了使用与配置 Kubernetes 网络资源的不同角色；
+* 表现力强：Gateway API 的核心功能就包含诸如基于头的匹配、流量加权以及其他在 Ingress 中只能通过各实现者自定义的非标准化
Annotations 等方式实现的功能；
+* 可扩展：Gateway API 允许不同资源在不同层级一同使用。这使得能够对 API 结构进行更精细化的控制。
+
+### 支持情况
+
+Gateway API 作为一种扩展 Kubernetes 服务网络的标准，其 Gateway 资源能够实现作为 Kubernetes API
来管理网关的生命周期，功能十分强大。目前许多 Ingress controller 都在积极支持它，包括 Istio、Kong、Traefik 等。在目前
[Gateway API
实现情况](https://gateway-api.sigs.k8s.io/implementations/#implementation-status)中，很遗憾的是，**Ingress
NGINX 尚未计划支持 Gateway API** 。而 APISIX Ingress 已经支持了 Gateway API 的大部分特性：包括
HTTPRoute、TCPRoute、TLSRoute、UDPRoute 等。
+
+## 总结
+
+经过 APISIX Ingress 与 Ingress NGINX
的完整对比，我们可以看到两者基础功能差异不大，也都具备扩展能力。但在微服务的架构中，APISIX Ingress 对服务治理和服务发现的支持更具优势。
+
+总体来看，两款开源软件均非常优秀，Ingress NGINX 主要特点是简单、易接入，但缺点也十分明显；APISIX Ingress 作为后来者解决了
NGINX 不支持热加载的痛点，在扩展能力和功能上相比 Ingress NGINX 也具有很大的优势。从项目发展角度而言，支持 Gateway API 和
CRD 能够扩展和丰富 Ingress controller 基础能力。
+
+如果读者正在进行 Ingress controller 选型，倾向于功能丰富和更强的扩展能力，推荐使用 APISIX Ingress。如果只是刚接触
Ingress controller，没有更多的功能需求，Ingress NGINX 也是一个比较好的选择。
diff --git a/blog/zh/blog/2023/01/12/amesh-config-plugin.md
b/blog/zh/blog/2023/01/12/amesh-config-plugin.md
new file mode 100644
index 00000000000..ad1e2d2112a
--- /dev/null
+++ b/blog/zh/blog/2023/01/12/amesh-config-plugin.md
@@ -0,0 +1,155 @@
+---
+title: "如何使用 Amesh 配置插件"
+authors:
+ - name: "lingsamuel"
+ title: "Author"
+ url: "https://github.com/lingsamuel";
+ image_url: "https://github.com/lingsamuel.png";
+keywords:
+- Apache APISIX
+- Amesh
+- Service Mesh
+- 服务网格
+- Kubernetes
+description: Amesh 是 Apache APISIX 的服务网格库。本文在假设已经成功安装 Amesh 后，如何在 Amesh
中进行部署、配置和更新插件等操作。
+tags: [Ecosystem]
+---
+
+> Amesh 是 Apache APISIX 的服务网格库。本文在假设已经成功安装 Amesh 后，如何在 Amesh 中进行部署、配置和更新插件等操作。
+
+<!--truncate-->
+
+> 作者[@lingsamuel](https://github.com/lingsamuel)，API7.ai 云原生技术专家，Apache APISIX
Committer。
+
+在上一篇 Amesh 产品介绍中，我们有提到在 Amesh v2.0 版本新增了一个可选的控制面组件，即 `amesh-controller` 及相应的
CRD。`amesh controller` 为用户提供了配置 APISIX 插件的能力，使 APISIX
众多的插件在服务网格场景下也能开箱即用，而无需用户进行自定义的开发。那么如何使用这些组件，来进行 APISIX 插件能力的使用呢？
+
+本文在假设已经成功安装 Amesh 后，如何在 Amesh 中进行部署、配置和更新插件等操作。
+
+## 部署 Amesh Controller 与 CRD
+
+使用如下命令部署 Amesh Controller 与 CRD：
+
+```bash
+cd controller
+kubectl apply -k ./config/crd/
+helm install amesh-controller -n istio-system ./charts/amesh-controller
+```
+
+默认情况下，Amesh 将会自动连接到位于 `istio-system` namespace 下的 `amesh-controller` 服务
`15810` 端口，而无需重启 Sidecar。
+
+如需自定义，可以使用 `AMESH_GRPC_SOURCE` 环境变量进行配置。该变量默认值为
`"grpc://amesh-controller.istio-system.svc:15810"`，按需指定到对应的 `amesh-controller`
即可。
+
+## 部署示例应用
+
+这里我们以 Istio 提供的 Bookinfo 应用为测试用例。
+
+```bash
+# 在 Istio 目录下执行
+kubectl -n test apply -f samples/bookinfo/platform/kube/bookinfo.yaml
+kubectl -n test run consumer --image curlimages/curl --image-pull-policy
IfNotPresent --command sleep 1d
+```
+
+测试是否能够正常访问：
+
+```bash
+kubectl -n test exec -it -c istio-proxy consumer -- curl -i -XGET
"http://productpage:9080/productpage"; | grep -o "<title>.*</title>"
+```
+
+输出细节类似如下所示：
+
+```bash
+<title>Simple Bookstore App</title>
+```
+
+## 配置示例插件
+
+本文将以 `response-rewrite` 插件为例进行演示。首先为集群应用下列示例配置：
+
+```yaml
+apiVersion: apisix.apache.org/v1alpha1
+kind: AmeshPluginConfig
+metadata:
+ name: ameshpluginconfig-sample
+spec:
+ plugins:
+ - name: response-rewrite
+ config: '{"body": "BODY_REWRITE", "headers": {"X-Header":"Rewrite"}}'
+```
+
+尝试访问测试负载：
+
+```bash
+kubectl -n test exec -it -c istio-proxy consumer -- curl -i -XGET
"http://productpage:9080/productpage";
+```
+
+输出细节应该包含如下内容：
+
+```yaml
+Via: APISIX
+Server: APISIX/2.15.0
+X-Header: Rewrite
+
+BODY_REWRITE
+```
+
+### 更新插件配置
+
+将示例 AmeshPluginConfig 文件修改为如下，移除 Body 配置：
+
+```yaml
+apiVersion: apisix.apache.org/v1alpha1
+kind: AmeshPluginConfig
+metadata:
+ name: ameshpluginconfig-sample
+spec:
+ plugins:
+ - name: response-rewrite
+ config: '{"headers": {"X-Header":"Rewrite"}}'
+```
+
+再次请求测试负载：
+
+```bash
+kubectl -n test exec -it -c istio-proxy consumer -- curl -i -XGET
"http://productpage:9080/productpage"; | grep -o "<title>.*</title>"
+```
+
+输出应该包含如下内容：
+
+```html
+<title>Simple Bookstore App</title>
+```
+
+这表明响应 Body 没有被重写，符合我们的预期。
+
+下面的命令可以验证 Header 是否被正常重写：
+
+```bash
+kubectl -n test exec -it -c istio-proxy consumer -- curl -i -XGET
"http://productpage:9080/productpage"; | grep "X-Header"
+```
+
+输出内容如下所示：
+
+```yaml
+X-Header: Rewrite
+```
+
+## 其他场景
+
+除了上文演示的 `response-rewrite` 插件之外，Amesh 还支持配置 APISIX 的所有插件。用户可以根据需要进行配置。
+
+例如，当需要进行故障注入时，只需要将配置中的插件名改为 `fault-injection`，插件配置改为 `'{"abort": {
"http_status": 200, "body": "Fault Injection!" }'` 即可实现，具体如下所示：
+
+```yaml
+apiVersion: apisix.apache.org/v1alpha1
+kind: AmeshPluginConfig
+metadata:
+ name: faultinjection-sample
+spec:
+ plugins:
+ - name: fault-injection
+ config: '{"abort": { "http_status": 200, "body": "Fault Injection!" }'
+```
+
+## 总结
+
+本文以 `response-rewrite` 插件为例，演示了 Amesh v0.2 版本新增的插件配置功能。在实际使用中，用户可以根据需要，为 Amesh
配置适合的 APISIX 中已有的插件。也欢迎各位在实践中进行体验，并反馈更多关于服务网格的想法。
diff --git a/blog/zh/blog/2023/01/12/serverless-auth-type.md
b/blog/zh/blog/2023/01/12/serverless-auth-type.md
new file mode 100644
index 00000000000..40f4980925a
--- /dev/null
+++ b/blog/zh/blog/2023/01/12/serverless-auth-type.md
@@ -0,0 +1,119 @@
+---
+title: "盘点微服务架构下的诸多身份验证方式"
+authors:
+ - name: "罗泽轩"
+ title: "Author"
+ url: "https://github.com/spacewander";
+ image_url: "https://github.com/spacewander.png";
+ - name: "赵士瑞"
+ title: "Author"
+ url: "https://github.com/soulbird";
+ image_url: "https://github.com/soulbird.png";
+keywords:
+- Apache APISIX
+- Auth
+- Serviceless
+- 微服务
+- 身份认证
+description: 本文将从传统服务架构和微服务架构下的身份认证方式区别进行讨论，并最终衡量微服务架构中身份认证服务的各种实现方式的优劣。
+tags: [Ecosystem]
+---
+
+> 身份认证是授予用户访问系统并授予使用系统的必要权限的过程。而提供了这一功能的服务，就是身份认证服务。
+
+<!--truncate-->
+
+> 联合作者罗泽轩，API7.ai 技术专家、Apache APISIX PMC 成员；
+>
+> 联合作者赵士瑞，API7.ai 技术工程师，Apache APISIX Committer。
+
+在传统的单体软件应用程序中，所有这些都发生在同一个应用程序中。但在微服务架构中，系统由多个服务组成，在这样的架构中，每个微服务都有自己的任务，因此为每个微服务分别实现授权和身份验证过程并不完全符合此原则。
+
+本文将从传统服务架构和微服务架构下的身份认证方式区别进行讨论，并最终衡量微服务架构中身份认证服务的各种实现方式的优劣。
+
+## 传统服务架构中的身份认证服务
+
+在企业开发服务的早期，所有功能都是做到同一个应用程序里面的。我们把这种模式称之为 “单体”，以跟当下更为主流的 “微服务” 架构区分开来。
+
+单体应用由单个不可分割的单元组成。它通常由各个业务线各自开发，但是部署时放入到同一个环境中。所有这些都紧密集成以在一个单元中提供所有功能。这一单元里拥有所需的所有资源。单体应用的好处在于部署迭代简单，适合业务线较少且比较独立的公司采用。
+
+随着企业开发出来的业务越来越复杂，我们会发现单体服务已经无法满足现实生活里面快速迭代的需要了。我们需要把这个单体的巨无霸拆分一下，同时保证现有的各个功能间的调用能正常进行。这时候，ESB（企业服务总线）便应运而生了。
+
+所谓的 “企业服务总线”，就是一根连接各个企业服务的管道。ESB 的存在是为了集成基于不同协议的不同服务，ESB
做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通。从名称就能知道，它的概念借鉴了计算机组成原理中的通信模型 ——
总线，所有需要和外部系统通信的系统，统统接入 ESB，就可以利用现有的系统构建一个全新的松耦合的异构的分布式系统。
+
+ESB 做了消息的转换解释与路由等工作，让不同的服务互联互通。传统的 ESB
的服务调用方式是，每一次服务的调用者要向服务提供者进行服务交互请求时都必须通过中心的 ESB 来进行路由。
+
+接下来将按照这两种情况，分别描述对应的身份认证功能的实现。
+
+### 单体架构
+
+单体架构下，用户身份验证和会话管理相对简单。身份认证和授权发生在同一个应用程序中，通常使用基于 session
的认证方案。一旦通过身份验证，就会创建一个会话并将其存储在服务器上，任何需要它的组件都可以访问它并用于通知和授权后续要求。会话 ID
被发送到客户端并用于应用程序的所有后续请求，以将请求与当前会话相关联。
+
+### ESB 架构
+
+在 ESB 架构下，所有用户与服务之间，服务与服务之间全部通过 ESB 总线进行处理。由于 ESB
的架构是从单体拆分下来的，身份认证方式相对于单体架构并没有变化。
+
+## 微服务架构中的身份认证服务
+
+从单体架构迁移到微服务架构有很多优势，但微服务架构作为一种分布式架构，会存在更大的攻击面，共享用户上下文更加困难。因此微服务架构下需要有跟传统架构不一样的身份认证服务，才能响应更大的安全性挑战。
+
+目前，我们可以把微服务架构下的身份认证服务分为以下三类：
+
+1. 通过每个微服务实现身份认证；
+2. 通过身份认证服务实现身份认证；
+3. 通过网关实现身份认证。
+
+当然，每种做法都有自己特定的优缺点。
+
+### 通过每个微服务实现身份认证
+
+既然微服务架构是从单体架构拆分出来的，因此比较自然的过渡方式就是由每个微服务自己实现身份认证。
+
+
+
+每个微服务都需要实现自己独立的安全性保障，并在每个入口点上强制执行。此方法使微服务团队能够自主决定如何实现其安全解决方案。但是，这种方法有几个缺点：
+
+* 安全逻辑需要在每个微服务中重复实现，这会导致服务之间的代码重复。
+* 它分散了开发团队的注意力，使其无法专注于其主要服务。
+* 每个微服务都依赖于它不拥有的用户身份验证数据。
+* 很难维护和监控。
+
+完善这个解决方案的选择之一就是使用一个加载在每个微服务上的共享认证库。这个操作可以防止代码重复，开发团队将只关注他们的业务领域，但仍然存在这种改进无法解决的缺点。
+
+因为共享的认证库仍然需要有对应的用户身份数据，而且还需要保证各个微服务使用同样版本的认证库。老实说，共享认证库更像是服务拆分不透彻的结果。
+
+因此这种方式总结来说，优势在于实施速度快，独立性强；而劣势也比较明显，服务之间的代码重复、违反单一职责原则，较难维护。
+
+### 通过身份认证服务实现身份认证
+
+既然每个微服务自己实现身份认证难以维护，而使用共享认证库又违背了微服务拆分的本意，那么能不能把共享认证库升级成专门的身份认证服务呢？
+
+
+
+在这种情况下，所有访问都通过同一服务进行控制，类似于单体应用里面的身份认证功能。每个业务服务都必须在执行操作时，向访问控制模块发送单独的授权请求。
+
+但是，这种方法在一定程度上减慢了服务的运行速度，并增加了服务之间的互连量。并且各个微服务会依赖这个“单点”的身份认证服务。万一统一的身份认证服务出问题，会造成链式反应，带来二次伤害。
+
+所以总结来看，这种方式虽然确保了每个微服务职责单一，使得身份认证功能更加集中。但是仍会造成单点依赖，进而增加请求延迟。
+
+### 通过网关实现身份认证
+
+迁移到微服务体系结构时，需要回答的问题之一是微服务之间如何通信。前面提到的 ESB 是种方案，但是更常见的选择则是采用 API 网关。
+
+
+
+API
网关是所有请求的单个终端节点入口，它通过充当使用这些微服务的中央接口来提供灵活性。某个需要访问其他微服务的微服务（以下称之为“客户端”，以跟被它访问的微服务相区分）无权访问多个服务，而是需要向负责将其路由到上游服务的
API 网关发送请求。
+
+由于 API 网关位于客户端访问的必经之路上，因此它是强制实施身份验证问题的绝佳选择。使用 API
网关可以减少延迟（调用身份验证服务），并确保身份验证过程在整个应用程序中保持一致。
+
+举个例子，通过 APISIX 的
[jwt-auth](https://apisix.apache.org/docs/apisix/plugins/jwt-auth/)
插件，我们可以在网关上实现身份认证。
+
+首先，我们需要规划若干个用户身份信息（名称、密钥等等），并将其配置到 APISIX 上。其次，根据给定的用户密钥，向 APISIX
发起签名请求，得到这个用户的 JWT token。接着，当客户端需要访问某个上游服务时，带上 JWT token，由 APISIX 作为 API
网关代理该访问。最后，APISIX 会通过 JWT token，完成身份认证的操作。
+
+当然，凡事有利就有弊，没有完全无劣势的技术选型。使用网关来完成身份认证，还是带来了少许单点问题。比起在每个微服务内完成身份认证，在网关上解决该问题，安全性相比会降低些。比如
API 网关被攻破之后，就可以访问该网关背后的任何微服务。但是风险是相对的，比起统一的身份认证服务，使用 API 网关的单点问题并没有那么严重。
+
+因此这种方式操作起来，在优势上较为明显，比如可以有效保护后端微服务，微服务不用处理任何认证逻辑等。但同时还是会存有少许的单点依赖。
+
+## 总结
+
+在不同的场景下，我们会需要不同的身份认证方案。在单体应用中，身份认证发生在同一个应用程序中，服务端保存了所有的会话。进入微服务时代，单体应用演变为分布式服务，单体应用中的身份认证方式在微服务中并不适用。在微服务架构中，我们有上述提到的三种身份认证的方式可供选择。每种选择都有属于自己的利弊，需要根据具体的实际情况做具体分析。
![https://github.com/lingsamuel.png"](https://github.com/lingsamuel.png"){kind=link}
![https://github.com/AlinsRan.png"](https://github.com/AlinsRan.png"){kind=link}
![https://github.com/spacewander.png"](https://github.com/spacewander.png"){kind=link}
![https://github.com/soulbird.png"](https://github.com/soulbird.png"){kind=link}
