You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@apisix.apache.org by su...@apache.org on 2021/10/28 10:19:06 UTC
[apisix-website] branch master updated: docs: translate blogs on
05/2021 (#681)
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 c449787 docs: translate blogs on 05/2021 (#681)
c449787 is described below
commit c449787ea664ca58013b27385962b2d11a0469c3
Author: 琚致远 <ju...@apache.org>
AuthorDate: Thu Oct 28 18:19:01 2021 +0800
docs: translate blogs on 05/2021 (#681)
---
.../12/18/first-look-at-kubernetes-service-api.md | 130 ++++++++++-----------
...na-Data-Security-and-Privacy-Protection-Team.md | 42 +++----
.../blog/2021/05/25/Apache APISIX 2.6.0-Release.md | 64 +++++-----
3 files changed, 118 insertions(+), 118 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 c5611af..a60c614 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
@@ -1,6 +1,6 @@
---
-title: "初探 Kubernetes Service APIs"
-author: "金卫"
+title: A First Look at Kubernetes Service APIs
+author: Wei Jin
authorURL: "https://github.com/gxthrj"
authorImageURL: "https://avatars2.githubusercontent.com/u/4413028?s=400&u=e140a6d2bf19c426da6498b8888edc96509be649&v=4"
keywords:
@@ -8,38 +8,38 @@ keywords:
- APISIX
- Apache APISIX
- Kubernetes Service APIs
-description: 本文通过提问的方式，对 Kubernetes Service APIs 做了一些基本介绍，从整体来看，Kubernetes Service APIs 提炼了很多 ingress 的最佳实践，比如表达能力的增强，其实就是扩展了 Route 的能力，再比如 BackendPolicy 对象，可以为 upstream 指定几乎所有的 Kubernetes 后端资源。
+description: 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 the enhanced expressiveness, which actually extends the capabilities of Route, and the BackendPolicy objects, which can specify almost any Kubernetes backend resource for upstream.
tags: [Technology]
---
-> 本文通过提问的方式，对 Kubernetes Service APIs 做了一些基本介绍，从整体来看，Kubernetes Service APIs 提炼了很多 ingress 的最佳实践，比如表达能力的增强，其实就是扩展了 Route 的能力，再比如 BackendPolicy 对象，可以为 upstream 指定几乎所有的 Kubernetes 后端资源。
+> 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:
>
> - https://github.com/apache/apisix
> - https://github.com/apache/apisix-ingress-controller
-## 前言
+## Preface
-笔者是 Apache APISIX PMC，也是 Apache APISIX Ingress Controller Founder，通过调研和社区交流，打算在 Apache APISIX Ingress Controller 的后期版本中逐步支持 Kubernetes Service APIs.
+The author is an Apache APISIX PMC and Apache APISIX Ingress Controller Founder. Through research and community communication, I plan to gradually support Kubernetes Service APIs in later versions of Apache APISIX Ingress Controller.
-我们知道 Kubernetes 为了将集群内部服务暴露出去，有多种方案实现，其中一个比较受大众推崇的就是 Ingress。Ingress 作为一种对外暴露服务的标准，有相当多的第三方实现，每种实现都有各自的技术栈 和 所依赖的网关的影子，相互之间并不兼容。
+As we know, Kubernetes has a variety of solutions for exposing services inside the cluster, one of which is Ingress, a standard for exposing services to the public, and there are many third-party implementations of Ingress, each with its own technology stack and dependency on gateways that are not compatible with each other.
-为了统一各种 Ingress 的实现，便于 Kubernetes 上统一管理，[SIG-NETWORK](https://github.com/kubernetes/community/tree/master/sig-network) 社区推出了[Kubernetes Service APIs](https://gateway-api.sigs.k8s.io/) 一套标准实现，称为第二代 Ingress 。
+To unify the various Ingress implementations and facilitate unified management on Kubernetes, the [SIG-NETWORK](https://github.com/kubernetes/community/tree/master/sig-network) community has launched the [Kubernetes Service APIs](https://gateway-api.sigs.k8s.io/), a set of standard implementations called second-generation Ingress.
-## 主题描述
+## Topic Description
-本文从几个问题入手，对 Kubernetes Service APIs 的基本概念进行介绍。
+This article provides an introduction to the basic concepts of Kubernetes Service APIs, starting with a few questions.
-## 介绍
+## Introduction
-### Kubernetes Service APIs 号称第二代 Ingress 技术，到底在哪些方面优于第一代
+### Kubernetes Service APIs is called the second generation of Ingress technology, in what ways is it better than the first generation
-Kubernetes Service APIs 设计之初，目标并没有局限在 Ingress， 而是为了增强 service networking，着重通过以下几点来增强：表达性、扩展性、RBAC。
+The Kubernetes Service APIs were designed not to be limited to Ingress, but to enhance service networking by focusing on the following points: expressiveness, scalability, and RBAC.
-1. 更强的表达能力，例如 可以根据 header 、weighting 来管理流量
+For example, traffic can be managed based on header, weighting
```text
kind: HTTPRoute
@@ -53,107 +53,107 @@ matches:
version: "2"
- path:
value: "/v2/foo"
-```
+```` 2.
-2. 增强了扩展能力，Service APIs 提出多层 API 的概念，各层独立暴露接口，方便其他自定义资源与 API 对接，做到更细粒度（API 粒度）的控制。
+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)
-3. 面向角色 RBAC：多层 API 的实现，其中一个思想就是从使用者的角度去设计资源对象。这些资源最终会与 Kubernetes 上运行应用程序的常见角色进行映射。
+3. Role-oriented RBAC: One of the ideas behind the multi-tier API implementation is to design resource objects from the user's perspective. These resources are ultimately mapped to common roles for running applications on Kubernetes.
-## Kubernetes Service APIs 抽象出了哪些资源对象
+## What resource objects are abstracted by the Kubernetes Service APIs
-Kubernetes Service APIs 基于使用者角色，将定义了以下几种资源：
+The Kubernetes Service APIs will define the following kinds of resources based on user roles.
GatewayClass, Gateway, Route
-1. GatewayClass 定义了一组具有通用配置和行为的网关类型
+1. GatewayClass defines a set of gateway types with common configuration and behavior
-- 与 Gateway 的关系，类似 ingress 中的 ingress.class annotation；
+- relationship to the Gateway, similar to the ingress.class annotation in ingress.
-- GatewayClass 定义了一组共享相同配置和行为的网关。每个 GatewayClass 将由单个 controller 处理，controller 与 GatewayClass 是一对多的关系；
+- A GatewayClass defines a set of gateways that share the same configuration and behavior. Each GatewayClass will be handled by a single controller, and controllers have a one-to-many relationship with GatewayClass.
-- GatewayClass 是 cluster 资源。必须至少定义一个 GatewayClass 才能具有功能网关。
+- A GatewayClass is a cluster resource. At least one GatewayClass must be defined to have a functional gateway. 2.
-2. Gateway 请求一个可以将流量转换为群集内服务的点。
+Gateway requests a point at which traffic can be converted to services within the cluster.
-- 作用：把集群外的流量引入集群内部。这个才是真正的 ingress 实体；
+- Role: Bringing traffic from outside the cluster inside the cluster. This is the true ingress entity.
-- 它定义了对特定 LB 配置的请求，该配置也是 GatewayClass 的配置和行为的实现；
+- It defines a request for a specific LB configuration that is also the implementation of the GatewayClass configuration and behavior.
-- Gateway 资源可以由操作员直接创建，也可以由处理 GatewayClass 的 controller 创建；
+- Gateway resources can be created either directly by the operator or by the controller handling the GatewayClass.
-- Gateway 与 Route 是多对多的关系；
+- (b) Gateway and Route are in a many-to-many relationship.
-3. Route 描述了通过网关的流量如何映射到服务。
+3. the Route describes how traffic passing through the gateway is mapped to a service.
-
+! [schema-uml](https://gateway-api.sigs.k8s.io/images/schema-uml.svg)
-另外，Kubernetes Service APIs 为了能够灵活的配置后端服务，特地定义了一个 BackendPolicy 资源对象。
+In addition, the Kubernetes Service APIs define a BackendPolicy resource object in order to enable flexible configuration of backend services.
-通过 BackendPolicy 对象，可以配置 TLS、健康检查 以及指定后端服务类型，比如 service 还是 pod。
+The BackendPolicy object allows you to configure TLS, health checks, and specify the type of backend service, such as service or pod.
-## Kubernetes Service APIs 的推行会带来哪些改变
+## What changes will come with the implementation of Kubernetes Service APIs
-Kubernetes Service APIs 作为一种实现标准，带来了以下改变：
+Kubernetes Service APIs, as an implementation standard, brings the following changes.
-1. 通用性： 可以有多种实现，就像 ingress 有多种实现一样，可以根据网关的特点去自定义 ingress controller，但是他们都有一致的配置结构。一种数据结构，可以配置多种 ingress controller。
+1. generality: there can be multiple implementations, just like there are multiple implementations of ingress. ingress controllers can be customized based on the characteristics of the gateway, but they all have a consistent configuration structure. A data structure, you can configure a variety of ingress controller. 2.
-2. Class 概念：GatewayClasses 可以配置不同负载均衡实现的类型。这些类 class 使用户可以轻松而明确地了解哪些功能可以用作资源模型本身。
+Class concept: GatewayClasses can be configured for different types of load balancing implementations. These class classes allow the user to easily and explicitly understand what functionality can be used as the resource model itself. 3.
-3. 共享网关：通过允许独立的路由资源 HTTPRoute 绑定到同一个 GatewayClass，它们可以共享负载平衡器和 VIP。按照使用者分层，这使得团队可以安全地共享基础结构，而无需关心下层 Gateway 的具体实现。
+By allowing independent routing resources HTTPRoute to be bound to the same GatewayClass, they can share load balancers and VIPs. layered by user, this allows teams to safely share infrastructure without having to care about the specific implementation of the lower level Gateway. 4.
-4. 带类型的后端引用: 使用带类型的后端引用，路由可以引用 Kubernetes Services，也可以引用任何类型的设计为网关后端的 Kubernetes 资源，比如 pod，又或者是 statefulset 比如 DB， 甚至是可访问的集群外部资源。
+4. backend references with types: With backend references with types, routes can reference Kubernetes Services, or any type of Kubernetes resource designed as a gateway backend, such as a pod, or a statefulset such as a DB, or even an accessible cluster external resource.
-5. 跨命名空间引用：跨不同命名空间的路由可以绑定到 Gateway。允许跨命名空间的互相访问。同时也可以限制某个 Gateway 下的 Route 可以访问的命名空间范围。
+Cross-namespace references: Routes across different namespaces can be bound to a Gateway, allowing access to each other across namespaces. It is also possible to restrict the range of namespaces that a Route under a Gateway can access.
-## 目前有哪些 ingress 实现了 Kubernetes Service APIs
+## What ingress implementations of Kubernetes Service APIs are currently available
-目前已知的从代码层面能看到对 Kubernetes Service APIs 资源对象支持的 Ingress 有 Contour, ingress-gce。
+The Ingress that are known to support Kubernetes Service APIs resource objects at the code level are Contour, ingress-gce.
-## Kubernetes Service APIs 如何管理资源读写权限
+## How Kubernetes Service APIs manage resource read and write permissions
-Kubernetes Service APIs 按照使用者的维度分为 3 个角色
+The Kubernetes Service APIs are divided into 3 roles based on the user dimension
-1. 基础设施提供方 GatewayClass
+1. infrastructure provider GatewayClass
-2. 集群操作人员 Gateway
+2. cluster operator Gateway
-3. 应用开发者 Route
+3. application developer Route
-RBAC（基于角色的访问控制）是用于 Kubernetes 授权的标准。允许用户配置谁可以对特定范围内的资源执行操作。 RBAC 可用于启用上面定义的每个角色。
+RBAC (Role Based Access Control) is the standard used for Kubernetes authorization. It allows users to configure who can perform operations on a specific range of resources. RBAC can be used to enable each of the roles defined above.
-在大多数情况下，希望所有角色都可以读取所有资源
+In most cases, all roles are expected to be able to read all resources
-三层模型的写权限如下。
+The three-tier model has the following write permissions.
-| | GatewayClass | Gateway | Route |
+| | GatewayClass | Gateway | Route |
| ----------------------- | ------------ | ------- | ----- |
-| Infrastructure Provider | Yes | Yes | Yes |
-| Cluster Operators | No | Yes | Yes |
-| Application Developers | No | No | Yes |
+| Infrastructure Provider | Yes | Yes | Yes |
+| Cluster Operators | No | Yes | Yes | Yes | Application Developers | No | No | No
+| The Kubernetes Service Provider is a service provider that provides a variety of services to the Kubernetes community.
-## Kubernetes Service APIs 有哪些扩展点
+## What are the extension points for Kubernetes Service APIs
-网关的需求非常丰富，同一个场景实现的方式多种多样，各有利弊。Kubernetes Service APIs 提炼出 多层 资源对象，同时也预留了一些扩展点。
+The Kubernetes Service APIs refine the multi-tier resource object, but also leave some extension points open.
-目前 Kubernetes Service APIs 的扩展点基本集中在 Route 上：
+Currently, the Kubernetes Service APIs are focused on Route.
-- RouteMatch 可以扩展 Route 匹配规则。
+- RouteMatch extends Route matching rules.
-- specify Backend 可以扩展特定类型的 后端服务， 除了上面提到的 Kubernetes 资源外，还可以扩展比如 文件系统，函数表达式等。
+- Specify Backend extends specific types of backend services, such as file systems, function expressions, etc., in addition to the Kubernetes resources mentioned above.
-- Route filter 可以在 Route 的生命周期中增加扩展点，处理 request/response 。
+- Route filter adds extensions to the Route lifecycle to handle requests/response.
-- Custom Route 以上扩展点都不能满足时，可以完全自定义一个 Route。
+- Custom Route can be fully customized if none of the above extensions are met.
-## 总结
+## Summary
-本文通过提问的方式，对 Kubernetes Service APIs 做了一些基本介绍，从整体来看，Kubernetes Service APIs 提炼了很多 ingress 的最佳实践，比如表达能力的增强，其实就是扩展了 Route 的能力，再比如 BackendPolicy 对象，可以为 upstream 指定几乎所有的 Kubernetes 后端资源。当然，项目初期也有不足的地方，目前 Kubernetes Service APIs 虽然已经从大的层面上规定了资源对象，但资源对象内部还有不少细节需要讨论之后再确定，以防止可能出现的冲突场景，结构上存在一定变数。
+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/
- https://www.apiseven.com/zh/blog/a-first-look-at-kubernetes-service-api
diff --git a/website/blog/2021/01/11/interview-Apache-APISIX-contributor-Wang-Pengcheng-Senior-Security-Advisor-of-PwC-South-China-Data-Security-and-Privacy-Protection-Team.md b/website/blog/2021/01/11/interview-Apache-APISIX-contributor-Wang-Pengcheng-Senior-Security-Advisor-of-PwC-South-China-Data-Security-and-Privacy-Protection-Team.md
index 25b8517..ffe1428 100644
--- a/website/blog/2021/01/11/interview-Apache-APISIX-contributor-Wang-Pengcheng-Senior-Security-Advisor-of-PwC-South-China-Data-Security-and-Privacy-Protection-Team.md
+++ b/website/blog/2021/01/11/interview-Apache-APISIX-contributor-Wang-Pengcheng-Senior-Security-Advisor-of-PwC-South-China-Data-Security-and-Privacy-Protection-Team.md
@@ -1,46 +1,46 @@
---
-title: "Apache APISIX 贡献者专访 | 普华永道华南数据安全与隐私保护团队高级安全顾问王鹏诚"
-author: "温铭"
+title: Apache APISIX Contributor Interview | Pengcheng Wang, Senior Security Consultant, PricewaterhouseCoopers China Data Security & Privacy Team
+author: Ming Wen
authorURL: "https://github.com/moonming"
authorImageURL: "https://avatars.githubusercontent.com/u/26448043?v=4"
keywords:
- API Gateway
- APISIX
- Apache APISIX
-- 普华永道
-- 漏洞
-description: 近日，来自普华永道华南数据安全及隐私保护团队的高级安全顾问王鹏诚向国家信息安全漏洞共享平台（CNVD）和 Apache 软件基金会，报告了 Apache APISIX 的第一个 CVE：Apache APISIX Admin API 默认 Token 漏洞（CVE-2020-13945）。为了感谢鹏诚对 Apache APISIX 社区做的贡献，我们也特意对鹏诚进行了专访。
+- PricewaterhouseCoopers
+- CVE
+description: "Recently, Pengcheng Wang, a senior security consultant from PwC's South China Data Security and Privacy team, reported the first CVE for Apache APISIX to the National Information Security Vulnerability Sharing Platform (CNVD) and the Apache Software Foundation: Apache APISIX Admin API Default Token Vulnerability (CVE-2020- 13945). To thank Pengcheng for his contribution to the Apache APISIX community, we also conducted an interview with Pengcheng."
tags: [Interview]
---
-> 近日，来自普华永道华南数据安全及隐私保护团队的高级安全顾问王鹏诚向国家信息安全漏洞共享平台（CNVD）和 Apache 软件基金会，报告了 Apache APISIX 的第一个 CVE：Apache APISIX Admin API 默认 Token 漏洞（CVE-2020-13945）。为了感谢鹏诚对 Apache APISIX 社区做的贡献，我们也特意对鹏诚进行了专访。
+> Recently, Pengcheng Wang, a senior security consultant from PwC's South China Data Security and Privacy team, reported the first CVE for Apache APISIX to the National Information Security Vulnerability Sharing Platform (CNVD) and the Apache Software Foundation: Apache APISIX Admin API Default Token Vulnerability (CVE-2020- 13945). To thank Pengcheng for his contribution to the Apache APISIX community, we also had an interview with Pengcheng.
-<!--truncate-->
+<! --truncate-->
-## 贡献者简介
+## Contributor Profile
-王鹏诚，普华永道华南数据安全及隐私保护团队担任高级安全顾问，为多家龙头企业提供数据安全与隐私合规咨询、红蓝对抗、安全运营等技术服务，目前拥有 cisp/cisp-pte/cisp-dsg/CEH/iso27701/ccsk 等多项安全认证。
+Pengcheng Wang is a senior security consultant in PwC South China data security and privacy team. He provides data security and privacy compliance consulting, red-blue confrontation, security operations and other technical services for many leading companies, and currently holds many security certifications such as cisp/cisp-pte/cisp-dsg/CEH/iso27701/ccsk.
-## 专访正文
+## Interview Text
-**小编**：恭喜鹏诚！也感谢鹏诚为 Apache APISIX 社区做的贡献！能简单介绍下您和您的团队嘛？
+**Editor**: Congratulations to Pengcheng! And thank you for your contribution to the Apache APISIX community! Can you tell us a little bit about yourself and your team?
-**鹏诚**：大家好，我是王鹏诚，来自普华永道广州数据安全及隐私保护团队，为普华永道的客户提供数据安全和隐私保护的专业咨询服务。做为一名安全咨询顾问和开源技术爱好者，帮助团队拿到第一枚 CVE 同时也为 Apache APISIX 做了一点贡献，还是蛮激动的。
+**I'm Pengcheng Wang, from the PwC Guangzhou Data Security and Privacy team, providing data security and privacy consulting services to PwC clients. As a security consultant and open source technology enthusiast, I am quite excited to help the team get the first CVE and also make a little contribution to Apache APISIX.
-**小编**：普华永道在大部分人的印象中是会计师事务所，没想到还提供专业的安全服务。请问你们是如何了解到 Apache APISIX 的呢？
+**Editor**: PricewaterhouseCoopers is an accounting firm in most people's mind, but I didn't expect that it also provides professional security services. How did you learn about Apache APISIX?
-**鹏诚**：普华永道不仅提供传统的财务审计服务，现在还提供安全运营、企业安全咨询、数据安全与合规、隐私咨询、车联网、物联网等一系列的安全测试与隐私合规咨询服务。2020 年中，我们在对几个客户做渗透测试的时候，发现他们都使用了 Apache APISIX 这个开源产品作为 API 网关。虽然这对于我们而言是一个新的产品，但是已经被这么多优质客户使用，我们决定对 Apache APISIX 进行安全方面的研究，看看其是否可靠，是否有安全漏洞。然后我们发现其存在固定 token 的问题，该问题将会导致恶意攻击者可直接控制 API 网关而影响到正常业务开展。**但是在 Apache APISIX 的默认配置下，并不会产生这个安全问题，只有在用户修改了默认的控制平面的 IP 限制而没有修改默认 token，才会把自己暴露在风险之中。**
+**Pengcheng**: PwC not only provides traditional financial audit services, but now also provides a series of security testing and privacy compliance consulting services such as security operations, enterprise security consulting, data security and compliance, privacy consulting, Internet of Vehicles, Internet of Things, etc. In the middle of 2020, when we did penetration testing on several clients, we found that they all used Apache APISIX, an open source product as an API gateway. Altho [...]
-**小编**：我们团队也有来自安全背景的同事，我们了解安全对于一个产品而言是多么重要。请问在你们的安全测试中，是否还发现了 Apache APISIX 的其他问题呢？
+**Editor**: Our team also has colleagues from a security background, and we understand how important security is for a product. Are there any other issues with Apache APISIX that you have found in your security testing?
-**鹏诚**：暂时还没有。之前的测试只是站在黑盒角度并且比较浅的一次安全测试，后续会尝试白盒审计相关代码，从安全的角度看看是否会有其他的漏洞。如果发现的话，也会第一时间向 Apache 软件基金会的安全部门报告，来为开源社区贡献自己的力量。
+**Pengcheng**: Not yet. The previous test was just a shallow security test from a black-box perspective, and we will try to white-box audit the code to see if there are other vulnerabilities from a security perspective. If found, will also be the first time to report to the Apache Software Foundation security department, to contribute to the open source community.
-**小编**：非常感谢鹏诚和普华永道广州数据安全及隐私保护团队的同事！对于开源项目而言，不仅代码和文档是贡献，报告安全问题也一样是非常重要的贡献！请问后续有什么相应的计划吗？
+**Editor**: Thank you very much to Pengcheng and PwC Guangzhou data security and privacy protection team colleagues! For open source projects, not only is code and documentation a contribution, but reporting on security issues is also a very important contribution! Do you have any plans for follow-up?
-**鹏诚**：我们团队后面也会积极参与到 Apache APISIX 的社区中来，帮助社区预防和尽早发现安全隐患，让大家用上安全可靠的 API 网关。
+**Pengcheng**: Our team will actively participate in the Apache APISIX community to help the community prevent and discover security risks as early as possible, so that everyone can use a safe and secure API gateway.
-## Apache APISIX 的第一个 CVE
+## First CVE for Apache APISIX
-Apache APISIX 的第一个 CVE：Apache APISIX Admin API 默认 Token 漏洞（CVE-2020-13945）。[安全漏洞详情](https://nvd.nist.gov/vuln/detail/CVE-2020-13945)
+The first CVE for Apache APISIX: Apache APISIX Admin API Default Token Vulnerability (CVE-2020-13945). [Security Vulnerability Details](https://nvd.nist.gov/vuln/detail/CVE-2020-13945)
-
+! [2021-01-11-1](/img/blog_img/2021-01-11-1.png)
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 66e1a62..253f498 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
@@ -1,77 +1,77 @@
---
-title: "Apache APISIX 2.6.0-Release 正式发布"
-author: "罗泽轩"
+title: Apache APISIX 2.6.0-Release Officially Released
+author: Zexuan Luo
authorURL: "https://github.com/spacewander"
authorImageURL: "https://avatars.githubusercontent.com/u/4161644?v=4"
keywords:
-- API 网关
+- API gateway
- APISIX
- Apache APISIX
- Release Notes
-description: Apache APISIX 2.6.0-Release 正式发布！欢迎大家下载使用。
+description: Apache APISIX 2.6.0-Release is officially released! You are welcome to download and use it.
tags: [Release]
---
-> Apache APISIX 2.6.0-Release 正式发布！欢迎大家下载使用。
+> Apache APISIX 2.6.0-Release is officially released! Welcome to download and use.
-<!--truncate-->
+<! --truncate -->
## Release Notes
-▌**新功能：APISIX 现在支持使用其他语言编写自定义插件**
+### New feature: APISIX now supports writing custom plugins in other languages
-APISIX 现在支持通过 Lua 语言编写插件，在代理请求的过程中执行自定义的逻辑，诸如调用 webhook 通知外部系统、执行特殊的鉴权逻辑等等。但是有些情况下开发者可能会想要采用 Lua 以外的语言来编写插件。
+APISIX now supports writing plug-ins in Lua to perform custom logic during proxy requests, such as calling webhook to notify external systems, performing special forensic logic, and so on. However, there are cases where developers may want to write plugins in languages other than Lua.
-比如开发者不熟悉 Lua，想要用自己熟悉的语言来编写插件；或者第三方团队只提供了 Java SDK，没有办法在 Lua 插件里面使用。
+For example, developers are not familiar with Lua and want to write plugins in a language they are familiar with, or third-party teams only provide the Java SDK and there is no way to use it inside Lua plugins.
-从 2.6 版本开始，借助 plugin runner，APISIX 支持运行非 Lua 语言编写的插件。架构图如下：
+Starting from version 2.6, APISIX supports running plugins written in languages other than Lua with the help of plugin runner. The architecture diagram is as follows.
-
+! [2021-05-25-1](/img/blog_img/2021-05-25-1.png)
-APISIX 会以 sidecar 的形式运行 plugin runner。
+APISIX will run the plugin runner as a sidecar.
-它们两者之间采用 RPC 进行通讯，APISIX 负责发送请求数据和配置，plugin runner 负责加载用户的自定义插件，处理这些数据并告诉 APISIX 怎么处理这些请求。目前支持在代理请求到上游之前，执行非 Lua 语言编写的逻辑。后续将会支持用非 Lua 语言改写响应。
+They communicate with each other using RPC, with APISIX sending the request data and configuration and plugin runner loading the user's custom plugin, processing that data and telling APISIX what to do with the requests. Currently, it supports executing logic written in non-Lua languages before the proxy request goes upstream. Later on there will be support for rewriting responses in non-Lua languages.
-APISIX 现在放置了两个入口给 plugin runner 发送 RPC。一个是 ext-plugin-pre-req，另一个是 ext-plugin-post-req。前者会在执行 Lua 插件逻辑前运行，后者会在执行完 Lua 插件且在代理请求到上游之前运行。这两个入口都是可以在路由级别上动态开关的。
+APISIX now places two entry points for the plugin runner to send RPCs: ext-plugin-pre-req, which runs before the Lua plugin logic is executed, and ext-plugin-post-req, which runs after the Lua plugin is executed and before the proxy request goes upstream. Both entries can be dynamically switched on and off at the route level.
-假设我们对于某些请求开启了 ext-plugin-pre-req，且 plugin runner 里面加载了 validator 和 rewrite 两个插件，那么每个匹配的请求，它都会触发对 plugin runner 的 RPC 调用，先执行 plugin runner 里面的 validator 和 rewrite，然后把执行的结果返回给 APISIX。APISIX 可以根据结果来判断是否要继续执行请求，还是拒绝掉请求。如果继续执行，会运行 APISIX 内置的 Lua 插件，比如限流限速等等。如果开启的是 ext-plugin-post-req，则正好相反。
+Assuming we have ext-plugin-pre-req enabled for some requests, and the plugin runner has the validator and rewrite plugins loaded, then for each matching request, it will trigger an RPC call to the plugin runner, first executing the Based on the result, APISIX can determine whether to continue executing the request or reject it. If the request continues, it will run the Lua plugins built into APISIX, such as the flow and speed limiting plugins. If ext-plugin-post-req is enabled, the oppo [...]
-Java 和 Go 的 plugin runner 已在开发中。预计本周内 Java 版的 plugin runner 将会可用，Go 版的 plugin runner 将于六月份完成。
+The plugin runner for Java and Go is already in development. The Java version of the plugin runner is expected to be available within this week, and the Go version of the plugin runner will be completed in June.
-▌**安全提升：修改 Prometheus 默认端口，不再暴露到数据面的端口上**
+### Security enhancement: change the Prometheus default port to no longer expose the port to the data plane
-之前默认情况下 Prometheus 的数据会暴露在数据面的端口上，虽然可以通过配置 plugin interceptor 来限制 IP 访问，但是还是存在默认不安全的问题。所以从 2.6 开始，专门采用一个新端口来暴露指标，而且默认只监听 127.0.0.1 .
+Previously, by default, Prometheus data would be exposed to the port on the data plane, and although you could restrict IP access by configuring the plugin interceptor, there was still the problem of insecurity by default. So starting with 2.6, a new port is dedicated to exposing metrics and by default only listens to 127.0.0.1 .
-在 2.6 之前，Prometheus 采集 APISIX 的指标时访问的是数据面的端口（默认 9080 端口）。
+Prior to 2.6, Prometheus collected APISIX metrics on the data side of the port (default port 9080).
-新端口是 9091 端口，且只监听 127.0.0.1，你需要修改监听地址为你的服务器的内网地址，并加上防火墙规则确保只有 Prometheus 才能访问。
+The new port is port 9091 and only listens to 127.0.0.1. You need to change the listening address to your server's intranet address and add a firewall rule to ensure that only Prometheus can access it.
-▌**支持:生态完整支持 Nacos 服务发现**
+### Support: Ecological full support for Nacos service discovery
-APISIX 添加了对 Nacos 服务发现功能的支持。
+APISIX adds support for the Nacos service discovery feature.
-用户只需开启 Nacos 服务发现功能，并在上游配置中设置服务名称，APISIX 就会在后台定期根据服务名称获取 Nacos 中对应服务的实例地址。这样一来，无需在 APISIX 里面配置具体的上游节点地址，只需要在 Nacos 里面配置即可。
-目前 APISIX 内置的服务发现功能已支持下列外部服务：
+Users only need to enable the Nacos service discovery function and set the service name in the upstream configuration, and APISIX will periodically get the instance address of the corresponding service in Nacos based on the service name in the background. In this way, there is no need to configure the specific upstream node address inside APISIX, only inside Nacos.
+Currently, the following external services are supported by APISIX built-in service discovery function.
1. DNS
2. Consul KV mode
3. Eureka
4. Nacos
-▌**支持:配置 IPv6 的 DNS resolver**
+### Support: Configuring DNS resolver for IPv6
-之前配置 APISIX 的 DNS resolver 时，只能配置 IPv4 服务器。从 2.6 版本之后，我们加上了对 IPv6 DNS 服务器的支持。
+Previously, when configuring DNS resolver for APISIX, only IPv4 servers could be configured. Since version 2.6, we have added support for IPv6 DNS servers.
-现在配置 DNS resolver 的时候，可以写上 IPv6 的服务器地址了。
+Now when configuring DNS resolver, you can write IPv6 server address.
-## 下载
+## Download
-下载 Apache APISIX 2.6.0-Release 源代码及二进制安装包，请访问下载页面: `https://apisix.apache.org/downloads/`。
+To download the Apache APISIX 2.6.0-Release source code and binary installation package, please visit the download page: `https://apisix.apache.org/downloads/`.
-## 文档更新
+## Documentation Update
-在本次发布过程中，我们也在持续更新和发布新的使用文档，欢迎大家提出宝贵的意见。
+During this release, we are also continuously updating and releasing new documentation for use, and welcome your valuable comments.
`https://apisix.apache.org/docs/apisix/getting-started/`
-更详细的内容可以参考 2.6 版本的 Changelog 和 GitHub 上 Apache APISIX 的提交记录。
+For more details, see the Changelog for version 2.6 and the Apache APISIX commits on GitHub.