Clean up docs (#43)

Signed-off-by: windsonsea <[email protected]>

content/en/docs/Concepts/_index.md

@@ -8,13 +8,20 @@ description: >
 
 ## eBPF
 
-The full name of eBPF is Extended Berkeley Packet Filter. As the name implies, this is a module used to filter network packets. For example, sockops and redir capabilities of eBPF can efficiently filter and intercept packets.
+The full name of eBPF is Extended Berkeley Packet Filter. As the name implies,
+this is a module used to filter network packets. For example, sockops and redir
+capabilities of eBPF can efficiently filter and intercept packets.
 
-eBPF is a revolutionary technology with origins in the Linux kernel that can run sandboxed programs in an operating system kernel. It is used to safely and efficiently extend the capabilities of the kernel without requiring to change kernel source code or load kernel modules.
+eBPF is a revolutionary technology with origins in the Linux kernel that can run
+sandboxed programs in an operating system kernel. It is used to safely and efficiently
+extend the capabilities of the kernel without requiring to change kernel source code or load kernel modules.
 
 ## iptables
 
-iptables is a traffic filter built on netfilter. It implements traffic filtering and interception by registering hook functions on the mount point of netfilter. From the name of iptables, we can guess it may contain some tables. In practice, by mounting rule tables on different chains of netfilter, iptables can filter or modify the traffic packets entering and leaving the kernel protocol stack.
+iptables is a traffic filter built on netfilter. It implements traffic filtering and interception
+by registering hook functions on the mount point of netfilter. From the name of iptables, we can
+guess it may contain some tables. In practice, by mounting rule tables on different chains of
+netfilter, iptables can filter or modify the traffic packets entering and leaving the kernel protocol stack.
 
 iptables has 4 tables by default:
 
@@ -33,24 +40,43 @@ iptables has 5 chains by default:
 
 ## Service Mesh
 
-A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. A service mesh can guarantee fast, reliable, and secure communication between containerized application infrastructure services. Key capabilities provided by mesh include service discovery, load balancing, secure encryption and authentication, failover, observability, and more.  
+A service mesh is a dedicated infrastructure layer for handling service-to-service communication.
+It’s responsible for the reliable delivery of requests through the complex topology of services that
+comprise a modern, cloud native application. A service mesh can guarantee fast, reliable, and secure
+communication between containerized application infrastructure services. Key capabilities provided by
+mesh include service discovery, load balancing, secure encryption and authentication, failover,
+observability, and more.
 
-A service mesh typically injects a sidecar proxy into each service instance. These sidecars handle inter-service communication, monitoring, and security. In this way, developers can focus on the development, support, and maintenance of the application code in the service, while the O\&M team is responsible for the maintenance of the service mesh and applications. 
+A service mesh typically injects a sidecar proxy into each service instance. These sidecars handle
+inter-service communication, monitoring, and security. In this way, developers can focus on the
+development, support, and maintenance of the application code in the service, while the O\&M team
+is responsible for the maintenance of the service mesh and applications.
 
 Today, the most well-known service mesh is Istio.
 
 ## Istio
 
-Istio is a service mesh technology originally open sourced by IBM, Google, and Lyft. It can be layered transparently onto distributed applications and provides all the benefits of a service mesh, such as traffic governance, security, and observability.
+Istio is a service mesh technology originally open sourced by IBM, Google, and Lyft. It can be layered
+transparently onto distributed applications and provides all the benefits of a service mesh, such as
+traffic governance, security, and observability.
 
-Istio can adapt to all services hosted with on-premises, cloud, Kubernetes containers, and virtual machines. It is typically used with microservices deployed on a Kubernetes platform.
+Istio can adapt to all services hosted with on-premises, cloud, Kubernetes containers, and virtual machines.
+It is typically used with microservices deployed on a Kubernetes platform.
 
-Fundamentally, Istio works by deploying an extended version of Envoy as a sidecar proxy to each microservice. The proxy network it uses forms a data plane of Istio. The configuration and management of these proxies is done in a control plane, providing discovery, configuration, and certificate management for Envoy proxies in the data plane.
+Fundamentally, Istio works by deploying an extended version of Envoy as a sidecar proxy to each microservice.
+The proxy network it uses forms a data plane of Istio. The configuration and management of these proxies is
+done in a control plane, providing discovery, configuration, and certificate management for Envoy proxies
+in the data plane.
 
 ## Linkerd
 
 Linkerd is the first service mesh launched on the market, but Istio is more popular today.
 
-Linkerd is an open source, ultra-lightweight service mesh designed by Buoyant for Kubernetes. It is completely rewritten in Rust, which makes it as small, light and safe as possible. It provides runtime debugging, observability, reliability, and safety without code changes in distributed applications.
+Linkerd is an open source, ultra-lightweight service mesh designed by Buoyant for Kubernetes.
+It is completely rewritten in Rust, which makes it as small, light and safe as possible.
+It provides runtime debugging, observability, reliability, and safety without code changes
+in distributed applications.
 
-Linkerd has three basic components: UI, data plane, and control plane. Linkerd works by installing a set of ultra-light, transparent proxies next to each service instance that automatically handle all traffic to and from the service.
+Linkerd has three basic components: UI, data plane, and control plane. Linkerd works by installing
+a set of ultra-light, transparent proxies next to each service instance that automatically handle
+all traffic to and from the service.

content/en/docs/Getting started/_index.md → content/en/docs/get-started/_index.md

@@ -6,42 +6,41 @@ description: >
   This page helps you quickly get started with Merbridge.
 ---
 
-## Prerequisites {#prerequisites}
+## Prerequisites
 
 1. Use kernel `5.7` or a higher version. Check your version with `uname -r`.
 1. Activate `cgroup2` in your system. Check the status with `mount | grep cgroup2`.
 
-## Installation {#installation}
-
+## Installation
 Merbridge can be installed on Istio and Linkerd2 only.
 
-### Install on Istio {#installation-on-istio}
+### Install on Istio
 
 Apply the following command to install Merbridge:
 
 ```bash
 kubectl apply -f https://raw.githubusercontent.com/merbridge/merbridge/main/deploy/all-in-one.yaml
 ```
 
-### Install on Linkerd2 {#installation-on-linkerd}
+### Install on Linkerd2
 
 Apply the following command to install Merbridge:
 
 ```bash
 kubectl apply -f https://raw.githubusercontent.com/merbridge/merbridge/main/deploy/all-in-one-linkerd.yaml
 ```
 
-### Install on Kuma {#installation-on-kuma}
+### Install on Kuma
 
 Apply the following command to install Merbridge:
 
 ```bash
 kubectl apply -f https://raw.githubusercontent.com/merbridge/merbridge/main/deploy/all-in-one-kuma.yaml
 ```
 
-## Verification {#verification}
+## Verification
 
-### Verify installation {#verification-installation}
+### Verify installation
 
 Before you start this verification, make sure all Pods relevant to Merbridge are running well. You can check Pod status in Istio with the following command:
 
@@ -51,7 +50,7 @@ kubectl -n istio-system get pods
 
 If all these Pods are `Running`, it means Merbridge is successfully installed.
 
-### Verify connection {#verification-connection-test}
+### Verify connection
 
 Use the following methods to check the connectivity of Merbridge:
 
@@ -70,4 +69,3 @@ kubectl exec $(kubectl get po -l app=sleep -o=jsonpath='{..metadata.name}') -c s
 ```
 
 If you see words like `* Connected to helloworld (127.128.0.1) port 5000 (#0)` in the output, it means Merbridge has managed to replace iptables with eBPF for traffic forwarding.
-

content/zh/docs/Concepts/_index.md

@@ -8,13 +8,17 @@ description: >
 
 ## eBPF
 
-eBPF 全称为 Extended Berkeley Packet Filter，顾名思义，这是一个用来过滤网络数据包的模块。例如 eBPF 的 sockops 和 redir 能力，就可以高效地过滤和拦截数据包。  
+eBPF 全称为 Extended Berkeley Packet Filter，顾名思义，这是一个用来过滤网络数据包的模块。
+例如 eBPF 的 sockops 和 redir 能力，就可以高效地过滤和拦截数据包。  
 
-eBPF 是一项起源于 Linux 内核的革命性技术，可以在操作系统的内核中运行沙盒程序，能够安全、有效地扩展 Linux 内核的功能，无需改变内核的源代码，也无需加载内核模块。
+eBPF 是一项起源于 Linux 内核的革命性技术，可以在操作系统的内核中运行沙盒程序，能够安全、有效地扩展
+Linux 内核的功能，无需改变内核的源代码，也无需加载内核模块。
 
 ## iptables
 
-iptables 是建立在 netfilter 之上的流量过滤器，通过向 netfilter 的挂载点上注册钩子函数来实现对流量过滤和拦截。从 iptables 这个名字上可以看出有表的概念，iptables 通过把这些规则表挂载在 netfilter 的不同链上，对进出内核协议栈的流量数据包进行过滤或者修改。  
+iptables 是建立在 netfilter 之上的流量过滤器，通过向 netfilter 的挂载点上注册钩子函数来实现对流量过滤和拦截。
+从 iptables 这个名字上可以看出有表的概念，iptables 通过把这些规则表挂载在 netfilter 的不同链上，
+对进出内核协议栈的流量数据包进行过滤或者修改。  
 
 iptables 默认有 4 个表：
 
@@ -33,24 +37,33 @@ iptables 默认有 5 个链：
 
 ## Service Mesh
 
-中文名为服务网格，这是一个可配置的低延迟基础设施层，通过 API 接口处理应用服务之间的网络进程间通信。服务网格能确保容器化应用基础结构服务之间的通信快速、可靠和安全。网格提供的关键功能包括服务发现、负载均衡、安全加密和身份验证、故障恢复、可观测性等。  
+中文名为服务网格，这是一个可配置的低延迟基础设施层，通过 API 接口处理应用服务之间的网络进程间通信。
+服务网格能确保容器化应用基础结构服务之间的通信快速、可靠和安全。网格提供的关键功能包括服务发现、负载均衡、
+安全加密和身份验证、故障恢复、可观测性等。
 
-服务网格通常会为每个服务实例注入一个 Sidcar 的代理实例。这些 Sidcar 会处理服务间的通信、监控和安全等问题。这样，开发人员就可以专注于服务中应用代码的开发、支持和维护，而运维团队负责服务网格以及应用的维护工作。  
+服务网格通常会为每个服务实例注入一个 Sidcar 的代理实例。这些 Sidcar 会处理服务间的通信、监控和安全等问题。
+这样，开发人员就可以专注于服务中应用代码的开发、支持和维护，而运维团队负责服务网格以及应用的维护工作。  
 
 目前最著名的服务网格架构是 Istio。
 
 ## Istio
 
-Istio 是最初由 IBM、Google 和 Lyft 开源的服务网格技术。它可以透明地分层到分布式应用上，并提供服务网格的所有优点，例如流量治理、安全性和可观测性等。  
+Istio 是最初由 IBM、Google 和 Lyft 开源的服务网格技术。它可以透明地分层到分布式应用上，
+并提供服务网格的所有优点，例如流量治理、安全性和可观测性等。  
 
-Istio 能够适配本地部署、云托管、Kubernetes 容器以及虚拟机上运行的服务程序。通常与 Kubernetes 平台上部署的微服务一起使用。  
+Istio 能够适配本地部署、云托管、Kubernetes 容器以及虚拟机上运行的服务程序。
+通常与 Kubernetes 平台上部署的微服务一起使用。  
 
-从根本上讲，Istio 的工作原理是以 Sidcar 的形式将 Envoy 的扩展版本作为代理布署到每个微服务中。其使用的代理网络构成了 Istio 的数据平面。而这些代理的配置和管理在控制平面完成，为数据平面中的 Envoy 代理提供发现、配置和证书管理。
+从根本上讲，Istio 的工作原理是以 Sidcar 的形式将 Envoy 的扩展版本作为代理布署到每个微服务中。
+其使用的代理网络构成了 Istio 的数据平面。而这些代理的配置和管理在控制平面完成，为数据平面中的
+Envoy 代理提供发现、配置和证书管理。
 
 ## Linkerd
 
 Linkerd 是市场上出现的第一个服务网格。  
 
-Linkerd 是 Buoyant 为 Kubernetes 设计的开源、超轻量级的服务网格。用 Rust 语言完全重写，使其尽可能小、轻和安全，它提供了运行时调试、可观测性、可靠性和安全性，而无需在分布式应用中更改代码。  
+Linkerd 是 Buoyant 为 Kubernetes 设计的开源、超轻量级的服务网格。用 Rust 语言完全重写，
+使其尽可能小、轻和安全，它提供了运行时调试、可观测性、可靠性和安全性，而无需在分布式应用中更改代码。  
 
-Linkerd 有三个基本组件：UI、数据平面和控制平面。Linkerd 通过在每个服务实例旁安装一组超轻、透明的代理来工作，这些代理会自动处理进出服务的所有流量。
+Linkerd 有三个基本组件：UI、数据平面和控制平面。Linkerd 通过在每个服务实例旁安装一组超轻、透明的代理来工作，
+这些代理会自动处理进出服务的所有流量。

content/zh/docs/Contribution guidelines/_index.md → content/zh/docs/Contribution/_index.md

@@ -11,4 +11,3 @@ Merbridge 目前托管在 GitHub 上进行开源，所有与代码相关的事
 如果您对 Merbridge 有疑问，需要我们帮忙解决问题，或者想要提供一些新的功能，可以在 GitHub 上[创建新的 Issue](https://github.com/merbridge/merbridge/issues)，我们会及时查看并处理。
 
 如果您发现了 Merbridge 的 bug，并且有兴趣帮助我们修复，那么非常欢迎您[提交 Pull Request](https://github.com/merbridge/merbridge/pulls)，附带上您的修复代码，我们会及时处理您的 PR。
-

content/zh/docs/Getting started/_index.md → content/zh/docs/get-started/_index.md

@@ -1,9 +1,9 @@
 ---
-title: "快速开始"
-linkTitle: "快速开始"
+title: "快速入门"
+linkTitle: "快速入门"
 weight: 2
 description: >
-  本文将帮助您快速开始使用 Merbridge
+  本文将帮助您快速使用 Merbridge
 ---
 
 ## 先决条件 {#prerequisites}