update summary

SUMMARY.md

@@ -19,9 +19,9 @@
     * [Application Scope](cloud-native/application-scope.md)
     * [Application Configuration](cloud-native/application-configuration.md)
   * [Crossplane](cloud-native/crossplane.md)
-* [云原生编程语言](cloud-native/cloud-native-programming-languages.md)
-  * [云原生编程语言 Ballerina](cloud-native/cloud-native-programming-language-ballerina.md)
-  * [云原生编程语言 Pulumi](cloud-native/cloud-native-programming-language-pulumi.md)
+* [云原生平台配置语言](cloud-native/cloud-native-programming-languages.md)
+  * [Ballerina](cloud-native/cloud-native-programming-language-ballerina.md)
+  * [Pulumi](cloud-native/cloud-native-programming-language-pulumi.md)
 * [云原生的未来](cloud-native/the-future-of-cloud-native.md)
 
 ## 快速入门
@@ -34,7 +34,7 @@
 ## 概念与原理
 
 * [Kubernetes 架构](concepts/index.md)
-  * [设计理念](concepts/concepts.md)
+  * [Kubernetes 的设计理念](concepts/concepts.md)
   * [Etcd 解析](concepts/etcd.md)
   * [开放接口](concepts/open-interfaces.md)
     * [容器运行时接口（CRI）](concepts/cri.md)
@@ -96,7 +96,7 @@
   * [使用 CRD 扩展 Kubernetes API](concepts/crd.md)
   * [Aggregated API Server](concepts/aggregated-api-server.md)
   * [APIService](concepts/apiservice.md)
-  * [Service Catalog](concepts/service-catalog.md)
+  * [服务目录（Service Catalog）](concepts/service-catalog.md)
 * [多集群管理](concepts/multicluster.md)
   * [多集群服务 API（Multi-Cluster Services API）](concepts/multi-cluster-services-api.md)
   * [集群联邦（Cluster Federation）](practice/federation.md)
@@ -131,8 +131,7 @@
   * [通过端口转发访问集群中的应用程序](guide/connecting-to-applications-port-forward.md)
   * [使用 service 访问群集中的应用程序](guide/service-access-application-cluster.md)
   * [从外部访问 Kubernetes 中的 Pod](guide/accessing-kubernetes-pods-from-outside-of-the-cluster.md)
-  * [Cabin - Kubernetes 手机客户端](guide/cabin-mobile-dashboard-for-kubernetes.md)
-  * [Lens - Kubernetes IDE/桌面客户端](guide/kubernetes-desktop-client.md)
+  * [Lens - Kubernetes IDE](guide/kubernetes-desktop-client.md)
   * [Kubernator - 更底层的 Kubernetes UI](guide/kubernator-kubernetes-ui.md)
 * [在 Kubernetes 中开发部署应用](guide/application-development-deployment-flow.md)
   * [适用于 Kubernetes 的应用开发部署流程](guide/deploy-applications-in-kubernetes.md)
@@ -194,7 +193,6 @@
   * [Prometheus](practice/prometheus.md)
     * [使用 Prometheus 监控 Kubernetes 集群](practice/using-prometheus-to-monitor-kuberentes-cluster.md)
     * [Prometheus 查询语言 PromQL 使用说明](practice/promql.md)
-  * [使用 Vistio 监控 Istio 服务网格中的流量](practice/vistio-visualize-your-istio-mesh.md)
 * [分布式追踪](practice/distributed-tracing.md)
   * [OpenTracing](practice/opentracing.md)
 * [服务编排管理](practice/services-management-tool.md)

appendix/material-share.md

@@ -4,7 +4,7 @@
 
 ## 社区资源
 
-Kubernetes 社区的贡献、交流和治理方式相关的内容都保存在 <https://github.com/kubernetes/community> 这个 repo 中，建议参与 Kubernetes 社区前先阅读该 repo 中的资料。
+Kubernetes 社区的贡献、交流和治理方式相关的内容都保存在[这个 repo](https://github.com/kubernetes/community)  中，建议参与 Kubernetes 社区前先阅读该 repo 中的资料。
 
 在这里你可以找到：
 
@@ -45,7 +45,6 @@ Kubernetes和Cloud Native相关网站、专栏、博客等。
 - [dockone.io](http://www.dockone.io)
 - [Cloud Native 知乎专栏](https://zhuanlan.zhihu.com/cloud-native)
 - [kubernetes.org.cn](https://www.kubernetes.org.cn/)
-- [servicemesher.com](https://www.servicemesher.com)
 
 ### 博客
 

cloud-native/cloud-native-local-quick-start.md

@@ -13,13 +13,13 @@
 - 8G 以上内存
 - [Vagrant 2.0+](https://www.vagrantup.com/)
 - [VirtualBox 5.0 +](https://www.virtualbox.org/wiki/Downloads)
-- 提前下载kubernetes1.9.1以上版本的release压缩包，[至百度网盘下载](https://pan.baidu.com/s/1zkg2xEAedvZHObmTHDFChg)（并将名字中的版本号删除）
+- 提前下载 Kubernetes1.9.1 以上版本的 release 压缩包，[至百度网盘下载](https://pan.baidu.com/s/1zkg2xEAedvZHObmTHDFChg)（并将名字中的版本号删除）
 - Mac/Linux，**不支持 Windows**
 - 支持 Kubernetes1.9 以上版本（支持当前 Kubernetes 最新版本 1.11.1）
 
 ## 集群
 
-我们使用Vagrant和Virtualbox安装包含3个节点的kubernetes集群，其中master节点同时作为node节点。
+我们使用 Vagrant 和 VirtualBox 安装包含 3 个节点的 Kubernetes 集群，其中 master 节点同时作为 node 节点。
 
 | IP           | 主机名 | 组件                                                         |
 | ------------ | ------ | ------------------------------------------------------------ |
@@ -111,7 +111,7 @@ kubectl get nodes
 
 **Kubernetes dashboard**
 
-还可以直接通过dashboard UI来访问：https://172.17.8.101:8443
+还可以直接通过 dashboard UI 来访问：[https://172.17.8.101:8443](https://172.17.8.101:8443/)
 
 可以在本地执行以下命令获取 token 的值（需要提前安装 kubectl）：
 
@@ -157,7 +157,7 @@ kubectl apply -f addon/traefik-ingress
 172.17.8.102 traefik.jimmysong.io
 ```
 
-访问Traefik UI：<http://traefik.jimmysong.io>
+访问 Traefik UI：[http://traefik.jimmysong.io](http://traefik.jimmysong.io/)
 
 ![Traefik dashboard](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster/raw/master/images/traefik-ingress.gif)
 
@@ -181,7 +181,7 @@ hack/deploy-helm.sh
 
 ### Service Mesh
 
-我们使用 [istio](https://istio.io) 作为 service mesh。
+我们使用 [Istio](https://istio.io/) 作为 service mesh。
 
 **安装**
 
@@ -216,27 +216,6 @@ istioctl create -f yaml/istio-bookinfo/bookinfo-gateway.yaml
 
 ![bookinfo示例](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster/raw/master/images/bookinfo-demo.gif)
 
-### Vistio
-
-[Vizceral](https://github.com/Netflix/vizceral)是Netflix发布的一个开源项目，用于近乎实时地监控应用程序和集群之间的网络流量。Vistio是使用Vizceral对Istio和网格监控的改进。它利用Istio Mixer生成的指标，然后将其输入Prometheus。Vistio查询Prometheus并将数据存储在本地以允许重播流量。
-
-```bash
-# Deploy vistio via kubectl
-kubectl apply -f addon/vistio/
-
-# Expose vistio-api
-kubectl -n default port-forward $(kubectl -n default get pod -l app=vistio-api -o jsonpath='{.items[0].metadata.name}') 9091:9091 &
-
-# Expose vistio in another terminal window
-kubectl -n default port-forward $(kubectl -n default get pod -l app=vistio-web -o jsonpath='{.items[0].metadata.name}') 8080:8080 &
-```
-
-如果一切都已经启动并准备就绪，您就可以访问Vistio UI，开始探索服务网格网络，访问[http://localhost:8080](http://localhost:8080/) 您将会看到类似下图的输出。
-
-![vistio视图动画](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster/raw/master/images/vistio-animation.gif)
-
-更多详细内容请参考[Vistio—使用Netflix的Vizceral可视化Istio service mesh](https://servicemesher.github.io/blog/vistio-visualize-your-istio-mesh-using-netflixs-vizceral/)。
-
 ### Kiali
 
 Kiali 是一个用于提供 Istio service mesh 观察性的项目，更多信息请查看 [https://kiali.io](https://kiali.io/)。
@@ -255,9 +234,11 @@ Kiali web地址：`http://172.17.8.101:31439`
 
 **注意**：Kilia使用Jaeger做追踪，请不用屏蔽kilia页面的弹出窗口。
 
+**注意**：Kilia 使用 Jaeger 做追踪，请不用屏蔽 kilia 页面的弹出窗口。
+
 ### Weave scope
 
-[Weave scope](https://github.com/weaveworks/scope)可用于监控、可视化和管理Docker&Kubernetes集群，详情见 https://www.weave.works/oss/scope/ 
+[Weave scope](https://github.com/weaveworks/scope) 可用于监控、可视化和管理 Docker&Kubernetes 集群，详情见 [Weave 官方文档](https://www.weave.works/oss/scope/)。
 
 在本地该项目的根路径下执行下面的命令：
 
@@ -348,6 +329,5 @@ rm -rf .vagrant
 ## 参考
 
 - [Kubernetes handbook - jimmysong.io](https://jimmysong.io/kubernetes-handbook)
-- [duffqiu/centos-vagrant](https://github.com/duffqiu/centos-vagrant)
-- [coredns/deployment](https://github.com/coredns/deployment)
-- [Vistio—使用Netflix的Vizceral可视化Istio service mesh](http://www.servicemesher.com/blog/vistio-visualize-your-istio-mesh-using-netflixs-vizceral/)
+- [duffqiu/centos-vagrant - github.com](https://github.com/duffqiu/centos-vagrant)
+- [coredns/deployment - github.com](https://github.com/coredns/deployment)

cloud-native/cloud-native-programming-language-ballerina.md

@@ -1,4 +1,4 @@
-# 云原生编程语言 Ballerina
+# Ballerina
 
 当我第一眼看到 [Ballerina](https://ballerina.io) 还真有点惊艳的感觉。Ballerina 这个单词的意思是“芭蕾舞女演员”。我想他们之所以给公司和这们语言起这个名字，可能是希望它成为云原生这个大舞台中，Ballerina 能像一个灵活的芭蕾舞者一样轻松自如吧！
 

cloud-native/cloud-native-programming-language-pulumi.md

@@ -1,4 +1,4 @@
-# 云原生编程语言 Pulumi
+# Pulumi
 
 2018 年 6 月 18 日 Joe Duffy 在[他的博客](http://joeduffyblog.com/2018/06/18/hello-pulumi/)中宣布开源了云原生编程语言 [Pulumi](https://www.pulumi.com/)。这是继 [Ballerina](https://ballerina.io/) 之后我看到的另一款云原生编程语言，他们之间有一些共同的特点，例如都是为了支持多种云环境，基于不可变基础设施和基础设施即代码的理念构建，使云原生应用的集成更加方便，但也有一些不同，Ballerina 是直接创建了一个基于 JVM 的语言，而 Pulumi 是为不同编程语言构建了 SDK。
 

cloud-native/cloud-native-programming-languages.md

@@ -1,6 +1,14 @@
-# 云原生编程语言
+# 云原生平台配置语言
 
-> 以下内容来自Joe Duffy的博客，[Hello, Pulumi!](http://joeduffyblog.com/2018/06/18/hello-pulumi/)。他说这些是为了说明为什么要创造Pulumi，在此我引用它说明为什么会有云原生编程语言。
+云原生平台配置语言是一种 DSL（Domain Specific Language），通过编程的方式来创建云原生平台，目前已有的云原生 DSL 有：
+
+- Ballerina
+- Pulumi
+- Cue
+- KSL
+- Kusion
+
+以下内容引用自 [Joe Duffy 的博客](http://joeduffyblog.com/2018/06/18/hello-pulumi/)。他说这些是为了说明为什么要创造 Pulumi，在此我引用它说明为什么会有云原生编程语言。
 
 对于每一个 serverless 函数来说，我都要写几十行的 JSON 或者 YAML 配置。要链接到一个 API 端点，我还要学习晦涩的概念，执行一系列复制 - 粘贴的低级工作。如果我想在本机上运行一个小的集群的话，那么 Docker 还是很棒的，但是如果要在生产上使用的话，那么就要手动管理 etcd 集群，配置网络和 iptables 路由表，还有一系列与我的应用程序本身不相干的事情。不过 Kubernetes 的出现至少让我可以配置一次下次就可以跨云平台重用，但这还是会分散开发人员的精力。
 

cloud-native/play-with-kubernetes.md

@@ -51,4 +51,3 @@ kubeadm join --token 513212.cfea0165b8988d18 192.168.0.13:6443 --discovery-token
 
 ![Play with Kubernetes 网页截图](../images/play-with-kubernetes.jpg)
 
-Play with Kuberentes (PWK) is a project hacked by [Marcos Lilljedahl](https://www.twitter.com/marcosnils) and [Jonathan Leibiusky](https://www.twitter.com/xetorthio) and sponsored by Docker Inc.

cloud-native/quick-start.md

@@ -176,4 +176,4 @@ Grafana 是一个优秀的仪表盘、分析和数据可视化工具。它没有
 
 云原生领域的开源项目众多（见 [Awesome Cloud Native / 云原生开源项目大全](https://jimmysong.io/awesome-cloud-native)），其中有大量的优秀项目可供我们学习。此外，Kubernetes 开源已经多年时间，网上有大量的学习资料，业界出版过很多[书籍](https://jimmysong.io/cloud-native/note/books/)，建议大家通过阅读[官方文档](https://kubernetes.io/)和实践来学习，也可以参考我编写的 [Kubernetes Handbook——Kubernetes 中文指南 / 云原生架构实践手册](https://jimmysong.io/kubernetes-handbook)。
 
-推荐大家加入我发起创办的[云原生社区](https://cloudnative.to/)，这是一个立足中国，放眼世界的云原生终端用户社区，致力于云原生技术的传播和应用。云原生社区主办的[云原生学院](https://github.com/cloudnativeto/academy)定期邀请云原生和开源领域的大咖在 B 站上进行直播分享，成员自发组织了多个 SIG（特别兴趣小组）进行讨论学习。欢迎加入我们，共同学习和交流云原生技术。
+推荐大家加入笔者发起创办的[云原生社区](https://cloudnative.to/)，这是一个立足中国，放眼世界的云原生终端用户社区，致力于云原生技术的传播和应用。云原生社区主办的[云原生学院](https://github.com/cloudnativeto/academy)定期邀请云原生和开源领域的大咖进行直播分享，成员自发组织了多个 SIG（特别兴趣小组）进行讨论学习。欢迎加入我们，共同学习和交流云原生技术。

concepts/admission-controller.md

@@ -2,9 +2,10 @@
 
 准入控制器（Admission Controller）位于 API Server 中，在对象被持久化之前，准入控制器拦截对 API Server 的请求，一般用来做身份验证和授权。其中包含两个特殊的控制器：`MutatingAdmissionWebhook` 和 `ValidatingAdmissionWebhook`。分别作为配置的变异和验证[准入控制 webhook](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。
 
-**变更（Mutating）准入控制**：修改请求的对象
+准入控制器包括以下两种：
 
-**验证（Validating）准入控制**：验证请求的对象
+- **变更（Mutating）准入控制**：修改请求的对象
+- **验证（Validating）准入控制**：验证请求的对象
 
 准入控制器是在 API Server 的启动参数重配置的。一个准入控制器可能属于以上两者中的一种，也可能两者都属于。当请求到达 API Server 的时候首先执行变更准入控制，然后再执行验证准入控制。
 

concepts/aggregated-api-server.md

@@ -12,8 +12,6 @@ Aggregated（聚合的）API  server是为了将原来的API server这个巨石
 
 **注意**：这里说的 API server 是一组 “API Server”，而不是说我们安装集群时候的那个 API server，而且这组 API server 是可以横向扩展的。
 
-关于聚合的API server的更多信息请参考：[Aggregated API Server](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)
-
 ## 安装配置聚合的 API server
 
 有两种方式来启用 `kube-aggregator`：
@@ -21,8 +19,4 @@ Aggregated（聚合的）API  server是为了将原来的API server这个巨石
 - 使用 **test mode/single-user mode**，作为一个独立的进程来运行
 - 使用 **gateway mode**，`kube-apiserver` 将嵌入到 `kbe-aggregator` 组件中，它将作为一个集群的 gateway，用来聚合所有 apiserver。
 
-`kube-aggregator`二进制文件已经包含在kubernetes release里面了。
-
-## 参考
-
-[Aggregated API Servers - kuberentes design-proposals](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)
+`kube-aggregator` 二进制文件已经包含在 Kubernetes release 里面了。

concepts/cluster.md

@@ -1,3 +1,3 @@
-# 集群信息
+# 集群资源管理
 
 为了管理异构和不同配置的主机，为了便于 Pod 的运维管理，Kubernetes 中提供了很多集群管理的配置和管理功能，通过 namespace 划分的空间，通过为 node 节点创建 label 和 taint 用于 pod 的调度等。

concepts/configmap.md

@@ -142,9 +142,6 @@ metadata:
 $ kubectl create configmap game-config-2 --from-file=docs/user-guide/configmap/kubectl/game.properties 
 
 $ kubectl get configmaps game-config-2 -o yaml
-```
-
-```yaml
 apiVersion: v1
 data:
   game-special-key: |
@@ -175,9 +172,6 @@ metadata:
 $ kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
 
 $ kubectl get configmaps special-config -o yaml
-```
-
-```yaml
 apiVersion: v1
 data:
   special.how: very
@@ -207,9 +201,6 @@ metadata:
 data:
   special.how: very
   special.type: charm
-```
-
-```yaml
 apiVersion: v1
 kind: ConfigMap
 metadata:

concepts/crd.md

@@ -613,4 +613,4 @@ crontabs/my-new-cron-object   3s
 ## 参考
 
 - [Extend the Kubernetes API with CustomResourceDefinitions - kubernetes.io](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)
-- [如何从零开始编写一个Kubernetes CRD - servicemesher.com](https://www.servicemesher.com/blog/kubernetes-crd-quick-start/)
+- [如何从零开始编写一个 Kubernetes CRD - cloudnative.to](https://cloudnative.to/blog/kubernetes-crd-quick-start/)

concepts/custom-metrics-hpa.md

@@ -2,13 +2,13 @@
 
 Kubernetes 中不仅支持 CPU、内存为指标的 HPA，还支持自定义指标的 HPA，例如 QPS。
 
-本文中使用的 yaml 文件见 [manifests/HPA](https://github.com/rootsongjc/kubernetes-handbook/tree/master/manifests/HPA)。
+本文中使用的 YAML 文件见 [manifests/HPA](https://github.com/rootsongjc/kubernetes-handbook/tree/master/manifests/HPA)。
 
 ## 设置自定义指标
 
-**kubernetes1.6**
+**Kubernetes1.6**
 
-> 在 kubernetes1.6 集群中配置自定义指标的 HPA 的说明已废弃。
+> 在 Kubernetes1.6 集群中配置自定义指标的 HPA 的说明已废弃。
 
 在设置定义指标 HPA 之前需要先进行如下配置：
 
@@ -18,13 +18,13 @@ Kubernetes 中不仅支持 CPU、内存为指标的 HPA，还支持自定义指
 - 启用 custom metric API
 - 将 kube-controller-manager 的启动参数中 `--horizontal-pod-autoscaler-use-rest-clients` 设置为 true，并指定 `--master` 为 API server 地址，如 `--master=http://172.20.0.113:8080`
 
-在 kubernetes1.5 以前很容易设置，参考 [1.6 以前版本的 kubernetes 中开启自定义 HPA](https://medium.com/@marko.luksa/kubernetes-autoscaling-based-on-custom-metrics-without-using-a-host-port-b783ed6241ac)，而在 1.6 中因为取消了原来的 annotation 方式设置 custom metric，只能通过 API server 和 kube-aggregator 来获取 custom metric，因为只有两种方式来设置了，一是直接通过 API server 获取 heapster 的 metrics，二是部署 [kube-aggragator](https://github.com/kubernetes/kube-aggregator) 来实现。
+在 Kubernetes1.5 以前很容易设置，参考 [1.6 以前版本的 kubernetes 中开启自定义 HPA](https://medium.com/@marko.luksa/kubernetes-autoscaling-based-on-custom-metrics-without-using-a-host-port-b783ed6241ac)，而在 1.6 中因为取消了原来的 annotation 方式设置 custom metric，只能通过 API server 和 kube-aggregator 来获取 custom metric，因为只有两种方式来设置了，一是直接通过 API server 获取 heapster 的 metrics，二是部署 [kube-aggragator](https://github.com/kubernetes/kube-aggregator) 来实现。
 
-我们将在 kubernetes1.8 版本的 kubernetes 中，使用聚合的 API server 来实现自定义指标的 HPA。
+我们将在 Kubernetes1.8 版本的 Kubernetes 中，使用聚合的 API server 来实现自定义指标的 HPA。
 
-**kuberentes1.7+**
+**Kuberentes1.7+**
 
-确认您的 kubernetes 版本在 1.7 或以上，修改以下配置：
+确认您的 Kubernetes 版本在 1.7 或以上，修改以下配置：
 
 - 将 kube-controller-manager 的启动参数中 `--horizontal-pod-autoscaler-use-rest-clients` 设置为 true，并指定 `--master` 为 API server 地址，如 `--master=http://172.20.0.113:8080`
 - 修改 kube-apiserver 的配置文件 apiserver，增加一条配置 `--requestheader-client-ca-file=/etc/kubernetes/ssl/ca.pem --requestheader-allowed-names=aggregator --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --proxy-client-cert-file=/etc/kubernetes/ssl/kubernetes.pem --proxy-client-key-file=/etc/kubernetes/ssl/kubernetes-key.pem`，用来配置 aggregator 的 CA 证书。

concepts/custom-resource.md

@@ -1,60 +1,29 @@
 # 使用自定义资源扩展 API
 
-> **注意：**TPR 已经停止维护，kubernetes 1.7 及以上版本请使用 CRD。
-
-自定义资源是对 Kubernetes API 的扩展，kubernetes 中的每个资源都是一个 API 对象的集合，例如我们在 YAML 文件里定义的那些 spec 都是对 kubernetes 中的资源对象的定义，所有的自定义资源可以跟 kubernetes 中内建的资源一样使用 kubectl 操作。
+自定义资源是对 Kubernetes API 的扩展，Kubernetes 中的每个资源都是一个 API 对象的集合，例如我们在 YAML 文件里定义的那些 spec 都是对 Kubernetes 中的资源对象的定义，所有的自定义资源可以跟 Kubernetes 中内建的资源一样使用 kubectl 操作。
 
 ## 自定义资源
 
-Kubernetes1.6 版本中包含一个内建的资源叫做 TPR（ThirdPartyResource），可以用它来创建自定义资源，但该资源在 kubernetes1.7 中版本已被 CRD（CustomResourceDefinition）取代。
+Kubernetes 从 1.6 版本开始包含一个内建的资源叫做 TPR（ThirdPartyResource），可以用它来创建自定义资源，但该资源在 Kubernetes 1.7 版本开始已被 CRD（CustomResourceDefinition）取代。
 
 ## 扩展 API
 
-自定义资源实际上是为了扩展 kubernetes 的 API，向 kubenetes API 中增加新类型，可以使用以下三种方式：
+自定义资源实际上是为了扩展 Kubernetes 的 API，向 Kubernetes API 中增加新类型，可以使用以下三种方式：
 
-- 修改 kubenetes 的源码，显然难度比较高，也不太合适
+- 修改 Kubernetes 的源码，显然难度比较高，也不太合适
 - 创建自定义 API server 并聚合到 API 中
-- 1.7 以下版本编写 TPR，kubernetes1.7 及以上版本用 CRD
 
-编写自定义资源是扩展 kubernetes API 的最简单的方式，是否编写自定义资源来扩展 API 请参考 [Should I add a custom resource to my Kubernetes Cluster?](https://kubernetes.io/docs/concepts/api-extension/custom-resources/)，行动前请先考虑以下几点：
+编写自定义资源是扩展 Kubernetes API 的最简单的方式，是否编写自定义资源来扩展 API 请参考 [Should I add a custom resource to my Kubernetes Cluster?](https://kubernetes.io/docs/concepts/api-extension/custom-resources/)，行动前请先考虑以下几点：
 
 - 你的 API 是否属于 [声明式的](https://kubernetes.io/docs/concepts/api-extension/custom-resources/#declarative-apis)
 - 是否想使用 kubectl 命令来管理
-- 是否要作为 kubenretes 中的对象类型来管理，同时显示在 kubernetes dashboard 上
-- 是否可以遵守 kubernetes 的 API 规则限制，例如 URL 和 API group、namespace 限制
+- 是否要作为 Kubernetes 中的对象类型来管理，同时显示在 Kubernetes dashboard 上
+- 是否可以遵守 Kubernetes 的 API 规则限制，例如 URL 和 API group、namespace 限制
 - 是否可以接受该 API 只能作用于集群或者 namespace 范围
-- 想要复用 kubernetes API 的公共功能，比如 CRUD、watch、内置的认证和授权等
+- 想要复用 Kubernetes API 的公共功能，比如 CRUD、watch、内置的认证和授权等
 
 如果这些都不是你想要的，那么你可以开发一个独立的 API。
 
-## TPR
-
-> **注意：**TPR 已经停止维护，kubernetes 1.7 及以上版本请使用 CRD。
-
-假如我们要创建一个名为 `cron-tab.stable.example.com` 的 TPR，yaml 文件定义如下：
-
-```yaml
-apiVersion: extensions/v1beta1
-kind: ThirdPartyResource
-metadata:
-  name: cron-tab.stable.example.com
-description: "A specification of a Pod to run on a cron style schedule"
-versions:
-- name: v1
-​```然后使用`kubectl create`命令创建该资源，这样就可以创建出一个 API 端点`/apis/stable.example.com/v1/namespaces/<namespace>/crontabs/...`。
-
-下面是在 [Linkerd](https://linkerd.io) 中的一个实际应用，Linkerd 中的一个名为 namerd 的组件使用了 TPR，定义如下：
-​```yaml
----
-kind: ThirdPartyResource
-apiVersion: extensions/v1beta1
-metadata:
-  name: d-tab.l5d.io
-description: stores dtabs used by namerd
-versions:
-- name: v1alpha1
-```
-
 ### CRD
 
 参考下面的 CRD，resourcedefinition.yaml：
@@ -82,9 +51,17 @@ spec:
     # CLI 中使用的资源简称
     shortNames:
     - ct
-​```创建该 CRD：```bash
+```
+
+创建该 CRD：
+
+```bash
 kubectl create -f resourcedefinition.yaml
-​```访问 RESTful API 端点如 <http://172.20.0.113:8080> 将看到如下 API 端点已创建：```bash
+```
+
+访问 RESTful API 端点如 <http://172.20.0.113:8080> 将看到如下 API 端点已创建：
+
+```bash
 /apis/stable.example.com/v1/namespaces/*/crontabs/...
 ```
 
@@ -124,7 +101,7 @@ metadata:
 
 单纯设置了自定义资源，并没有什么用，只有跟自定义控制器结合起来，才能将资源对象中的声明式 API 翻译成用户所期望的状态。自定义控制器可以用来管理任何资源类型，但是一般是跟自定义资源结合使用。
 
-请参考使用 [Operator](https://coreos.com/blog/introducing-operators.html) 模式，该模式可以让开发者将自己的领域知识转换成特定的 kubenretes API 扩展。
+请参考使用 [Operator](https://coreos.com/blog/introducing-operators.html) 模式，该模式可以让开发者将自己的领域知识转换成特定的 Kubernetes API 扩展。
 
 ## API server 聚合
 
@@ -134,6 +111,6 @@ Aggregated（聚合的）API  server 是为了将原来的 API server 这个巨
 
 ## 参考
 
-- [Custom Resources](https://kubernetes.io/docs/concepts/api-extension/custom-resources/)
-- [Extend the Kubernetes API with CustomResourceDefinitions](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
-- [Introducing Operators: Putting Operational Knowledge into Software](https://coreos.com/blog/introducing-operators.html)
+- [Custom Resources - kubernetes.io](https://kubernetes.io/docs/concepts/api-extension/custom-resources/)
+- [Extend the Kubernetes API with CustomResourceDefinitions - kubernetes.io](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
+- [Introducing Operators: Putting Operational Knowledge into Software - coreos.com](https://coreos.com/blog/introducing-operators.html)

concepts/extension.md

@@ -1,3 +1,3 @@
 # 扩展
 
-Kubernetes是一个高度开放可扩展的架构，可以通过自定义资源类型CRD来定义自己的类型，还可以自己来扩展API服务，用户的使用方式跟Kubernetes的原生对象无异。
+Kubernetes 是一个高度开放可扩展的架构，可以通过自定义资源类型（CRD）来定义自己的类型，还可以自己来扩展 API 服务，用户的使用方式跟 Kubernetes 的原生对象无异。

concepts/horizontal-pod-autoscaling.md

@@ -144,6 +144,6 @@ Kubernetes 然后查询新的自定义 metric API 来获取相应自定义 metri
 
 ## 参考
 
-- [HPA说明 - kubernetes.io(https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)
+- [HPA 说明 - kubernetes.io](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)
 - [HPA 详解 - kubernetes.io](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)
 - [自定义 metrics 开发 - github.com](https://github.com/kubernetes/metrics)

concepts/ingress.md

@@ -1,4 +1,4 @@
-# Ingress 解析
+# Ingress
 
 Ingress 是从 Kubernetes 集群外部访问集群内部服务的入口，这篇文章部分译自 Kubernetes 官方文档 [Ingress Resource](https://kubernetes.io/docs/concepts/services-networking/ingress/)，后面的章节会讲到使用 [Traefik](https://github.com/containous/traefik) 来做 Ingress controller，文章末尾给出了几个相关链接。
 

concepts/job.md

@@ -28,9 +28,6 @@ spec:
         image: perl
         command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
       restartPolicy: Never
-```
-
-```bash
 $ kubectl create -f ./job.yaml
 job "pi" created
 $ pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath={.items..metadata.name})
@@ -38,6 +35,6 @@ $ kubectl logs $pods -c pi
 3.141592653589793238462643383279502...
 ```
 
-## Bare Pods
+## Bare Pod
 
-所谓Bare Pods是指直接用PodSpec来创建的Pod（即不在ReplicaSets或者ReplicationController的管理之下的Pods）。这些Pod在Node重启后不会自动重启，但Job则会创建新的Pod继续任务。所以，推荐使用Job来替代Bare Pods，即便是应用只需要一个Pod。
+所谓 Bare Pod 是指直接用 PodSpec 来创建的 Pod（即不在 ReplicaSet 或者 ReplicationController 的管理之下的 Pod）。这些 Pod 在 Node 重启后不会自动重启，但 Job 则会创建新的 Pod 继续任务。所以，推荐使用 Job 来替代 Bare Pod，即便是应用只需要一个 Pod。

concepts/multi-cluster-services-api.md

@@ -9,4 +9,3 @@ Kubernetes 用户可能希望将他们的部署分成多个集群，但仍然保
 ## 参考
 
 - [KEP-1645: Multi-Cluster Services API - github.com](https://github.com/kubernetes/enhancements/tree/master/keps/sig-multicluster/1645-multi-cluster-services-api)
-

concepts/multicluster.md

@@ -27,4 +27,3 @@
 
 - [Multicluster Special Interest Group - github.com](https://github.com/kubernetes/community/blob/master/sig-multicluster/README.md)
 - [配置对多集群的访问 - kubernetes.io](https://kubernetes.io/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
-

concepts/network-policy.md

@@ -102,5 +102,4 @@ spec:
 ```
 ## 参考
 
-- [Network Policies - k8smeetup.github.io](https://k8smeetup.github.io/docs/concepts/services-networking/network-policies/)
 - [Network Policies - kubernetes.io](https://kubernetes.io/docs/concepts/services-networking/network-policies/)

concepts/pause-container.md

@@ -66,7 +66,7 @@ kubernetes中的pause容器主要为每个业务容器提供以下功能：
 - 在 pod 中担任 Linux 命名空间共享的基础；
 - 启用 pid 命名空间，开启 init 进程。
 
-在[The Almighty Pause Container](https://www.ianlewis.org/en/almighty-pause-container)这篇文章中做出了详细的说明，pause容器的作用可以从这个例子中看出，首先见下图：
+[这篇文章](https://www.ianlewis.org/en/almighty-pause-container)做出了详细的说明，pause 容器的作用可以从这个例子中看出，首先见下图：
 
 ![Pause容器](../images/pause-container.png)
 
@@ -96,13 +96,33 @@ EOF
 $ docker run -d --name nginx -v `pwd`/nginx.conf:/etc/nginx/nginx.conf --net=container:pause --ipc=container:pause --pid=container:pause nginx
 ```
 
+然后再运行一个 nginx 容器，nginx 将为 `localhost:2368` 创建一个代理。
+
+```bash
+$ cat <<EOF >> nginx.conff
+error_log stderr;
+events { worker_connections  1024; }
+http {
+    access_log /dev/stdout combined;
+    server {
+        listen 80 default_server;
+        server_name example.com www.example.com;
+        location / {
+            proxy_pass http://127.0.0.1:2368;
+        }
+    }
+}
+EOF
+$ docker run -d --name nginx -v `pwd`/nginx.conf:/etc/nginx/nginx.conf --net=container:pause --ipc=container:pause --pid=container:pause nginx
+```
+
 然后再为 [ghost](https://github.com/TryGhost/Ghost) 创建一个应用容器，这是一款博客软件。
 
 ```bash
 $ docker run -d --name ghost --net=container:pause --ipc=container:pause --pid=container:pause ghost
 ```
 
-现在访问<http://localhost:8880/>就可以看到ghost博客的界面了。
+现在访问 http://localhost:8880/ 就可以看到 ghost 博客的界面了。
 
 **解析**
 
@@ -119,11 +139,9 @@ root        79  0.1  0.0   4336   812 pts/0    Ss   14:09   0:00 sh
 root        87  0.0  0.0  17500  2080 pts/0    R+   14:10   0:00 ps aux
 ```
 
-在ghost容器中同时可以看到pause和nginx容器的进程，并且pause容器的PID是1。而在kubernetes中容器的PID=1的进程即为容器本身的业务进程。
+在 ghost 容器中同时可以看到 pause 和 nginx 容器的进程，并且 pause 容器的 PID 是 1。而在 Kubernetes 中容器的 PID=1 的进程即为容器本身的业务进程。
 
 ## 参考
 
-- [The Almighty Pause Container](https://www.ianlewis.org/en/almighty-pause-container)
-- [Kubernetes之Pause容器](https://o-my-chenjian.com/2017/10/17/The-Pause-Container-Of-Kubernetes/)
-- [CNCF&Aliyun云原生课程](https://edu.aliyun.com/lesson_1651_16895?spm=5176.10731542.0.0.41a620be3s3dmu#_16895)
-
+- [The Almighty Pause Container - ianlewis.org](https://www.ianlewis.org/en/almighty-pause-container)
+- [Kubernetes 之 Pause 容器 - o-my-chenjian.com](https://o-my-chenjian.com/2017/10/17/The-Pause-Container-Of-Kubernetes/)

concepts/pod-hook.md

@@ -37,5 +37,5 @@ Hook 调用的日志没有暴露给 Pod 的 event，所以只能通过 `describe
 
 ## 参考
 
-- [Attach Handlers to Container Lifecycle Events](https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
-- [Container Lifecycle Hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/)
+- [Attach Handlers to Container Lifecycle Events - kuberentes.io](https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
+- [Container Lifecycle Hooks - kubernetes.io](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/)

concepts/pod-preset.md

@@ -1,6 +1,6 @@
 # Pod Preset
 
-> **注意：**PodPreset 资源对象只有 kubernetes 1.8 以上版本才支持。
+> **注意：**PodPreset 资源对象只有 Kubernetes 1.8 以上版本才支持。
 
 Preset 就是预设，有时候想要让一批容器在启动的时候就注入一些信息，比如 secret、volume、volume mount 和环境变量，而又不想一个一个的改这些 Pod 的 template，这时候就可以用到 PodPreset 这个资源对象了。
 

concepts/pod.md

@@ -1,8 +1,10 @@
 # Pod 解析
 
-Pod是kubernetes中可以创建的最小部署单元。
+Pod 是 Kubernetes 中可以创建的最小部署单元，也是 Kubernetes REST API 中的顶级资源类型。V1 core 版本的 Pod 的配置模板见 [Pod template](../manifests/template/pod-v1-template.yaml)。
 
-V1 core版本的Pod的配置模板见[Pod template](../manifests/template/pod-v1-template.yaml)。
+在 Kuberentes V1 core API 版本中的 Pod 的数据结构如下图所示：
+
+![Pod Cheatsheet](../images/kubernetes-pod-cheatsheet.png)
 
 ## 什么是 Pod？
 
@@ -26,7 +28,7 @@ Volume跟pod有相同的生命周期（当其UID存在的时候）。当Pod因
 
 ![Pod示意图](../images/pod-overview.png)
 
-*一个多容器Pod，包含文件提取程序和Web服务器，该服务器使用持久卷在容器之间共享存储。*
+说明：一个多容器 Pod，包含文件提取程序和 Web 服务器，该服务器使用持久卷在容器之间共享存储。 s
 
 ## Pod 的动机
 
@@ -73,9 +75,9 @@ Pod也可以用于垂直应用栈（例如LAMP），这样使用的主要动机
 
 Pod 在设计支持就不是作为持久化实体的。在调度失败、节点故障、缺少资源或者节点维护的状态下都会死掉会被驱逐。
 
-通常，用户不需要手动直接创建Pod，而是应该使用controller（例如[Deployments](./deployment.md)），即使是在创建单个Pod的情况下。Controller可以提供集群级别的自愈功能、复制和升级管理。
+通常，用户不需要手动直接创建 Pod，而是应该使用 controller（例如 [Deployments](deployment.md)），即使是在创建单个 Pod 的情况下。Controller 可以提供集群级别的自愈功能、复制和升级管理。
 
-使用集合API作为主要的面向用户的原语在集群调度系统中相对常见，包括[Borg](https://research.google.com/pubs/pub43438.html)、[Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)、[Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)和[Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)。
+使用集合 API 作为主要的面向用户的原语在集群调度系统中相对常见，包括 [Borg](https://research.google.com/pubs/pub43438.html)、[Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)、[Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema) 和 [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)。
 
 Pod 原语有利于：
 
@@ -86,7 +88,7 @@ Pod 原语有利于：
 - 将集群级功能与 Kubelet 级功能的清晰组合 ——Kubelet 实际上是 “pod 控制器”
 - 高可用性应用程序，它们可以在终止之前及在删除之前更换 pod，例如在计划驱逐、镜像预拉取或实时 pod 迁移的情况下[#3949](https://github.com/kubernetes/kubernetes/issues/3949)
 
-[StatefulSet](statefulset.md) 控制器支持有状态的Pod。在1.4版本中被称为PetSet。在kubernetes之前的版本中创建有状态pod的最佳方式是创建一个replica为1的replication controller。
+[StatefulSet](./statefulset.md) 控制器支持有状态的 Pod。在 1.4 版本中被称为 PetSet。在 kubernetes 之前的版本中创建有状态 pod 的最佳方式是创建一个 replica 为 1 的 replication controller。
 
 ## Pod 的终止
 
@@ -104,8 +106,7 @@ Pod 原语有利于：
 6. 过了宽限期后，将向 Pod 中依然运行的进程发送 SIGKILL 信号而杀掉进程。
 7. Kubelet 会在 API server 中完成 Pod 的的删除，通过将优雅周期设置为 0（立即删除）。Pod 在 API 中消失，并且在客户端也不可见。
 
-删除宽限期默认是30秒。 `kubectl delete`命令支持 `—grace-period=<seconds>` 选项，允许用户设置自己的宽限期。如果设置为0将强制删除pod。在kubectl>=1.5版本的命令中，你必须同时使用 `--force` 和 `--grace-period=0` 来强制删除pod。
-在 yaml 文件中可以通过 `{{ .spec.spec.terminationGracePeriodSeconds }}` 来修改此值。
+删除宽限期默认是 30 秒。 `kubectl delete` 命令支持 `—grace-period=<seconds>` 选项，允许用户设置自己的宽限期。如果设置为 0 将强制删除 pod。在 kubectl>=1.5 版本的命令中，你必须同时使用 `--force` 和 `--grace-period=0` 来强制删除 pod。 在 yaml 文件中可以通过 `{{ .spec.spec.terminationGracePeriodSeconds }}` 来修改此值。
 
 ### 强制删除 Pod
 
@@ -119,17 +120,10 @@ Pod的强制删除是通过在集群和etcd中将其定义为删除状态。当
 
 如果 master 节点运行的是 kuberentes1.1 或更高版本，而 node 节点的版本低于 1.1 版本，则 API server 将也可以接受新的特权模式的 pod，但是无法启动，pod 将处于 pending 状态。
 
-执行 `kubectl describe pod FooPodName`，可以看到为什么pod处于pending状态。输出的event列表中将显示： 
-`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'`
+执行 `kubectl describe pod FooPodName`，可以看到为什么 pod 处于 pending 状态。输出的 event 列表中将显示： `Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'`
 
 如果 master 节点的版本低于 1.1，无法创建特权模式的 pod。如果你仍然试图去创建的话，你得到如下错误：
 
-`The Pod "FooPodName" is invalid. spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'`
-
-## API Object
-
-Pod是kubernetes REST API中的顶级资源类型。
-
-在kuberentes1.6的V1 core API版本中的Pod的数据结构如下图所示：
-
-![Pod Cheatsheet](../images/kubernetes-pod-cheatsheet.png)
+```
+The Pod "FooPodName" is invalid. spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'
+```

concepts/scheduling.md

@@ -8,5 +8,5 @@ Kubernetes中的众多资源类型，例如Deployment、DaemonSet、StatefulSet
 
 考虑以下两种情况：
 
-- 集群中有新增节点，想要让集群中的节点的资源利用率比较均衡一些，想要将一些高负载的节点上的pod驱逐到新增节点上，这是kuberentes的scheduler所不支持的，需要使用如[descheduler](https://github.com/kubernetes-incubator/descheduler)这样的插件来实现。
-- 想要运行一些大数据应用，设计到资源分片，pod需要与数据分布达到一致均衡，避免个别节点处理大量数据，而其它节点闲置导致整个作业延迟，这时候可以考虑使用[kube-batch](https://github.com/kubernetes-incubator/kube-batch)。
+- 集群中有新增节点，想要让集群中的节点的资源利用率比较均衡一些，想要将一些高负载的节点上的 pod 驱逐到新增节点上，这是 kuberentes 的 scheduler 所不支持的，需要使用如 [descheduler](https://github.com/kubernetes-sigs/descheduler) 这样的插件来实现。
+- 想要运行一些大数据应用，设计到资源分片，pod 需要与数据分布达到一致均衡，避免个别节点处理大量数据，而其它节点闲置导致整个作业延迟，这时候可以考虑使用 [kube-batch](https://github.com/kubernetes-sigs/kube-batch)。

concepts/secret.md

@@ -4,9 +4,9 @@ Secret解决了密码、token、密钥等敏感数据的配置问题，而不需
 
 Secret 有三种类型：
 
-* **Service Account** ：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的`/run/secrets/kubernetes.io/serviceaccount`目录中；
-* **Opaque** ：base64编码格式的Secret，用来存储密码、密钥等；
-* **kubernetes.io/dockerconfigjson** ：用来存储私有docker registry的认证信息。
+- **Service Account** ：用来访问 Kubernetes API，由 Kubernetes 自动创建，并且会自动挂载到 Pod 的 `/run/secrets/kubernetes.io/serviceaccount` 目录中；
+- **Opaque** ：base64 编码格式的 Secret，用来存储密码、密钥等；
+- **kubernetes.io/dockerconfigjson** ：用来存储私有 docker registry 的认证信息。
 
 ## Opaque Secret
 
@@ -36,8 +36,8 @@ data:
 
 创建好 secret 之后，有两种方式来使用它：
 
-* 以Volume方式
-* 以环境变量方式
+- 以 Volume 方式
+- 以环境变量方式
 
 ### 将 Secret 挂载到 Volume 中
 
@@ -156,5 +156,3 @@ ca.crt
 namespace
 token
 ```
-
-

concepts/service-catalog.md

@@ -22,30 +22,27 @@ Service Catalog使用[Open Service Broker API](https://github.com/openservicebro
 
 Service Catalog 通过扩展 API 服务器和控制器实现，使用 etcd 进行存储。它还使用 Kubernetes 1.7 + 中提供的聚合层来呈现其 API。
 
-![Service Catalog Architecture](../images/service-catalog-architecture.jpg)
-
+![Service Catalog 架构](../images/service-catalog-architecture.jpg)
 
 ### API 资源
+
 Service Catalog 安装 servicecatalog.k8s.ioAPI 并提供以以下 Kubernetes 资源：
 
-* ClusterServiceBroker：作为service broker的群集内代理，封装其服务器连接详细信息。这些由集群运营者创建和管理，希望使用broker服务在其集群中提供新类型的托管服务。
-
-* ClusterServiceClass：由特定service broker提供的托管服务。将新ClusterServiceBroker资源添加到群集时，Service catalog controller将连接到service broker以获取可用托管服务的列表清单。然后它会创建新的ClusterServiceClass资源，与每个托管服务相对应。
-
-* ClusterServicePlan：托管服务的特定产品。例如，托管服务可能有不同的可用套餐，例如免费套餐或付费套餐，或者可能有不同的配置选项，例如使用SSD存储或拥有更多资源。同向群集添加ClusterServiceClass一样，当添加一个新的ClusterServiceBroker时，Service Catalog会创建一个新的ClusterServicePlan资源，与每个托管服务可用的每个服务套餐对应。
-
-* ServiceInstance：一个提供好的ClusterServiceClass实例。这些是由集群运营者创建的托管服务的特定实例，供一个或多个集群内应用程序使用。当创建一个新的ServiceInstance资源时，Service Catalog controller连接到相应的服务代理并指示它提供服务实例。
-
-* ServiceBinding：访问ServiceInstance的凭据。由想让他们的应用利用ServiceInstance的集群集运营者创建。创建之后，Service Catalog controller将创建一个与此服务实例对应的Kubernetes的Secret，包含此服务实例的连接详细信息和凭证 ，可以挂载到Pod中。
+- ClusterServiceBroker：作为 service broker 的群集内代理，封装其服务器连接详细信息。这些由集群运营者创建和管理，希望使用 broker 服务在其集群中提供新类型的托管服务。
+- ClusterServiceClass：由特定 service broker 提供的托管服务。将新 ClusterServiceBroker 资源添加到群集时，Service catalog controller 将连接到 service broker 以获取可用托管服务的列表清单。然后它会创建新的 ClusterServiceClass 资源，与每个托管服务相对应。
+- ClusterServicePlan：托管服务的特定产品。例如，托管服务可能有不同的可用套餐，例如免费套餐或付费套餐，或者可能有不同的配置选项，例如使用 SSD 存储或拥有更多资源。同向群集添加 ClusterServiceClass 一样，当添加一个新的 ClusterServiceBroker 时，Service Catalog 会创建一个新的 ClusterServicePlan 资源，与每个托管服务可用的每个服务套餐对应。
+- ServiceInstance：一个提供好的 ClusterServiceClass 实例。这些是由集群运营者创建的托管服务的特定实例，供一个或多个集群内应用程序使用。当创建一个新的 ServiceInstance 资源时，Service Catalog controller 连接到相应的服务代理并指示它提供服务实例。
+- ServiceBinding：访问 ServiceInstance 的凭据。由想让他们的应用利用 ServiceInstance 的集群集运营者创建。创建之后，Service Catalog controller 将创建一个与此服务实例对应的 Kubernetes 的 Secret，包含此服务实例的连接详细信息和凭证 ，可以挂载到 Pod 中。
 
 ### 鉴权认证
 
 Service Catalog 支持这些认证方法：
 
-* Basic (username/password)
-* [OAuth 2.0 Bearer Token](https://tools.ietf.org/html/rfc6750)
+- Basic (username/password)
+- [OAuth 2.0 Bearer Token](https://tools.ietf.org/html/rfc6750)
 
 ## 用法
+
 群集运营者可以使用 Service Catalog API 资源来提供托管服务，并使其在 Kubernetes 群集中可用。涉及的步骤是：
 
 1. 列出 Service Broker 提供的托管服务清单和服务套餐。
@@ -53,7 +50,7 @@ Service Catalog 支持这些认证方法：
 3. 绑定到托管服务，该服务返回连接凭证。
 4. 将连接凭证映射到应用程序中。
 
-### 列出托管服务和服务套餐
+### 列出托管服务和服务组
 
 首先，群集运营者必须在 servicecatalog.k8s.io 群组内创建 ClusterServiceBroker 资源。此资源包含访问服务代理端点所需的 URL 和连接详细信息。
 
@@ -72,32 +69,42 @@ spec:
   # with the service broker, such as bearer token info or a caBundle for TLS.
   #####
 ```
+
 以下是说明从一个 service broker 列出托管服务和套餐所涉及步骤的顺序图：
 
-![List Services](../images/service-catalog-list.jpg)
+![列出服务](../images/service-catalog-list.jpg)
 
 1. 将 ClusterServiceBroker 资源添加到 Service catalog 中，它会触发对外部 Service Broker 的调用以获取可用服务的清单。
+
 2. Service Broker 返回可用托管服务的清单和服务套餐的列表，它们分别在本地缓存为 `ClusterServiceClass` 资源和 `ClusterServicePlan` 资源。
+
 3. 然后，集群运营者可以使用以下命令获取可用托管服务的清单：
 
+   ```sh
    kubectl get clusterserviceclasses -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
+   ```
 
    它应该输出一个类似于以下格式的服务名称列表：
 
+   ```sh
     SERVICE NAME                           EXTERNAL NAME
     4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468   cloud-provider-service
     ...                                    ...
+   ```
 
    他们还可以使用以下命令查看可用的服务套餐：
 
+   ```sh
    kubectl get clusterserviceplans -o=custom-columns=PLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
+   ```
 
    它应该输出一个类似于以下格式的套餐名称列表：
 
+   ```sh
     PLAN NAME                              EXTERNAL NAME
     86064792-7ea2-467b-af93-ac9694d96d52   service-plan-name
     ...                                    ...
-
+   ```
 
 ### 提供新的实例
 
@@ -120,9 +127,10 @@ spec:
   # which may be used by the service broker.
   #####
 ```
+
 以下序列图说明了提供一个新的托管服务的实例所涉及的步骤：
 
-![Provision a Service](../images/service-catalog-provision.jpg)
+![启用一个服务](../images/service-catalog-provision.jpg)
 
 1. 当 `ServiceInstance` 资源创建后，Service Catalog 发起到外部 service broker 来提供服务的一个实例。
 2. service broker 创建托管服务的新实例并返回 HTTP 响应。
@@ -163,7 +171,7 @@ spec:
 
 绑定后，最后一步是将连接凭证和服务特定的信息映射到应用程序中。这些信息存储在secret中，应用程序可以用来访问并与托管服务连接。
 
-![Map connection credentials](../images/service-catalog-map.jpg)
+![映射连接凭证](../images/service-catalog-map.jpg)
 
 #### Pod 配置文件
 
@@ -202,11 +210,11 @@ spec:
 
 ## 下一步
 
-* 如果熟悉Helm Charts ，使用Helm将Service Catalog安装到Kubernetes集群中。或者，可以使用SC工具安装服务目录。
-* 查看 [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
-* 探索[kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 项目。
+- 如果熟悉 Helm Charts ，使用 Helm 将 Service Catalog 安装到 Kubernetes 集群中。或者，可以使用 SC 工具安装服务目录。
+- 查看 [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)。
+- 探索 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 项目。
 
-以上翻译自[官方文档](https://kubernetes.io/docs/concepts/service-catalog/)。
+以上翻译自[官方文档](https://kubernetes.io/docs/concepts/extend-kubernetes/service-catalog/)。
 
 ## Service Catalog 的安装 (利用 Helm) 和交互
 
@@ -226,9 +234,11 @@ Kubernetes 1.7或更高版本的集群运行 API Aggregator，它位于core API
 ## 前提条件
 
 ### Kubernetes 版本
+
 Service Catalog 需要 Kubernetes v1.7 或更高版本。您还需要 在主机上安装 [Kubernetes configuration file](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 。你需要这个文件，以便可以使用 kubectl 和 helm 与群集通信。许多 Kubernetes 安装工具或云提供商会为你设置此配置文件。有关详细信息，请与您的工具或提供商联系。
 
 #### `kubectl` 版本
+
 大多数与 Service Catalog 系统的交互都是通过 `kubectl` 命令行界面实现的。与群集版本一样，Service Catalog 需要 kubectl 版本 1.7 或更高版本。
 
 首先，检查 `kubectl` 版本：
@@ -236,6 +246,7 @@ Service Catalog需要Kubernetes v1.7或更高版本。您还需要 在主机上
 ```bash
 kubectl version
 ```
+
 确保 Kubernetes 版本和 kubectl 版本均为 1.7 或更高。
 
 如果需要升级客户端，请按照[安装说明](https://kubernetes.io/docs/tasks/kubectl/install/) 获取新的 `kubectl` 二进制文件。
@@ -246,6 +257,7 @@ kubectl version
 curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl
 chmod +x ./kubectl
 ```
+
 ### 群集内 DNS
 
 您需要启用 Kubernetes 集群内的 DNS。大多数常用的安装方法会为您自动配置群集内 DNS：
@@ -255,12 +267,15 @@ chmod +x ./kubectl
 - 大多数云提供商
 
 ### Helm
+
 使用 Helm 安装 Service Catalog ，需要 v2.7.0 或更高版本。请参阅以下步骤进行安装。
 
 #### 如果还没有安装 Helm
+
 如果尚未安装 Helm，请下载 [`helm` CLI](https://github.com/kubernetes/helm#install)，然后运行 helm init（这会将 Helm 的服务器端组件 Tiller 安装到 Kubernetes 群集中）。
 
 #### 如果已经安装了 Helm
+
 如果已经安装了 Helm，请运行 helm version 并确保客户端和服务器版本均为 v2.7.0 或更高。
 
 如果不是， 请安装[更新版本的 helm CLI](https://github.com/kubernetes/helm#install) 并运行 `helm init --upgrade`。
@@ -268,6 +283,7 @@ chmod +x ./kubectl
 有关安装的更多详细信息，请参阅 Helm 安装说明。
 
 #### Tiller 权限
+
 Tiller 是 Helm 的服务端组件。默认情况下， helm init 将 Tiller pod 安装到 kube-system 名称空间中，并将 Tiller 配置为使用 default 服务帐户（service account）。
 
 需要对 Tiller 进行配置 `cluster-admin` 权限，才能正确安装 Service Catalog：
@@ -277,7 +293,9 @@ kubectl create clusterrolebinding tiller-cluster-admin \
     --clusterrole=cluster-admin \
     --serviceaccount=kube-system:default
 ```
+
 ### Helm Repository 设置
+
 Service Catalog 很容易通过 Helm chart 安装 。
 
 此 chart 位于 chart repository 中。将此 repository 添加到本地计算机：
@@ -285,51 +303,62 @@ Service Catalog很容易通过 Helm chart 安装 。
 ```bash
 helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
 ```
+
 然后，确保 repository 已成功添加：
 
 ```bash
 helm search service-catalog
 ```
-应该看到以下输出：
 
+应该看到以下输出：
 
 ```bash
 NAME               VERSION    DESCRIPTION
 svc-cat/catalog    x,y.z      service-catalog API server and controller-manag...
 ```
+
 ### RBAC
+
 Kubernetes 群集必须启用 [RBAC](https://kubernetes.io/docs/admin/authorization/rbac/) 才能使用 Service Catalog。
 
 与群集内 DNS 一样，许多安装方法都有对应启用 RBAC 的途径。
 
 #### Minikube
+
 如果您正在使用 Minikube，请使用以下命令启动群集：
 
 ```bash
 minikube start --extra-config=apiserver.Authorization.Mode=RBAC
 ```
+
 #### hack/local-cluster-up.sh
+
 如果使用 [`hack/local-up-cluster.sh`](https://github.com/kubernetes/kubernetes/blob/master/hack/local-up-cluster.sh) 脚本，请使用以下命令启动群集：
 
 ```bash
 AUTHORIZATION_MODE=Node,RBAC hack/local-up-cluster.sh -O
 ```
+
 #### 云提供商
+
 许多云提供商为你启用了 RBAC 的新集群。有关详细信息，请查阅你的提供商的文档。
 
 ## 安装 Service Catalog
+
 集群和 Helm 配置正确，安装 Service Catalog 很简单：
 
 ```bash
 helm install svc-cat/catalog \
     --name catalog --namespace catalog
 ```
+
 ## 安装 Service Catalog CLI 客户端
+
 按照适用于操作系统的说明安装 svcat。二进制文件可以单独使用，也可以作为 kubectl 插件使用。
 
 ### MacOS
 
-```
+```sh
 curl -sLO https://download.svcat.sh/cli/latest/darwin/amd64/svcat
 chmod +x ./svcat
 mv ./svcat /usr/local/bin/
@@ -338,15 +367,16 @@ svcat version --client
 
 ### Linux
 
-```
+```sh
 curl -sLO https://download.svcat.sh/cli/latest/linux/amd64/svcat
 chmod +x ./svcat
 mv ./svcat /usr/local/bin/
 svcat version --client
 ```
-### Windows
-下面的片段仅在当前会话的PATH添加一个路径。后续使用需要将它相应的路径永久添加到PATH中。
 
+### Windows
+
+下面的片段仅在当前会话的 PATH 添加一个路径。后续使用需要将它相应的路径永久添加到 PATH 中。
 
 ```
 iwr 'https://download.svcat.sh/cli/latest/windows/amd64/svcat.exe' -UseBasicParsing -OutFile svcat.exe
@@ -356,18 +386,21 @@ svcat version --client
 ```
 
 ### 手动方式
+
 1. 对应操作系统下载相应的二进制文件：
-  * macOS: https://download.svcat.sh/cli/latest/darwin/amd64/svcat
-  * Windows: https://download.svcat.sh/cli/latest/windows/amd64/svcat.exe
-  * Linux: https://download.svcat.sh/cli/latest/linux/amd64/svcat
+   - [macOS](https://download.svcat.sh/cli/latest/darwin/amd64/svcat)
+   - [Windows](https://download.svcat.sh/cli/latest/windows/amd64/svcat.exe)
+   - [Linux](https://download.svcat.sh/cli/latest/linux/amd64/svcat)
 2. 使二进制文件可执行。
 3. 将二进制文件移动到 PATH 相应的目录。
 
 ### 插件方式使用客户端
+
 要将 svcat 用作插件，请在下载后运行以下命令：
 
 ```bash
 $ ./svcat install plugin
 Plugin has been installed to ~/.kube/plugins/svcat. Run kubectl plugin svcat --help for help using the plugin.
 ```
+
 当作为插件运行时，这些命令与添加全局 kubectl 配置标志相同。其中一个例外是，在插件模式下运行时不支持布尔标志，所以不要使用 `--flag`, 必须指定 `--flag=true`。

concepts/service.md

@@ -435,4 +435,4 @@ Kubernetes 最主要的哲学之一，是用户不应该暴露那些能够导致
 
 ## 更多信息
 
-- [使用 Service 连接 Frontend 到 Backend](https://kubernetes.io/docs/tutorials/connecting-apps/connecting-frontend-backend/)
+- [使用 Service 连接 Frontend 到 Backend - kubernetes.io](https://kubernetes.io/docs/tutorials/connecting-apps/connecting-frontend-backend/)

concepts/serviceaccount.md

@@ -205,4 +205,4 @@ spec:
 
 ## 参考
 
-- [Configure Service Accounts for Pods](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)
+- [Configure Service Accounts for Pods - kubernetes.io](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)

concepts/volume.md

@@ -711,6 +711,6 @@ spec:
 
 ## 参考
 
-- https://kubernetes.io/docs/concepts/storage/volumes/
+- [Volumes - kubernetes.io](https://kubernetes.io/docs/concepts/storage/volumes/)
 
-- [使用持久化卷来部署 WordPress 和 MySQL](https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)
+- [使用持久化卷来部署 WordPress 和 MySQL - kubernetes.io](https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)

guide/access-cluster.md

@@ -1,5 +1,7 @@
 # 访问集群
 
+本文列举了集中访问 Kubernetes 集群的方式。
+
 ## 第一次使用 kubectl 访问
 
 如果您是第一次访问 Kubernetes API 的话，我们建议您使用 Kubernetes 命令行工具：`kubectl`。

guide/access-kubernetes-cluster.md

@@ -1,8 +1,8 @@
 # 访问 Kubernetes 集群
 
-根据用户部署和暴露服务的方式不同，有很多种方式可以用来访问 kubernetes 集群。
+根据用户部署和暴露服务的方式不同，有很多种方式可以用来访问 Kubernetes 集群。
 
 - 最简单也是最直接的方式是使用 `kubectl` 命令。
 - 其次可以使用 `kubeconfig` 文件来认证授权访问 API server。
-- 通过各种 proxy 经过端口转发访问 kubernetes 集群中的服务
-- 使用 Ingress，在集群外访问 kubernetes 集群内的 service
+- 通过各种 proxy 经过端口转发访问 Kubernetes 集群中的服务
+- 使用 Ingress，在集群外访问 Kubernetes 集群内的 service

guide/accessing-kubernetes-pods-from-outside-of-the-cluster.md

@@ -1,6 +1,6 @@
 # 从外部访问 Kubernetes 中的 Pod
 
-前面几节讲到如何访问kubneretes集群，本文主要讲解访问kubenretes中的Pod和Serivce的几种方式，包括如下几种：
+前面几节讲到如何访问 Kubernetes 集群，本文主要讲解访问 Kubernetes 中的 Pod 和 Serivce 的几种方式，包括如下几种：
 
 - hostNetwork
 - hostPort
@@ -50,7 +50,7 @@ curl -v http://$POD_IP:8086/ping
 
 这是一种直接定义 Pod 网络的方式。
 
-`hostPort`是直接将容器的端口与所调度的节点上的端口路由，这样用户就可以通过宿主机的IP加上<hostPort>来访问Pod了，如<hostIP>:<hostPort>。
+`hostPort` 是直接将容器的端口与所调度的节点上的端口路由，这样用户就可以通过宿主机的 IP 加上来访问 Pod 了，如:。
 
 ```yaml
 apiVersion: v1
@@ -66,13 +66,13 @@ spec:
           hostPort: 8086
 ```
 
-这样做有个缺点，因为Pod重新调度的时候该Pod被调度到的宿主机可能会变动，这样<hostIP>就变化了，用户必须自己维护一个Pod与所在宿主机的对应关系。
+这样做有个缺点，因为 Pod 重新调度的时候该 Pod 被调度到的宿主机可能会变动，这样就变化了，用户必须自己维护一个 Pod 与所在宿主机的对应关系。
 
-这种网络方式可以用来做 nginx ingress controller。外部流量都需要通过kubenretes node节点的80和443端口。
+这种网络方式可以用来做 nginx ingress controller。外部流量都需要通过 Kubernetes node 节点的 80 和 443 端口。
 
 ## NodePort
 
-NodePort在kubenretes里是一个广泛应用的服务暴露方式。Kubernetes中的service默认情况下都是使用的`ClusterIP`这种类型，这样的service会产生一个ClusterIP，这个IP只能在集群内部访问，要想让外部能够直接访问service，需要将service type修改为 `nodePort`。
+NodePort 在 Kubernetes 里是一个广泛应用的服务暴露方式。Kubernetes 中的 service 默认情况下都是使用的 `ClusterIP` 这种类型，这样的 service 会产生一个 ClusterIP，这个 IP 只能在集群内部访问，要想让外部能够直接访问 service，需要将 service type 修改为 `nodePort`。
 
 ```yaml
 apiVersion: v1
@@ -166,7 +166,7 @@ spec:
 
 ## 总结
 
-总的来说Ingress是一个非常灵活和越来越得到厂商支持的服务暴露方式，包括Nginx、HAProxy、Traefik，还有各种Service Mesh，而其它服务暴露方式可以更适用于服务调试、特殊应用的部署。
+总的来说 Ingress 是一个非常灵活和越来越得到厂商支持的服务暴露方式，包括 Nginx、HAProxy、Traefik，还有各种 服务网格，而其它服务暴露方式可以更适用于服务调试、特殊应用的部署。
 
 ## 参考
 

guide/authentication.md

@@ -629,6 +629,7 @@ rules:
 #### 认证 API
 
 您可以使用 `certificates.k8s.io` API将 x509 证书配置为用于身份验证，如 [此处](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster) 所述。
-官方最新文档地址：https://kubernetes.io/docs/admin/authentication/
 
-译者：[Jimmy Song](https://jimmysong.io)
+## 参考
+
+- [Authenticating - kubernetes.io](https://kubernetes.io/docs/reference/access-authn-authz/authentication/)

guide/configure-liveness-readiness-probes.md

@@ -1,6 +1,6 @@
 # 配置Pod的liveness和readiness探针
 
-当你使用kubernetes的时候，有没有遇到过Pod在启动后一会就挂掉然后又重新启动这样的恶性循环？你有没有想过kubernetes是如何检测pod是否还存活？虽然容器已经启动，但是kubernetes如何知道容器的进程是否准备好对外提供服务了呢？让我们通过kubernetes官网的这篇文章[Configure Liveness and Readiness Probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)，来一探究竟。
+当你使用 Kubernetes 的时候，有没有遇到过 Pod 在启动后一会就挂掉然后又重新启动这样的恶性循环？你有没有想过 Kubernetes 是如何检测 pod 是否还存活？虽然容器已经启动，但是 Kubernetes 如何知道容器的进程是否准备好对外提供服务了呢？让我们通过 Kubernetes 官网的这篇文章 [Configure Liveness and Readiness Probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)，来一探究竟。
 
 本文将展示如何配置容器的存活和可读性探针。
 
@@ -159,8 +159,7 @@ http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
 kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/http-liveness.yaml
 ```
 
-After 10 seconds, view Pod events to verify that liveness probes have failed and
-the Container has been restarted:
+After 10 seconds, view Pod events to verify that liveness probes have failed and the Container has been restarted:
 
 10 秒后，查看 Pod 的 event，确认 liveness probe 失败并重启了容器。
 

guide/connecting-to-applications-port-forward.md

@@ -42,7 +42,6 @@
 
    ```
    6379
-
 ```
 
 ## 将本地端口转发到 Pod 中的端口
@@ -58,7 +57,6 @@
    ```
     I0710 14:43:38.274550    3655 portforward.go:225] Forwarding from 127.0.0.1:6379 -> 6379
     I0710 14:43:38.274797    3655 portforward.go:225] Forwarding from [::1]:6379 -> 6379
-
    ```
    
 2. 启动 Redis 命令行界面

guide/deploy-applications-in-kubernetes.md

@@ -1,4 +1,4 @@
-# 适用于kubernetes的应用开发部署流程
+# 适用于 Kubernetes 的应用开发部署流程
 
 本文讲解了如何开发容器化应用，并使用 Wercker 持续集成工具构建 docker 镜像上传到 docker 镜像仓库中，然后在本地使用 *docker-compose* 测试后，再使用 `kompose` 自动生成 kubernetes 的 yaml 文件，再将注入 Envoy sidecar 容器，集成 Istio service mesh 中的详细过程。
 
@@ -21,7 +21,7 @@ API文档见[k8s-app-monitor-test](https://github.com/rootsongjc/k8s-app-monitor
 
 我们知道 Kubernetes 在启动 Pod 的时候为容器注入环境变量，这些环境变量在所有的 namespace 中共享（环境变量是不断追加的，新启动的 Pod 中将拥有老的 Pod 中所有的环境变量，而老的 Pod 中的环境变量不变）。但是既然使用这些环境变量就已经可以访问到对应的 service，那么获取应用的地址信息，究竟是使用变量呢？还是直接使用 DNS 解析来发现？
 
-答案是使用DNS，详细说明见[Kubernetes中的服务发现与Docker容器间的环境变量传递源码探究](https://jimmysong.io/posts/exploring-kubernetes-env-with-docker/)。
+答案是使用 DNS，详细说明见[Kubernetes中的服务发现与Docker容器间的环境变量传递源码探究](https://jimmysong.io/blog/exploring-kubernetes-env-with-docker/)。
 
 ## 持续集成
 
@@ -65,7 +65,7 @@ services:
 docker-compose up
 ```
 
-在浏览器中访问<http://localhost:8888/k8s-app-monitor-test>就可以看到监控页面。
+在浏览器中访问 http://localhost:8888/k8s-app-monitor-test 就可以看到监控页面。
 
 ## 发布
 
@@ -77,7 +77,7 @@ docker-compose up
 
 **方式一**
 
-服务启动后需要更新ingress配置，在[ingress.yaml](../manifests/traefik-ingress/ingress.yaml)文件中增加以下几行：
+服务启动后需要更新 ingress 配置，在 [ingress.yaml](https://jimmysong.io/kubernetes-handbook/manifests/traefik-ingress/ingress.yaml) 文件中增加以下几行：
 
 ```yaml
   - host: k8s-app-monitor-agent.jimmysong.io
@@ -125,7 +125,7 @@ spec:
 
 ## 集成 Istio service mesh
 
-上一步中我们生成了kubernetes可读取的应用的YAML配置文件，我们可以将所有的YAML配置和并到同一个YAML文件中假如文件名为`k8s-app-monitor-istio-all-in-one.yaml`，如果要将其集成到Istio service mesh，只需要执行下面的命令。
+上一步中我们生成了 Kubernetes 可读取的应用的 YAML 配置文件，我们可以将所有的 YAML 配置和并到同一个 YAML 文件中假如文件名为 `k8s-app-monitor-istio-all-in-one.yaml`，如果要将其集成到 Istio service mesh，只需要执行下面的命令。
 
 ```bash
 kubectl apply -n default -f <(istioctl kube-inject -f k8s-app-monitor-istio-all-in-one.yaml)
@@ -135,13 +135,13 @@ kubectl apply -n default -f <(istioctl kube-inject -f k8s-app-monitor-istio-all-
 
 ## 验证
 
-如果您使用的是Traefik ingress来暴露的服务，那么在浏览器中访问<http://k8s-app-monitor-agent.jimmysong.io/k8s-app-monitor-agent>，可以看到如下的画面，每次刷新页面将看到新的柱状图。
+如果您使用的是 Traefik ingress 来暴露的服务，那么在浏览器中访问 http://k8s-app-monitor-agent.jimmysong.io/k8s-app-monitor-agent，可以看到如下的画面，每次刷新页面将看到新的柱状图。
 
 ![图表](../images/k8s-app-monitor-agent.jpg)
 
-使用[kubernetes-vagrant-centos-cluster](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster)来部署的kubernetes集群，该应用集成了Istio service mesh后可以通过<http://172.17.8.101:32000/k8s-app-monitor-agent>来访问。
+使用 [kubernetes-vagrant-centos-cluster](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster) 来部署的 kubernetes 集群，该应用集成了 Istio service mesh 后可以通过 http://172.17.8.101:32000/k8s-app-monitor-agent 来访问。
 
-在对*k8s-app-monitor-agent*服务进行了N此访问之后，再访问<http://grafana.istio.jimmysong.io>可以看到Service Mesh的监控信息。
+在对 *k8s-app-monitor-agent* 服务进行了 N 此访问之后，再访问 [http://grafana.istio.jimmysong.io](http://grafana.istio.jimmysong.io/) 可以看到 Service Mesh 的监控信息。
 
 ![Grafana页面](../images/k8s-app-monitor-istio-grafana.png)
 

guide/docker-cli-to-kubectl.md

@@ -1,6 +1,6 @@
-#  docker用户过渡到kubectl命令行指南
+#  Docker 用户过渡到 kubectl 命令行指南
 
-对于没有使用过 kubernetes 的 docker 用户，如何快速掌握 kubectl 命令？
+对于没有使用过 Kubernetes 的 Docker 用户，如何快速掌握 kubectl 命令？
 
 在本文中，我们将向 docker-cli 用户介绍 Kubernetes 命令行如何与 api 进行交互。该命令行工具——kubectl，被设计成 docker-cli 用户所熟悉的样子，但是它们之间又存在一些必要的差异。该文档将向您展示每个 docker 子命令和 kubectl 与其等效的命令。
 
@@ -266,4 +266,3 @@ Grafana is running at https://108.59.85.141/api/v1/namespaces/kube-system/servic
 Heapster is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
 InfluxDB is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy
 ```
-原文地址：https://github.com/rootsongjc/kubernetes.github.io/blob/master/docs/user-guide/docker-cli-to-kubectl.md

guide/index.md

@@ -7,8 +7,3 @@
 - 集群安全性管理
 - 如何访问 Kubernetes 集群
 - 如何在 Kubernetes 中开发部署应用
-
-
-
-
-

guide/ip-masq-agent.md

@@ -93,6 +93,7 @@ MASQUERADE  all  --  anywhere             anywhere             /* ip-masq-agent:
 
 默认情况下，在 GCE/GKE 中将启动 kubernetes 1.7.0 版本，ip-masq-agent 已经在集群中运行。如果您在其他环境中运行 kubernetes，那么您可以将 ip-masq-agent 以 [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) 的方式在集群中运行。
 
-原文地址：https://k8smeetup.github.io/docs/tasks/administer-cluster/ip-masq-agent/
+## 参考
+
+- [IP Masquerade Agent User Guide - kubernetes.io](https://kubernetes.io/docs/tasks/administer-cluster/ip-masq-agent/)
 
-译者：[rootsongjc](https://github.com/rootsongjc)

guide/kubectl-cheatsheet.md

@@ -291,9 +291,8 @@ $ kubectl taint nodes foo dedicated=special-user:NoSchedule
 
 ## 参考
 
-- [Kubectl 概览](https://kubernetes.io/docs/user-guide/kubectl-overview)
+- [Kubectl 概览 - kubernetes.io](https://kubernetes.io/docs/user-guide/kubectl-overview)
 
 
-- [JsonPath 手册](https://kubernetes.io/docs/user-guide/jsonpath)
-
-本文是对官方文档的中文翻译，原文地址：<https://kubernetes.io/docs/user-guide/kubectl-cheatsheet/>
+- [JsonPath 手册 - kubernetes.io](https://kubernetes.io/docs/user-guide/jsonpath)
+- [Cheatsheet - kubernetes.io](https://kubernetes.io/docs/user-guide/kubectl-cheatsheet/)

guide/kubelet-authentication-authorization.md

@@ -1,7 +1,5 @@
 # Kublet 的认证授权
 
-## 概览
-
 Kubelet 的 HTTPS 端点对外暴露了用于访问不同敏感程度数据的 API，并允许您在节点或者容器内执行不同权限级别的操作。
 
 本文档向您描述如何通过认证授权来访问 kubelet 的 HTTPS 端点。
@@ -47,7 +45,7 @@ kubelet 使用与 apiserver 相同的 [请求属性](https://kubernetes.io/docs/
 Verb（动词）是根据传入的请求的 HTTP 动词确定的：
 
 | HTTP 动词 | request 动词 |
-| --------- | ---------- |
+| --------- | ------------ |
 | POST      | create       |
 | GET, HEAD | get          |
 | PUT       | update       |

guide/kubernetes-desktop-client.md

@@ -1,4 +1,4 @@
-# Lens - Kubernetes IDE/桌面客户端
+# Lens - Kubernetes IDE
 
 [Lens](https://k8slens.dev/) 是一款开源的 Kubenretes IDE，也可以作为桌面客户端，官方网站 <https://k8slens.dev>，具有以下特性：
 

guide/managing-tls-in-a-cluster.md

@@ -1,6 +1,6 @@
 # 管理集群中的TLS
 
-在本书的最佳实践部分，我们在CentOS上部署了kuberentes集群，其中最开始又重要的一步就是创建TLS认证的，查看[创建TLS证书和秘钥](../practice/create-tls-and-secret-key.md)。很多人在进行到这一步时都会遇到各种各样千奇百怪的问题，这一步是创建集群的基础，我们有必要详细了解一下其背后的流程和原理。
+在本书的最佳实践部分，我们在 CentOS 上部署了 Kuberentes 集群，其中最开始又重要的一步就是创建 TLS 认证的，查看[创建TLS证书和秘钥](../practice/create-tls-and-secret-key.md)。很多人在进行到这一步时都会遇到各种各样千奇百怪的问题，这一步是创建集群的基础，我们有必要详细了解一下其背后的流程和原理。
 
 ## 概览
 
@@ -14,11 +14,11 @@
 
 以下部分演示如何为通过 DNS 访问的 Kubernetes 服务创建 TLS 证书。
 
-### 步骤0. 下载安装SSL
+### 下载安装SSL
 
-下载cfssl工具：[https://pkg.cfssl.org/](https://pkg.cfssl.org/).
+[下载 cfssl 工具](https://pkg.cfssl.org/)。
 
-### 步骤1. 创建证书签名请求
+### 创建证书签名请求
 
 通过运行以下命令生成私钥和证书签名请求（或 CSR）：
 
@@ -49,9 +49,9 @@ EOF
 2017/03/21 06:48:17 [INFO] encoded CSR
 ```
 
-此命令生成两个文件; 它生成包含PEM编码的[pkcs #10](https://tools.ietf.org/html/rfc2986)认证请求的`server.csr`，以及包含仍然要创建的证书的PEM编码密钥的`server-key.pem`。
+此命令生成两个文件；它生成包含 PEM 编码的 [pkcs #10](https://tools.ietf.org/html/rfc2986) 认证请求的 `server.csr`，以及包含仍然要创建的证书的 PEM 编码密钥的 `server-key.pem`。
 
-### 步骤2. 创建证书签名请求对象以发送到Kubernetes API
+### 创建证书签名请求对象以发送到 Kubernetes API
 
 使用以下命令创建 CSR yaml 文件，并发送到 API server：
 
@@ -94,11 +94,11 @@ Subject Alternative Names:
 Events: <none>
 ```
 
-### 步骤3. 获取证书签名请求
+### 获取证书签名请求
 
 批准证书签名请求是通过自动批准过程完成的，或由集群管理员一次完成。 有关这方面涉及的更多信息，请参见下文。
 
-### 步骤4. 下载签名并使用
+### 下载签名并使用
 
 一旦 CSR 被签署并获得批准，您应该看到以下内容：
 

guide/resource-quota-management.md

@@ -6,7 +6,7 @@
 
 目前有两种资源分配管理相关的控制策略插件 `ResourceQuota` 和 `LimitRange`。
 
-要启用它们只要 API Server 的启动配置的 `KUBE_ADMISSION_CONTROL` 参数中加入了 `ResourceQuota` 的设置，这样就给集群开启了资源配额限制功能，加入 `LimitRange` 可以用来限制一个资源申请的范围限制，参考 [为 namesapce 配置默认的内存请求与限额](https://k8smeetup.github.io/docs/tasks/administer-cluster/memory-default-namespace/) 和 [在 namespace 中配置默认的CPU请求与限额](https://k8smeetup.github.io/docs/tasks/administer-cluster/cpu-default-namespace/)。
+要启用它们只要 API Server 的启动配置的 `KUBE_ADMISSION_CONTROL` 参数中加入了 `ResourceQuota` 的设置，这样就给集群开启了资源配额限制功能，加入 `LimitRange` 可以用来限制一个资源申请的范围限制，参考 [为 namesapce 配置默认的内存请求与限额](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) 和 [在 namespace 中配置默认的CPU请求与限额](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。
 
 两种控制策略的作用范围都是对于某一 namespace，`ResourceQuota` 用来限制 namespace 中所有的 Pod 占用的总的资源 request 和 limit，而 `LimitRange` 是用来设置 namespace 中 Pod 的默认的资源 request 和 limit 值。
 
@@ -16,7 +16,7 @@
 - 存储资源配额
 - 对象数量配额
 
-关于资源配额的详细信息请参考 kubernetes 官方文档 [资源配额](https://k8smeetup.github.io/docs/concepts/policy/resource-quotas/)。
+关于资源配额的详细信息请参考 Kubernetes 官方文档 [资源配额](https://kubernetes.io/docs/concepts/policy/resource-quotas/)。
 
 ## 示例
 
@@ -94,6 +94,6 @@ spec:
 
 ## 参考
 
-- [资源配额](https://k8smeetup.github.io/docs/concepts/policy/resource-quotas/)
-- [为命名空间配置默认的内存请求与限额](https://k8smeetup.github.io/docs/tasks/administer-cluster/memory-default-namespace/)
-- [在命名空间中配置默认的CPU请求与限额](https://k8smeetup.github.io/docs/tasks/administer-cluster/cpu-default-namespace/)
+- [资源配额 - kubernetes.io](https://kubernetes.io/docs/concepts/policy/resource-quotas/)
+- [为命名空间配置默认的内存请求与限额 - kubernetes.io](https://kubernetes.io/docs/tasks/administer-cluster/memory-default-namespace/)
+- [在命名空间中配置默认的 CPU 请求与限额 - kubernetes.io](https://kubernetes.io/docs/tasks/administer-cluster/cpu-default-namespace/)

guide/secret-configuration.md

@@ -577,5 +577,3 @@ Pod 中有多个容器。但是，pod 中的每个容器必须请求其挂载卷
 - 可以创建和使用 secret 的 pod 的用户也可以看到该 secret 的值。即使 API server 策略不允许用户读取 secret 对象，用户也可以运行暴露 secret 的 pod。
 - 如果运行了多个副本，那么这些 secret 将在它们之间共享。默认情况下，etcd 不能保证与 SSL/TLS 的对等通信，尽管可以进行配置。
 - 目前，任何节点的 root 用户都可以通过模拟 kubelet 来读取 API server 中的任何 secret。只有向实际需要它们的节点发送 secret 才能限制单个节点的根漏洞的影响，该功能还在计划中。
-
-原文地址：https://github.com/rootsongjc/kubernetes.github.io/blob/master/docs/concepts/configuration/secret.md

guide/using-etcdctl-to-access-kubernetes-data.md

@@ -1,4 +1,4 @@
-# 使用etcdctl访问kubernetes数据
+# 使用 etcdctl 访问 Kubernetes 数据
 
 Kubenretes1.6 中使用 etcd V3 版本的 API，使用 `etcdctl` 直接 `ls` 的话只能看到 `/kube-centos` 一个路径。需要在命令前加上 `ETCDCTL_API=3` 这个环境变量才能看到 kuberentes 在 etcd 中保存的数据。
 
@@ -197,8 +197,3 @@ statefulsets
 storageclasses
 thirdpartyresources
 ```
-
-## 参考
-
-- [etcd中文文档](https://github.com/doczhcn/etcd)
-- [etcd官方文档](https://coreos.com/etcd/docs/latest/)

guide/using-kubectl.md

@@ -23,7 +23,7 @@ Kubectl的子命令主要分为8个类别：
 
 ![增加kubeclt命令的工具（图片来自网络）](../images/tools-to-supercharge-kubectl.jpg)
 
-- [kubectx](https://github.com/ahmetb/kubectx)：用于切换kubernetes context
+- [kubectx](https://github.com/ahmetb/kubectx)：用于切换 Kubernetes context
 - [kube-ps1](https://github.com/jonmosco/kube-ps1)：为命令行终端增加`$PROMPT`字段
 - [kube-shell](https://github.com/cloudnativelabs/kube-shell)：交互式带命令提示的 kubectl 终端
 
@@ -31,7 +31,7 @@ Kubectl的子命令主要分为8个类别：
 
 ![增强的kubectl命令](../images/supercharged-kubectl.jpg)
 
-### kube-shell
+kube-shell
 
 开源项目 [kube-shell](https://github.com/cloudnativelabs/kube-shell) 可以为 kubectl 提供自动的命令提示和补全，使用起来特别方便，推荐给大家。
 
@@ -74,4 +74,6 @@ source <(kubectl completion zsh)
 
 保存后重启终端即可生效。
 
-参考：[Install and Set Up kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#using-zsh)
+## 参考
+
+- [Install and Set Up kubectl - kubernetes.io](https://kubernetes.io/docs/tasks/tools/install-kubectl/#using-zsh)

guide/using-statefulset.md

@@ -16,9 +16,7 @@ Dockerfile中从远程获取zookeeper的安装文件，然后在定义了三个
 - zkMetrics.sh：获取 zookeeper 的 metrics
 - zkOk.sh：用来做 ReadinessProb
 
-我们在来看下这三个脚本的执行结果：
-
-zkGenConfig.sh
+我们在来看下这三个脚本的执行结果。
 
 zkMetrics.sh 脚本实际上执行的是下面的命令：
 
@@ -53,7 +51,7 @@ imok
 
 **zookeeper.yaml**
 
-下面是启动三个zookeeper实例的yaml配置文件：
+下面是启动三个 zookeeper 实例的 YAML 配置文件：
 
 ```yaml
 ---
@@ -228,7 +226,7 @@ sed -i s'/zookeeper.connect=localhost:2181/zookeeper.connect=zk-0.zk-svc.brand.s
 
 **Kafka.yaml**
 
-下面是创建3个kafka实例的yaml配置。
+下面是创建 3 个 kafka 实例的 YAML 配置。
 
 ```yaml
 ---
@@ -322,5 +320,4 @@ spec:
 
 ## 参考
 
-- https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
-- [kubernetes contrib - statefulsets](https://github.com/kubernetes/contrib/tree/master/statefulsets)
+- [StatefulSet - kubernetes.i](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)

practice/configuring-dns.md

@@ -326,7 +326,7 @@ Kubernetes 1.3 版本起引入了支持多站点 Kubernetes 安装的集群联
 
 ## 参考
 
-- [Configure DNS Service](https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/)
-- [Service 和 Pod 的 DNS](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/)
-- [自动扩容集群中的 DNS 服务](https://kubernetes.io/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)
-- [Using CoreDNS for Service Discovery](https://kubernetes.io/docs/tasks/administer-cluster/coredns/)
+- [Configure DNS Service - kubernetes.io](https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/)
+- [Service 和 Pod 的 DNS - kubernetes.io](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/)
+- [自动扩容集群中的 DNS 服务 - kubernetes.io](https://kubernetes.io/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)
+- [Using CoreDNS for Service Discovery - kubernetes.io](https://kubernetes.io/docs/tasks/administer-cluster/coredns/)

practice/coredns.md

@@ -1,14 +1,12 @@
 # 安装配置 CoreDNS
 
-CoreDNS可以在具有标准的Kube-DNS的Kubernetes集群中运行。作为Kubernetes 的插件使用，CoreDNS将从
-Kubernetes集群中读取区（zone）数据。它实现了为Kubernetes的DNS服务发现定义的规范：[Kubernetes DNS-Based Service Discovery](https://github.com/kubernetes/dns/blob/master/docs/specification.md)。
+CoreDNS 可以在具有标准的 Kube-DNS 的 Kubernetes 集群中运行。作为 Kubernetes 的插件使用，CoreDNS 将从 Kubernetes 集群中读取区（zone）数据。它实现了为 Kubernetes 的 DNS 服务发现定义的规范：[Kubernetes DNS-Based Service Discovery](https://github.com/kubernetes/dns/blob/master/docs/specification.md)。
 
 ## 部署 CoreDNS
 
 部署 CoreDNS 需要使用到官方提供的两个文件 [deploy.sh](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh) 和 [coredns.yaml.sed](https://github.com/coredns/deployment/blob/master/kubernetes/coredns.yaml.sed)（这两个文件已经放入 manifest 的 coredns 目录中）
 
-`deploy.sh` 是一个用于在已经运行kube-dns的集群中生成运行CoreDNS部署文件（manifest）的工具脚本。它使用 `coredns.yaml.sed`文件作为模板，创建一个ConfigMap和CoreDNS的deployment，然后更新集群中已有的kube-dns
-服务的selector使用CoreDNS的deployment。重用已有的服务并不会在服务的请求中发生冲突。
+`deploy.sh` 是一个用于在已经运行 kube-dns 的集群中生成运行 CoreDNS 部署文件（manifest）的工具脚本。它使用 `coredns.yaml.sed` 文件作为模板，创建一个 ConfigMap 和 CoreDNS 的 deployment，然后更新集群中已有的 kube-dns 服务的 selector 使用 CoreDNS 的 deployment。重用已有的服务并不会在服务的请求中发生冲突。
 
 `deploy.sh` 文件并不会删除 kube-dns 的 deployment 或者 replication controller。如果要删除 kube-dns，你必须在部署 CoreDNS 后手动的删除 kube-dns。
 
@@ -26,9 +24,10 @@ $ kubectl delete --namespace=kube-system deployment kube-dns
 注意：我们建议在部署 CoreDNS 后删除 kube-dns。否则如果 CoreDNS 和 kube-dns 同时运行，服务查询可能会随机的在 CoreDNS 和 kube-dns 之间产生。
 
 对于非 RBAC 部署，你需要编辑生成的结果 yaml 文件：
+
 1. 从 yaml 文件的 `Deployment` 部分删除 `serviceAccountName: coredns`
 2. 删除 `ServiceAccount`、 `ClusterRole` 和 `ClusterRoleBinding` 部分
 
 ## 参考
 
-- [Kubernetes DNS-Based Service Discovery](https://github.com/kubernetes/dns/blob/master/docs/specification.md)
+- [Kubernetes DNS-Based Service Discovery - github.com](https://github.com/kubernetes/dns/blob/master/docs/specification.md)

practice/create-tls-and-secret-key.md

@@ -1,7 +1,5 @@
 # 创建 TLS 证书和秘钥
 
-## 前言
-
 执行下列步骤前建议你先阅读以下内容：
 
 - [管理集群中的TLS](../guide/managing-tls-in-a-cluster.md)：教您如何创建TLS证书
@@ -404,6 +402,5 @@ cp *.pem /etc/kubernetes/ssl
 
 ## 参考
 
-+ [Generate self-signed certificates](https://coreos.com/os/docs/latest/generate-self-signed-certificates.html)
-+ [Client Certificates V/s Server Certificates](https://blogs.msdn.microsoft.com/kaushal/2012/02/17/client-certificates-vs-server-certificates/)
-+ [TLS bootstrap 引导程序](../guide/tls-bootstrapping.md)
++ [Generate self-signed certificates - coreos.com](https://coreos.com/os/docs/latest/generate-self-signed-certificates.html)
++ [Client Certificates V/s Server Certificates - blogs.msdn.microsoft.com](https://blogs.msdn.microsoft.com/kaushal/2012/02/17/client-certificates-vs-server-certificates/)

practice/distributed-load-test.md

@@ -1,16 +1,14 @@
 ## 分布式负载测试
 
-该教程描述如何在[Kubernetes](http://kubernetes.io)中进行分布式负载均衡测试，包括一个web应用、docker镜像和Kubernetes controllers/services。关于分布式负载测试的更多资料请查看[Distributed Load Testing Using Kubernetes](http://cloud.google.com/solutions/distributed-load-testing-using-kubernetes) 。
+该教程描述如何在 [Kubernetes](https://kubernetes.io/) 中进行分布式负载均衡测试，包括一个 web 应用、docker 镜像和 Kubernetes controllers/services。关于分布式负载测试的更多资料请查看 [Distributed Load Testing Using Kubernetes](https://cloud.google.com/solutions/distributed-load-testing-using-kubernetes) 。
 
 ## 准备
 
-**不需要GCE及其他组件，你只需要有一个kubernetes集群即可。**
-
-如果你还没有kubernetes集群，可以参考[kubernetes-handbook](https://www.gitbook.com/book/rootsongjc/kubernetes-handbook)部署一个。
+不需要 GCE 及其他组件，你只需要有一个 kubernetes 集群即可。
 
 ## 部署 Web 应用
 
-本文中使用的镜像、kubernetes应用的yaml配置来自我的另一个项目，请参考：https://github.com/rootsongjc/distributed-load-testing-using-kubernetes
+本文中使用的镜像、kubernetes 应用的 yaml 配置来自我的另一个项目，请参考 [GitHub](https://github.com/rootsongjc/distributed-load-testing-using-kubernetes)。
 
 `sample-webapp` 目录下包含一个简单的 web 测试应用。我们将其构建为 docker 镜像，在 kubernetes 中运行。
 
@@ -46,6 +44,7 @@ $ docker push jimmysong/locust-tasks:latest
 ```ini
 image: jimmysong/locust-tasks:latest
 ```
+
 ### 部署 locust-master
 
 ```bash
@@ -60,18 +59,20 @@ Now deploy `locust-worker-controller`:
 ```bash
 $ kubectl create -f locust-worker-controller.yaml
 ```
+
 你可以很轻易的给 work 扩容，通过命令行方式：
 
 ```bash
 $ kubectl scale --replicas=20 replicationcontrollers locust-worker
 ```
+
 当然你也可以通过 WebUI：Dashboard - Workloads - Replication Controllers - **ServiceName** - Scale 来扩容。
 
 ![使用 dashboard 来扩容](../images/dashbaord-scale.jpg)
 
 ### 配置Traefik
 
-参考[kubernetes的traefik ingress安装](https://jimmysong.io/posts/traefik-ingress-installation/)，在`ingress.yaml`中加入如下配置：
+参考 [Kubernetes 的 traefik ingress 安装](https://jimmysong.io/posts/traefik-ingress-installation/)，在 `ingress.yaml` 中加入如下配置：
 
 ```yaml
   - host: traefik.locust.io

practice/efk-addon-installation.md

@@ -11,7 +11,7 @@ es-controller.yaml  es-service.yaml  fluentd-es-ds.yaml  kibana-controller.yaml
 
 同样 EFK 服务也需要一个`efk-rbac.yaml`文件，配置 serviceaccount 为 `efk`。
 
-已经修改好的 yaml 文件见：[../manifests/EFK](https://github.com/rootsongjc/kubernetes-handbook/blob/master/manifests/EFK)
+已经修改好的 YAML 文件见：[../manifests/EFK](https://github.com/rootsongjc/kubernetes-handbook/blob/master/manifests/EFK)
 
 
 ## 配置 es-controller.yaml
@@ -26,7 +26,7 @@ $ diff es-controller.yaml.orig es-controller.yaml
 
 ## 配置 es-service.yaml
 
-无需配置；
+无需配置。
 
 ## 配置 fluentd-es-ds.yaml
 
@@ -96,7 +96,7 @@ elasticsearch-logging   10.254.77.62    <none>        9200/TCP
 kibana-logging          10.254.8.113    <none>        5601/TCP                        2m
 ```
 
-kibana Pod 第一次启动时会用较长时间(10-20分钟)来优化和 Cache 状态页面，可以 tailf 该 Pod 的日志观察进度：
+Kibana Pod 第一次启动时会用较长时间(10-20分钟)来优化和 Cache 状态页面，可以 tailf 该 Pod 的日志观察进度：
 
 ``` bash
 $ kubectl logs kibana-logging-1432287342-0gdng -n kube-system -f

practice/flannel-installation.md

@@ -1,4 +1,4 @@
-## 安装flannel网络插件
+# 安装 flannel 网络插件
 
 所有的 node 节点都需要安装网络插件才能让所有的 Pod 加入到同一个局域网中，本文是安装 flannel 网络插件的参考文档。
 
@@ -72,7 +72,7 @@ etcdctl --endpoints=https://172.20.0.113:2379,https://172.20.0.114:2379,https://
 
 如果你要使用 `host-gw` 模式，可以直接将 vxlan 改成 `host-gw` 即可。
 
-**注**：参考[网络和集群性能测试](network-and-cluster-perfermance-test.md)那节，最终我们使用的`host-gw`模式，关于flannel支持的backend模式见：<https://github.com/coreos/flannel/blob/master/Documentation/backends.md>。
+**注**：参考[网络和集群性能测试](network-and-cluster-perfermance-test.md)那节，最终我们使用的 `host-gw` 模式，关于 flannel 支持的 backend 模式见 [GitHub](https://github.com/coreos/flannel/blob/master/Documentation/backends.md)。
 
 **启动 flannel**
 

practice/heapster-addon-installation.md

@@ -1,5 +1,7 @@
 # 安装 heapster 插件
 
+注：Heapster 已不再维护。
+
 ## 准备镜像
 
 官方镜像保存在 gcr.io 中需要翻墙才能下载，请自行拷贝到私有仓库。
@@ -43,7 +45,7 @@ $ diff grafana-deployment.yaml.orig grafana-deployment.yaml
 >           #value: /
 ```
 
-+ 如果后续使用 kube-apiserver 或者 kubectl proxy 访问 grafana dashboard，则必须将 `GF_SERVER_ROOT_URL` 设置为 `/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana/`，否则后续访问grafana时访问时提示找不到`http://172.20.0.113:8086/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana/api/dashboards/home` 页面；
+如果后续使用 kube-apiserver 或者 kubectl proxy 访问 grafana dashboard，则必须将 `GF_SERVER_ROOT_URL` 设置为 `/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana/`，否则后续访问grafana时访问时提示找不到`http://172.20.0.113:8086/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana/api/dashboards/home` 页面；
 
 
 ## 配置 heapster-deployment
@@ -106,7 +108,7 @@ $ diff influxdb-service.yaml.orig influxdb-service.yaml
 >     name: admin
 ```
 
-- 定义端口类型为 NodePort，额外增加了 admin 端口映射，用于后续浏览器访问 influxdb 的 admin UI 界面；
+定义端口类型为 NodePort，额外增加了 admin 端口映射，用于后续浏览器访问 influxdb 的 admin UI 界面；
 
 ## 执行所有定义文件
 
@@ -190,7 +192,7 @@ monitoring-influxdb-1411048194-lzrpc    1/1       Running   0          2m
 
 获取 influxdb http 8086 映射的 NodePort
 
-```
+```sh
 $ kubectl get svc -n kube-system|grep influxdb
 monitoring-influxdb    10.254.22.46    <nodes>       8086:32299/TCP,8083:30269/TCP   9m
 ```
@@ -199,7 +201,7 @@ monitoring-influxdb    10.254.22.46    <nodes>       8086:32299/TCP,8083:30269/T
 
 在页面的 “Connection Settings” 的 Host 中输入 node IP， Port 中输入 8086 映射的 nodePort 如上面的 32299，点击 “Save” 即可（我的集群中的地址是172.20.0.113:32299）：
 
-![kubernetes-influxdb-heapster](../images/kubernetes-influxdb-heapster.jpg)
+![Influxdb 页面](../images/kubernetes-influxdb-heapster.jpg)
 
 ## 注意
 
@@ -208,7 +210,3 @@ monitoring-influxdb    10.254.22.46    <nodes>       8086:32299/TCP,8083:30269/T
 ![修改grafana模板](../images/grafana-dashboard-setting.jpg)
 
 将 Templating 中的 namespace 的 Data source 设置为 influxdb-datasource，Refresh 设置为 on Dashboard Load 保存设置，刷新浏览器，即可看到其他 namespace 选项。
-
-## 参考
-
-[使用Heapster获取集群对象的metric数据](../practice/using-heapster-to-get-object-metrics.md)

practice/index.md

@@ -1,6 +1,6 @@
 # 最佳实践概览
 
-本章节从零开始创建我们自己的kubernetes集群，并在该集群的基础上，配置服务发现、负载均衡和日志收集等功能，使我们的集群能够成为一个真正线上可用、功能完整的集群。
+本章节从零开始手动创建我们自己的 Kubernetes 集群，并在该集群的基础上，配置服务发现、负载均衡和日志收集等功能，使我们的集群能够成为一个真正线上可用、功能完整的集群。
 
 - 第一部分[ 在CentOS上部署kubernetes集群](install-kubernetes-on-centos.md)中介绍了如何通过二进制文件在 CentOS 物理机（也可以是公有云主机）上快速部署一个 kubernetes 集群。
 - 第二部分介绍如何在 kubernetes 中的服务发现与负载均衡。
@@ -10,6 +10,3 @@
 - 第六部分介绍 kuberentes 中的服务编排与管理。
 - 第七部分介绍如何基于 kubernetes 做持续集成与发布。
 - 第八部分是 kubernetes 集群与插件的更新升级。
-
-
-

practice/install-kubernetes-on-centos.md

@@ -1,16 +1,16 @@
-# 在CentOS上部署kubernetes集群
+# 在 CentOS 上部署 Kubernetes 集群
 
 > 本文档最初是基于 kubenetes1.6 版本编写的，对于 kuberentes1.8 及以上版本同样适用，只是个别位置有稍许变动，变动的地方我将特别注明版本要求。
 
-本系列文档介绍使用二进制部署 `kubernetes` 集群的所有步骤，而不是使用 `kubeadm` 等自动化方式来部署集群，同时开启了集群的TLS安全认证，该安装步骤适用于所有bare metal环境、on-premise环境和公有云环境。
+本系列文档介绍使用二进制部署 `Kubernetes` 集群的所有步骤，而不是使用 `kubeadm` 等自动化方式来部署集群，同时开启了集群的 TLS 安全认证，该安装步骤适用于所有 bare metal 环境、on-premise 环境和公有云环境。
 
->  如果您想快速的在自己电脑的本地环境下使用虚拟机来搭建kubernetes集群，可以参考[本地分布式开发环境搭建（使用Vagrant和Virtualbox）](../develop/using-vagrant-and-virtualbox-for-development.md)。
+>  如果您想快速的在自己电脑的本地环境下使用虚拟机来搭建 Kubernetes 集群，可以参考 [本地分布式开发环境搭建（使用 Vagrant 和 Virtualbox）](../develop/using-vagrant-and-virtualbox-for-development.md)。
 
 在部署的过程中，将详细列出各组件的启动参数，给出配置文件，详解它们的含义和可能遇到的问题。
 
 部署完成后，你将理解系统各组件的交互原理，进而能快速解决实际问题。
 
-所以本文档主要适合于那些有一定 kubernetes 基础，想通过一步步部署的方式来学习和了解系统配置、运行原理的人。
+所以本文档主要适合于那些有一定 Kubernetes 基础，想通过一步步部署的方式来学习和了解系统配置、运行原理的人。
 
 **注：本文档中不包括 docker 和私有镜像仓库的安装，安装说明中使用的镜像来自 Google Cloud Platform，中国大陆用户若无法访问请自行选择其他镜像仓库备份。**
 
@@ -21,7 +21,7 @@
 集群安装时所有组件用到的配置文件，包含在以下目录中：
 
 -**etc**：service 的环境变量配置文件
-- **manifest**：kubernetes应用的yaml文件
+-**manifest**：Kubernetes 应用的 yaml 文件
 -**systemd**：systemd serivce 配置文件
 
 ## 集群详情
@@ -31,7 +31,7 @@
 + Docker：建议使用 Docker CE，**请勿使用 docker-1.13.1-84.git07f3374.el7.centos.x86_64 版本**，[查看详情](https://jimmysong.io/posts/docker-exec-bug-on-centos7/)
 + Etcd 3.1.5
 + Flannel 0.7.1 vxlan 或者 host-gw 网络
-+ TLS 认证通信 (所有组件，如 etcd、kubernetes master 和 node)
++ TLS 认证通信 (所有组件，如 etcd、Kubernetes master 和 node)
 + RBAC 授权
 + kubelet TLS BootStrapping
 + kubedns、dashboard、heapster (influxdb、grafana)、EFK (elasticsearch、fluentd、kibana) 集群插件
@@ -39,7 +39,7 @@
 
 ## 环境说明
 
-在下面的步骤中，我们将在三台CentOS系统的物理机上部署具有三个节点的kubernetes1.6.0集群。
+在下面的步骤中，我们将在三台 CentOS 系统的物理机上部署具有三个节点的 Kubernetes1.6.0 集群。
 
 角色分配如下：
 
@@ -49,7 +49,7 @@
 
 **Node**：172.20.0.113、172.20.0.114、172.20.0.115
 
-注意：172.20.0.113这台主机master和node复用。所有生成证书、执行kubectl命令的操作都在这台节点上执行。一旦node加入到kubernetes集群之后就不需要再登陆node节点了。
+注意：172.20.0.113 这台主机 master 和 node 复用。所有生成证书、执行 kubectl 命令的操作都在这台节点上执行。一旦 node 加入到 Kubernetes 集群之后就不需要再登陆 node 节点了。
 
 ## 安装前的准备
 
@@ -93,6 +93,8 @@
 
 1. 由于启用了 TLS 双向认证、RBAC 授权等严格的安全机制，建议**从头开始部署**，而不要从中间开始，否则可能会认证、授权等失败！
 2. 部署过程中需要有很多证书的操作，请大家耐心操作，不明白的操作可以参考本书中的其他章节的解释。
-3. 该部署操作仅是搭建成了一个可用 kubernetes 集群，而很多地方还需要进行优化，heapster 插件、EFK 插件不一定会用于真实的生产环境中，但是通过部署这些插件，可以让大家了解到如何部署应用到集群上。
+3. 该部署操作仅是搭建成了一个可用 Kubernetes 集群，而很多地方还需要进行优化，heapster 插件、EFK 插件不一定会用于真实的生产环境中，但是通过部署这些插件，可以让大家了解到如何部署应用到集群上。
 
-**注：本安装文档参考了 [opsnull 跟我一步步部署 kubernetes 集群](https://github.com/opsnull/follow-me-install-kubernetes-cluster/)**
+## 参考
+
+- [opsnull 跟我一步步部署 kubernetes 集群 - github.com](https://github.com/opsnull/follow-me-install-kubernetes-cluster/)

practice/install-kubernetes-on-ubuntu-server-16.04-with-kubeadm.md

@@ -6,11 +6,10 @@
 
 ## 概述
 
-本次安装建议至少4台服务器或者虚拟机，每台服务器4G内存，2个CPU核心以上，基本架构为1台master节点，3台slave节点。整个安装过程将在Ubuntu服务器上安装完kubeadm，以及安装kubernetes的基本集群，包括canal网络，另后台存储可参考本书的最佳实践中的存储管理内容。
-本次安装一共4个节点，节点信息如下:
+本次安装建议至少 4 台服务器或者虚拟机，每台服务器 4G 内存，2 个 CPU 核心以上，基本架构为 1 台 master 节点，3 台 slave 节点。整个安装过程将在 Ubuntu 服务器上安装完 kubeadm，以及安装 kubernetes 的基本集群，包括 canal 网络，另后台存储可参考本书的最佳实践中的存储管理内容。 本次安装一共 4 个节点，节点信息如下:
 
 | 角色   | 主机名        | IP 地址       |
-|----------|-----------       |------------|
+| ------ | ------------- | ------------- |
 | Master | Ubuntu-master | 192.168.5.200 |
 | Slave  | ubuntu-1      | 192.168.5.201 |
 | Slave  | ubuntu-2      | 192.168.5.202 |
@@ -28,10 +27,26 @@
 192.168.0.201   Ubuntu-1
 192.168.0.202   Ubuntu-2
 192.168.0.203   Ubuntu-3
+```
+
+- 如果连接 gcr 网站不方便，无法下载镜像，会导致安装过程卡住，可以下载我导出的镜像包，
+
+  我导出的镜像网盘链接
+
+  ，解压缩以后是多个个 tar 包，使用
+
+   
 
   ```
-* 如果连接gcr网站不方便，无法下载镜像，会导致安装过程卡住，可以下载我导出的镜像包，[我导出的镜像网盘链接](https://pan.baidu.com/s/1ZJFRt_UNCQvwcu9UENr_gw)，解压缩以后是多个个tar包，使用```docker load< xxxx.tar``` 导入各个文件即可）。
+  docker load< xxxx.tar
+  ```
+
+   
+
+  导入各个文件即可）。
+
   ## 在所有节点上安装 kubeadm
+
   查看 apt 安装源如下配置，使用阿里云的系统和 kubernetes 的源。
 
 ```bash
@@ -58,6 +73,7 @@ Reading state information... Done
 docker.io is already the newest version (1.13.1-0ubuntu1~16.04.2).
 0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
 ```
+
 更新源，可以不理会 gpg 的报错信息。
 
 ```bash
@@ -74,6 +90,7 @@ W: The repository 'https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenial I
 N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
 N: See apt-secure(8) manpage for repository creation and user configuration details.
 ```
+
 强制安装 kubeadm，kubectl，kubelet 软件包。
 
 ```bash
@@ -107,6 +124,7 @@ Preparing to unpack .../socat_1.7.3.1-1_amd64.deb ...
 Unpacking ....
 ....
 ```
+
 kubeadm 安装完以后，就可以使用它来快速安装部署 Kubernetes 集群了。
 
 ## 使用 kubeadm 安装 Kubernetes 集群
@@ -115,7 +133,7 @@ kubeadm安装完以后，就可以使用它来快速安装部署Kubernetes集群
 
 ### 使用 kubeadmin 初始化 master 节点
 
-因为使用要使用canal，因此需要在初始化时加上网络配置参数,设置kubernetes的子网为10.244.0.0/16，注意此处不要修改为其他地址，因为这个值与后续的canal的yaml值要一致，如果修改，请一并修改。
+因为使用要使用 canal，因此需要在初始化时加上网络配置参数，设置 kubernetes 的子网为 10.244.0.0/16，注意此处不要修改为其他地址，因为这个值与后续的 canal 的 yaml 值要一致，如果修改，请一并修改。
 
 这个下载镜像的过程涉及翻墙，因为会从 gcr 的站点下载容器镜像。。。（如果大家翻墙不方便的话，可以用我在上文准备工作中提到的导出的镜像）。
 
@@ -155,7 +173,7 @@ Suggestion: go get github.com/kubernetes-incubator/cri-tools/cmd/crictl
 [init] Waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests".
 [init] This might take a minute or longer if the control plane images have to be pulled.
 [apiclient] All control plane components are healthy after 28.003828 seconds
-[uploadconfig] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
+[uploadconfig] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
 [markmaster] Will mark node ubuntu-master as master by adding a label and a taint
 [markmaster] Master ubuntu-master tainted and labelled with key/value: node-role.kubernetes.io/master=""
 [bootstraptoken] Using token: rw4enn.mvk547juq7qi2b5f
@@ -191,11 +209,12 @@ mkdir -p $HOME/.kube
 sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
 sudo chown $(id -u):$(id -g) $HOME/.kube/config
 ```
+
 这样 master 的节点就配置好了，并且可以使用 kubectl 来进行各种操作了，根据上面的提示接着往下做，将 slave 节点加入到集群。
 
 ### Slave 节点加入集群
 
-在slave节点执行如下的命令,将slave节点加入集群，正常的返回信息如下：
+在 slave 节点执行如下的命令，将 slave 节点加入集群，正常的返回信息如下：
 
 ```bash
 #kubeadm join 192.168.0.200:6443 --token rw4enn.mvk547juq7qi2b5f --discovery-token-ca-cert-hash sha256:ba260d5191213382a806a9a7d92c9e6bb09061847c7914b1ac584d0c69471579
@@ -215,6 +234,7 @@ This node has joined the cluster:
 
 Run 'kubectl get nodes' on the master to see this node join the cluster.
 ```
+
 等待节点加入完毕。加入中状态。
 
 ```bash
@@ -225,7 +245,9 @@ ubuntu-2        NotReady   <none>    6m        v1.10.1
 ubuntu-3        NotReady   <none>    6m        v1.10.1
 ubuntu-master   NotReady   master    10m       v1.10.1
 ```
+
 在 master 节点查看信息如下状态为节点加入完毕。
+
 ```bash
 root@Ubuntu-master:~# kubectl get pod -n kube-system -o wide
 NAME                                    READY     STATUS    RESTARTS   AGE       IP              NODE
@@ -252,9 +274,6 @@ clusterrole.rbac.authorization.k8s.io "calico" created
 clusterrole.rbac.authorization.k8s.io "flannel" created
 clusterrolebinding.rbac.authorization.k8s.io "canal-flannel" created
 clusterrolebinding.rbac.authorization.k8s.io "canal-calico" created
-```
-
-```bash
 # kubectl apply -f https://docs.projectcalico.org/v3.0/getting-started/kubernetes/installation/hosted/canal/canal.yaml
 configmap "canal-config" created
 daemonset.extensions "canal" created
@@ -268,6 +287,7 @@ serviceaccount "canal" created
 ```
 
 查看 canal 的安装状态。
+
 ```bash
 # kubectl get pod -n kube-system -o wide
 NAME                                    READY     STATUS    RESTARTS   AGE       IP              NODE
@@ -289,6 +309,7 @@ kube-scheduler-ubuntu-master            1/1       Running   0          28m
 可以看到 canal 和 kube-dns 都已经运行正常，一个基本功能正常的测试环境就部署完毕了。
 
 此时查看集群的节点状态，版本为最新的版本 v1.10.1。
+
 ```bash
 # kubectl get node
 NAME            STATUS    ROLES     AGE       VERSION
@@ -299,6 +320,7 @@ ubuntu-master   Ready     master    31m       v1.10.1
 ```
 
 让 master 也运行 pod（默认 master 不运行 pod）, 这样在测试环境做是可以的，不建议在生产环境如此操作。
+
 ```bash
 #kubectl taint nodes --all node-role.kubernetes.io/master-
 node "ubuntu-master" untainted
@@ -306,8 +328,7 @@ taint "node-role.kubernetes.io/master:" not found
 taint "node-role.kubernetes.io/master:" not found
 taint "node-role.kubernetes.io/master:" not found
 ```
-后续如果想要集群其他功能启用，请参考后续文章。
 
 ## 参考
 
-- [Overview of kubeadm](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/)
+- [Overview of kubeadm - kubernetest.io](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/)

practice/install-kubernetes-with-kubeadm.md

@@ -47,4 +47,4 @@ Kubernetes版本通常支持九个月，在此期间，如果发现严重的错
 
 ## 参考
 
-- [Overview of kubeadm](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/)
+- [Overview of kubeadm - kubernetes.io](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/)

practice/kubectl-installation.md

@@ -1,6 +1,6 @@
 # 安装 kubectl 命令行工具
 
-本文档介绍下载和配置 kubernetes 集群命令行工具 kubelet 的步骤。
+本文介绍下载和配置 kubernetes 集群命令行工具 kubelet 的步骤。
 
 ## 下载 kubectl
 
@@ -39,8 +39,3 @@ kubectl config use-context kubernetes
 + 生成的 kubeconfig 被保存到 `~/.kube/config` 文件；
 
 **注意：**`~/.kube/config`文件拥有对该集群的最高权限，请妥善保管。
-
-## 更多资料
-
-- [kubectl命令概览](../guide/using-kubectl.md)
-- [kubectl命令技巧大全](../guide/kubectl-cheatsheet.md)

practice/kubedns-addon-installation.md

@@ -9,6 +9,7 @@ gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64:1.14.1
 gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.1
 gcr.io/google_containers/k8s-dns-sidecar-amd64:1.14.1
 ```
+
 我 clone 了上述镜像，上传到我的私有镜像仓库：
 
 ```ini
@@ -180,7 +181,6 @@ root@nginx:/# ping kube-dns.kube-system.svc.cluster.local
 PING kube-dns.kube-system.svc.cluster.local (10.254.0.2): 56 data bytes
 ^C--- kube-dns.kube-system.svc.cluster.local ping statistics ---
 6 packets transmitted, 0 packets received, 100% packet loss
-```
 从结果来看，service 名称可以正常解析。
-
+```
 **注意**：直接 ping ClusterIP 是 ping 不通的，ClusterIP 是根据 **IPtables** 路由到服务的 endpoint 上，只有结合 ClusterIP 加端口才能访问到对应的服务。

practice/master-ha.md

@@ -1,17 +1,14 @@
 # Master 节点高可用
-作者：[mendickxiao](https://github.com/mendickxiao)
-
 经过部署 Kubernetes 集群章节我们已经可以顺利的部署一个集群用于开发和测试，但是要应用到生产就就不得不考虑 master 节点的高可用问题，因为现在我们的 master 节点上的几个服务 `kube-apiserver`、`kube-scheduler` 和 `kube-controller-manager` 都是单点的而且都位于同一个节点上，一旦 master 节点宕机，虽然不应答当前正在运行的应用，将导致 kubernetes 集群无法变更。本文将引导你创建一个高可用的 master 节点。
 
-在大神gzmzj的ansible创建kubernetes集群神作中有讲到如何配置多个Master，但是在实践过程中还是遇到不少坑。需要将坑填上才能工作。
-神作链接地址：[集群规划和基础参数设定](https://github.com/mendickxiao/kubeasz/blob/master/docs/00-%E9%9B%86%E7%BE%A4%E8%A7%84%E5%88%92%E5%92%8C%E5%9F%BA%E7%A1%80%E5%8F%82%E6%95%B0%E8%AE%BE%E5%AE%9A.md)。
+在大神 gzmzj 的 ansible 创建 kubernetes 集群神作中有讲到如何配置多个 Master，但是在实践过程中还是遇到不少坑。需要将坑填上才能工作。 参考[集群规划和基础参数设定](https://github.com/mendickxiao/kubeasz/blob/master/docs/00-集群规划和基础参数设定.md)。
 
 按照神作的描述，实际上是通过 keepalived + haproxy 实现的，其中 keepalived 是提供一个 VIP，通过 VIP 关联所有的 Master 节点；然后 haproxy 提供端口转发功能。由于 VIP 还是存在 Master 的机器上的，默认配置 API Server 的端口是 6443，所以我们需要将另外一个端口关联到这个 VIP 上，一般用 8443。
 
 ![Master HA架构图](../images/master-ha.JPG)
 
 
-根据神作的实践，我发现需要在Master手工安装keepalived, haproxy。
+根据参考文章的实践，我发现需要在Master手工安装keepalived, haproxy。
 ```bash
 yum install keepalived
 yum install haproxy
@@ -23,7 +20,6 @@ yum install haproxy
 
 - bind 绑定的就是 VIP 对外的端口号，这里是 8443。
 
-
 - balance 指定的负载均衡方式是 `roundrobin` 方式，默认是 source 方式。在我的测试中，source 方式不工作。
 - server 指定的就是实际的 Master 节点地址以及真正工作的端口号，这里是 6443。有多少台 Master 就写多少条记录。
 
@@ -62,7 +58,7 @@ listen kube-master
 - priority 决定哪个 Master 是主，哪个 Master 是次。数字大的是主，数字小的是次。数字越大优先级越高。
 - `virtual_router_id` 决定当前 VIP 的路由号，实际上 VIP 提供了一个虚拟的路由功能，该 VIP 在同一个子网内必须是唯一。
 - virtual_ipaddress 提供的就是 VIP 的地址，该地址在子网内必须是空闲未必分配的。
-- `state` 决定初始化时节点的状态, 建议 `priority` 最高的节点设置为 `MASTER`。
+- `state` 决定初始化时节点的状态，建议 `priority` 最高的节点设置为 `MASTER`。
 
 ```ini
 # keepalived.cfg sample
@@ -73,24 +69,28 @@ global_defs {
 
 vrrp_instance VI-kube-master {
     state BACKUP
-    **priority 110**
-    dont_track_primary
+    **priority 110**
+    dont_track_primary
     interface eth0
-    **virtual_router_id 51**
-    advert_int 3
+    **virtual_router_id 51**
+    advert_int 3
     virtual_ipaddress {
-        **10.86.13.36**
-    }
+        **10.86.13.36**
+    }
 }
 ```
+
 配置好后，那么先启动主 Master 的 keepalived 和 haproxy。
+
 ```bash
 systemctl enable keepalived
 systemctl start keepalived
 systemctl enable haproxy
 systemctl start haproxy
 ```
+
 然后使用 ip a s 命令查看是否有 VIP 地址分配。如果看到 VIP 地址已经成功分配在 eth0 网卡上，说明 keepalived 启动成功。
+
 ```bash
 [root@kube32 ~]# ip a s
 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
@@ -103,12 +103,14 @@ systemctl start haproxy
     link/ether 00:50:56:a9:d5:be brd ff:ff:ff:ff:ff:ff
     inet 10.86.13.32/23 brd 10.86.13.255 scope global eth0
        valid_lft forever preferred_lft forever
-    **inet 10.86.13.36/32 scope global eth0**
-       valid_lft forever preferred_lft forever
+    **inet 10.86.13.36/32 scope global eth0**
+       valid_lft forever preferred_lft forever
     inet6 fe80::250:56ff:fea9:d5be/64 scope link
-       valid_lft forever preferred_lft forever
+       valid_lft forever preferred_lft forever
 ```
+
 更保险方法还可以通过 `systemctl status keepalived -l` 看看 keepalived 的状态
+
 ```bash
 [root@kube32 ~]# systemctl status keepalived -l
 ● keepalived.service - LVS and VRRP High Availability Monitor
@@ -125,7 +127,9 @@ Mar 20 04:51:15 kube32 Keepalived_vrrp[13450]: VRRP_Instance(VI-kube-master) Dro
 **Mar 20 04:51:18 kube32 Keepalived_vrrp[13450]: (VI-kube-master): ip address associated with VRID 51 not present in MASTER advert : 10.86.13.36
 Mar 20 04:51:18 kube32 Keepalived_vrrp[13450]: bogus VRRP packet received on eth0 !!!**
 ```
+
 然后通过 systemctl status haproxy -l 看 haproxy 的状态
+
 ```bash
 [root@kube32 ~]# systemctl status haproxy -l
 ● haproxy.service - HAProxy Load Balancer
@@ -138,15 +142,17 @@ Mar 20 04:51:18 kube32 Keepalived_vrrp[13450]: bogus VRRP packet received on eth
            ├─15117 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
            └─15118 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
 ```
+
 这个时候通过 kubectl version 命令，可以获取到 kubectl 的服务器信息。
+
 ```bash
 [root@kube32 ~]# kubectl version
 **Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.1", GitCommit:"3a1c9449a956b6026f075fa3134ff92f7d55f812", GitTreeState:"clean", BuildDate:"2018-01-03T22:31:01Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
 Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.1", GitCommit:"3a1c9449a956b6026f075fa3134ff92f7d55f812", GitTreeState:"clean", BuildDate:"2018-01-03T22:18:41Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}**
 ```
 
-这个时候说明你的keepalived和haproxy都是成功的。这个时候你可以依次将你其他Master节点的keepalived和haproxy启动。
-此时，你通过ip a s命令去查看其中一台Master（*非主Master*）的时候，你看不到VIP，这个是正常的，因为VIP永远只在主Master节点上，只有当主Master节点挂掉后，才会切换到其他Master节点上。
+这个时候说明你的 keepalived 和 haproxy 都是成功的。这个时候你可以依次将你其他 Master 节点的 keepalived 和 haproxy 启动。 此时，你通过 ip a s 命令去查看其中一台 Master（*非主 Master*）的时候，你看不到 VIP，这个是正常的，因为 VIP 永远只在主 Master 节点上，只有当主 Master 节点挂掉后，才会切换到其他 Master 节点上。
+
 ```bash
 [root@kube31 ~]# ip a s
 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
@@ -162,6 +168,11 @@ Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.1", GitCommi
     inet6 fe80::250:56ff:fea9:723/64 scope link
        valid_lft forever preferred_lft forever
 ```
+
 在我的实践过程中，通过大神的脚本快速启动多个 Master 节点，会导致主 Master 始终获取不了 VIP，当时的报错非常奇怪。后来经过我的研究发现，主 Master 获取 VIP 是需要时间的，如果多个 Master 同时启动，会导致冲突。这个不知道是否算是 Keepalived 的 Bug。但是最稳妥的方式还是先启动一台主 Master，等 VIP 确定后再启动其他 Master 比较靠谱。
 
 Kubernetes 通过 Keepalived + Haproxy 实现多个 Master 的高可用部署，你实际上可以采用其他方式，如外部的负载均衡方式。实际上 Kubernetes 的多个 Master 是没有主从的，都可以提供一致性服务。Keepalived + Haproxy 实际上就是提供了一个简单的负载均衡方式。
+
+---
+
+注：本文来自 [mendickxiao](https://github.com/mendickxiao) 的贡献。

practice/nginx-ingress-installation.md

@@ -1,8 +1,8 @@
 # 安装Nginx ingress
 
-[Nginx ingress](https://github.com/kubernetes/ingress-nginx) 使用ConfigMap来管理Nginx配置，nginx是大家熟知的代理和负载均衡软件，比起[Traefik](https://traefik.io)来说功能更加强大.
+[Nginx ingress](https://github.com/kubernetes/ingress-nginx) 使用 ConfigMap 来管理 Nginx 配置，nginx 是大家熟知的代理和负载均衡软件，比起 [Traefik](https://traefik.io/) 来说功能更加强大.
 
-我们使用[helm](http://helm.sh)来部署，[chart](https://github.com/kubernetes/charts)保存在私有的仓库中，请确保您已经安装和配置好helm，helm安装使用见[使用Helm管理kubernetes应用](helm.md)。
+我们使用 [helm](http://helm.sh/) 来部署，[chart](https://github.com/kubernetes/charts) 保存在私有的仓库中，请确保您已经安装和配置好 helm，helm 安装使用见[使用 Helm 管理 kubernetes 应用](helm.md)。
 
 ## 镜像准备
 
@@ -168,6 +168,5 @@ helm delete --purge nginx-ingress
 
 ## 参考
 
-- [Ingress-nginx github](https://github.com/kubernetes/ingress-nginx)
-- [Nginx chart configuration](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress)
-- [使用Helm管理kubernetes应用](helm.md)
+- [Ingress-nginx - github.com](https://github.com/kubernetes/ingress-nginx)
+- [Nginx chart configuration - github.com](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress)

practice/node-installation.md

@@ -405,6 +405,3 @@ Commercial support is available at
 
 ![nginx欢迎页面](../images/kubernetes-installation-test-nginx.png)
 
-## 参考
-
-- [Kubelet 的认证授权](../guide/kubelet-authentication-authorization.md)

practice/openebs.md

@@ -63,17 +63,15 @@ OpenEBS的控制平面也是基于微服务的，它的服务可以分成以下
 - 节点服务，提供 OpenEBS 特定的随 kubelet 一起运行的存储智能，如：
   - **maya-agent**：包括存储管理功能
 
-通过使用prometheus、heapster、grafana和jaegar进行上述服务，可以添加监控和跟踪功能。
+通过使用 Prometheus、Heapster、Grafana 和 Jaegar 进行上述服务，可以添加监控和跟踪功能。
 
 **源码**
 
 - [openebs/maya](https://github.com/openebs/maya)：所有特定的二进制代码（非插件）都存储在这个仓库中，比如 `maya-apiserver`、`maya-agent`、`maya-mulebot`、`maya-connect`、`mayactl` 等等。
 - [openebs-dashboard](https://github.com/openebs/dashboard)：kubernetes-dashboard 项目的分支，扩展了存储功能。
-- [openebs-provisioner](https://github.com/openebs/external-storage/tree/master/openebs)：来自Kubernetes孵化器项目的OpenEBS K8s Provisioner。
+- [openebs-provisioner](https://github.com/openebs/external-storage/tree/master/openebs)：来自 Kubernetes 孵化器项目的 OpenEBS Kubernetes Provisioner。
 
 ## 参考
 
-- https://www.openebs.io/
-- https://github.com/openebs/openebs
-- [Data Scientists adopting tools and solutions that allow them to focus more on Data Science and less on the infrastructure around them](https://blog.openebs.io/data-scientists-adopting-tools-and-solutions-that-allow-them-to-focus-more-on-data-science-and-less-db9654063bd5)
-
+- [OpenEBS 官网 - openebs.io](https://www.openebs.io/)
+- [Data Scientists adopting tools and solutions that allow them to focus more on Data Science and less on the infrastructure around them - blog.openebs.io](https://blog.openebs.io/data-scientists-adopting-tools-and-solutions-that-allow-them-to-focus-more-on-data-science-and-less-db9654063bd5)

practice/service-discovery-and-loadbalancing.md

@@ -130,9 +130,9 @@ spec:
 
 ## 参考资料
 
-- https://kubernetes.io/docs/concepts/services-networking/service/
-- http://kubernetes.io/docs/user-guide/ingress/
-- https://github.com/kubernetes/contrib/tree/master/service-loadbalancer
-- https://www.nginx.com/blog/load-balancing-kubernetes-services-nginx-plus/
-- https://github.com/weaveworks/flux
-- https://github.com/AdoHe/kube2haproxy
+- [Service - kubernetes.io](https://kubernetes.io/docs/concepts/services-networking/service/)
+- [Ingress - kubernetes.io](http://kubernetes.io/docs/user-guide/ingress/)
+- [service Loadbalancer - github.com](https://github.com/kubernetes/contrib/tree/master/service-loadbalancer)
+- [Load Balancing Kubernetes Services with NGINX Plus - nginx.com](https://www.nginx.com/blog/load-balancing-kubernetes-services-nginx-plus/)
+- [Flux - github.com](https://github.com/weaveworks/flux)
+- [kube2haproxy - github.com](https://github.com/adohe-zz/kube2haproxy)

practice/traefik-ingress-installation.md

@@ -1,26 +1,10 @@
-# 安装traefik ingress
-
-## Ingress简介
-
-如果你还不了解，ingress是什么，可以先看下我翻译的Kubernetes官网上ingress的介绍[Kubernetes Ingress解析](https://jimmysong.io/posts/kubernetes-ingress-resource/)。
-
-**理解Ingress**
-
-简单的说，ingress就是从kubernetes集群外访问集群的入口，将用户的URL请求转发到不同的service上。Ingress相当于nginx、apache等负载均衡方向代理服务器，其中还包括规则定义，即URL的路由信息，路由信息得的刷新由[Ingress controller](https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-controllers)来提供。
-
-**理解Ingress Controller**
-
-Ingress Controller 实质上可以理解为是个监视器，Ingress Controller 通过不断地跟 kubernetes API 打交道，实时的感知后端 service、pod 等变化，比如新增和减少 pod，service 增加与减少等；当得到这些变化信息后，Ingress Controller 再结合下文的 Ingress 生成配置，然后更新反向代理负载均衡器，并刷新其配置，达到服务发现的作用。
-
-## 部署Traefik
-
-**介绍traefik**
+# 安装 Traefik ingress
 
 [Traefik](https://traefik.io/) 是一款开源的反向代理与负载均衡工具。它最大的优点是能够与常见的微服务系统直接整合，可以实现自动化动态配置。目前支持 Docker, Swarm, Mesos/Marathon, Mesos, Kubernetes, Consul, Etcd, Zookeeper, BoltDB, Rest API 等等后端模型。
 
-以下配置文件可以在[kubernetes-handbook](https://github.com/rootsongjc/kubernetes-handbook)GitHub仓库中的[../manifests/traefik-ingress/](https://github.com/rootsongjc/kubernetes-handbook/blob/master/manifests/traefik-ingress/)目录下找到。
+以下配置文件可以在 [../manifests/traefik-ingress/](https://github.com/rootsongjc/kubernetes-handbook/blob/master/manifests/traefik-ingress/) 目录下找到。
 
-**创建ingress-rbac.yaml**
+## 创建 ingress-rbac.yaml
 
 将用于 service account 验证。
 
@@ -47,7 +31,9 @@ roleRef:
   apiGroup: rbac.authorization.k8s.io
 ```
 
-**创建名为`traefik-ingress`的ingress**，文件名ingress.yaml
+## 创建 Ingress
+
+创建名为 `traefik-ingress` 的 ingress，文件名 ingress.yaml
 
 ```yaml
 apiVersion: extensions/v1beta1
@@ -79,7 +65,7 @@ spec:
 
 我们现在集群中已经有两个 service 了，一个是 nginx，另一个是官方的 `guestbook` 例子。
 
-**创建DaemonSet**
+## 创建 DaemonSet
 
 我们使用 DaemonSet 类型来部署 Traefik，并使用 `nodeSelector` 来限定 Traefik 所部署的主机。
 
@@ -183,7 +169,7 @@ kubectl create -f .
 
 访问该地址 `http://172.20.0.115:8580/` 将可以看到 dashboard。
 
-![kubernetes-dashboard](../images/traefik-dashboard.jpg)
+![Terafik dashboard](../images/traefik-dashboard.jpg)
 
 左侧黄色部分部分列出的是所有的 rule，右侧绿色部分是所有的 backend。
 
@@ -235,13 +221,8 @@ Traefik会解析http请求header里的Host参数将流量转发给Ingress配置
 
 修改 hosts 后就就可以在 kubernetes 集群外访问以上两个 service，如下图：
 
-![traefik-nginx](../images/traefik-nginx.jpg)
+![Nginx 页面](../images/traefik-nginx.jpg)
 
 
 
-![traefik-guestbook](../images/traefik-guestbook.jpg)
-
-
-## 参考
-
-- [Traefik简介](http://www.tuicool.com/articles/ZnuEfay)
+![Guestbook 页面](../images/traefik-guestbook.jpg)

usecases/conduit.md

@@ -14,5 +14,3 @@ Conduit使用Rust和Go语言开发，GitHub地址https://github.com/runconduit/c
 
 - Conduit GitHub：https://github.com/runconduit/conduit
 - 关于Conduit的更多资源请参考官方网站：https://conduit.io/
-- Conduit的官方文档中文版：https://github.com/doczhcn/conduit
-- 关于Service Mesh的更多内容请访问ServiceMesher：http://www.servicemesher.com

usecases/envoy.md

@@ -1,8 +1,6 @@
 # Envoy
 
-[Envoy](https://github.com/envoyproxy/envoy) 是一款由 Lyft 开源的，使用 C++ 编写的 L7 代理和通信总线，目前是 [CNCF](https://cncf.io) 旗下的开源项目且已经毕业，代码托管在 GitHub 上，它也是 [Istio](https://istio.io) service mesh 中默认的 data plane。
-
-ServiceMesher 共同联合翻译了 [Envoy 最新版本的官方文档](https://www.envoyproxy.io/docs/envoy/latest/)，翻译的代码托管在 <https://github.com/servicemesher/envoy>，Envoy 官方文档中文版地址：<https://www.servicemesher.com/envoy/>。
+[Envoy](https://github.com/envoyproxy/envoy) 是一款由 Lyft 开源的，使用 C++ 编写的 L7 代理和通信总线，目前是 [CNCF](https://cncf.io) 旗下的开源项目且已经毕业，代码托管在 GitHub 上，它也是 [Istio](https://istio.io) service mesh 中默认的 data plane。关于 Envoy 的详情请阅读 [Envoy 中文文档](https://cloudnative.to/envoy/).
 
 ## 特性
 
@@ -36,6 +34,5 @@ Matt Klein 是在他的文章中指出 sidecar 模式的 proxy 将取代另外
 
 ## 参考
 
-- [Introduction to modern network load balancing and proxying](https://blog.envoyproxy.io/introduction-to-modern-network-load-balancing-and-proxying-a57f6ff80236)
-- 更多信息请参考 [Envoy 官网](https://www.envoyproxy.io/)
-- [Envoy官方文档中文版](https://www.servicemesher.com/envoy/)
+- [Introduction to modern network load balancing and proxying - blog.envoyproxy.io](https://blog.envoyproxy.io/introduction-to-modern-network-load-balancing-and-proxying-a57f6ff80236)
+- [Envoy 官方文档中文版 - cloudnative.to](https://cloudnative.to/envoy/)

usecases/understand-sidecar-injection-and-traffic-hijack-in-istio-service-mesh.md

@@ -19,7 +19,7 @@
 
 ### 使用 Sidecar 模式的优势
 
-使用 sidecar 模式部署服务网格时，无需在节点上运行代理，但是集群中将运行多个相同的 sidecar 副本。在 sidecar 部署方式中，每个应用的容器旁都会部署一个伴生容器（如 [Envoy](https://www.servicemesher.com/istio-handbook/GLOSSARY.html#envoy) 或 [MOSN](https://www.servicemesher.com/istio-handbook/GLOSSARY.html#mosn)），这个容器称之为 sidecar 容器。Sidecar 接管进出应用容器的所有流量。在 Kubernetes 的 Pod 中，在原有的应用容器旁边注入一个 Sidecar 容器，两个容器共享存储、网络等资源，可以广义的将这个包含了 sidecar 容器的 Pod 理解为一台主机，两个容器共享主机资源。
+使用 sidecar 模式部署服务网格时，无需在节点上运行代理，但是集群中将运行多个相同的 sidecar 副本。在 sidecar 部署方式中，每个应用的容器旁都会部署一个伴生容器，这个容器称之为 sidecar 容器。Sidecar 接管进出应用容器的所有流量。在 Kubernetes 的 Pod 中，在原有的应用容器旁边注入一个 Sidecar 容器，两个容器共享存储、网络等资源，可以广义的将这个包含了 sidecar 容器的 Pod 理解为一台主机，两个容器共享主机资源。
 
 因其独特的部署结构，使得 sidecar 模式具有以下优势：
 
@@ -219,7 +219,7 @@ $ istioctl kube-inject -f samples/bookinfo/platform/kube/bookinfo.yaml
 Istio 给应用 Pod 注入的配置主要包括：
 
 - Init 容器 `istio-init`：用于 pod 中设置 iptables 端口转发
-- Sidecar 容器 `istio-proxy`：运行 sidecar 代理，如 [Envoy](https://www.servicemesher.com/istio-handbook/GLOSSARY.html#envoy) 或 [MOSN](https://www.servicemesher.com/istio-handbook/GLOSSARY.html#mosn)
+- Sidecar 容器 `istio-proxy`：运行 sidecar 代理
 
 接下来将分别解析下这两个容器。
 
@@ -639,7 +639,7 @@ Inbound handler 的流量被 `virtualInbound` Listener 转移到 `172.17.0.15_90
 
 我们看其中的 `filterChains.filters` 中的 `envoy.http_connection_manager` 配置部分，该配置表示流量将转交给Cluster`inbound|9080|http|reviews.default.svc.cluster.local` 处理。
 
-**[Cluster](https://www.servicemesher.com/istio-handbook/GLOSSARY.html#cluster) `inbound|9080|http|reviews.default.svc.cluster.local`**
+**Cluster `inbound|9080|http|reviews.default.svc.cluster.local`**
 
 运行 `istioctl proxy-config cluster reviews-v1-54b8794ddf-jxksn --fqdn reviews.default.svc.cluster.local --direction inbound -o json` 查看该Cluster的配置如下。
 
@@ -789,7 +789,7 @@ Endpoint 可以是一个或多个，sidecar 将根据一定规则选择适当的
 
 本文使用了 Istio 官方提供的 bookinfo 示例，按图索骥得带领读者了解了 sidecar 注入、iptables 透明流量劫持及 sidecar 中流量路由背后的实现细节。Sidecar 模式和流量透明劫持是 Istio 服务网格的特色和基础功能，理解该功能的背后过程及实现细节，将有助于大家理解 Service Mesh 的原理和 [Istio Handbook](https://www.servicemesher.com/istio-handbook/) 后面章节中的内容，因此希望读者可以在自己的环境中从头来试验一遍以加深理解。
 
-使用 iptables 做流量劫持只是 service mesh 的数据平面中做流量劫持的方式之一，还有更多的流量劫持方案，下面引用自 [云原生网络代理 MOSN 官网中给出的流量劫持](https://mosn.io/zh/docs/concept/traffic-hijack/)部分的描述。
+使用 iptables 做流量劫持只是 service mesh 的数据平面中做流量劫持的方式之一，还有更多的流量劫持方案，下面引用自 [云原生网络代理 MOSN 官网中给出的流量劫持](https://mosn.io/docs/concept/traffic-hijack/)部分的描述。
 
 ### 使用 iptables 做流量劫持时存在的问题
 
@@ -821,4 +821,4 @@ tproxy 可以用于 inbound 流量的重定向，且无需改变报文中的目
 
 - [Debugging Envoy and Istiod - istio.io](https://istio.io/docs/ops/diagnostic-tools/proxy-cmd/)
 - [揭开 Istio Sidecar 注入模型的神秘面纱 - istio.io](https://istio.io/zh/blog/2019/data-plane-setup/)
-- [MOSN 作为 Sidecar 使用时的流量劫持方案 - mosn.io](https://mosn.io/zh/docs/concept/traffic-hijack/)
+- [MOSN 作为 Sidecar 使用时的流量劫持方案 - mosn.io](https://mosn.io/docs/concept/traffic-hijack/)