fix broken links

appendix/kubernetes-and-cloud-native-summary-in-2017-and-outlook-for-2018.md

@@ -42,7 +42,7 @@ Kubernetes 的架构做的足够开放，通过系列的接口，如 CRI（Conta
 
 - 2017 年 6 月 19 日 - 20 日，北京，[L3 大会](https://www.bagevent.com/event/561769)（LinuxCon+ContainerCon+CloudOpen China）。CNCF（Cloud Native Computing Foundation）作为云原生应用的联合推广团体，也是由 Google 一手培植起来的强大 “市场媒体”（Kubernetes 是第一个入选该基金会的项目），第一次进入中国，华为、Google、Rancher、红帽等公司分别做了关于 Kubernetes 及 Cloud Native 的演讲。
 - 2017 年 7 月 25 日，北京、上海，[k8smeetup](http://www.k8smeetup.com/)，Kubernetes 二周年北京 - 上海 Meetup 双城庆生。
-- 2017 年 9 月 12 日，北京，[T11 大会](https://www.talkingdata.com/activity/T11-2017/index.html)，前 Pivotal 技术专家，现 CapitalOne 高级专家 Kevin Hoffman 做了 [High Level Cloud Native Concepts](https://jimmysong.io/posts/high-level-cloud-native-from-kevin-hoffman/) 的演讲。
+- 2017 年 9 月 12 日，北京，T11 大会，前 Pivotal 技术专家，现 CapitalOne 高级专家 Kevin Hoffman 做了 [High Level Cloud Native Concepts](https://jimmysong.io/posts/high-level-cloud-native-from-kevin-hoffman/) 的演讲。
 - 2017 年 10 月 15 日，杭州，[KEUC 2017- Kubernetes 中国用户大会](https://www.bagevent.com/event/827437)。由才云科技（Caicloud）、美国 The Linux Foundation 基金会旗下 Cloud Native Computing Foundation (CNCF)、「K8sMeetup 中国社区」联合主办的聚焦 Kubernetes 中国行业应用与技术落地的盛会。
 - 2017 年 12 月 13 日 - 15 日，杭州，[云原生技术大会 ——CNTC](https://www.huodongjia.com/event-5854212.html)。这次会议由谐云科技与网易云共同主办，主要探讨云原生技术与应用，同时还进行了云原生集训。
 

cloud-native/kubernetes-and-cloud-native-app-overview.md

@@ -32,9 +32,9 @@
 
 ### 云原生概念介绍
 
-下面是Cloud Native概念思维导图
+下面是云原生概念思维导图
 
-![Cloud native思维导图](../images/cloud-native-architecutre-mindnode.jpg)
+![云原生思维导图](../images/cloud-native-architecutre-mindnode.jpg)
 
 云原生准确来说是一种文化，更是一种潮流，它是云计算的一个必然导向。它的意义在于让云成为云化战略成功的基石，而不是阻碍，如果业务应用上云之后开发和运维人员比原先还痛苦，成本还高的话，这样的云我们宁愿不上。
 
@@ -67,7 +67,7 @@ Kuberentes可以说是乘着Docker和微服务的东风，一经推出便迅速
 
 [Kubernetes](http://kubernetes.io) 是 Google 基于 [Borg](https://research.google.com/pubs/pub43438.html) 开源的容器编排调度引擎，作为 [CNCF](http://cncf.io)（Cloud Native Computing Foundation）最重要的组件之一，它的目标不仅仅是一个编排系统，而是提供一个规范，可以让你来描述集群的架构，定义服务的最终状态，Kubernetes 可以帮你将系统自动得达到和维持在这个状态。
 
-更直白的说，Kubernetes用户可以通过编写一个yaml或者json格式的配置文件，也可以通过工具/代码生成或直接请求Kubernetes API创建应用，该配置文件中包含了用户想要应用程序保持的状态，不论整个Kubernetes集群中的个别主机发生什么问题，都不会影响应用程序的状态，你还可以通过改变该配置文件或请求Kubernetes API来改变应用程序的状态。
+更直白的说，Kubernetes 用户可以通过编写一个 YAML 或者 json 格式的配置文件，也可以通过工具 / 代码生成或直接请求 Kubernetes API 创建应用，该配置文件中包含了用户想要应用程序保持的状态，不论整个 Kubernetes 集群中的个别主机发生什么问题，都不会影响应用程序的状态，你还可以通过改变该配置文件或请求 Kubernetes API 来改变应用程序的状态。
 
 ### 12 因素应用
 
@@ -125,7 +125,7 @@ Kuberentes可以说是乘着Docker和微服务的东风，一经推出便迅速
 
 后台管理任务当作一次性进程运行，`kubectl exec` 进入容器内部操作。
 
-另外，[Cloud Native Go](https://jimmysong.io/cloud-native-go) 这本书的作者，CapitalOne公司的Kevin Hoffman在TalkingData T11峰会上的[High Level Cloud Native](https://jimmysong.io/posts/high-level-cloud-native-from-kevin-hoffman/)的演讲中讲述了云原生应用的15个因素，在原先的12因素应用的基础上又增加了如下三个因素：
+另外，[Cloud Native Go](https://jimmysong.io/cloud-native-go) 这本书的作者，CapitalOne 公司的 Kevin Hoffman 在 TalkingData T11 峰会上的 [High Level Cloud Native](https://jimmysong.io/blog/high-level-cloud-native-from-kevin-hoffman/) 的演讲中讲述了云原生应用的 15 个因素，在原先的 12 因素应用的基础上又增加了如下三个因素：
 
 **API 优先 **
 
@@ -149,8 +149,6 @@ Kuberentes可以说是乘着Docker和微服务的东风，一经推出便迅速
 * Bearer token、OAuth、OIDC 认证
 * 操作审计
 
-详见[High Level Cloud Native From Kevin Hoffman](https://jimmysong.io/posts/high-level-cloud-native-from-kevin-hoffman/)。
-
 ## Kubernetes 中的资源管理与容器设计模式
 
 Kubernetes 通过声明式配置，真正让开发人员能够理解应用的状态，并通过同一份配置可以立马启动一个一模一样的环境，大大提高了应用开发和部署的效率，其中 Kubernetes 设计的多种资源类型可以帮助我们定义应用的运行状态，并使用资源配置来细粒度的明确限制应用的资源使用。
@@ -298,9 +296,9 @@ Kubernetes是一个多租户的云平台，因此必须对用户的权限加以
 
 ## 如何迁移到云原生应用架构
 
-Pivotal（后被 VMware 收购）是云原生应用的提出者，并推出了 [Pivotal Cloud Foundry](https://pivotal.io/platform) 云原生应用平台和 [Spring](https://spring.io/) 开源 Java 开发框架，成为云原生应用架构中先驱者和探路者。
+Pivotal（后被 VMware 收购）是云原生应用的提出者，并推出了 Pivotal Cloud Foundry 云原生应用平台和 [Spring](https://spring.io/) 开源 Java 开发框架，成为云原生应用架构中先驱者和探路者。
 
-原书作于2015年，其中的示例主要针对 Java 应用，实际上也适用于任何应用类型，云原生应用架构适用于异构语言的程序开发，不仅仅是针对 Java 语言的程序开发。截止到本人翻译本书时，云原生应用生态系统已经初具规模，[CNCF](https://cncf.io/) 成员不断发展壮大，基于 Cloud Native 的创业公司不断涌现，[kubernetes](https://kubernetes.io/) 引领容器编排潮流，和 Service Mesh 技术（如 [Linkerd](https://linkerd.io/) 和 [Istio](https://istio.io/)） 的出现，Go 语言的兴起（参考另一本书 [Cloud Native Go](http://rootsongjc.github.io/cloud-native-go)）等为我们将应用迁移到云原生架构的提供了更多的方案选择。
+原书作于 2015 年，其中的示例主要针对 Java 应用，实际上也适用于任何应用类型，云原生应用架构适用于异构语言的程序开发，不仅仅是针对 Java 语言的程序开发。截止到本人翻译本书时，云原生应用生态系统已经初具规模，[CNCF](https://cncf.io/) 成员不断发展壮大，基于云原生的创业公司不断涌现，[Kubernetes](https://kubernetes.io/) 引领容器编排潮流，和 Service Mesh 技术（如 [Linkerd](https://linkerd.io/) 和 [Istio](https://istio.io/)） 的出现，Go 语言的兴起（参考另一本书 [Cloud Native Go](http://rootsongjc.github.io/cloud-native-go)）等为我们将应用迁移到云原生架构的提供了更多的方案选择。
 
 ### 迁移到云原生应用架构指南
 
@@ -314,7 +312,7 @@ Pivotal（后被 VMware 收购）是云原生应用的提出者，并推出了 [
 * 基于 API 的协作：发布和版本化的 API，允许在云原生应用程序架构中的服务之间进行交互
 * 抗压性：根据压力变强的系统
 
-详见：[迁移到云原生应用架构](https://jimmysong.io/migrating-to-cloud-native-application-architectures/)
+详见：[迁移到云原生应用架构](https://jimmysong.io/migrating-to-cloud-native-application-architectures/)。
 
 ### 迁移案例解析
 
@@ -341,7 +339,6 @@ Service Mesh现在一般被翻译作服务网格，目前主流的Service Mesh
 * [Istio](https://istio.io)：IBM、Google、Lyft 共同开源，详细文档见 [Istio 官方文档](https://istio.io)
 * [Linkerd](https://linkerd.io)：原 Twitter 工程师开发，现为 [CNCF](https://cncf.io) 中的项目之一
 * [Envoy](https://www.envoyproxy.io/)：Lyft 开源的，可以在 Istio 中使用 Sidecar 模式运行
-* [Conduit](https://conduit.io)：同样由Buoyant开源的轻量级的基于Kubernetes的Service Mesh
 
 此外还有很多其它的 Service Mesh 鱼贯而出，请参考 [awesome-cloud-native](https://jimmysong.io/awesome-cloud-native)。
 
@@ -351,20 +348,11 @@ Service Mesh现在一般被翻译作服务网格，目前主流的Service Mesh
 
 ![service mesh 架构图](../images/serivce-mesh-control-plane.png)
 
-详见[什么是 Service Mesh - jimmysong.io](https://jimmysong.io/posts/what-is-a-service-mesh/)。
-
-### Service Mesh使用指南
-
-两款Service Mesh各有千秋，我分别写了他们的使用案例指南：
-
-* [微服务管理框架Service Mesh——Linkerd安装试用笔记](https://jimmysong.io/posts/linkerd-user-guide/)
-* [微服务管理框架Service Mesh——Istio安装试用笔记](https://jimmysong.io/posts/istio-installation/)
-
-更多关于 Service Mesh 的内容请访问 [ServiceMesher 社区网站](http://www.servicemesher.com)。
+详见 [什么是 Service Mesh - jimmysong.io](https://jimmysong.io/blog/what-is-a-service-mesh/)。
 
 ## 使用案例
 
-Kubernetes作为云原生计算的基本组件之一，开源2年时间以来热度与日俱增，它可以跟我们的生产结合，擦出很多火花，比如FaaS和Serverless类应用，都很适合运行在kubernetes上。
+Kubernetes 作为云原生计算的基本组件之一，自开源以来热度与日俱增，它可以跟我们的生产结合，擦出很多火花，比如 FaaS 和 Serverless 类应用，都很适合运行在 Kubernetes 上。
 
 关于 Cloud Native 开源软件生态请参考 [Awesome Cloud Native - jimmysong.io](https://jimmysong.io/awesome-cloud-native)。
 
@@ -378,7 +366,7 @@ Kubernetes作为云原生计算的基本组件之一，开源2年时间以来热
 
 1. 根据环境（比如开发、测试、生产）划分 `namespace`，也可以根据项目来划分
 2. 再为每个用户划分一个 `namespace`、创建一个 `serviceaccount` 和 `kubeconfig` 文件，不同 `namespace` 间的资源隔离，目前不隔离网络，不同 `namespace` 间的服务可以互相访问
-3. 创建yaml模板，降低编写Kubernetes yaml文件编写难度
+3. 创建 YAML 模板，降低编写 Kubernetes YAML 文件编写难度
 4. 在 `kubectl` 命令上再封装一层，增加用户身份设置和环境初始化操作，简化 `kubectl` 命令和常用功能
 5. 管理员通过 dashboard 查看不同 `namespace` 的状态，也可以使用它来使操作更便捷
 6. 所有应用的日志统一收集到 ElasticSearch 中，统一日志访问入口
@@ -393,7 +381,7 @@ Kubernetes作为云原生计算的基本组件之一，开源2年时间以来热
 
 **使用 Grafana 查看应用状态**
 
-**注**：感谢【K8S🤘Cloud Native实战群】尊贵的黄金会员小刚同学提供下面的Grafana监控图🙏
+**注**：以下监控图片由云原生社区涂小刚提供
 
 监控分类示意图：
 
@@ -413,19 +401,17 @@ Kubernetes全局监控图2
 
 ### Spark on Kubernetes
 
-TL;DR [https://jimmysong.io/spark-on-k8s](https://jimmysong.io/spark-on-k8s)
+Spark 原生支持 Standalone、Mesos 和 YARN 资源调度，现已支持 Kubernetes 原生调度，详见 [Spark on Kubernetes](https://jimmysong.io/spark-on-k8s)。
 
-Spark原生支持standalone、mesos和YARN资源调度，现已支持Kubernetes原生调度，详见[运行支持Kubernetes原生调度的spark程序-Spark on Kubernetes](https://jimmysong.io/posts/running-spark-with-kubernetes-native-scheduler/)。
+**为何要使用 Spark on Kubernetes**
 
-**为何要使用spark on kubernetes**
+使用 Kubernetes 原生调度的 Spark on Kubernetes 是对原先的 Spark on YARN 和 YARN on Docker 的改变是革命性的，主要表现在以下几点：
 
-使用Kubernetes原生调度的spark on kubernetes是对原先的spark on yarn和yarn on docker的改变是革命性的，主要表现在以下几点：
-
-1. **Kubernetes原生调度**：不再需要二层调度，直接使用Kubernetes的资源调度功能，跟其他应用共用整个kubernetes管理的资源池；
-2. **资源隔离，粒度更细**：原先yarn中的queue在spark on kubernetes中已不存在，取而代之的是kubernetes中原生的namespace，可以为每个用户分别指定一个namespace，限制用户的资源quota；
-3. **细粒度的资源分配**：可以给每个spark任务指定资源限制，实际指定多少资源就使用多少资源，因为没有了像yarn那样的二层调度（圈地式的），所以可以更高效和细粒度的使用资源；
+1. **Kubernetes 原生调度 **：不再需要二层调度，直接使用 Kubernetes 的资源调度功能，跟其他应用共用整个 Kubernetes 管理的资源池；
+2. **资源隔离，粒度更细**：原先 YARN 中的 queue 在 Spark on Kubernetes 中已不存在，取而代之的是 Kubernetes 中原生的 namespace，可以为每个用户分别指定一个 namespace，限制用户的资源 quota；
+3. **细粒度的资源分配 **：可以给每个 spark 任务指定资源限制，实际指定多少资源就使用多少资源，因为没有了像 YARN那样的二层调度（圈地式的），所以可以更高效和细粒度的使用资源；
 4. **监控的变革**：因为做到了细粒度的资源分配，所以可以对用户提交的每一个任务做到资源使用的监控，从而判断用户的资源使用情况，所有的 metric 都记录在数据库中，甚至可以为每个用户的每次任务提交计量；
-5. **日志的变革**：用户不再通过yarn的web页面来查看任务状态，而是通过pod的log来查看，可将所有的kuberentes中的应用的日志等同看待收集起来，然后可以根据标签查看对应应用的日志；
+5. **日志的变革**：用户不再通过 YARN 的 web 页面来查看任务状态，而是通过 pod 的 log 来查看，可将所有的 Kuberentes 中的应用的日志等同看待收集起来，然后可以根据标签查看对应应用的日志；
 
 **如何提交任务**
 
@@ -476,4 +462,4 @@ Spark原生支持standalone、mesos和YARN资源调度，现已支持Kubernetes
 * [迁移到云原生应用架构指南 - jimmysong.io](https://jimmysong.io/migrating-to-cloud-native-application-architectures)
 * [Cloud Native Go - jimmysong.io](https://jimmysong.io/book/cloud-native-go/)
 * [Cloud Native Python - jimmysong.io](https://jimmysong.io/book/cloud-native-python/)
-* [Istio 官方文档（中文）- istio.io](https://istio.io/zh/)
+* [Istio 官方文档（中文）- istio.io](https://istio.io/latest/zh/)

concepts/custom-metrics-hpa.md

@@ -62,8 +62,7 @@ $ kubectl get --raw=apis/custom-metrics.metrics.k8s.io/v1alpha1
 
 ## 参考
 
-- [1.6以前版本的kubernetes中开启自定义HPA](https://medium.com/@marko.luksa/kubernetes-autoscaling-based-on-custom-metrics-without-using-a-host-port-b783ed6241ac)
-- [1.7版本的kubernetes中启用自定义HPA](https://docs.bitnami.com/kubernetes/how-to/configure-autoscaling-custom-metrics/)
-- [Horizontal Pod Autoscaler Walkthrough](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)
-- [Kubernetes 1.8: Now with 100% Daily Value of Custom Metrics](https://blog.openshift.com/kubernetes-1-8-now-custom-metrics/)
-- [Arbitrary/Custom Metrics in the Horizontal Pod Autoscaler#117](https://github.com/kubernetes/features/issues/117)
+- [1.6 以前版本的 kubernetes 中开启自定义 HPA - medium.com](https://medium.com/@marko.luksa/kubernetes-autoscaling-based-on-custom-metrics-without-using-a-host-port-b783ed6241ac)
+- [Horizontal Pod Autoscaler Walkthrough - kubernetes.io](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)
+- [Kubernetes 1.8: Now with 100% Daily Value of Custom Metrics - blog.openshift.com](https://blog.openshift.com/kubernetes-1-8-now-custom-metrics/)
+- [Arbitrary/Custom Metrics in the Horizontal Pod Autoscaler#117 - github.com](https://github.com/kubernetes/features/issues/117)

concepts/deployment.md

@@ -764,7 +764,7 @@ $ echo $?
 
 #### Rolling Update Deployment
 
-`.spec.strategy.type==RollingUpdate` 时，Deployment 使用 [rolling update](https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller) 的方式更新 Pod 。您可以指定 `maxUnavailable` 和 `maxSurge` 来控制 rolling update 进程。
+`.spec.strategy.type==RollingUpdate` 时，Deployment 使用 Rolling Update 的方式更新 Pod 。您可以指定 `maxUnavailable` 和 `maxSurge` 来控制 rolling update 进程。
 
 ##### Max Unavailable
 

concepts/pod-preset.md

@@ -41,7 +41,3 @@ Kubernetes 提供了一个准入控制器（`PodPreset`），当其启用时，P
 1. 您已启用 `settings.k8s.io/v1alpha1/podpreset` API 类型。例如，可以通过在 API server 的 `--runtime-config` 选项中包含 `settings.k8s.io/v1alpha1=true` 来完成此操作。
 2. 您已启用 `PodPreset` 准入控制器。 一种方法是将 `PodPreset` 包含在为 API server 指定的 `--admission-control` 选项值中。
 3. 您已经在要使用的命名空间中通过创建 `PodPreset` 对象来定义 `PodPreset`。
-
-## 更多资料
-
-- [使用 PodPreset 向 Pod 中注入数据](https://kubernetes.io/docs/tasks/inject-data-application/podpreset)

develop/advance-developer.md

@@ -24,7 +24,7 @@
 
 - Taint（污点）和 Toleration（容忍）：这些为节点“吸引”或“排斥” Pod 提供了一种方法。当需要将应用程序部署到特定硬件（例如用于科学计算的 GPU）时，经常使用它们。[阅读更多](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)。
 - **向下 API**：这允许您的容器使用有关自己或集群的信息，而不会过度耦合到 Kubernetes API server。这可以通过[环境变量](https://kubernetes.io/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) 或者 [DownwardAPIVolumeFiles](https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)。
-- **Pod 预设**：通常，要将运行时需求（例如环境变量、ConfigMap 和 Secret）安装到资源中，可以在资源的配置文件中指定它们。PodPresets 允许您在创建资源时动态注入这些需求。例如，这允许团队 A 将任意数量的新Secret 安装到团队 B 和 C 创建的资源中，而不需要 B 和 C 的操作。[请参阅示例](https://kubernetes.io/docs/tasks/inject-data-application/podpreset/)。
+- **Pod 预设**：通常，要将运行时需求（例如环境变量、ConfigMap 和 Secret）安装到资源中，可以在资源的配置文件中指定它们。PodPresets 允许您在创建资源时动态注入这些需求。例如，这允许团队 A 将任意数量的新Secret 安装到团队 B 和 C 创建的资源中，而不需要 B 和 C 的操作。
 
 #### 其他 API 对象
 

guide/kubernetes-security-best-practice.md

@@ -31,7 +31,7 @@
 
 ## Kubernetes 加固指南
 
-*Kubernetes Hardening Guidance*（[查看英文原版 PDF](https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES HARDENING GUIDANCE.PDF)） 是由美国国家安全局（NSA）于 2021 年 8 月发布的，详见[出版信息](https://jimmysong.io/kubernetes-hardening-guidance/publication-infomation.md)。其中文版《Kubernetes 加固指南》（或译作《Kubernetes 强化指南》）是由 [Jimmy Song](https://jimmysong.i/) 翻译，[点击在线阅读](https://jimmysong.io/kubernetes-hardening-guidance)，如您发现错误，欢迎在 [GitHub](https://github.com/rootsongjc/kubernetes-hardening-guidance) 上提交勘误（已知[勘误](https://jimmysong.io/kubernetes-hardening-guidance/corrigendum.html)）。
+*Kubernetes Hardening Guidance*（[查看英文原版 PDF](https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES HARDENING GUIDANCE.PDF)） 是由美国国家安全局（NSA）于 2021 年 8 月发布的，详见[出版信息](https://jimmysong.io/kubernetes-hardening-guidance/publication-infomation.md)。其中文版《Kubernetes 加固指南》（或译作《Kubernetes 强化指南》），可[在线阅读](https://jimmysong.io/kubernetes-hardening-guidance)。
 
 ## 参考
 

guide/secret-configuration.md

@@ -335,7 +335,7 @@ imagePullSecret 的使用在 [镜像文档](https://kubernetes.io/docs/concepts/
 
 #### 自动挂载手动创建的 Secret
 
-手动创建的 secret（例如包含用于访问 github 帐户的令牌）可以根据其服务帐户自动附加到 pod。请参阅 [使用 PodPreset 向 Pod 中注入信息](https://kubernetes.io/docs/tasks/run-application/podpreset) 以获取该进程的详细说明。
+手动创建的 secret（例如包含用于访问 github 帐户的令牌）可以根据其服务帐户自动附加到 pod。
 
 ## 详细
 

guide/tls-bootstrapping.md

@@ -1,4 +1,4 @@
-## TLS Bootstrap
+# TLS Bootstrap
 
 本文档介绍如何为 kubelet 设置 TLS 客户端证书引导（bootstrap）。
 

practice/network-and-cluster-perfermance-test.md

@@ -1,5 +1,7 @@
 # Kubernetes 网络和集群性能测试
 
+本节将通过构建一个 Kubernetes 测试环境，来测试其网络和集群性能。
+
 ## 准备
 
 **测试环境**
@@ -20,7 +22,7 @@ Ingress Host：traefik.sample-webapp.io
 
 **测试工具**
 
-- [Locust](http://locust.io)：一个简单易用的用户负载测试工具，用来测试web或其他系统能够同时处理的并发用户数。
+- [Locust](http://locust.io/)：一个简单易用的用户负载测试工具，用来测试 web 或其他系统能够同时处理的并发用户数。
 - curl
 - [kubemark](https://github.com/kubernetes/kubernetes/tree/master/test/e2e)
 - 测试程序：sample-webapp，源码见 Github [kubernetes 的分布式负载测试](https://github.com/rootsongjc/distributed-load-testing-using-kubernetes)
@@ -242,6 +244,8 @@ Vxlan会有一个封包解包的过程，所以会对网络性能造成较大的
 
 ## Kubernete的性能测试
 
+## Kubernete 的性能测试
+
 参考 [Kubernetes 集群性能测试](https://supereagle.github.io/2017/03/09/kubemark/)中的步骤，对 kubernetes 的性能进行测试。
 
 我的集群版本是 Kubernetes1.6.0，首先克隆代码，将 kubernetes 目录复制到 `$GOPATH/src/k8s.io/` 下然后执行：
@@ -344,7 +348,9 @@ Test Suite Passed
 
 从 `log.txt` 日志中还可以看到更多详细请求的测试指标。
 
-![kubernetes-dashboard](../images/kubenetes-e2e-test.jpg)
+![Kubernetes dashboard](../images/kubenetes-e2e-test.jpg)
+
+### 注意事项
 
 ### 注意事项
 
@@ -381,12 +387,10 @@ Locust模拟10万用户，每秒增长100个。
 
 ![locust测试页面](../images/kubernetes-locust-test.jpg)
 
-关于Locust的使用请参考Github：https://github.com/rootsongjc/distributed-load-testing-using-kubernetes
+关于 Locust 的使用请参考 [Github](https://github.com/rootsongjc/distributed-load-testing-using-kubernetes)。
 
 ## 参考
 
-- [基于 Python 的性能测试工具 locust (与 LR 的简单对比)](https://testerhome.com/topics/4839)
-- [Locust docs](http://docs.locust.io/en/latest/what-is-locust.html)
-- [Kubernetes集群性能测试](https://supereagle.github.io/2017/03/09/kubemark/)
-- [CoreOS是如何将Kubernetes的性能提高10倍的](http://dockone.io/article/1050)
-- [运用Kubernetes进行分布式负载测试](http://www.csdn.net/article/2015-07-07/2825155)
+- [Locust 文档 - docs.locust.io](http://docs.locust.io/en/latest/what-is-locust.html)
+- [Kubernetes 集群性能测试 - supereagle.github.io](https://supereagle.github.io/2017/03/09/kubemark/)
+- [CoreOS 是如何将 Kubernetes 的性能提高 10 倍的 - dockone.io](http://dockone.io/article/1050)

practice/rook.md

@@ -1,6 +1,6 @@
 # Rook
 
-[Rook](https://github.com/rook/rook)是一款云原生环境下的开源分布式存储编排系统，目前已进入CNCF孵化。Rook的官方网站是<https://rook.io>。
+[Rook](https://github.com/rook/rook) 是一款云原生环境下的开源分布式存储编排系统，目前已进入 CNCF 孵化。Rook 的官方网站是 [https://rook.io](https://rook.io/)。
 
 ## Rook 是什么？
 
@@ -138,7 +138,7 @@ parameters:
 
 ## 工具
 
-部署rook操作工具pod，该工具pod的yaml文件（rook-tools.yaml）如下：
+部署 Rook 操作工具 pod，该工具 pod 的 yaml 文件（rook-tools.yaml）如下：
 
 ```yaml
 apiVersion: v1
@@ -239,7 +239,7 @@ POOLS:
 
 ## 示例
 
-官方提供了使用rook作为典型的LAMP（Linux + Apache + MySQL + PHP）应用Wordpress的存储后端的示例的yaml文件`mysql.yaml`和`wordpress.yaml`，使用下面的命令创建。
+官方提供了使用 Rook 作为典型的 LAMP（Linux + Apache + MySQL + PHP）应用 Wordpress 的存储后端的示例的 yaml 文件 `mysql.yaml` 和 `wordpress.yaml`，使用下面的命令创建。
 
 ```bash
 kubectl apply -f mysql.yaml
@@ -263,5 +263,4 @@ helm delete daemonset rook-agent
 
 ## 参考
 
-- [Operator Helm Chart](https://rook.io/docs/rook/master/helm-operator.html)
-- [Creating Rook Clusters](https://rook.io/docs/rook/v0.6/cluster-crd.html)
+- [Creating Rook Clusters - rook.io](https://rook.io/docs/rook/v0.6/cluster-crd.html)

practice/storage-for-containers-using-glusterfs-with-openshift.md

@@ -1,18 +1,5 @@
 # 在 OpenShift 中使用 GlusterFS 做持久化存储
 
-### 概述
-
-本文由Daniel Messer（Technical Marketing Manager Storage @RedHat）和Keith Tenzer（Solutions Architect @RedHat）共同撰写。
-
-- [Storage for Containers Overview – Part I](https://keithtenzer.com/2017/03/07/storage-for-containers-overview-part-i/)
-- [Storage for Containers using Gluster – Part II](https://keithtenzer.com/2017/03/24/storage-for-containers-using-gluster-part-ii/)
-- [Storage for Containers using Container Native Storage – Part III](https://keithtenzer.com/2017/03/29/storage-for-containers-using-container-native-storage-part-iii/)
-- [Storage for Containers using Ceph – Part IV](https://keithtenzer.com/2017/04/07/storage-for-containers-using-ceph-rbd-part-iv/)
-- [Storage for Containers using NetApp ONTAP NAS – Part V](https://keithtenzer.com/2017/04/05/storage-for-containers-using-netapp-ontap-nas-part-v/)
-- [Storage for Containers using NetApp SolidFire – Part VI](https://keithtenzer.com/2017/04/05/storage-for-containers-using-netapp-solidfire-part-vi/)
-
-### Gluster作为Container-Ready Storage(CRS)
-
 在本文中，我们将介绍容器存储的首选以及如何部署它。 Kusternet 和 OpenShift 支持 GlusterFS 已经有一段时间了。 GlusterFS 的适用性很好，可用于所有的部署场景：裸机、虚拟机、内部部署和公共云。 在容器中运行 GlusterFS 的新特性将在本系列后面讨论。
 
 GlusterFS 是一个分布式文件系统，内置了原生协议（GlusterFS）和各种其他协议（NFS，SMB，...）。 为了与 OpenShift 集成，节点将通过 FUSE 使用原生协议，将 GlusterFS 卷挂在到节点本身上，然后将它们绑定到目标容器中。 OpenShift / Kubernetes 具有实现请求、释放和挂载、卸载 GlusterFS 卷的原生程序。
@@ -156,9 +143,6 @@ StandardError=syslog
 
 [Install]
 WantedBy=multi-user.target
-```
-
-```bash
 [root@crs-node1 ~]# systemctl daemon-reload
 [root@crs-node1 ~]# systemctl start heketi
 ```
@@ -438,8 +422,6 @@ Source:
     ReadOnly:        false
 ```
 
-What happened in the background was that when the PVC reached the system, our default StorageClass reached out to the GlusterFS Provisioner with the volume specs from the PVC. The provisioner in turn communicates with our heketi instance which facilitates the creation of the GlusterFS volume, which we can trace in it’s log messages:
-
 该 volume 是根据 PVC 中的定义特别创建的。 在 PVC 中，我们没有明确指定要使用哪个 StorageClass，因为 heketi 的 GlusterFS StorageClass 已经被定义为系统范围的默认值。
 
 在后台发生的情况是，当 PVC 到达系统时，默认的 StorageClass 请求具有该 PVC 中 volume 声明规格的 GlusterFS Provisioner。 Provisioner 又与我们的 heketi 实例通信，这有助于创建 GlusterFS volume，我们可以在其日志消息中追踪：
@@ -493,7 +475,7 @@ nfs.disable: on
 
 ![创建存储](../images/create-gluster-storage.png)
 
-![Screen Shot 2017-03-24 at 11.09.34.png](https://keithtenzer.files.wordpress.com/2017/03/screen-shot-2017-03-24-at-11-09-341.png?w=440)
+![容器存储](../images/container-storage.png)
 
 让我们做点更有趣的事情，在 OpenShift 中运行工作负载。
 
@@ -652,8 +634,6 @@ o这就是我们如何将存储带入DevOps世界 - 无痛苦，并在OpenShift
 
 GlusterFS 和 OpenShift 可跨越所有环境：裸机，虚拟机，私有和公共云（Azure，Google Cloud，AWS ...），确保应用程序可移植性，并避免云供应商锁定。
 
-祝你愉快在容器中使用GlusterFS！
+---
 
-(c) 2017 Keith Tenzer
-
-原文链接：https://keithtenzer.com/2017/03/24/storage-for-containers-using-gluster-part-ii/
+本文由译自 Daniel Messer（Technical Marketing Manager Storage @RedHat）和Keith Tenzer（Solutions Architect @RedHat）共同撰写文章，原文已无法访问。

usecases/envoy-front-proxy.md

@@ -19,11 +19,11 @@ Envoy 官方提供了以下打包用例：
 - [Jaeger Tracing](https://www.envoyproxy.io/docs/envoy/latest/start/sandboxes/jaeger_tracing)
 - [gRPC Bridge](https://www.envoyproxy.io/docs/envoy/latest/start/sandboxes/grpc_bridge)
 
-全部可以使用 `docker-compose` 运行，代码可以在 https://github.com/envoyproxy/envoy/tree/master/examples 找到。
+全部可以使用 `docker-compose` 运行，代码可以在 [GitHub](https://github.com/envoyproxy/envoy/tree/master/examples) 找到。
 
 ## Front proxy
 
-Envoy 在 envoymesh 的边缘做反向代理，详细使用方式见 <https://www.envoyproxy.io/docs/envoy/latest/start/sandboxes/front_proxy>，在此我将解说下以下问题：
+Envoy 在 Envoy mesh 的边缘做反向代理，详细使用方式见 [Envoy 文档](https://www.envoyproxy.io/docs/envoy/latest/start/sandboxes/front_proxy)，在此我将解说下以下问题：
 
 - Envoy 是如何作为进程外架构运行的？
 - 为何说 Envoy 是无侵入式架构？
@@ -292,8 +292,8 @@ Hello from behind Envoy (service 1)! hostname: c5b9f1289e0f resolvedhostname: 17
 | /stats               | 打印服务器状态统计信息                   |
 | /stats/prometheus    | 打印 prometheus 格式的服务器状态统计信息 |
 
-Envoy 提供了 API 管理端点，可以对 Envoy 进行动态配置，参考 [v2 API reference](https://www.envoyproxy.io/docs/envoy/latest/api-v2/api)。
+Envoy 提供了 API 管理端点，可以对 Envoy 进行动态配置。
 
 ## 参考
 
-- [Front proxy](https://www.envoyproxy.io/docs/envoy/latest/start/sandboxes/front_proxy)
+- [Front proxy - envoyproxy.io](https://www.envoyproxy.io/docs/envoy/latest/start/sandboxes/front_proxy)

usecases/how-to-integrate-istio-with-vm.md

@@ -32,7 +32,7 @@ Istio 社区和 [Tetrate](https://www.tetrate.io/) 在 Istio 对虚拟机的支
 
 ## Demo
 
-在下面这个 demo 中我们将使在 GKE 中部署 Istio 并运行 bookinfo 示例，其中 ratings 服务的后端使用的是部署在虚拟机上的 MySQL，该示例可以在 [Istio 官方文档](https://istio.io/latest/docs/examples/virtual-machines/bookinfo/)中找到，我作出了部分改动，最终的流量路由如下图所示。
+在下面这个 demo 中我们将使在 GKE 中部署 Istio 并运行 bookinfo 示例，其中 ratings 服务的后端使用的是部署在虚拟机上的 MySQL，流量路由如下图所示。
 
 ![Bookinfo 示例中的流量示意图](../images/istio-bookinfo-vm-traffic.jpg)
 
@@ -56,6 +56,5 @@ Istio 社区和 [Tetrate](https://www.tetrate.io/) 在 Istio 对虚拟机的支
 ## 参考阅读
 
 - [Virtual Machine Installation - istio.io](https://istio.io/latest/docs/setup/install/virtual-machine/)
-- [Virtual Machines in Single-Network Meshes - istio.io](https://istio.io/latest/docs/examples/virtual-machines/single-network/)
 - [Istio: Bringing VMs into the Mesh (with Cynthia Coan) - tetrate.io](https://www.tetrate.io/blog/istio-bringing-vms-into-the-mesh-with-cynthia-coan/)
 - [Bridging Traditional and Modern Workloads - tetrate.io](https://www.tetrate.io/blog/bridging-traditional-and-modern-workloads/)

usecases/serverless.md

@@ -50,7 +50,7 @@ Serverless架构明显比其他架构更简单。更少的组件，就意味着
 - [kubeless](https://github.com/kubeless/kubeless) - Kubernetes Native Serverless Framework [http://kubeless.io](http://kubeless.io/)
 - [OpenWhisk](http://openwhisk.incubator.apache.org/) -  Apache OpenWhisk (Incubating) is a serverless, open source cloud platform that executes functions in response to events at any scale.
 
-以上项目收录于 [awsome-cloud-native](https://github.com/rootsongjc/awesome-cloud-native)。
+更多 Serverless 项目请见 [awsome-cloud-native](https://github.com/rootsongjc/awesome-cloud-native)。
 
 ## FaaS
 
@@ -60,9 +60,8 @@ Function-as-a-Service景观图（图片来自`https://github.com/amyers1793/Func
 
 ## 参考
 
-- [Why Serverless? - serverless.com](https://serverless.com/learn/)
-- [Serverless Architectures - Martin Fowler](https://martinfowler.com/articles/serverless.html)
-- [Serverless架构综述](http://dockone.io/article/1460)
-- [2017年会是Serverless爆发之年吗？](http://www.infoq.com/cn/news/2017/04/2017-Serverless)
-- [从IaaS到FaaS—— Serverless架构的前世今生](https://aws.amazon.com/cn/blogs/china/iaas-faas-serverless/)
-- [Introducing Redpoint's FaaS Landscape](https://medium.com/memory-leak/this-year-gartner-added-serverless-to-its-hype-cycle-of-emerging-technologies-reflecting-the-5dfe43d818f0)
+- [Serverless Architectures - martinfowler.com](https://martinfowler.com/articles/serverless.html)
+- [Serverless 架构综述 - dockone.io](http://dockone.io/article/1460)
+- [2017 年会是 Serverless 爆发之年吗？- infoq.cn](https://www.infoq.cn/news/2017/04/2017-Serverless/)
+- [从 IaaS 到 FaaS—— Serverless 架构的前世今生 - aws.amazon.com](https://aws.amazon.com/cn/blogs/china/iaas-faas-serverless/)
+- [Introducing Redpoint's FaaS Landscape - medium.com](https://medium.com/memory-leak/this-year-gartner-added-serverless-to-its-hype-cycle-of-emerging-technologies-reflecting-the-5dfe43d818f0)

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

@@ -9,13 +9,6 @@
 - Sidecar proxy 是如何做透明流量劫持的？
 - 流量是如何路由到 upstream 的？
 
-在此之前我曾写过基于 Istio 1.1 版本的[理解 Istio Service Mesh 中 Envoy 代理 Sidecar 注入及流量劫持](/blog/envoy-sidecar-injection-in-istio-service-mesh-deep-dive/)，Istio 1.5 与 Istio 1.1 中的 sidecar 注入和流量劫持环节最大的变化是：
-
-- iptables 改用命令行工具，不再使用 shell 脚本。
-- sidecar inbound 和 outbound 分别指定了端口，而之前是使用同一个端口（15001）。
-
-注：本文中部分内容收录于 ServiceMesher 社区出品的 [Istio Handbook](https://www.servicemesher.com/istio-handbook/)。
-
 ## Sidecar 模式
 
 将应用程序的功能划分为单独的进程运行在同一个最小调度单元中（例如 Kubernetes 中的 Pod）可以被视为 **sidecar 模式**。如下图所示，sidecar 模式允许您在应用程序旁边添加更多功能，而无需额外第三方组件配置或修改应用程序代码。
@@ -402,8 +395,6 @@ Init 容器中使用的的 iptables 版本是 `v1.6.0`，共包含 5 张表：
 | POSTROUTING |      |        | ✓    | ✓      |          |
 | FORWARD     | ✓    | ✓      |      | ✓      | ✓        |
 
-关于 iptables 的详细介绍请参考[常见 iptables 使用规则场景整理](https://www.aliang.org/Linux/iptables.html)。
-
 ### 理解 iptables 规则
 
 查看 `istio-proxy` 容器中的默认的 iptables 规则，默认查看的是 filter 表中的规则。
@@ -438,8 +429,6 @@ Chain OUTPUT (policy ACCEPT 18M packets, 1916M bytes)
 
 还有一列没有表头，显示在最后，表示规则的选项，作为规则的扩展匹配条件，用来补充前面的几列中的配置。`prot`、`opt`、`in`、`out`、`source` 和 `destination` 和显示在 `destination` 后面的没有表头的一列扩展条件共同组成匹配规则。当流量匹配这些规则后就会执行 `target`。
 
-关于 iptables 规则请参考[常见 iptables 使用规则场景整理](https://www.aliang.org/Linux/iptables.html)。
-
 **target 支持的类型**
 
 `target` 类型包括 ACCEPT`、REJECT`、`DROP`、`LOG` 、`SNAT`、`MASQUERADE`、`DNAT`、`REDIRECT`、`RETURN` 或者跳转到其他规则等。只要执行到某一条链中只有按照顺序有一条规则匹配后就可以确定报文的去向了，除了 `RETURN` 类型，类似编程语言中的 `return` 语句，返回到它的调用点，继续执行下一条规则。`target` 支持的配置详解请参考 [iptables 详解（1）：iptables 概念](http://www.zsythink.net/archives/1199)。