Merge pull request servicemesher#40 from DasyDong/fixtypos

Fix some typos

best-practices/how-to-implement-ingress-gateway.md

@@ -229,7 +229,7 @@ Istio Gateway资源本身只能配置L4-L6的功能，例如暴露的端口，TL
 
 Gateway和VirtualService用于表示Istio Ingress的配置模型，Istio Ingress的缺省实现则采用了和Sidecar相同的Envoy proxy。
 
-通过该方式，Istio控制面用一致的配置模型同时控制了入口网关和内部的sidecar代理。这些配置包括路由规则，策略检查、Telementry收集以及其他服务管控功能。
+通过该方式，Istio控制面用一致的配置模型同时控制了入口网关和内部的sidecar代理。这些配置包括路由规则，策略检查、Telemetry收集以及其他服务管控功能。
 
 ![采用 Istio Ingress Gateway作为服务网格的流量入口](../images/6ce41a46ly1g1kur6wqsjj20kh0cbaax.jpg)
 
@@ -257,7 +257,7 @@ API Gateway需求中很大一部分需要根据不同的应用系统进行定制
 
 ## 采用API Gateway + Sidecar Proxy作为服务网格的流量入口
 
-在目前难以找到一个同时具备API Gateway和Isito Ingress能力的网关的情况下，一个可行的方案是使用API Gateway和Sidecar Proxy一起为服务网格提供外部流量入口。
+在目前难以找到一个同时具备API Gateway和Istio Ingress能力的网关的情况下，一个可行的方案是使用API Gateway和Sidecar Proxy一起为服务网格提供外部流量入口。
 
 由于API Gateway已经具备七层网关的功能，Mesh Ingress中的Sidecar只需要提供VirtualService资源的路由能力，并不需要提供Gateway资源的网关能力，因此采用Sidecar Proxy即可。网络入口处的Sidecar Proxy和网格内部应用Pod中Sidecar Proxy的唯一一点区别是：该Sidecar只接管API Gateway向Mesh内部的流量，并不接管外部流向API Gateway的流量；而应用Pod中的Sidecar需要接管进入应用的所有流量。
 

concepts-and-principle/istio-architecture.md

@@ -42,6 +42,6 @@ Istio 的架构设计中有几个关键目标，这些目标对于使系统能
 
 ## 参考
 
-- [Isito 是什么? - istio.io](https://istio.io/zh/docs/concepts/what-is-istio/)
+- [Istio 是什么? - istio.io](https://istio.io/zh/docs/concepts/what-is-istio/)
 - [Bookinfo 示例](https://istio.io/zh/docs/examples/bookinfo/)
 

concepts-and-principle/sidecar-injection-deep-dive.md

@@ -698,7 +698,7 @@ envoy    11 istio-proxy   54u  IPv4 338551      0t0  TCP productpage-v1-745ffc55
 envoy    11 istio-proxy   55u  IPv4 338364      0t0  TCP productpage-v1-745ffc55b7-2l2lw:44046->172.33.78.9:9091 (ESTABLISHED) # 9091：istio-telemetry 服务的 grpc-mixer 端口
 envoy    11 istio-proxy   56u  IPv4 338473      0t0  TCP productpage-v1-745ffc55b7-2l2lw:47210->zipkin.istio-system.svc.cluster.local:9411 (ESTABLISHED) # 9411: zipkin 端口
 envoy    11 istio-proxy   58u  IPv4 338383      0t0  TCP productpage-v1-745ffc55b7-2l2lw:41564->172.33.84.8:9080 (ESTABLISHED) # 9080：details-v1 的 http 端口
-envoy    11 istio-proxy   59u  IPv4 338390      0t0  TCP productpage-v1-745ffc55b7-2l2lw:54410->172.33.78.5:9080 (ESTABLISHED) # 9080：reivews-v2 的 http 端口
+envoy    11 istio-proxy   59u  IPv4 338390      0t0  TCP productpage-v1-745ffc55b7-2l2lw:54410->172.33.78.5:9080 (ESTABLISHED) # 9080：reviews-v2 的 http 端口
 envoy    11 istio-proxy   60u  IPv4 338411      0t0  TCP productpage-v1-745ffc55b7-2l2lw:35200->172.33.84.5:9091 (ESTABLISHED) # 9091:istio-telemetry 服务的 grpc-mixer 端口
 envoy    11 istio-proxy   62u  IPv4 338497      0t0  TCP productpage-v1-745ffc55b7-2l2lw:34402->172.33.84.9:9080 (ESTABLISHED) # reviews-v1 的 http 端口
 envoy    11 istio-proxy   63u  IPv4 338525      0t0  TCP productpage-v1-745ffc55b7-2l2lw:50592->172.33.71.5:9080 (ESTABLISHED) # reviews-v3 的 http 端口

concepts-and-principle/what-is-service-mesh.md

@@ -48,7 +48,7 @@ Service mesh 又译作 “服务网格”，作为服务间通信的基础设施
 
 图片来自：[Pattern: Service Mesh](http://philcalcado.com/2017/08/03/pattern_service_mesh.html)
 
-服务网格作为 sidecar 运行，对应用程序来说是透明，所有应用程序间的流量都会通过它，所以对应用程序流量的控制都可以在 serivce mesh 中实现。
+服务网格作为 sidecar 运行，对应用程序来说是透明，所有应用程序间的流量都会通过它，所以对应用程序流量的控制都可以在 service mesh 中实现。
 
 ## 服务网格如何工作？
 

control-plane/index.md

@@ -46,7 +46,7 @@ Service Mesh 的 Sidecar 模式要求对数据面的用户 Pod 进行代理的
 
 ## Istio 源码, 镜像和命令
 
-Isito 项目代码主要由以下两个 git 仓库组成:
+Istio 项目代码主要由以下两个 git 仓库组成:
 
 | 仓库地址                       | 语言 | 模块                                                                            |
 |--------------------------------|------|---------------------------------------------------------------------------------|

traffic-management/index.md

@@ -12,7 +12,7 @@ category: "original"
 
 这一章节将带大家了解 Istio 流量管理中的各种概念的含义及表示方法。
 
-流量管理是 Isito 中的最基础功能，使用 Istio 的流量管理模型，本质上是将流量与基础设施扩容解耦，让运维人员可以通过 Pilot 指定流量遵循什么规则，而不是指定哪些 pod/VM 应该接收流量——Pilot 和智能 Envoy 代理会帮我们搞定。
+流量管理是 Istio 中的最基础功能，使用 Istio 的流量管理模型，本质上是将流量与基础设施扩容解耦，让运维人员可以通过 Pilot 指定流量遵循什么规则，而不是指定哪些 pod/VM 应该接收流量——Pilot 和智能 Envoy 代理会帮我们搞定。
 
 所谓流量管理是指：