Fix broken links

Fix the broken internal and external links
2018-09-25 22:09:51 +08:00 · 2018-09-25 22:09:51 +08:00 · 6f07aa85a3
parent 723d6cdeec
commit 6f07aa85a3
89 changed files with 358 additions and 464 deletions
--- a/appendix/about-cka-candidate.md
+++ b/appendix/about-cka-candidate.md
@ -70,9 +70,6 @@
  - 排查工作节点（work node）故障
  - 排查网络故障

-
->  参考[课程大纲](https://github.com/cncf/curriculum/blob/master/certified_kubernetes_administrator_exam_V0.9.pdf)
-
 ## 考试说明和checklist

 - 注册考试
@ -139,8 +136,6 @@ kubectl   get   no   −l   name=hk8s−node−1   −−context=hk8s
 10. 取消和重订
 >  在预定考试日期前24小时外，取消或重订， 可以获得完整退费

-> 参考 [CNCF_FAQ](https://www.cncf.io/certification/expert/faq/)
-
 ## 复习资料

 - [Kubernetes-Learning-Resources](https://github.com/kubernauts/Kubernetes-Learning-Resources)
--- a/appendix/docker-best-practice.md
+++ b/appendix/docker-best-practice.md
@ -5,22 +5,22 @@

 ## 环境配置

-[Docker1.13环境配置](https://jimmysong.io/docker-handbook/docs/docker_env)
+- [Docker1.13环境配置](https://jimmysong.io/docker-handbook/docs/docker_env)

-[docker源码编译](https://jimmysong.io/docker-handbook/docs/docker_compile)
+- [docker源码编译](https://jimmysong.io/docker-handbook/docs/docker_compile)


 ## 网络管理

 网络配置和管理是容器使用中的的一个重点和难点，对比我们之前使用的docker版本是1.11.1，docker1.13中网络模式跟之前的变动比较大，我们会花大力气讲解。

-[如何创建docker network](https://jimmysong.io/docker-handbook/docs/create_network)
+- [如何创建docker network](https://jimmysong.io/docker-handbook/docs/create_network)

-[Rancher网络探讨和扁平网络实现](https://jimmysong.io/docker-handbook/docs/rancher_network)
+- [Rancher网络探讨和扁平网络实现](https://jimmysong.io/docker-handbook/docs/rancher_network)

-[swarm mode的路由网络](https://jimmysong.io/docker-handbook/docs/swarm_mode_routing_mesh)
+- [swarm mode的路由网络](https://jimmysong.io/docker-handbook/docs/swarm_mode_routing_mesh)

-[docker扁平化网络插件Shrike（基于docker1.11）](https://github.com/TalkingData/shrike)
+- [docker扁平化网络插件Shrike（基于docker1.11）](https://github.com/TalkingData/shrike)

 ## 存储管理

@ -31,8 +31,6 @@
 - [torus](https://jimmysong.io/docker-handbook/docs/torus) **已废弃**
 - [flocker](https://jimmysong.io/docker-handbook/docs/flocker) ClusterHQ开发

-
-
 ## 日志管理

 Docker提供了一系列[log drivers](https://docs.docker.com/engine/admin/logging/overview/)，如fluentd、journald、syslog等。
@ -41,13 +39,13 @@ Docker提供了一系列[log drivers](https://docs.docker.com/engine/admin/loggi

 ## 创建应用

-官方文档：[Docker swarm sample app overview](https://docs.docker.com/engine/getstarted-voting-app/)
+- 官方文档：[Docker swarm sample app overview](https://docs.docker.com/engine/getstarted-voting-app/)

-[基于docker1.13手把手教你创建swarm app](https://jimmysong.io/docker-handbook/docs/create_swarm_app)
+- [基于docker1.13手把手教你创建swarm app](https://jimmysong.io/docker-handbook/docs/create_swarm_app)

-[swarm集群应用管理](https://jimmysong.io/docker-handbook/docs/swarm_app_manage)
+- [swarm集群应用管理](https://jimmysong.io/docker-handbook/docs/swarm_app_manage)

-[使用docker-compose创建应用](https://jimmysong.io/docker-handbook/docs/docker_compose)
+- [使用docker-compose创建应用](https://jimmysong.io/docker-handbook/docs/docker_compose)

 ## 集群管理##

@ -60,17 +58,17 @@ Docker提供了一系列[log drivers](https://docs.docker.com/engine/admin/loggi
 - [Crane](https://github.com/Dataman-Cloud/crane)：由数人云开源的基于swarmkit的容器管理软件，可以作为docker和go语言开发的一个不错入门项目
 - [Rancher](https://github.com/rancher/rancher):Rancher是一个企业级的容器管理平台，可以使用Kubernetes、swarm和rancher自研的cattle来管理集群。

-[Crane的部署和使用](https://jimmysong.io/docker-handbook/docs/crane_usage)
+- [Crane的部署和使用](https://jimmysong.io/docker-handbook/docs/crane_usage)

-[Rancher的部署和使用](https://jimmysong.io/docker-handbook/docs/rancher_usage)
+- [Rancher的部署和使用](https://jimmysong.io/docker-handbook/docs/rancher_usage)

 ## 资源限制

-[内存资源限制](https://jimmysong.io/docker-handbook/docs/memory_resource_limit)
+- [内存资源限制](https://jimmysong.io/docker-handbook/docs/memory_resource_limit)

-[CPU资源限制](https://jimmysong.io/docker-handbook/docs/cpu_resource_limit)
+- [CPU资源限制](https://jimmysong.io/docker-handbook/docs/cpu_resource_limit)

-[IO资源限制](https://jimmysong.io/docker-handbook/docs/io_resource_limit)
+- [IO资源限制](https://jimmysong.io/docker-handbook/docs/io_resource_limit)

 ## 服务发现

@ -105,15 +103,15 @@ Docker提供了一系列[log drivers](https://docs.docker.com/engine/admin/loggi

 ## 业界使用案例

-[京东从OpenStack切换到Kubernetes的经验之谈](https://jimmysong.io/docker-handbook/docs/jd_transform_to_kubernetes)
+- [京东从OpenStack切换到Kubernetes的经验之谈](https://jimmysong.io/docker-handbook/docs/jd_transform_to_kubernetes)

-[美团点评容器平台介绍](https://jimmysong.io/docker-handbook/docs/meituan_docker_platform)
+- [美团点评容器平台介绍](https://jimmysong.io/docker-handbook/docs/meituan_docker_platform)

-[阿里超大规模docker化之路](https://jimmysong.io/docker-handbook/docs/ali_docker)
+- [阿里超大规模docker化之路](https://jimmysong.io/docker-handbook/docs/ali_docker)

-[TalkingData-容器技术在大数据场景下的应用Yarn on Docker](http://rootsongjc.github.io/projects/yarn-on-docker/)
+- [TalkingData-容器技术在大数据场景下的应用Yarn on Docker](https://jimmysong.io/posts/yarn-on-docker/)

-[乐视云基于Kubernetes的PaaS平台建设](https://jimmysong.io/docker-handbook/docs/letv_docker)
+- [乐视云基于Kubernetes的PaaS平台建设](https://jimmysong.io/docker-handbook/docs/letv_docker)

 ## 资源编排

@ -123,14 +121,14 @@ Docker提供了一系列[log drivers](https://docs.docker.com/engine/admin/loggi

 ## 相关资源

-[容器技术工具与资源](https://jimmysong.io/docker-handbook/docs/tech_resource)
+- [容器技术工具与资源](https://jimmysong.io/docker-handbook/docs/tech_resource)

-[容器技术2016年总结](https://jimmysong.io/docker-handbook/docs/container_2016)
+- [容器技术2016年总结](https://jimmysong.io/docker-handbook/docs/container_2016)

 ## 关于

-Author: [Jimmy Song](https://jimmysong.io/about)
+- Author：[Jimmy Song](https://jimmysong.io/about)

-rootsongjc@gmail.com
+- Email：rootsongjc@gmail.com

 更多关于**Docker**、**MicroServices**、**Big Data**、**DevOps**、**Deep Learning**的内容请关注[Jimmy Song's Blog](https://jimmysong.io)，将不定期更新。
--- a/appendix/issues.md
+++ b/appendix/issues.md
@ -36,8 +36,6 @@ kubelet启动时报错systemd版本不支持start a slice as transient unit。

 与[kubeadm init waiting for the control plane to become ready on CentOS 7.2 with kubeadm 1.6.1 #228](https://github.com/kubernetes/kubeadm/issues/228)类似。

-另外有一个使用systemd管理kubelet的[proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/kubelet-systemd.md)。
-
 ## 4.kube-proxy报错kube-proxy[2241]: E0502 15:55:13.889842    2241 conntrack.go:42] conntrack returned error: error looking for path of conntrack: exec: "conntrack": executable file not found in $PATH

 **导致的现象**
@ -126,12 +124,6 @@ kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"templat
 - [Helm: Error: no available release name found - StackOverflow](https://stackoverflow.com/questions/43499971/helm-error-no-available-release-name-found)
 - [Helm 2.2.3 not working properly with kubeadm 1.6.1 default RBAC rules #2224](https://github.com/kubernetes/helm/issues/2224)

-
-
 ## 参考

-[Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
-
-[Resource Design Proposals](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resources.md)
-
-[Helm: Error: no available release name found]()
+- [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
--- a/appendix/kubernetes-1.7-changelog.md
+++ b/appendix/kubernetes-1.7-changelog.md
@ -15,7 +15,7 @@
 - [Network Policy API](https://kubernetes.io/docs/concepts/services-networking/network-policies/) 提升为稳定版本。用户可以通过使用网络插件实现的网络策略来控制哪些Pod之间能够互相通信。
 - [节点授权](https://kubernetes.io/docs/admin/authorization/node/)和准入控制插件是新增加的功能，可以用于限制kubelet可以访问的secret、pod和其它基于节点的对象。
 - [加密的Secret](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)和etcd中的其它资源，现在是alpha版本。
- [Kubelet TLS bootstrapping](https://kubernetes.io/docs/admin/kubelet-tls-bootstrapping/)现在支持客户端和服务器端的证书轮换。
+- Kubelet TLS bootstrapping 现在支持客户端和服务器端的证书轮换。
 - 由API server存储的[审计日志](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/)现在更具可定制性和可扩展性，支持事件过滤和webhook。它们还为系统审计提供更丰富的数据。

 **有状态负载**
--- a/appendix/kubernetes-1.8-changelog.md
+++ b/appendix/kubernetes-1.8-changelog.md
@ -6,7 +6,7 @@

 Kubernetes1.8的[基于角色的访问控制（RBAC）](https://en.wikipedia.org/wiki/Role-based_access_control)成为stable支持。RBAC允许集群管理员[动态定义角色](https://kubernetes.io/docs/admin/authorization/rbac/)对于Kubernetes API的访问策略。通过[网络策略](https://kubernetes.io/docs/concepts/services-networking/network-policies/)筛选出站流量的Beta支持，增强了对入站流量进行过滤的现有支持。 RBAC和网络策略是强化Kubernetes内组织和监管安全要求的两个强大工具。

-Kubelet的传输层安全性（TLS）[证书轮换](https://kubernetes.io/docs/admin/kubelet-tls-bootstrapping/)成为beta版。自动证书轮换减轻了集群安全性运维的负担。
+Kubelet的传输层安全性（TLS）证书轮换成为beta版。自动证书轮换减轻了集群安全性运维的负担。

 ## 聚焦工作负载支持

--- a/appendix/kubernetes-and-cloud-native-summary-in-2017-and-outlook-for-2018.md
+++ b/appendix/kubernetes-and-cloud-native-summary-in-2017-and-outlook-for-2018.md
@ -12,7 +12,7 @@ Kubernetes是谷歌根据其内部使用的Borg改造成一个通用的容器编

 ### Kubernetes发展历史

-相信凡是关注容器生态圈的人都不会否认，Kubernetes已经成为容器编排调度的实际标准，不论Docker官方还是Mesos都已经支持Kubernetes，Docker公司在今年10月16日至19日举办的DockerCon EU 2017大会上宣布支持Kubernetes调度，就在这不久前Mesos的商业化公司Mesosphere的CTO Tobi Knaup也在官方博客中宣布[Kubernetes on DC/OS](kubectl get --raw=apis/|python -m json.tool)。而回想下2016年时，我们还在为Swarm、Mesos、Kubernetes谁能够在容器编排调度大战中胜出而猜测时，而经过不到一年的发展，Kubernetes就以超过70%的市场占有率（据[TheNewStack](https://www.thenewstack.io)的调研报告）将另外两者遥遥的甩在了身后，其已经在大量的企业中落地，还有一些重量级的客户也宣布将服务迁移到Kubernetes上，比如GitHub（见[Kubernetes at GitHub](https://githubengineering.com/kubernetes-at-github/)），还有eBay、彭博社等。
+相信凡是关注容器生态圈的人都不会否认，Kubernetes已经成为容器编排调度的实际标准，不论Docker官方还是Mesos都已经支持Kubernetes，Docker公司在今年10月16日至19日举办的DockerCon EU 2017大会上宣布支持Kubernetes调度，就在这不久前Mesos的商业化公司Mesosphere的CTO Tobi Knaup也在官方博客中宣布Kubernetes on DC/OS。而回想下2016年时，我们还在为Swarm、Mesos、Kubernetes谁能够在容器编排调度大战中胜出而猜测时，而经过不到一年的发展，Kubernetes就以超过70%的市场占有率（据[TheNewStack](https://www.thenewstack.io)的调研报告）将另外两者遥遥的甩在了身后，其已经在大量的企业中落地，还有一些重量级的客户也宣布将服务迁移到Kubernetes上，比如GitHub（见[Kubernetes at GitHub](https://githubengineering.com/kubernetes-at-github/)），还有eBay、彭博社等。

 Kubernetes自2014年由Google开源以来，至今已经发展到了1.9版本，下面是Kubernetes的版本发布路线图：

--- a/appendix/material-share.md
+++ b/appendix/material-share.md
@ -40,7 +40,6 @@ Kubernetes和Cloud Native相关网站、专栏、博客等。

 ### 博客

- [apcera](https://www.apcera.com/blog)
 - [aporeto](https://www.aporeto.com/blog/)
 - [applatix](https://applatix.com/blog/)
 - [apprenda](https://apprenda.com/blog/)
@ -52,7 +51,6 @@ Kubernetes和Cloud Native相关网站、专栏、博客等。
 - [containership](https://blog.containership.io/)
 - [coreos](https://coreos.com/blog/)
 - [coscale](https://www.coscale.com/blog)
- [deis](https://deis.com/blog/)
 - [fabric8](https://blog.fabric8.io/)
 - [grafana](https://grafana.com/blog/)
 - [gravitational](https://gravitational.com/blog/)
--- a/cloud-native/cloud-native-local-quick-start.md
+++ b/cloud-native/cloud-native-local-quick-start.md
@ -139,7 +139,7 @@ kubectl apply -f addon/heapster/
 172.17.8.102 grafana.jimmysong.io
 ```

-访问Grafana：<http://grafana.jimmysong.io>
+访问Grafana：`http://grafana.jimmysong.io`

 ![Grafana](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster/raw/master/images/grafana-animation.gif)

@ -207,14 +207,14 @@ istioctl create -f yaml/istio-bookinfo/bookinfo-gateway.yaml

 | Service      | URL                                                          |
 | ------------ | ------------------------------------------------------------ |
-| grafana      | http://grafana.istio.jimmysong.io                            |
-| servicegraph | http://servicegraph.istio.jimmysong.io/dotviz>, <http://servicegraph.istio.jimmysong.io/graph>,http://servicegraph.istio.jimmysong.io/force/forcegraph.html |
-| tracing      | http://172.17.8.101:$JAEGER_PORT                             |
-| productpage  | http://172.17.8.101:$GATEWAY_PORT/productpage                |
+| grafana      | `http://grafana.istio.jimmysong.io`                          |
+| servicegraph | `http://servicegraph.istio.jimmysong.io/dotviz`, `http://servicegraph.istio.jimmysong.io/graph`, `http://servicegraph.istio.jimmysong.io/force/forcegraph.htm` |
+| tracing      | `http://172.17.8.101:$JAEGER_PORT`                           |
+| productpage  | `http://172.17.8.101:$GATEWAY_PORT/productpage`              |

 **注意**：`JAEGER_PORT`可以通过`kubectl -n istio-system get svc tracing -o jsonpath='{.spec.ports[0].nodePort}'`获取，`GATEWAY_PORT`可以通过`kubectl -n istio-system get svc istio-ingressgateway -o jsonpath='{.spec.ports[0].nodePort}'`获取。

-详细信息请参阅 https://istio.io/docs/guides/bookinfo.html
+详细信息请参阅 https://istio.io/zh/docs/examples/bookinfo/

 ![bookinfo示例](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster/raw/master/images/bookinfo-demo.gif)

@ -241,7 +241,7 @@ kubectl -n default port-forward $(kubectl -n default get pod -l app=vistio-web -

 ### Kiali

-Kiali是一个用于提供Istio service mesh观察性的项目，更多信息请查看[https://kiali.io](https://kiali.io/)。
+Kiali是一个用于提供Istio service mesh观察性的项目，更多信息请查看 [https://kiali.io](https://kiali.io/)。

 在本地该项目的根路径下执行下面的命令：

@ -255,7 +255,7 @@ kubectl apply -n istio-system -f addon/kiali

 ### 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集群，详情见 https://www.weave.works/oss/scope/ 

 在本地该项目的根路径下执行下面的命令：

@ -269,7 +269,7 @@ kubectl apply -f addon/weave-scope
 172.17.8.102 scope.weave.jimmysong.io
 ```

-现在打开浏览器，访问http://scope.weave.jimmysong.io/
+现在打开浏览器，访问 `http://scope.weave.jimmysong.io/`

 ![Kiali动画](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster/raw/master/images/weave-scope-animation.gif)

--- a/cloud-native/cloud-native-programming-languages.md
+++ b/cloud-native/cloud-native-programming-languages.md
@ -1,6 +1,6 @@
 # 云原生编程语言

-> 以下内容来自Joe Duffy的博客，[Hello, Pulumi!](joeduffyblog.com/2018/06/18/hello-pulumi/)。他说这些是为了说明为什么要创造Pulumi，在此我引用它说明为什么会有云原生编程语言。
+> 以下内容来自Joe Duffy的博客，[Hello, Pulumi!](http://joeduffyblog.com/2018/06/18/hello-pulumi/)。他说这些是为了说明为什么要创造Pulumi，在此我引用它说明为什么会有云原生编程语言。

 对于每一个serverless函数来说，我都要写几十行的JSON或者YAML配置。要链接到一个API端点，我还要学习晦涩的概念，执行一系列复制-粘贴的低级工作。如果我想在本机上运行一个小的集群的话，那么Docker还是很棒的，但是如果要在生产上使用的话，那么就要手动管理etcd集群，配置网络和iptables路由表，还有一系列与我的应用程序本身不相干的事情。不过Kubernetes的出现至少让我可以配置一次下次就可以跨云平台重用，但这还是会分散开发人员的精力。

--- a/cloud-native/cncf-charter.md
+++ b/cloud-native/cncf-charter.md
@ -162,7 +162,7 @@ CNCF 技术监督委员会，为了保持中立，则达成了以下共识：
   - 理事会、最终用户TAB和TOC应确定提名、投票和关于TOC选举提名和选举过程的任何其他细节的时间表和日期。
   - 评估期间最少保留14个日历日，TOC 提名者可以联系和/或评估候选人。
 3. 选举：评估期结束后，理事会、最终用户标签和最初的7位TOC成员应分别对每位被候选人进行表决。有效投票需要满足会议法定人数所需的选票数量。每名被候选人均需要支持超过50％的投票人数，以确认被提名者符合资格标准。以多数票通过的候选人应为合格的 TOC 成员。
-4. 如果合格的被提名者的人数等于或少于可选 TOC 席位的数量，则此被提名者应在提名期结束后获得批准。如果有更多的合格被候选人比理事会，最终用户TAB或TOC可选的开放TOC席位多，那么该组应通过Condorcet投票选出TOC成员。Condorcet投票应通过康奈尔在线服务（http://civs.cs.cornell.edu/）使用Condorcet-IRV方法运行。
+4. 如果合格的被提名者的人数等于或少于可选 TOC 席位的数量，则此被提名者应在提名期结束后获得批准。如果有更多的合格被候选人比理事会，最终用户TAB或TOC可选的开放TOC席位多，那么该组应通过Condorcet投票选出TOC成员。Condorcet投票应通过康奈尔在线服务（<http://civs.cs.cornell.edu/>）使用Condorcet-IRV方法运行。
 5. 如果理事会，最终用户TAB或TOC可供选举的公开TOC席位的合格被候选人数较少，该小组将启动另一轮提名，每名成员或个人有资格提名至多提名1名候选人。

 ### f) 约束条件
--- a/cloud-native/cncf.md
+++ b/cloud-native/cncf.md
@ -10,7 +10,7 @@ CNCF作为一个厂商中立的基金会，致力于Github上的快速成长的

 其中包含了CNCF中托管的项目，还有很多是非CNCF项目。

-关于CNCF的使命与组织方式请参考[CNCF宪章](https://www.cncf.io/about/charter/)，概括的讲CNCF的使命包括以下三点：
+关于CNCF的使命与组织方式请参考[CNCF章程](https://www.cncf.io/about/charter/)，概括的讲CNCF的使命包括以下三点：

 * 容器化包装。
 * 通过中心编排系统的动态资源管理。
@ -61,7 +61,6 @@ TOC成员通过选举产生，见[选举时间表](https://github.com/cncf/toc/b
 ## 参考

 * [https://www.cncf.io](https://www.cncf.io)
-* [https://www.cncf.io/projects/graduation-criteria/](https://www.cncf.io/projects/graduation-criteria/)
 * [https://www.cncf.io/about/charter/](https://www.cncf.io/about/charter/)
 * [https://github.com/cncf/landscape](https://github.com/cncf/landscape)
 * [https://github.com/cncf/toc](https://github.com/cncf/toc)
--- a/cloud-native/kubernetes-and-cloud-native-app-overview.md
+++ b/cloud-native/kubernetes-and-cloud-native-app-overview.md
@ -359,7 +359,7 @@ 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 的内容请访问 [Service Mesh 中文网](http://www.servicemesh.cn)。
+更多关于 Service Mesh 的内容请访问 [ServiceMesher 社区网站](http://www.servicemesher.com)。

 ## 使用案例

--- a/cloud-native/the-future-of-cloud-native.md
+++ b/cloud-native/the-future-of-cloud-native.md
@ -80,13 +80,13 @@ Kubernetes中的基本资源类型分成了三类：

 在最近一届的KubeCon & CloudNativeCon上Operator已经变得越来越流行。下面是OpenEBS的一个使用Operator的例子。

-![](https://ws1.sinaimg.cn/large/00704eQkgy1frr56m7z2sj31y010y17y.jpg)
+![OpenEBS 控制平面架构](https://ws1.sinaimg.cn/large/00704eQkgy1frr56m7z2sj31y010y17y.jpg)

 OpenEBS是一款容器化存储，它基于Ceph构建，容器化存储最大的好处就是复用Kubernetes的资源类型，简化存储应用的部署，将单体的存储拆分为“微服务化”的存储，即每个应用在声明PV的时候才会创建存储，并与PV的生命周期一样都是独立于应用的。

 OpenEBS的存储也是分控制平面和数据平面的，下图是OpenEBS的架构图。

-![](https://ws1.sinaimg.cn/large/00704eQkgy1frr57nm2mnj31xk11qqej.jpg)
+![OpenEBS 的存储卷管理](https://ws1.sinaimg.cn/large/00704eQkgy1frr57nm2mnj31xk11qqej.jpg)

 黄色部分是OpenEBS的组件（除了kube-dashboard），它是使用Kubernetes的各种原语和CRD来创建的，架构跟Kubernetes本身也很类似。

@ -94,13 +94,13 @@ OpenEBS的存储也是分控制平面和数据平面的，下图是OpenEBS的架

 上面说到了Operator的一个应用，下面再来看一个我们之前在Kubernetes中部署Hadoop YARN和Spark的例子。

-![](https://ws1.sinaimg.cn/large/00704eQkgy1frr58ebf2lj323o11219r.jpg)
+![Hadoop YARN 迁移到 Kubernetes的示例](https://ws1.sinaimg.cn/large/00704eQkgy1frr58ebf2lj323o11219r.jpg)

-![](https://ws1.sinaimg.cn/large/00704eQkgy1frr59gzzwsj32gg16k4qp.jpg)
+![Spark on Yarn with Kubernetes](https://ws1.sinaimg.cn/large/00704eQkgy1frr59gzzwsj32gg16k4qp.jpg)

 Kubernetes始于12因素应用的PaaS平台，它是微服务的绝佳部署管理平台，基于它可以应用多种设计模式。它的未来将变成什么样呢？

-![](https://ws1.sinaimg.cn/large/00704eQkgy1frr5arzvetj31no12mdre.jpg)
+![云原生与12因素应用](https://ws1.sinaimg.cn/large/00704eQkgy1frr5arzvetj31no12mdre.jpg)

 - Service Mesh：解决微服务治理问题
 - Auto Pilot：自动驾驭能力，服务自动扩展，智能运维
@ -114,7 +114,7 @@ Kubernetes始于12因素应用的PaaS平台，它是微服务的绝佳部署管

 甚至出现了像ballerina这样的云原生编程语言，它的出现就是为了解决应用开发到服务集成之间的鸿沟的。它有以下几个特点。

-![](https://ws1.sinaimg.cn/large/00704eQkgy1frr5c8bwmtj31ou152qc3.jpg)
+![云原生编程语言](https://ws1.sinaimg.cn/large/00704eQkgy1frr5c8bwmtj31ou152qc3.jpg)

 - 使用云原生语义的DSL
 - 注解式配置
@ -123,13 +123,13 @@ Kubernetes始于12因素应用的PaaS平台，它是微服务的绝佳部署管

 要完成云的集成CI/CD，或者用一个词代替来说就是GitOps的需求越来越强烈。

-![](https://ws1.sinaimg.cn/large/00704eQkgy1frr5bulhuhj329m10iwua.jpg)
+![Gitkube](https://ws1.sinaimg.cn/large/00704eQkgy1frr5bulhuhj329m10iwua.jpg)

 ### Kubernetes没有做什么

 看下这张图中的两个服务，它们使用的是kube-proxy里基于iptables的原生的负载均衡，并且服务间的流量也没有任何控制。

-![](https://ws1.sinaimg.cn/large/00704eQkgy1frr5dsurx6j320i140tpf.jpg)
+![Kuberentes中的流量管理](https://ws1.sinaimg.cn/large/00704eQkgy1frr5dsurx6j320i140tpf.jpg)

 Kubernetes缺少的最重要的一个功能就是微服务的治理，微服务比起单体服务来说使得部署和运维起来更加复杂，对于微服务的可观测性也有更高的要求，同时CI/CD流程Kubernetes本身也没有提供。

@ -149,7 +149,7 @@ Service Mesh是一个专用的基础设施层，它能够将微服务的治理

 Service Mesh实际上为了解决社会分工问题，它本身是为了解决微服务的治理。

-![](https://ws1.sinaimg.cn/large/00704eQkgy1frr5fxzoltj32f81akqr2.jpg)
+![Service Mesh架构](https://ws1.sinaimg.cn/large/00704eQkgy1frr5fxzoltj32f81akqr2.jpg)

 Pilot和控制平面是为了运维人员准备的。

--- a/concepts/annotation.md
+++ b/concepts/annotation.md
@ -75,4 +75,4 @@ spec:
              fieldPath: metadata.namespace
 ```

-`alpha.istio.io/sidecar` 注解就是用来控制是否自动向 pod 中注入 sidecar 的。参考：[安装 Istio sidecar - istio.doczh.cn](http://istio.doczh.cn/docs/setup/kubernetes/sidecar-injection.html)。
+`alpha.istio.io/sidecar` 注解就是用来控制是否自动向 pod 中注入 sidecar 的。
--- a/concepts/cri.md
+++ b/concepts/cri.md
@ -136,7 +136,6 @@ CRI是由[SIG-Node](https://kubernetes.slack.com/archives/sig-node)来维护的
 ## 参考

 - [Kubernetes CRI and Minikube](https://sreeninet.wordpress.com/2017/02/11/kubernetes-cri-and-minikube/)
- [Kubernetes container runtime interface](https://feisky.xyz/2016/09/24/Kubernetes-container-runtime-interface/)
 - [CRI-O and Alternative Runtimes in Kubernetes](https://www.projectatomic.io/blog/2017/02/crio-runtimes/)
 - [Docker、Containerd、RunC...：你应该知道的所有](http://www.infoq.com/cn/news/2017/02/Docker-Containerd-RunC)
 - [Introducing Container Runtime Interface (CRI) in Kubernetes](http://blog.kubernetes.io/2016/12/container-runtime-interface-cri-in-kubernetes.html)
--- a/concepts/custom-resource.md
+++ b/concepts/custom-resource.md
@ -92,7 +92,7 @@ spec:
 kubectl create -f resourcedefinition.yaml
 ```

-访问RESTful API端点如http://172.20.0.113:8080将看到如下API端点已创建：
+访问RESTful API端点如<http://172.20.0.113:8080>将看到如下API端点已创建：

 ```
 /apis/stable.example.com/v1/namespaces/*/crontabs/...
--- a/concepts/deployment.md
+++ b/concepts/deployment.md
@ -56,8 +56,6 @@ kubectl rollout undo deployment/nginx-deployment

 ## Deployment 结构示意图

-参考：https://kubernetes.io/docs/api-reference/v1.6/#deploymentspec-v1beta1-apps
-
 ![kubernetes deployment cheatsheet](../images/deployment-cheatsheet.png)

 ## Deployment 概念详细解析
@ -386,8 +384,6 @@ $ kubectl rollout undo deployment/nginx-deployment --to-revision=2
 deployment "nginx-deployment" rolled back
 ```

-与 rollout 相关的命令详细文档见[kubectl rollout](https://kubernetes.io/docs/user-guide/kubectl/v1.6/#rollout)。
-
 该 Deployment 现在已经回退到了先前的稳定版本。如您所见，Deployment controller产生了一个回退到revison 2的`DeploymentRollback`的 event。

 ```bash
@ -568,7 +564,7 @@ nginx-3926361531   3         3         3         28s

 ## Deployment 状态

-Deployment 在生命周期中有多种状态。在创建一个新的 ReplicaSet 的时候它可以是 [progressing](https://kubernetes.io/docs/concepts/workloads/controllers/deployment.md#progressing-deployment) 状态， [complete](https://kubernetes.io/docs/concepts/workloads/controllers/deployment.md#complete-deployment) 状态，或者 [fail to progress ](https://kubernetes.io/docs/concepts/workloads/controllers/deployment.md#failed-deployment)状态。
+Deployment 在生命周期中有多种状态。在创建一个新的 ReplicaSet 的时候它可以是 [progressing](https://kubernetes.io/docs/concepts/workloads/controllers/deployment#progressing-deployment) 状态， [complete](https://kubernetes.io/docs/concepts/workloads/controllers/deployment#complete-deployment) 状态，或者 [fail to progress ](https://kubernetes.io/docs/concepts/workloads/controllers/deployment#failed-deployment)状态。

 ### 进行中的 Deployment

@ -610,7 +606,7 @@ $ echo $?
 - 范围限制
 - 程序运行时配置错误

-探测这种情况的一种方式是，在您的 Deployment spec 中指定[`spec.progressDeadlineSeconds`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment.md#progress-deadline-seconds)。`spec.progressDeadlineSeconds` 表示 Deployment controller 等待多少秒才能确定（通过 Deployment status）Deployment进程是卡住的。
+探测这种情况的一种方式是，在您的 Deployment spec 中指定[`spec.progressDeadlineSeconds`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment#progress-deadline-seconds)。`spec.progressDeadlineSeconds` 表示 Deployment controller 等待多少秒才能确定（通过 Deployment status）Deployment进程是卡住的。

 下面的`kubectl`命令设置`progressDeadlineSeconds` 使 controller 在 Deployment 在进度卡住10分钟后报告：

@ -625,8 +621,6 @@ $ kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSecond
 - Status=False
 - Reason=ProgressDeadlineExceeded

-浏览 [Kubernetes API conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#typical-status-properties) 查看关于status conditions的更多信息。
-
 **注意：** kubernetes除了报告`Reason=ProgressDeadlineExceeded`状态信息外不会对卡住的 Deployment 做任何操作。更高层次的协调器可以利用它并采取相应行动，例如，回滚 Deployment 到之前的版本。

 **注意：** 如果您暂停了一个 Deployment，在暂停的这段时间内kubernetnes不会检查您指定的 deadline。您可以在 Deployment 的 rollout 途中安全的暂停它，然后再恢复它，这不会触发超过deadline的状态。
@ -730,15 +724,13 @@ $ echo $?

 在所有的 Kubernetes 配置中，Deployment 也需要`apiVersion`，`kind`和`metadata`这些配置项。配置文件的通用使用说明查看 [部署应用](https://kubernetes.io/docs/tasks/run-application/run-stateless-application-deployment/)，配置容器，和 [使用 kubectl 管理资源 ](https://kubernetes.io/docs/tutorials/object-management-kubectl/object-management/) 文档。

-Deployment也需要 [`.spec` section](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#spec-and-status).
-
 ### Pod Template

 `.spec.template` 是 `.spec`中唯一要求的字段。

 `.spec.template` 是 [pod template](https://kubernetes.io/docs/user-guide/replication-controller/#pod-template). 它跟 [Pod](https://kubernetes.io/docs/user-guide/pods)有一模一样的schema，除了它是嵌套的并且不需要`apiVersion` 和 `kind`字段。

-另外为了划分Pod的范围，Deployment中的pod template必须指定适当的label（不要跟其他controller重复了，参考[selector](https://kubernetes.io/docs/concepts/workloads/controllers/deployment.md#selector)）和适当的重启策略。
+另外为了划分Pod的范围，Deployment中的pod template必须指定适当的label（不要跟其他controller重复了，参考[selector](https://kubernetes.io/docs/concepts/workloads/controllers/deployment#selector)）和适当的重启策略。

 [`.spec.template.spec.restartPolicy`](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle) 可以设置为 `Always` , 如果不指定的话这就是默认配置。

@ -784,7 +776,7 @@ Deployment也需要 [`.spec` section](https://github.com/kubernetes/community/bl

 ### Progress Deadline Seconds

-`.spec.progressDeadlineSeconds` 是可选配置项，用来指定在系统报告Deployment的[failed progressing](https://kubernetes.io/docs/concepts/workloads/controllers/deployment.md#failed-deployment) ——表现为resource的状态中`type=Progressing`、`Status=False`、 `Reason=ProgressDeadlineExceeded`前可以等待的Deployment进行的秒数。Deployment controller会继续重试该Deployment。未来，在实现了自动回滚后， deployment controller在观察到这种状态时就会自动回滚。
+`.spec.progressDeadlineSeconds` 是可选配置项，用来指定在系统报告Deployment的[failed progressing](https://kubernetes.io/docs/concepts/workloads/controllers/deployment#failed-deployment) ——表现为resource的状态中`type=Progressing`、`Status=False`、 `Reason=ProgressDeadlineExceeded`前可以等待的Deployment进行的秒数。Deployment controller会继续重试该Deployment。未来，在实现了自动回滚后， deployment controller在观察到这种状态时就会自动回滚。

 如果设置该参数，该值必须大于 `.spec.minReadySeconds`。

--- a/concepts/horizontal-pod-autoscaling.md
+++ b/concepts/horizontal-pod-autoscaling.md
@ -62,7 +62,7 @@ kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MA
 kubectl autoscale deployment foo --min=2 --max=5 --cpu-percent=80
 ```

-为Deployment foo创建 一个autoscaler，当Pod的CPU利用率达到80%的时候，RC的replica数在2到5之间。该命令的详细使用文档见https://kubernetes.io/docs/user-guide/kubectl/v1.6/#autoscale 。
+为Deployment foo创建 一个autoscaler，当Pod的CPU利用率达到80%的时候，RC的replica数在2到5之间。

 **注意** ：如果为ReplicaSet创建HPA的话，无法使用rolling update，但是对于Deployment来说是可以的，因为Deployment在执行rolling update的时候会自动创建新的ReplicationController。

@ -78,7 +78,7 @@ Horizontal Pod Autoscaler 由一个控制循环实现，循环周期由 controll

 在每个周期内，controller manager 会查询 HorizontalPodAutoscaler 中定义的 metric 的资源利用率。Controller manager 从 resource metric API（每个 pod 的 resource metric）或者自定义 metric API（所有的metric）中获取 metric。

- 每个 Pod 的 resource metric（例如 CPU），controller 通过 resource metric API 获取 HorizontalPodAutoscaler 中定义的每个 Pod 中的 metric。然后，如果设置了目标利用率，controller 计算利用的值与每个 Pod 的容器里的 resource request 值的百分比。如果设置了目标原始值，将直接使用该原始 metric 值。然后 controller 计算所有目标 Pod 的利用率或原始值（取决于所指定的目标类型）的平均值，产生一个用于缩放所需 replica 数量的比率。 请注意，如果某些 Pod 的容器没有设置相关的 resource request ，则不会定义 Pod 的 CPU 利用率，并且 Aucoscaler 也不会对该 metric 采取任何操作。 有关自动缩放算法如何工作的更多细节，请参阅 [自动缩放算法设计文档](https://git.k8s.io/community/contributors/design-proposals/horizontal-pod-autoscaler.md#autoscaling-algorithm)。
+- 每个 Pod 的 resource metric（例如 CPU），controller 通过 resource metric API 获取 HorizontalPodAutoscaler 中定义的每个 Pod 中的 metric。然后，如果设置了目标利用率，controller 计算利用的值与每个 Pod 的容器里的 resource request 值的百分比。如果设置了目标原始值，将直接使用该原始 metric 值。然后 controller 计算所有目标 Pod 的利用率或原始值（取决于所指定的目标类型）的平均值，产生一个用于缩放所需 replica 数量的比率。 请注意，如果某些 Pod 的容器没有设置相关的 resource request ，则不会定义 Pod 的 CPU 利用率，并且 Aucoscaler 也不会对该 metric 采取任何操作。 
 - 对于每个 Pod 自定义的 metric，controller 功能类似于每个 Pod 的 resource metric，只是它使用原始值而不是利用率值。
 - 对于 object metric，获取单个度量（描述有问题的对象），并与目标值进行比较，以产生如上所述的比率。

@ -86,22 +86,16 @@ HorizontalPodAutoscaler 控制器可以以两种不同的方式获取 metric ：

 当使用直接的 Heapster 访问时，HorizontalPodAutoscaler 直接通过 API 服务器的服务代理子资源查询 Heapster。需要在集群上部署 Heapster 并在 kube-system namespace 中运行。

-有关 REST 客户端访问的详细信息，请参阅 [支持自定义度量](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale.md#prerequisites)。
-
 Autoscaler 访问相应的 replication controller，deployment 或 replica set 来缩放子资源。

 Scale 是一个允许您动态设置副本数并检查其当前状态的接口。

-有关缩放子资源的更多细节可以在 [这里](https://git.k8s.io/community/contributors/design-proposals/horizontal-pod-autoscaler.md#scale-subresource) 找到。
-
 ## API Object

 Horizontal Pod Autoscaler 是 kubernetes 的 `autoscaling` API 组中的 API 资源。当前的稳定版本中，只支持 CPU 自动扩缩容，可以在`autoscaling/v1` API 版本中找到。

 在 alpha 版本中支持根据内存和自定义 metric 扩缩容，可以在`autoscaling/v2alpha1` 中找到。`autoscaling/v2alpha1` 中引入的新字段在`autoscaling/v1` 中是做为 annotation 而保存的。

-关于该 API 对象的更多信息，请参阅 [HorizontalPodAutoscaler Object](https://git.k8s.io/community/contributors/design-proposals/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object)。
-
 ## 在 kubectl 中支持 Horizontal Pod Autoscaling

 Horizontal Pod Autoscaler 和其他的所有 API 资源一样，通过 `kubectl` 以标准的方式支持。
@ -116,8 +110,6 @@ Horizontal Pod Autoscaler 和其他的所有 API 资源一样，通过 `kubectl`

 例如，执行`kubectl autoscale rc foo —min=2 —max=5 —cpu-percent=80`命令将为 replication controller *foo* 创建一个 autoscaler，目标的 CPU 利用率是`80%`，replica 的数量介于 2 和 5 之间。

-关于`kubectl autoscale`的更多信息请参阅 [这里](https://kubernetes.io/docs/user-guide/kubectl/v1.6/#autoscale)。
-
 ## 滚动更新期间的自动扩缩容

 目前在Kubernetes中，可以通过直接管理 replication controller 或使用 deployment 对象来执行 [滚动更新](https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller)，该 deployment 对象为您管理基础 replication controller。
@ -150,22 +142,12 @@ Kubernetes 然后查询新的自定义 metric API 来获取相应自定义 metri

 您可以使用 Heapster 实现 resource metric API，方法是将 `--api-server` 标志设置为 true 并运行 Heapster。 单独的组件必须提供自定义 metric API（有关自定义metric API的更多信息，可从 [k8s.io/metrics repository](https://github.com/kubernetes/metrics) 获得）。

-## 进一步阅读
-
- 设计文档：[Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/horizontal-pod-autoscaler.md)
- kubectl autoscale 命令：[kubectl autoscale](https://kubernetes.io/docs/user-guide/kubectl/v1.6/#autoscale)
- 使用例子： [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough)
-
 ## 参考

-HPA设计文档：https://github.com/kubernetes/community/blob/master/contributors/design-proposals/horizontal-pod-autoscaler.md
+- HPA说明：https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

-HPA说明：https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
+- HPA详解：https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/

-HPA详解：https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/
+- 自定义metrics开发：https://github.com/kubernetes/metrics

-kubectl autoscale命令详细使用说明：https://kubernetes.io/docs/user-guide/kubectl/v1.6/#autoscale
-
-自定义metrics开发：https://github.com/kubernetes/metrics
-
-1.7版本的kubernetes中启用自定义HPA：[Configure Kubernetes Autoscaling With Custom Metrics in Kubernetes 1.7 - Bitnami](https://docs.bitnami.com/kubernetes/how-to/configure-autoscaling-custom-metrics/)
+- 1.7版本的kubernetes中启用自定义HPA：[Configure Kubernetes Autoscaling With Custom Metrics in Kubernetes 1.7 - Bitnami](https://docs.bitnami.com/kubernetes/how-to/configure-autoscaling-custom-metrics/)
--- a/concepts/index.md
+++ b/concepts/index.md
@ -80,7 +80,6 @@ Kubernetes设计理念和功能其实就是一个类似Linux的分层架构，

 ## 参考文档

- [Kubernetes design and architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture.md)
 - <http://queue.acm.org/detail.cfm?id=2898444>
 - <http://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/43438.pdf>
 - <http://thenewstack.io/kubernetes-an-overview>
--- a/concepts/ingress.md
+++ b/concepts/ingress.md
@ -11,7 +11,7 @@
 - 节点：Kubernetes集群中的一台物理机或者虚拟机。
 - 集群：位于Internet防火墙后的节点，这是kubernetes管理的主要计算资源。
 - 边界路由器：为集群强制执行防火墙策略的路由器。 这可能是由云提供商或物理硬件管理的网关。
- 集群网络：一组逻辑或物理链接，可根据Kubernetes[网络模型](https://kubernetes.io/docs/admin/networking/)实现群集内的通信。 集群网络的实现包括Overlay模型的 [flannel](https://github.com/coreos/flannel#flannel) 和基于SDN的[OVS](https://kubernetes.io/docs/admin/ovs-networking/)。
+- 集群网络：一组逻辑或物理链接，可根据Kubernetes[网络模型](https://kubernetes.io/docs/admin/networking/)实现群集内的通信。 集群网络的实现包括Overlay模型的 [flannel](https://github.com/coreos/flannel#flannel) 和基于SDN的OVS。
 - 服务：使用标签选择器标识一组pod成为的Kubernetes[服务](https://kubernetes.io/docs/user-guide/services/)。 除非另有说明，否则服务假定在集群网络内仅可通过虚拟IP访问。

 ## 什么是Ingress？
@ -233,7 +233,7 @@ spec:

 请注意，各种Ingress controller支持的TLS功能之间存在差距。 请参阅有关[nginx](https://git.k8s.io/ingress-nginx/README.md#https)，[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)或任何其他平台特定Ingress controller的文档，以了解TLS在你的环境中的工作原理。

-Ingress controller启动时附带一些适用于所有Ingress的负载平衡策略设置，例如负载均衡算法，后端权重方案等。更高级的负载平衡概念（例如持久会话，动态权重）尚未在Ingress中公开。 你仍然可以通过[service loadbalancer](https://github.com/kubernetes/ingress-nginx/blob/master/docs/ingress-controller-catalog.md)获取这些功能。 随着时间的推移，我们计划将适用于跨平台的负载平衡模式加入到Ingress资源中。
+Ingress controller启动时附带一些适用于所有Ingress的负载平衡策略设置，例如负载均衡算法，后端权重方案等。更高级的负载平衡概念（例如持久会话，动态权重）尚未在Ingress中公开。 你仍然可以通过service loadbalancer获取这些功能。 随着时间的推移，我们计划将适用于跨平台的负载平衡模式加入到Ingress资源中。

 还值得注意的是，尽管健康检查不直接通过Ingress公开，但Kubernetes中存在并行概念，例如[准备探查](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)，可以使你达成相同的最终结果。 请查看特定控制器的文档，以了解他们如何处理健康检查（[nginx](https://git.k8s.io/ingress-nginx/README.md)，[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)）。

@ -288,7 +288,7 @@ test      -                       178.91.123.132

 ## 跨可用域故障

-在不通云供应商之间，跨故障域的流量传播技术有所不同。 有关详细信息，请查看相关Ingress controller的文档。 有关在federation集群中部署Ingress的详细信息，请参阅[federation文档]()。
+在不通云供应商之间，跨故障域的流量传播技术有所不同。 有关详细信息，请查看相关Ingress controller的文档。 有关在federation集群中部署Ingress的详细信息，请参阅federation文档。

 ## 未来计划

--- a/concepts/init-containers.md
+++ b/concepts/init-containers.md
@ -15,7 +15,7 @@ Init 容器与普通的容器非常像，除了如下两点：

 如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 `restartPolicy` 为 Never，它不会重新启动。

-指定容器为 Init 容器，在 PodSpec 中添加 `initContainers` 字段，以 [v1.Container](https://kubernetes.io/docs/api-reference/v1.6/#container-v1-core) 类型对象的 JSON 数组的形式，还有 app 的 `containers` 数组。 Init 容器的状态在 `status.initContainerStatuses` 字段中以容器状态数组的格式返回（类似 `status.containerStatuses` 字段）。
+指定容器为 Init 容器，在 PodSpec 中添加 `initContainers` 字段，以 v1.Container 类型对象的 JSON 数组的形式，还有 app 的 `containers` 数组。 Init 容器的状态在 `status.initContainerStatuses` 字段中以容器状态数组的格式返回（类似 `status.containerStatuses` 字段）。

 ### 与普通容器的不同之处

--- a/concepts/label.md
+++ b/concepts/label.md
@ -102,4 +102,3 @@ selector:
            - another-node-label-value
 ```

-详见[node selection](https://github.com/kubernetes/kubernetes.github.io/tree/master/docs/user-guide/node-selection)。
--- a/concepts/network-policy.md
+++ b/concepts/network-policy.md
@ -41,7 +41,7 @@ spec:

 *将上面配置 POST 到 API Server 将不起任何作用，除非选择的网络方案支持网络策略。*

-**必选字段**：像所有其它 Kubernetes 配置一样， `NetworkPolicy` 需要 `apiVersion`、`kind` 和 `metadata` 这三个字段，关于如何使用配置文件的基本信息，可以查看 [这里](https://kubernetes.io/docs/user-guide/simple-yaml)，[这里](https://kubernetes.io/docs/user-guide/configuring-containers) 和 [这里](https://kubernetes.io/docs/user-guide/working-with-resources)。
+**必选字段**：像所有其它 Kubernetes 配置一样， `NetworkPolicy` 需要 `apiVersion`、`kind` 和 `metadata` 这三个字段，关于如何使用配置文件的基本信息，可以查看 [这里](https://kubernetes.io/docs/user-guide/configuring-containers) 和 [这里](https://kubernetes.io/docs/user-guide/working-with-resources)。

 **spec**：`NetworkPolicy` [spec](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) 具有在给定 Namespace 中定义特定网络的全部信息。

--- a/concepts/objects.md
+++ b/concepts/objects.md
@ -80,7 +80,7 @@ spec:
        - containerPort: 80
 ```

-一种创建 Deployment 的方式，类似上面使用 `.yaml` 文件，是使用 `kubectl` 命令行接口（CLI）中的 [`kubectl create`](https://kubernetes.io/docs/user-guide/kubectl/v1.7/#create) 命令，传递 `.yaml` 作为参数。下面是一个示例：
+一种创建 Deployment 的方式，类似上面使用 `.yaml` 文件，是使用 `kubectl` 命令行接口（CLI）中的 `kubectl create` 命令，传递 `.yaml` 作为参数。下面是一个示例：

 ```bash
 $ kubectl create -f docs/user-guide/nginx-deployment.yaml --record
--- a/concepts/persistent-volume.md
+++ b/concepts/persistent-volume.md
@ -42,7 +42,7 @@ PV 属于集群中的资源。PVC 是对这些资源的请求，也作为对资

 Pod 使用声明作为卷。集群检查声明以查找绑定的卷并为集群挂载该卷。对于支持多种访问模式的卷，用户指定在使用声明作为容器中的卷时所需的模式。

-用户进行了声明，并且该声明是绑定的，则只要用户需要，绑定的 PV 就属于该用户。用户通过在 Pod 的 volume 配置中包含 `persistentVolumeClaim` 来调度 Pod 并访问用户声明的 PV。[请参阅下面的语法细节](#claims-as-volumes)。
+用户进行了声明，并且该声明是绑定的，则只要用户需要，绑定的 PV 就属于该用户。用户通过在 Pod 的 volume 配置中包含 `persistentVolumeClaim` 来调度 Pod 并访问用户声明的 PV。

 ### 持久化卷声明的保护

@ -50,7 +50,7 @@ PVC 保护的目的是确保由 pod 正在使用的 PVC 不会从系统中移除

 注意：当 pod 状态为 `Pending` 并且 pod 已经分配给节点或 pod 为 `Running` 状态时，PVC 处于活动状态。

-当启用[PVC 保护 alpha 功能](https://kubernetes.io/docs/tasks/administer-cluster/pvc-protection/)时，如果用户删除了一个 pod 正在使用的 PVC，则该 PVC 不会被立即删除。PVC 的删除将被推迟，直到 PVC 不再被任何 pod 使用。
+当启用PVC 保护 alpha 功能时，如果用户删除了一个 pod 正在使用的 PVC，则该 PVC 不会被立即删除。PVC 的删除将被推迟，直到 PVC 不再被任何 pod 使用。

 您可以看到，当 PVC 的状态为 `Teminatiing` 时，PVC 受到保护，`Finalizers` 列表中包含 `kubernetes.io/pvc-protection`：

@ -111,7 +111,7 @@ spec:

 #### 删除

-对于支持删除回收策略的卷插件，删除操作将从 Kubernetes 中删除 `PersistentVolume` 对象，并删除外部基础架构（如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷）中的关联存储资产。动态配置的卷继承其 [`StorageClass` 的回收策略](#reclaim-policy)，默认为 Delete。管理员应该根据用户的期望来配置 `StorageClass`，否则就必须要在 PV 创建后进行编辑或修补。请参阅[更改 PersistentVolume 的回收策略](https://kubernetes.iohttps://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/)。
+对于支持删除回收策略的卷插件，删除操作将从 Kubernetes 中删除 `PersistentVolume` 对象，并删除外部基础架构（如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷）中的关联存储资产。动态配置的卷继承其 `StorageClass`，默认为 Delete。管理员应该根据用户的期望来配置 `StorageClass`，否则就必须要在 PV 创建后进行编辑或修补。请参阅[更改 PersistentVolume 的回收策略](https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/)。

 ### 扩展持久化卷声明

--- a/concepts/pod-disruption-budget.md
+++ b/concepts/pod-disruption-budget.md
@ -39,7 +39,7 @@ Pod 不会消失，直到有人（人类或控制器）将其销毁，或者当

 - 确保您的 pod [请求所需的资源](https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-ram-container)。
 - 如果您需要更高的可用性，请复制您的应用程序。 （了解有关运行复制的[无状态](https://kubernetes.io/docs/tasks/run-application/run-stateless-application-deployment)和[有状态](https://kubernetes.io/docs/tasks/run-application/run-replicated-stateful-application)应用程序的信息。）
- 为了在运行复制应用程序时获得更高的可用性，请跨机架（使用[反亲和性](https://kubernetes.io/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)）或跨区域（如果使用[多区域集群](https://kubernetes.io/docs/admin/multiple-zones)）分布应用程序。
+- 为了在运行复制应用程序时获得更高的可用性，请跨机架（使用[反亲和性](https://kubernetes.io/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)）或跨区域（如果使用多区域集群）分布应用程序。

 自愿中断的频率各不相同。在 Kubernetes 集群上，根本没有自愿的中断。但是，您的集群管理员或托管提供商可能会运行一些导致自愿中断的附加服务。例如，节点软件更新可能导致自愿更新。另外，集群（节点）自动缩放的某些实现可能会导致碎片整理和紧缩节点的自愿中断。您的集群管理员或主机提供商应该已经记录了期望的自愿中断级别（如果有的话）。

@ -63,7 +63,7 @@ PDB 不能阻止[非自愿中断](https://kubernetes.io/docs/concepts/workloads/

 由于应用程序的滚动升级而被删除或不可用的 Pod 确实会计入中断预算，但控制器（如 Deployment 和 StatefulSet）在进行滚动升级时不受 PDB 的限制——在应用程序更新期间的故障处理是在控制器的规格（spec）中配置（了解[更新 Deployment](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#updating-your-application-without-a-service-outage)）。

-使用驱逐 API 驱逐 pod 时，pod 会被优雅地终止（请参阅 [PodSpec](https://kubernetes.io/docs/resources-reference/v1.6/#podspec-v1-core) 中的 `terminationGracePeriodSeconds`）。
+使用驱逐 API 驱逐 pod 时，pod 会被优雅地终止（请参阅 PodSpec） 中的 `terminationGracePeriodSeconds`）。

 ## PDB 示例

@ -153,7 +153,7 @@ Pod Disruption Budget（Pod 中断预算） 通过在角色之间提供接口来

 ## 参考

- [Disruptions - kubernetes.io](https://kubernetes.iohttps://kubernetes.io/docs/concepts/workloads/pods/disruptions/)
+- [Disruptions - kubernetes.io](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/)

 - 通过配置[Pod Disruption Budget（Pod 中断预算）](https://kubernetes.io/docs/tasks/run-application//configure-pdb)来执行保护应用程序的步骤。
 - 了解更多关于[排空节点](https://kubernetes.io/docs/tasks/administer-cluster//safely-drain-node)的信息。
--- a/concepts/pod-lifecycle.md
+++ b/concepts/pod-lifecycle.md
@ -2,7 +2,7 @@

 ## Pod phase

-Pod 的 `status` 在信息保存在 [PodStatus](https://kubernetes.io/docs/resources-reference/v1.7/#podstatus-v1-core) 中定义，其中有一个 `phase` 字段。
+Pod 的 `status` 在信息保存在 PodStatus 中定义，其中有一个 `phase` 字段。

 Pod 的相位（phase）是 Pod 在其生命周期中的简单宏观概述。该阶段并不是对容器或 Pod 的综合汇总，也不是为了做为综合状态机。

@ -22,15 +22,15 @@ Pod 相位的数量和含义是严格指定的。除了本文档中列举的状

 ## Pod 状态

-Pod 有一个 PodStatus 对象，其中包含一个 [PodCondition](https://kubernetes.io/docs/resources-reference/v1.7/#podcondition-v1-core) 数组。 PodCondition 数组的每个元素都有一个 `type` 字段和一个 `status` 字段。`type` 字段是字符串，可能的值有 PodScheduled、Ready、Initialized 和 Unschedulable。`status` 字段是一个字符串，可能的值有 True、False 和 Unknown。
+Pod 有一个 PodStatus 对象，其中包含一个 PodCondition 数组。 PodCondition 数组的每个元素都有一个 `type` 字段和一个 `status` 字段。`type` 字段是字符串，可能的值有 PodScheduled、Ready、Initialized 和 Unschedulable。`status` 字段是一个字符串，可能的值有 True、False 和 Unknown。

 ## 容器探针

-[探针](https://kubernetes.io/docs/resources-reference/v1.7/#probe-v1-core) 是由 [kubelet](https://kubernetes.io/docs/admin/kubelet/) 对容器执行的定期诊断。要执行诊断，kubelet 调用由容器实现的 [Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)。有三种类型的处理程序：
+探针是由 [kubelet](https://kubernetes.io/docs/admin/kubelet/) 对容器执行的定期诊断。要执行诊断，kubelet 调用由容器实现的 [Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)。有三种类型的处理程序：

- [ExecAction](https://kubernetes.io/docs/resources-reference/v1.7/#execaction-v1-core)：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
- [TCPSocketAction](https://kubernetes.io/docs/resources-reference/v1.7/#tcpsocketaction-v1-core)：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
- [HTTPGetAction](https://kubernetes.io/docs/resources-reference/v1.7/#httpgetaction-v1-core)：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。
+- ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
+- TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
+- HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。

 每次探测都将获得以下三种结果之一：

@ -57,7 +57,7 @@ Kubelet 可以选择是否执行在容器上运行的两种探针执行和做出

 ## Pod 和容器状态

-有关 Pod 容器状态的详细信息，请参阅 [PodStatus](https://kubernetes.io/docs/resources-reference/v1.7/#podstatus-v1-core) 和 [ContainerStatus](https://kubernetes.io/docs/resources-reference/v1.7/#containerstatus-v1-core)。请注意，报告的 Pod 状态信息取决于当前的 [ContainerState](https://kubernetes.io/docs/resources-reference/v1.7/#containerstatus-v1-core)。
+有关 Pod 容器状态的详细信息，请参阅 PodStatus 和 ContainerStatus。请注意，报告的 Pod 状态信息取决于当前的 ContainerState。

 ## 重启策略

--- a/concepts/pod-security-policy.md
+++ b/concepts/pod-security-policy.md
@ -183,7 +183,7 @@ podsecuritypolicy "permissive" deleted

 在 Kubernetes 1.5 或更新版本，可以使用 PodSecurityPolicy 来控制，对基于用户角色和组的已授权容器的访问。访问不同的 PodSecurityPolicy 对象，可以基于认证来控制。基于 Deployment、ReplicaSet 等创建的 Pod，限制访问 PodSecurityPolicy 对象，[Controller Manager](https://kubernetes.io/docs/admin/kube-controller-manager/) 必须基于安全 API 端口运行，并且不能够具有超级用户权限。

-PodSecurityPolicy 认证使用所有可用的策略，包括创建 Pod 的用户，Pod 上指定的服务账户（service acount）。当 Pod 基于 Deployment、ReplicaSet 创建时，它是创建 Pod 的 Controller Manager，所以如果基于非安全 API 端口运行，允许所有的 PodSecurityPolicy 对象，并且不能够有效地实现细分权限。用户访问给定的 PSP 策略有效，仅当是直接部署 Pod 的情况。更多详情，查看 [PodSecurityPolicy RBAC 示例](https://git.k8s.io/kubernetes/examples/podsecuritypolicy/rbac/README.md)，当直接部署 Pod 时，应用 PodSecurityPolicy 控制基于角色和组的已授权容器的访问 。
+PodSecurityPolicy 认证使用所有可用的策略，包括创建 Pod 的用户，Pod 上指定的服务账户（service acount）。当 Pod 基于 Deployment、ReplicaSet 创建时，它是创建 Pod 的 Controller Manager，所以如果基于非安全 API 端口运行，允许所有的 PodSecurityPolicy 对象，并且不能够有效地实现细分权限。用户访问给定的 PSP 策略有效，仅当是直接部署 Pod 的情况。当直接部署 Pod 时，应用 PodSecurityPolicy 控制基于角色和组的已授权容器的访问 。

 原文地址：https://k8smeetup.github.io/docs/concepts/policy/pod-security-policy/

--- a/concepts/pod.md
+++ b/concepts/pod.md
@ -75,7 +75,7 @@ Pod在设计支持就不是作为持久化实体的。在调度失败、节点

 通常，用户不需要手动直接创建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](http://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](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)和[Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)。

 Pod 原语有利于：

--- a/concepts/rbac.md
+++ b/concepts/rbac.md
@ -347,15 +347,15 @@ API Server会创建一组默认的`ClusterRole`和`ClusterRoleBinding`对象。

 ### 其它组件角色

-| 默认ClusterRole                            | 默认ClusterRoleBinding                     | 描述                                       |
-| ---------------------------------------- | ---------------------------------------- | ---------------------------------------- |
-| **system:auth-delegator**                | None                                     | 允许委托认证和授权检查。 通常由附加API Server用于统一认证和授权。   |
-| **system:heapster**                      | None                                     | [Heapster](https://github.com/kubernetes/heapster)组件的角色。 |
-| **system:kube-aggregator**               | None                                     | [kube-aggregator](https://github.com/kubernetes/kube-aggregator)组件的角色。 |
+| 默认ClusterRole                          | 默认ClusterRoleBinding                                       | 描述                                                         |
+| ---------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
+| **system:auth-delegator**                | None                                                         | 允许委托认证和授权检查。 通常由附加API Server用于统一认证和授权。 |
+| **system:heapster**                      | None                                                         | [Heapster](https://github.com/kubernetes/heapster)组件的角色。 |
+| **system:kube-aggregator**               | None                                                         | [kube-aggregator](https://github.com/kubernetes/kube-aggregator)组件的角色。 |
 | **system:kube-dns**                      | **kube-dns** service account in the **kube-system**namespace | [kube-dns](https://k8smeetup.github.io/docs/admin/dns/)组件的角色。 |
-| **system:node-bootstrapper**             | None                                     | 允许对执行[Kubelet TLS引导（Kubelet TLS bootstrapping）](https://k8smeetup.github.io/docs/admin/kubelet-tls-bootstrapping/)所需要资源的访问. |
-| **system:node-problem-detector**         | None                                     | [node-problem-detector](https://github.com/kubernetes/node-problem-detector)组件的角色。 |
-| **system:persistent-volume-provisioner** | None                                     | 允许对大部分[动态存储卷创建组件（dynamic volume provisioner）](https://k8smeetup.github.io/docs/user-guide/persistent-volumes/#provisioner)所需要资源的访问。 |
+| **system:node-bootstrapper**             | None                                                         | 允许对执行[Kubelet TLS引导（Kubelet TLS bootstrapping）](https://k8smeetup.github.io/docs/admin/kubelet-tls-bootstrapping/)所需要资源的访问. |
+| **system:node-problem-detector**         | None                                                         | [node-problem-detector](https://github.com/kubernetes/node-problem-detector)组件的角色。 |
+| **system:persistent-volume-provisioner** | None                                                         | 允许对大部分动态存储卷创建组件（dynamic volume provisioner）所需要资源的访问。 |

 ### 控制器（Controller）角色

--- a/concepts/service.md
+++ b/concepts/service.md
@ -1,7 +1,7 @@
 # Service

 Kubernetes [`Pod`](https://kubernetes.io/docs/user-guide/pods) 是有生命周期的，它们可以被创建，也可以被销毁，然而一旦被销毁生命就永远结束。 
-通过 [`ReplicationController`](https://kubernetes.io/docs/user-guide/replication-controller) 能够动态地创建和销毁 `Pod`（例如，需要进行扩缩容，或者执行 [滚动升级](https://kubernetes.io/docs/user-guide/kubectl/v1.7/#rolling-update)）。 
+通过 [`ReplicationController`](https://kubernetes.io/docs/user-guide/replication-controller) 能够动态地创建和销毁 `Pod`。 
 每个 `Pod` 都会获取它自己的 IP 地址，即使这些 IP 地址不总是稳定可依赖的。
 这会导致一个问题：在 Kubernetes 集群中，如果一组 `Pod`（称为 backend）为其它 `Pod` （称为 frontend）提供服务，那么那些 frontend 该如何发现，并连接到这组 `Pod` 中的哪些 backend 呢？

@ -216,7 +216,7 @@ Kubernetes 支持2种基本的服务发现模式 —— 环境变量和 DNS。
 ### 环境变量

 当 `Pod` 运行在 `Node` 上，kubelet 会为每个活跃的 `Service` 添加一组环境变量。
-它同时支持 [Docker links 兼容](https://docs.docker.com/userguide/dockerlinks/) 变量（查看 [makeLinkVariables](http://releases.k8s.io/{{page.githubbranch}}/pkg/kubelet/envvars/envvars.go#L49)）、简单的 `{SVCNAME}_SERVICE_HOST` 和 `{SVCNAME}_SERVICE_PORT` 变量，这里 `Service` 的名称需大写，横线被转换成下划线。
+它同时支持 [Docker links 兼容](https://docs.docker.com/userguide/dockerlinks/) 变量（查看 makeLinkVariables）、简单的 `{SVCNAME}_SERVICE_HOST` 和 `{SVCNAME}_SERVICE_PORT` 变量，这里 `Service` 的名称需大写，横线被转换成下划线。

 举个例子，一个名称为 `"redis-master"` 的 Service 暴露了 TCP 端口 6379，同时给它分配了 Cluster IP 地址 10.0.0.11，这个 Service 生成了如下环境变量：

@ -464,7 +464,7 @@ Kubernetes 最主要的哲学之一，是用户不应该暴露那些能够导致

 ## API 对象

-在 Kubernetes REST API 中，Service 是 top-level 资源。关于 API 对象的更多细节可以查看：[Service API 对象](https://kubernetes.io/docs/api-reference/v1.7/#service-v1-core)。
+在 Kubernetes REST API 中，Service 是 top-level 资源。

 ## 更多信息

--- a/concepts/statefulset.md
+++ b/concepts/statefulset.md
@ -41,7 +41,7 @@ StatefulSet 适用于有以下某个或多个需求的应用：

 - StatefulSet 是 beta 资源，Kubernetes 1.5 以前版本不支持。
 - 对于所有的 alpha/beta 的资源，您都可以通过在 apiserver 中设置 `--runtime-config` 选项来禁用。
- 给定 Pod 的存储必须由 [PersistentVolume Provisioner](http://releases.k8s.io/%7B%7Bpage.githubbranch%7D%7D/examples/persistent-volume-provisioning/README.md) 根据请求的 `storage class` 进行配置，或由管理员预先配置。
+- 给定 Pod 的存储必须由 PersistentVolume Provisioner 根据请求的 `storage class` 进行配置，或由管理员预先配置。
 - 删除或 scale StatefulSet 将_不会_删除与 StatefulSet 相关联的 volume。 这样做是为了确保数据安全性，这通常比自动清除所有相关 StatefulSet 资源更有价值。
 - StatefulSets 目前要求 [Headless Service](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services) 负责 Pod 的网络身份。 您有责任创建此服务。

@ -114,7 +114,7 @@ StatefulSet Pod 具有唯一的身份，包括序数，稳定的网络身份和

 StatefulSet 中的每个 Pod 从 StatefulSet 的名称和 Pod 的序数派生其主机名。构造的主机名的模式是`$（statefulset名称)-$(序数)`。 上面的例子将创建三个名为`web-0，web-1，web-2`的 Pod。

-StatefulSet 可以使用 [Headless Service](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services) 来控制其 Pod 的域。此服务管理的域的格式为：`$(服务名称).$(namespace).svc.cluster.local`，其中 “cluster.local” 是 [集群域](http://releases.k8s.io/%7B%7Bpage.githubbranch%7D%7D/cluster/addons/dns/README.md)。
+StatefulSet 可以使用 [Headless Service](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services) 来控制其 Pod 的域。此服务管理的域的格式为：`$(服务名称).$(namespace).svc.cluster.local`，其中 “cluster.local” 是集群域。

 在创建每个Pod时，它将获取一个匹配的 DNS 子域，采用以下形式：`$(pod 名称).$(管理服务域)`，其中管理服务由 StatefulSet 上的 `serviceName` 字段定义。

@ -126,7 +126,7 @@ StatefulSet 可以使用 [Headless Service](https://kubernetes.io/docs/concepts/
 | cluster.local  | foo/nginx         | foo/web               | nginx.foo.svc.cluster.local     | web-{0..N-1}.nginx.foo.svc.cluster.local | web-{0..N-1} |
 | kube.local     | foo/nginx         | foo/web               | nginx.foo.svc.kube.local        | web-{0..N-1}.nginx.foo.svc.kube.local    | web-{0..N-1} |

-注意 Cluster Domain 将被设置成 `cluster.local` 除非进行了 [其他配置](http://releases.k8s.io/%7B%7Bpage.githubbranch%7D%7D/cluster/addons/dns/README.md)。
+注意 Cluster Domain 将被设置成 `cluster.local` 除非进行了其他配置。

 ### 稳定存储

--- a/concepts/traefik-ingress-controller.md
+++ b/concepts/traefik-ingress-controller.md
@ -48,8 +48,6 @@ spec:
 - `traefik.frontend.rule.type: PathPrefixStrip`：表示将截掉URL中的`path`
 - `kubernetes.io/ingress.class`：表示使用的ingress类型

-关于Ingress annotation的更多信息请参考：[Ingress Annotations - kubernetes.io](https://github.com/kubernetes/ingress-nginx/blob/master/docs/annotations.md)。
-
 在nginx中增加配置：

 ```ini
--- a/concepts/volume.md
+++ b/concepts/volume.md
@ -14,7 +14,7 @@ Docker 中也有一个 [volume](https://docs.docker.com/engine/admin/volumes/)

 要使用卷，需要为 pod 指定为卷（`spec.volumes` 字段）以及将它挂载到容器的位置（`spec.containers.volumeMounts` 字段）。

-容器中的进程看到的是由其 Docker 镜像和卷组成的文件系统视图。 [Docker 镜像](https://docs.docker.com/userguide/dockerimages/)位于文件系统层次结构的根目录，任何卷都被挂载在镜像的指定路径中。卷无法挂载到其他卷上或与其他卷有硬连接。Pod 中的每个容器都必须独立指定每个卷的挂载位置。
+容器中的进程看到的是由其 Docker 镜像和卷组成的文件系统视图。[Docker 镜像](https://docs.docker.com/userguide/dockerimages/)位于文件系统层次结构的根目录，任何卷都被挂载在镜像的指定路径中。卷无法挂载到其他卷上或与其他卷有硬连接。Pod 中的每个容器都必须独立指定每个卷的挂载位置。

 ## 卷的类型

@ -51,7 +51,7 @@ Kubernetes 支持以下类型的卷：

 ### awsElasticBlockStore

-`awsElasticBlockStore` 卷将Amazon Web Services（AWS）[EBS Volume](http://aws.amazon.com/ebs/) 挂载到您的容器中。与 `emptyDir` 类型会在删除 Pod 时被清除不同，EBS 卷的的内容会保留下来，仅仅是被卸载。这意味着 EBS 卷可以预先填充数据，并且可以在数据包之间“切换”数据。
+`awsElasticBlockStore` 卷将Amazon Web Services（AWS）EBS Volume 挂载到您的容器中。与 `emptyDir` 类型会在删除 Pod 时被清除不同，EBS 卷的的内容会保留下来，仅仅是被卸载。这意味着 EBS 卷可以预先填充数据，并且可以在数据包之间“切换”数据。

 **重要提示**：您必须使用 `aws ec2 create-volume` 或 AWS API 创建 EBS 卷，才能使用它。

@ -97,14 +97,10 @@ spec:

 `AzureDisk` 用于将 Microsoft Azure [Data Disk](https://azure.microsoft.com/zh-cn/documentation/articles/virtual-machines-linux-about-disks-vhds) 挂载到 Pod 中。

-更多细节可以在[这里](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_disk/README.md)找到。
-
 ### azureFile

 `azureFile` 用于将 Microsoft Azure File Volume（SMB 2.1 和 3.0）挂载到 Pod 中。

-更多细节可以在[这里](https://github.com/kubernetes/examples/tree/ master/staging/volumes/azure_file/README.md)找到。
-
 ### cephfs

 `cephfs` 卷允许将现有的 CephFS 卷挂载到您的容器中。不像 `emptyDir`，当删除 Pod 时被删除，`cephfs` 卷的内容将被保留，卷仅仅是被卸载。这意味着 CephFS 卷可以预先填充数据，并且可以在数据包之间“切换”数据。 CephFS 可以被多个写设备同时挂载。
@ -174,7 +170,7 @@ fc 卷允许将现有的 `fc` 卷挂载到 pod 中。您可以使用卷配置中

 ### flocker

-[Flocker](https://clusterhq.com/flocker) 是一款开源的集群容器数据卷管理器。它提供了由各种存储后端支持的数据卷的管理和编排。
+Flocker 是一款开源的集群容器数据卷管理器。它提供了由各种存储后端支持的数据卷的管理和编排。

 `flocker` 允许将 Flocker 数据集挂载到 pod 中。如果数据集在 Flocker 中不存在，则需要先使用 Flocker CLI 或使用 Flocker API 创建数据集。如果数据集已经存在，它将被 Flocker 重新连接到 pod 被调度的节点上。这意味着数据可以根据需要在数据包之间“切换”。

@ -288,7 +284,7 @@ spec:

 - 由于每个节点上的文件都不同，具有相同配置（例如从 podTemplate 创建的）的 pod 在不同节点上的行为可能会有所不同
 - 当 Kubernetes 按照计划添加资源感知调度时，将无法考虑 `hostPath` 使用的资源
- 在底层主机上创建的文件或目录只能由 root 写入。您需要在[特权容器](/docs/user-guide/security-context)中以 root 身份运行进程，或修改主机上的文件权限以便写入 `hostPath` 卷
+- 在底层主机上创建的文件或目录只能由 root 写入。您需要在特权容器中以 root 身份运行进程，或修改主机上的文件权限以便写入 `hostPath` 卷

 #### Pod 示例

@ -321,8 +317,6 @@ spec:

 iSCSI 的一个特点是它可以同时被多个用户以只读方式安装。这意味着您可以预先使用您的数据集填充卷，然后根据需要向多个额 pod 同时提供。不幸的是，iSCSI 卷只能由单个使用者以读写模式挂载——不允许同时写入。

-有关更多详细信息，请参见 [iSCSI示例](https://github.com/kubernetes/examples/tree/ master/staging/volumes/iscsi)。
-
 ### local

 这个 alpha 功能要求启用 `PersistentLocalVolumes` feature gate。
@ -369,7 +363,7 @@ spec:

 **注意**：本地 PersistentVolume 清理和删除需要手动干预，无外部提供程序。

-从 1.9 开始，本地卷绑定可以被延迟，直到通过具有 StorageClass 中的 `WaitForFirstConsumer` 设置为`volumeBindingMode` 的 pod 开始调度。请参阅[示例](storage-classes.md＃local)。延迟卷绑定可确保卷绑定决策也可以使用任何其他节点约束（例如节点资源需求，节点选择器，pod 亲和性和 pod 反亲和性）进行评估。
+从 1.9 开始，本地卷绑定可以被延迟，直到通过具有 StorageClass 中的 `WaitForFirstConsumer` 设置为`volumeBindingMode` 的 pod 开始调度。请参阅示例。延迟卷绑定可确保卷绑定决策也可以使用任何其他节点约束（例如节点资源需求，节点选择器，pod 亲和性和 pod 反亲和性）进行评估。

 有关 `local` 卷类型的详细信息，请参见[本地持久化存储用户指南](https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume)。

@ -397,7 +391,7 @@ spec:
 - [`downwardAPI`](#downwardapi)
 - `configMap`

-所有来源都必须在与 pod 相同的命名空间中。有关更多详细信息，请参阅 [all-in-one 卷设计文档](https://github.com/kubernetes/community/blob/ master/contributors/design-suggestions/node/all-in-one-volume.md)。
+所有来源都必须在与 pod 相同的命名空间中。

 #### 带有 secret、downward API 和 configmap 的 pod

@ -506,16 +500,12 @@ spec:

 **重要提示**：在 pod 中使用之前，请确保您有一个名为 `pxvol` 的现有 PortworxVolume。

-更多的细节和例子可以在[这里](https://github.com/kubernetes/examples/tree/ master /staging/volumes/portworx/README.md)找到。
-
 ### quobyte

 `quobyte` 卷允许将现有的 [Quobyte](http://www.quobyte.com) 卷挂载到容器中。

 **重要提示**：您必须先创建自己的 Quobyte 安装程序，然后才能使用它。

-有关更多详细信息，请参见 [Quobyte示例](https://github.com/kubernetes/examples/tree/ master/staging/volumes/quobyte)。
-
 ### rbd

 `rbd` 卷允许将 [Rados Block Device](http://ceph.com/docs/master/rbd/rbd/) 卷挂载到容器中。不像 `emptyDir`，删除 Pod 时 `rbd `卷的内容被保留，卷仅仅被卸载。这意味着 RBD 卷可以预先填充数据，并且可以在 pod 之间“切换”数据。
@ -524,8 +514,6 @@ spec:

 RBD 的一个特点是它可以同时为多个用户以只读方式挂载。这意味着可以预先使用您的数据集填充卷，然后根据需要同时为多个 pod 并行提供。不幸的是，RBD 卷只能由单个用户以读写模式安装——不允许同时写入。

-有关更多详细信息，请参阅 [RBD示例](https://github.com/kubernetes/examples/tree/ master/staging/volumes/rbd)。
-
 ### scaleIO

 ScaleIO 是一个基于软件的存储平台，可以使用现有的硬件来创建可扩展的共享块网络存储集群。`scaleIO` 卷插件允许已部署的 pod 访问现有的 ScaleIO 卷（或者它可以为持久性卷声明动态调配新卷，请参阅 [ScaleIO 持久卷](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#scaleio)）。
@ -567,8 +555,6 @@ spec:

 **重要提示**：您必须先在 Kubernetes API 中创建一个 secret，然后才能使用它。

-Secret 在[这里](/docs/user-guide/secrets)被更详细地描述。
-
 ### storageOS

 `storageos` 卷允许将现有的 [StorageOS](https://www.storageos.com) 卷挂载到容器中。
@ -609,8 +595,6 @@ spec:
        fsType: ext4
 ```

-有关更多信息，包括动态配置和持久化卷声明，请参阅 [StorageOS 示例](https://github.com/kubernetes/kubernetes/tree/master/examples/volumes/storageos)。
-
 ### vsphereVolume

 **先决条件**：配置了 vSphere Cloud Provider 的 Kubernetes。有关云提供商的配置，请参阅 [vSphere 入门指南](https://kubernetes.io/docs/getting-started-guides/vsphere/)。
--- a/develop/advance-developer.md
+++ b/develop/advance-developer.md
@ -90,7 +90,7 @@ Kubernetes 在设计之初就考虑到了可扩展性。如果上面提到的 AP
 以下主题对构建更复杂的应用程序也很有用：

 - [Kubernetes 中的其他扩展点](https://kubernetes.io/docs/concepts/overview/extending/) - 在哪里可以挂勾到 Kubernetes 架构的概念性的概述
- [Kubernetes 客户端库](https://kubernetes.io/docs/reference/client-libraries/) - 用于构建需要与 Kubernetes API 大量交互的应用程序。
+- Kubernetes 客户端库 - 用于构建需要与 Kubernetes API 大量交互的应用程序。

 #### 下一步

@ -99,4 +99,4 @@ Kubernetes 在设计之初就考虑到了可扩展性。如果上面提到的 AP
 - 如果您想推荐新功能或跟上Kubernetes应用开发的最新进展，请考虑加入 SIG，如 [SIG Apps](https://github.com/kubernetes/community/tree/master/sig-apps)。
 - 如果您有兴趣详细了解 Kubernetes 的内部运作（例如网络），请考虑查看[集群运维之旅](https://kubernetes.io/docs/user-journeys/users/cluster-operator/foundational/)。

-原文：https://kubernetes.iohttps://kubernetes.io/docs/user-journeys/users/application-developer/advanced
+原文：https://kubernetes.io/docs/user-journeys/users/application-developer/advanced
--- a/develop/contribute.md
+++ b/develop/contribute.md
@ -4,6 +4,4 @@
 - [Kubernetes Developer Guide](https://github.com/kubernetes/community/tree/master/contributors/devel)
 - [Special Interest Groups](https://github.com/kubernetes/community)
 - [Feature Tracking and Backlog](https://github.com/kubernetes/features)
- [Community Expectations](https://github.com/kubernetes/community/blob/master/contributors/devel/community-expectations.md)
 - [Kubernetes 官方文档汉化项目](https://github.com/k8smeetup/kubernetes.github.io)
-
--- a/develop/testing.md
+++ b/develop/testing.md
@ -203,5 +203,4 @@ kubectl get pods nginx-4263166205-ggst4 -o template '--template={{if (exists . "
 * [End-to-End Testing](https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-tests.md)
 * [Node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-node-tests.md)
 * [How to write e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/writing-good-e2e-tests.md)
-* [Coding Conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/coding-conventions.md#testing-conventions)
 * https://github.com/kubernetes/test-infra
--- a/develop/using-vagrant-and-virtualbox-for-development.md
+++ b/develop/using-vagrant-and-virtualbox-for-development.md
@ -288,6 +288,5 @@ rm -rf .vagrant
 - [Kubernetes handbook - jimmysong.io](https://jimmysong.io/kubernetes-handbook)
 - [duffqiu/centos-vagrant](https://github.com/duffqiu/centos-vagrant)
 - [kubernetes-vagrant-centos-cluster](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster)
- [vagrant系列二：Vagrant的配置文件vagrantfile详解](https://helei112g.github.io/2016/10/30/vagrant%E7%B3%BB%E5%88%97%E4%BA%8C%EF%BC%9AVagrant%E7%9A%84%E9%85%8D%E7%BD%AE%E6%96%87%E4%BB%B6vagrantfile%E8%AF%A6%E8%A7%A3/)
 - [vagrant网络配置](https://blog.hedzr.com/2017/05/02/vagrant-%E7%BD%91%E7%BB%9C%E9%85%8D%E7%BD%AE/)
 - [Kubernetes 1.8 kube-proxy 开启 ipvs](https://mritd.me/2017/10/10/kube-proxy-use-ipvs-on-kubernetes-1.8/#%E4%B8%80%E7%8E%AF%E5%A2%83%E5%87%86%E5%A4%87)
--- a/guide/access-cluster.md
+++ b/guide/access-cluster.md
@ -12,8 +12,6 @@
 $ kubectl config view
 ```

-关于 kubectl 命令使用的更多 [示例](https://github.com/kubernetes/kubernetes/tree/%7B%7Bpage.githubbranch%7D%7D/examples/) 和完整文档可以在这里找到：[kubectl 手册](https://kubernetes.io/docs/user-guide/kubectl/index)
-
 ### 直接访问 REST API

 Kubectl 处理对 apiserver 的定位和认证。如果您想直接访问 REST API，可以使用像 curl、wget 或浏览器这样的 http 客户端，有以下几种方式来定位和认证：
@ -39,8 +37,6 @@ Kubectl 处理对 apiserver 的定位和认证。如果您想直接访问 REST A
 $ kubectl proxy --port=8080 &
 ```

-查看关于 [kubectl proxy](https://kubernetes.io/docs/user-guide/kubectl/v1.6/#proxy) 的更多细节。
-
 然后您可以使用 curl、wget 或者浏览器来访问 API，如下所示：

 ```bash
@ -128,7 +124,7 @@ Python 客户端可以使用与 kubectl 命令行工具相同的 [kubeconfig 文

 在 pod 中，连接到 API 的推荐方法是：

- 将 kubectl proxy 作为 pod 中的一个容器来运行，或作为在容器内运行的后台进程。它将 Kubernetes API 代理到 pod 的本地主机接口，以便其他任何 pod 中的容器内的进程都可以访问它。请参阅 [在 pod 中使用 kubectl proxy 的示例](https://github.com/kubernetes/kubernetes/tree/%7B%7Bpage.githubbranch%7D%7D/examples/kubectl-container/)。
+- 将 kubectl proxy 作为 pod 中的一个容器来运行，或作为在容器内运行的后台进程。它将 Kubernetes API 代理到 pod 的本地主机接口，以便其他任何 pod 中的容器内的进程都可以访问它。

 - 使用 Go 客户端库，并使用 `rest.InClusterConfig()` 和 `kubernetes.NewForConfig()` 函数创建一个客户端。

@ -145,7 +141,7 @@ Python 客户端可以使用与 kubectl 命令行工具相同的 [kubeconfig 文
 您可以选择以下几种方式从集群外部连接到 node、pod 和 service：

 - 通过 public IP 访问 service。
-  - 使用 `NodePort` 和 `LoadBalancer` 类型的 service，以使 service 能够在集群外部被访问到。请查看 [service](https://kubernetes.io/docs/user-guide/services) 和 [kubectl expose](https://kubernetes.io/docs/user-guide/kubectl/v1.6/#expose) 文档。
+  - 使用 `NodePort` 和 `LoadBalancer` 类型的 service，以使 service 能够在集群外部被访问到。
  - 根据您的群集环境，这可能会将服务暴露给您的公司网络，或者可能会将其暴露在互联网上。想想暴露的服务是否安全。它是否自己进行身份验证？
  - 将 pod 放在服务后面。 要从一组副本（例如为了调试）访问一个特定的 pod，请在 pod 上放置一个唯一的 label，并创建一个选择该 label 的新服务。
  - 在大多数情况下，应用程序开发人员不需要通过 node IP 直接访问节点。
@ -155,7 +151,7 @@ Python 客户端可以使用与 kubectl 命令行工具相同的 [kubeconfig 文
  - 仅适用于 HTTP/HTTPS。
  - [见此描述](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster.md#manually-constructing-apiserver-proxy-urls)。
 - 在集群内访问 node 和 pod。
-  - 运行一个 pod，然后使用 [kubectl exec](https://kubernetes.io/docs/user-guide/kubectl/v1.6/#exec) 命令连接到 shell。从该 shell 中连接到其他 node、pod 和 service。
+  - 运行一个 pod，然后使用 kubectl exec 命令连接到 shell。从该 shell 中连接到其他 node、pod 和 service。
  - 有些集群可能允许 ssh 到集群上的某个节点。 从那个节点您可以访问到集群中的服务。这是一个非标准的方法，它可能将在某些集群上奏效，而在某些集群不行。这些节点上可能安装了浏览器和其他工具也可能没有。群集 DNS 可能无法正常工作。

 ### 访问内置服务
--- a/guide/access-kubernetes-cluster.md
+++ b/guide/access-kubernetes-cluster.md
@ -6,4 +6,3 @@
 - 其次可以使用 `kubeconfig` 文件来认证授权访问 API server。
 - 通过各种 proxy 经过端口转发访问 kubernetes 集群中的服务
 - 使用 Ingress，在集群外访问 kubernetes 集群内的 service
-
--- a/guide/accessing-kubernetes-pods-from-outside-of-the-cluster.md
+++ b/guide/accessing-kubernetes-pods-from-outside-of-the-cluster.md
@ -68,7 +68,7 @@ spec:

 这样做有个缺点，因为Pod重新调度的时候该Pod被调度到的宿主机可能会变动，这样<hostIP>就变化了，用户必须自己维护一个Pod与所在宿主机的对应关系。

-这种网络方式可以用来做 nginx [Ingress controller](https://github.com/kubernetes/ingress/tree/master/controllers/nginx)。外部流量都需要通过kubenretes node节点的80和443端口。
+这种网络方式可以用来做 nginx ingress controller。外部流量都需要通过kubenretes node节点的80和443端口。

 ## NodePort

@ -143,7 +143,7 @@ influxdb   10.97.121.42   10.13.242.236   8086:30051/TCP   39s

 ## Ingress

-`Ingress`是自kubernetes1.1版本后引入的资源类型。必须要部署[Ingress controller](https://github.com/kubernetes/ingress/tree/master/controllers/nginx)才能创建Ingress资源，Ingress controller是以一种插件的形式提供。Ingress controller 是部署在Kubernetes之上的Docker容器。它的Docker镜像包含一个像nginx或HAProxy的负载均衡器和一个控制器守护进程。控制器守护程序从Kubernetes接收所需的Ingress配置。它会生成一个nginx或HAProxy配置文件，并重新启动负载平衡器进程以使更改生效。换句话说，Ingress controller是由Kubernetes管理的负载均衡器。
+`Ingress`是自kubernetes1.1版本后引入的资源类型。必须要部署 Ingress controller 才能创建Ingress资源，Ingress controller是以一种插件的形式提供。Ingress controller 是部署在Kubernetes之上的Docker容器。它的Docker镜像包含一个像nginx或HAProxy的负载均衡器和一个控制器守护进程。控制器守护程序从Kubernetes接收所需的Ingress配置。它会生成一个nginx或HAProxy配置文件，并重新启动负载平衡器进程以使更改生效。换句话说，Ingress controller是由Kubernetes管理的负载均衡器。

 Kubernetes Ingress提供了负载平衡器的典型特性：HTTP路由，粘性会话，SSL终止，SSL直通，TCP和UDP负载平衡等。目前并不是所有的Ingress controller都实现了这些功能，需要查看具体的Ingress controller文档。

@ -162,7 +162,7 @@ spec:
              servicePort: 8086
 ```

-外部访问URL http://influxdb.kube.example.com/ping 访问该服务，入口就是80端口，然后Ingress controller直接将流量转发给后端Pod，不需再经过kube-proxy的转发，比LoadBalancer方式更高效。
+外部访问URL `http://influxdb.kube.example.com/ping` 访问该服务，入口就是80端口，然后Ingress controller直接将流量转发给后端Pod，不需再经过kube-proxy的转发，比LoadBalancer方式更高效。

 ## 总结

--- a/guide/authenticate-across-clusters-kubeconfig.md
+++ b/guide/authenticate-across-clusters-kubeconfig.md
@ -11,7 +11,7 @@ Kubernetes 的认证方式对于不同的人来说可能有所不同。

 此文件包含一系列与昵称相关联的身份验证机制和集群连接信息。它还引入了一个（用户）认证信息元组和一个被称为上下文的与昵称相关联的集群连接信息的概念。

-如果明确指定，则允许使用多个 kubeconfig 文件。在运行时，它们与命令行中指定的覆盖选项一起加载并合并（参见下面的 [规则](https://kubernetes.io/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md#loading-and-merging-rules)）。
+如果明确指定，则允许使用多个 kubeconfig 文件。在运行时，它们与命令行中指定的覆盖选项一起加载并合并（参见下面的 [规则](https://kubernetes.io/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig#loading-and-merging-rules)）。

 ## 相关讨论

@ -79,7 +79,7 @@ clusters:

 `cluster` 中包含 kubernetes 集群的端点数据，包括 kubernetes apiserver 的完整 url 以及集群的证书颁发机构或者当集群的服务证书未被系统信任的证书颁发机构签名时，设置`insecure-skip-tls-verify: true`。

-`cluster` 的名称（昵称）作为该 kubeconfig 文件中的集群字典的 key。 您可以使用 [`kubectl config set-cluster`](https://kubernetes.io/docs/user-guide/kubectl/%7B%7Bpage.version%7D%7D/#-em-set-cluster-em-) 添加或修改 `cluster` 条目。
+`cluster` 的名称（昵称）作为该 kubeconfig 文件中的集群字典的 key。 您可以使用 `kubectl config set-cluster`添加或修改 `cluster` 条目。

 #### user

@ -96,7 +96,7 @@ users:

 `user` 定义用于向 kubernetes 集群进行身份验证的客户端凭据。在加载/合并 kubeconfig 之后，`user` 将有一个名称（昵称）作为用户条目列表中的 key。 可用凭证有 `client-certificate`、`client-key`、`token` 和 `username/password`。 `username/password` 和 `token` 是二者只能选择一个，但 client-certificate 和 client-key 可以分别与它们组合。

-您可以使用 [`kubectl config set-credentials`](https://kubernetes.io/docs/user-guide/kubectl/%7B%7Bpage.version%7D%7D/#-em-set-credentials-em-) 添加或者修改 `user` 条目。
+您可以使用 `kubectl config set-credentials` 添加或者修改 `user` 条目。

 #### context

@ -109,9 +109,9 @@ contexts:
  name: federal-context
 ```

-`context` 定义了一个命名的 [`cluster`](https://kubernetes.io/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md#cluster)、[`user`](https://kubernetes.io/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md#user)、[`namespace`](https://kubernetes.io/docs/user-guide/namespaces) 元组，用于使用提供的认证信息和命名空间将请求发送到指定的集群。 三个都是可选的；仅使用 `cluster`、`user`、`namespace` 之一指定上下文，或指定 none。 未指定的值或在加载的 kubeconfig 中没有相应条目的命名值（例如，如果为上述 kubeconfig 文件指定了 `pink-user` 的上下文）将被替换为默认值。 有关覆盖/合并行为，请参阅下面的 [加载和合并规则](https://kubernetes.io/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md#loading-and-merging)。
+`context` 定义了一个命名的 [`cluster`](https://kubernetes.io/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig#cluster)、[`user`](https://kubernetes.io/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig#user)、[`namespace`](https://kubernetes.io/docs/user-guide/namespaces) 元组，用于使用提供的认证信息和命名空间将请求发送到指定的集群。 三个都是可选的；仅使用 `cluster`、`user`、`namespace` 之一指定上下文，或指定 none。 未指定的值或在加载的 kubeconfig 中没有相应条目的命名值（例如，如果为上述 kubeconfig 文件指定了 `pink-user` 的上下文）将被替换为默认值。 有关覆盖/合并行为，请参阅下面的 [加载和合并规则](https://kubernetes.io/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig#loading-and-merging)。

-您可以使用 [`kubectl config set-context`](https://kubernetes.io/docs/user-guide/kubectl/%7B%7Bpage.version%7D%7D/#-em-set-context-em-) 添加或修改上下文条目。
+您可以使用 `kubectl config set-context` 添加或修改上下文条目。

 #### current-context

@ -119,11 +119,9 @@ contexts:
 current-context: federal-context
 ```

-`current-context` is the nickname or 'key' for the cluster,user,namespace tuple that kubectl will use by default when loading config from this file. You can override any of the values in kubectl from the commandline, by passing `--context=CONTEXT`, `--cluster=CLUSTER`, `--user=USER`, and/or `--namespace=NAMESPACE` respectively. You can change the `current-context` with [`kubectl config use-context`](https://kubernetes.io/docs/user-guide/kubectl/%7B%7Bpage.version%7D%7D/#-em-use-context-em-).
-
 `current-context` 是昵称或者说是作为 `cluster`、`user`、`namespace` 元组的 ”key“，当 kubectl 从该文件中加载配置的时候会被默认使用。您可以在 kubectl 命令行里覆盖这些值，通过分别传入 `—context=CONTEXT`、 `—cluster=CLUSTER`、`--user=USER` 和 `--namespace=NAMESPACE` 。

-您可以使用 [`kubectl config use-context`](https://kubernetes.io/docs/user-guide/kubectl/%7B%7Bpage.version%7D%7D/#-em-use-context-em-) 更改 `current-context`。
+您可以使用 `kubectl config use-context` 更改 `current-context`。

 ```yaml
 apiVersion: v1
@ -138,19 +136,17 @@ preferences:

 ## 查看 kubeconfig 文件

-`kubectl config view` 命令可以展示当前的 kubeconfig 设置。默认将为您展示所有的 kubeconfig 设置；您可以通过传入 `—minify` 参数，将视图过滤到与 `current-context` 有关的配额设置。有关其他选项，请参阅 [`kubectl config view`](https://kubernetes.io/docs/user-guide/kubectl/%7B%7Bpage.version%7D%7D/#-em-view-em-)。
+`kubectl config view` 命令可以展示当前的 kubeconfig 设置。默认将为您展示所有的 kubeconfig 设置；您可以通过传入 `—minify` 参数，将视图过滤到与 `current-context` 有关的配额设置。有关其他选项，请参阅 `kubectl config view`。

 ## 构建您自己的 kubeconfig 文件

-您可以使用上文 [示例 kubeconfig 文件](https://kubernetes.io/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md#example-kubeconfig-file) 作为
+您可以使用上文 [示例 kubeconfig 文件](https://kubernetes.io/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig#example-kubeconfig-file) 作为

 **注意：** 如果您是通过 `kube-up.sh` 脚本部署的 kubernetes 集群，不需要自己创建 kubeconfig 文件——该脚本已经为您创建过了。

-{:.note}
-
 当 api server 启动的时候使用了 `—token-auth-file=tokens.csv` 选项时，上述文件将会与 [API server](https://kubernetes.io/docs/admin/kube-apiserver/) 相关联，`tokens.csv` 文件看起来会像这个样子：

-```
+```bash
 blue-user,blue-user,1
 mister-red,mister-red,2
 ```
@ -159,7 +155,7 @@ mister-red,mister-red,2

 上述示例 kubeconfig 文件提供了 `green-user` 的客户端凭证。因为用户的 `current-user` 是 `green-user` ，任何该 API server 的客户端使用该示例 kubeconfig 文件时都可以成功登录。同样，我们可以通过修改 `current-context` 的值以 `blue-user` 的身份操作。

-在上面的示例中，`green-user` 通过提供凭据登录，`blue-user` 使用的是 token。使用 `kubectl config set-credentials` 指定登录信息。想了解更多信息，请访问 "[示例文件相关操作命令](https://kubernetes.io/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md#commands-for-the-example-file)"。
+在上面的示例中，`green-user` 通过提供凭据登录，`blue-user` 使用的是 token。使用 `kubectl config set-credentials` 指定登录信息。想了解更多信息，请访问 "[示例文件相关操作命令](https://kubernetes.io/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig#commands-for-the-example-file)"。

 ## 加载和合并规则

@ -207,7 +203,7 @@ Kubeconfig 文件中的任何路径都相对于 kubeconfig 文件本身的位置

 `kubectl config` 有一些列的子命令可以帮助我们更方便的操作 kubeconfig 文件。

-请参阅 [kubectl/kubectl_config](https://kubernetes.io/docs/user-guide/kubectl/%7B%7Bpage.version%7D%7D/#config)。
+请参阅 `kubectl/kubectl_config`。

 ### Example

--- a/guide/authentication.md
+++ b/guide/authentication.md
@ -34,7 +34,7 @@ Kubernetes 使用客户端证书、bearer token、身份验证代理或者 HTTP

 `system:authenticated` 组包含在所有已验证用户的组列表中。

-与其他身份验证协议（LDAP、SAML、Kerberos、x509 方案等）的集成可以使用 [身份验证代理](#authenticating-proxy) 或 [身份验证 webhook](#webhook-token-authentication) 来实现。
+与其他身份验证协议（LDAP、SAML、Kerberos、x509 方案等）的集成可以使用身份验证代理或身份验证 webhook来实现。

 ### X509 客户端证书

@ -48,8 +48,6 @@ openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app

 这将为一个用户名为 ”jbeda“ 的 CSR，属于两个组“app1”和“app2”。

-如何生成客户端证书请参阅 [附录](#appendix)。
-
 ### 静态 Token 文件

 当在命令行上指定 `--token-auth-file=SOMEFILE` 选项时，API server 从文件读取 bearer token。目前，token 会无限期地持续下去，并且不重新启动 API server 的话就无法更改令牌列表。
@ -158,7 +156,7 @@ type: kubernetes.io/service-account-token

 注意：所有值是基于 base64 编码的，因为 secret 总是基于 base64 编码。

-经过签名的 JWT 可以用作 bearer token 与给定的 service account 进行身份验证。请参阅 [上面](#putting-a-bearer-token-in-a-request) 关于如何在请求中放置 bearer token。通常情况下，这些 secret 被挂载到 pod 中，以便对集群内的 API server 进行访问，但也可以从集群外访问。
+经过签名的 JWT 可以用作 bearer token 与给定的 service account 进行身份验证。请参阅上面关于如何在请求中放置 bearer token。通常情况下，这些 secret 被挂载到 pod 中，以便对集群内的 API server 进行访问，但也可以从集群外访问。

 Service account 验证时用户名 `system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)`，被指定到组 `system:serviceaccounts` 和 `system:serviceaccounts:(NAMESPACE)`。

@ -168,7 +166,7 @@ Service account 验证时用户名 `system:serviceaccount:(NAMESPACE):(SERVICEAC

 [OpenID Connect](https://openid.net/connect/) 是由 OAuth2 供应商提供的 OAuth2，特别是 Azure Active Directory、Salesforce 和 Google。对 OAuth2 协议的主要扩展是返回一个称作 [ID Token](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) 的格外字段。该 token 是一个 JSON Web Token (JWT) ，有服务器签名，具有众所周知的字段，如用户的电子邮件。

-为了识别用户，认证者使用 OAuth2 [token 响应](https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse) 中的 `id_token`（而不是 `access_token`）作为 bearer token。请参阅 [上面](#putting-a-bearer-token-in-a-request) 的关于将 token 置于请求中。
+为了识别用户，认证者使用 OAuth2 [token 响应](https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse) 中的 `id_token`（而不是 `access_token`）作为 bearer token。请参阅上面的关于将 token 置于请求中。

 ![Kubernetes OpenID Connect Flow](../images/kubernetes-oidc-login.jpg)

@ -192,13 +190,13 @@ Service account 验证时用户名 `system:serviceaccount:(NAMESPACE):(SERVICEAC

 要启用该插件，需要在 API server 中配置如下标志：

-| 参数                      | 描述                                       | 示例                                       | 是否必需 |
-| ----------------------- | ---------------------------------------- | ---------------------------------------- | ---- |
-| `--oidc-issuer-url`     | 允许 API server 发现公共签名密钥的提供者的 URL。只接受使用 `https://` 的方案。通常是提供商的 URL 地址，不包含路径，例如“https://accounts.google.com” 或者 “https://login.salesforce.com”。这个 URL 应该指向下面的 .well-known/openid-configuration | 如果发现 URL 是 `https://accounts.google.com/.well-known/openid-configuration`，值应该是`https://accounts.google.com` | 是    |
-| `--oidc-client-id`      | 所有的 token 必须为其颁发的客户端 ID                  | kubernetes                               | 是    |
-| `--oidc-username-claim` | JWT声明使用的用户名。默认情况下，`sub` 是最终用户的唯一标识符。管理员可以选择其他声明，如` email` 或 `name`，具体取决于他们的提供者。不过，`email` 以外的其他声明将以发行者的 URL 作为前缀，以防止与其他插件命名冲突。 | sub                                      | 否    |
-| `--oidc-groups-claim`   | JWT声明使用的用户组。如果生命存在，它必须是一个字符串数组。          | groups                                   | 否    |
-| `--oidc-ca-file`        | 用来签名您的身份提供商的网络 CA 证书的路径。默认为主机的跟 CA。      | `/etc/kubernetes/ssl/kc-ca.pem`          | 否    |
+| 参数                    | 描述                                                         | 示例                                                         | 是否必需 |
+| ----------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | -------- |
+| `--oidc-issuer-url`     | 允许 API server 发现公共签名密钥的提供者的 URL。只接受使用 `https://` 的方案。通常是提供商的 URL 地址，不包含路径，例如“<https://accounts.google.com>” 或者 “<https://login.salesforce.com>”。这个 URL 应该指向下面的 .well-known/openid-configuration | 如果发现 URL 是 `https://accounts.google.com/.well-known/openid-configuration`，值应该是`https://accounts.google.com` | 是       |
+| `--oidc-client-id`      | 所有的 token 必须为其颁发的客户端 ID                         | kubernetes                                                   | 是       |
+| `--oidc-username-claim` | JWT声明使用的用户名。默认情况下，`sub` 是最终用户的唯一标识符。管理员可以选择其他声明，如` email` 或 `name`，具体取决于他们的提供者。不过，`email` 以外的其他声明将以发行者的 URL 作为前缀，以防止与其他插件命名冲突。 | sub                                                          | 否       |
+| `--oidc-groups-claim`   | JWT声明使用的用户组。如果生命存在，它必须是一个字符串数组。  | groups                                                       | 否       |
+| `--oidc-ca-file`        | 用来签名您的身份提供商的网络 CA 证书的路径。默认为主机的跟 CA。 | `/etc/kubernetes/ssl/kc-ca.pem`                              | 否       |

 如果为 `--oidc-username-claim` 选择了除 `email` 以外的其他声明，则该值将以 `--oidc-issuer-url` 作为前缀，以防止与现有 Kubernetes 名称（例如 `system:users`）冲突。例如，如果提供商网址是 https://accounts.google.com，而用户名声明映射到 `jane`，则插件会将用户身份验证为：

@ -218,11 +216,9 @@ Kubernetes不提供 OpenID Connect 身份提供商。您可以使用现有的公

 有关上述要求3的说明，需要 CA 签名证书。如果您部署自己的身份提供商（而不是像 Google 或 Microsoft 之类的云提供商），则必须让您的身份提供商的 Web 服务器证书由 CA 标志设置为 TRUE 的证书签名，即使是自签名的。这是由于 GoLang 的 TLS 客户端实现对证书验证的标准非常严格。如果您没有 `CA`，可以使用 `CoreOS` 团队的 [这个脚本](https://github.com/coreos/dex/blob/1ee5920c54f5926d6468d2607c728b71cfe98092/examples/k8s/gencert.sh) 创建一个简单的 CA 和一个签名的证书和密钥对。

-或者你可以使用 [这个类似的脚本](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/makecerts.sh) 来生成更长寿命和更长的 SHA256 证书密钥。
-
 针对特定系统的安装说明：

- [UAA](http://apigee.com/about/blog/engineering/kubernetes-authentication-enterprise)
+- [UAA](https://apigee.com/about/blog/engineering/kubernetes-authentication-enterprise)
 - [Dex](https://speakerdeck.com/ericchiang/kubernetes-access-control-with-dex)
 - [OpenUnison](https://github.com/TremoloSecurity/openunison-qs-kubernetes)

@ -319,7 +315,7 @@ contexts:
  name: webhook
 ```

-当客户端尝试使用 bearer token 与API server 进行认证是，如 [上](#putting-a-bearer-token-in-a-request) 论述，认证 webhook 用饱含该 token 的对象查询远程服务。Kubernetes 不会挑战缺少该 header 的请求。
+当客户端尝试使用 bearer token 与API server 进行认证是，如上论述，认证 webhook 用饱含该 token 的对象查询远程服务。Kubernetes 不会挑战缺少该 header 的请求。

 请注意，webhook API对象与其他 Kubernetes API 对象具有相同的 [版本控制兼容性规则](https://kubernetes.io/docs/concepts/overview/kubernetes-api/)。实现者应该意识到 Beta 对象的宽松兼容性承诺，并检查请求的 “apiVersion” 字段以确保正确的反序列化。此外，API server 必须启用 `authentication.k8s.io/v1beta1` API 扩展组（`--runtime config =authentication.k8s.io/v1beta1=true`）。

@ -633,8 +629,6 @@ rules:
 #### 认证 API

 您可以使用 `certificates.k8s.io` API将 x509 证书配置为用于身份验证，如 [此处](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster) 所述。
-
-官方v1.6文档地址：https://v1-6.docs.kubernetes.io/docs/admin/authentication/
 官方最新文档地址：https://kubernetes.io/docs/admin/authentication/

 译者：[Jimmy Song](https://jimmysong.io)
--- a/guide/configure-liveness-readiness-probes.md
+++ b/guide/configure-liveness-readiness-probes.md
@ -241,7 +241,7 @@ Readiness和livenss probe可以并行用于同一容器。 使用两者可以确

 ## 配置Probe

-[Probe](https://kubernetes.io/docs/api-reference/v1.6/#probe-v1-core)中有很多精确和详细的配置，通过它们你能准确的控制liveness和readiness检查：
+Probe 中有很多精确和详细的配置，通过它们你能准确的控制liveness和readiness检查：

 - `initialDelaySeconds`：容器启动后第一次执行探测是需要等待多少秒。
 - `periodSeconds`：执行探测的频率。默认是10秒，最小1秒。
@ -249,7 +249,7 @@ Readiness和livenss probe可以并行用于同一容器。 使用两者可以确
 - `successThreshold`：探测失败后，最少连续探测成功多少次才被认定为成功。默认是1。对于liveness必须是1。最小值是1。 
 - `failureThreshold`：探测成功后，最少连续探测失败多少次才被认定为失败。默认是3。最小值是1。

-[HTTP probe](https://kubernetes.io/docs/api-reference/v1.6/#httpgetaction-v1-core)中可以给 `httpGet`设置其他配置项：
+HTTP probe 中可以给 `httpGet`设置其他配置项：

 - `host`：连接的主机名，默认连接到pod的IP。你可能想在http header中设置"Host"而不是使用IP。
 - `scheme`：连接使用的schema，默认HTTP。
--- a/guide/deploy-applications-in-kubernetes.md
+++ b/guide/deploy-applications-in-kubernetes.md
@ -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容器间的环境变量传递源码探究](http://rootsongjc.github.io/blogs/exploring-kubernetes-env-with-docker/)。
+答案是使用DNS，详细说明见[Kubernetes中的服务发现与Docker容器间的环境变量传递源码探究](https://jimmysong.io/posts/exploring-kubernetes-env-with-docker/)。

 ## 持续集成

--- a/guide/ip-masq-agent.md
+++ b/guide/ip-masq-agent.md
@ -12,7 +12,7 @@ kubectl create -f https://raw.githubusercontent.com/kubernetes-incubator/ip-masq

 关于 ip-masq-agent 的更多信息请参考 [该文档](https://github.com/kubernetes-incubator/ip-masq-agent)。

-在大多数情况下，默认的一套规则应该是足够的；但是，如果内置的规则不适用于您的集群，您可以创建并应用 [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configmap/) 来自定义受影响的 IP 范围。例如，为了仅允许 ip-masq-agent 考虑 10.0.0.0/8，您可以在名为 “config” 的文件中创建以下 [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configmap)。
+在大多数情况下，默认的一套规则应该是足够的；但是，如果内置的规则不适用于您的集群，您可以创建并应用 ConfigMap 来自定义受影响的 IP 范围。例如，为了仅允许 ip-masq-agent 考虑 10.0.0.0/8，您可以在名为 “config” 的文件中创建以下 ConfigMap。

 ```yaml
 nonMasqueradeCIDRs:
--- a/guide/kubernetes-security-best-practice.md
+++ b/guide/kubernetes-security-best-practice.md
@ -23,7 +23,7 @@

 **授权模式和匿名认证**

-像kops这样的一些安装程序会为集群使用`AlwaysAllow`授权模式。这将授予任何经过身份验证的实体拥有完全访问集群的权限。应该使用RBAC基于角色的访问控制。检查您的kube-apiserver进程的`--authorization-mode`参数。有关该主题的更多信息，请访问https://kubernetes.io/docs/admin/authorization/。要强制进行身份验证，请确保通过设置`--anonymous-auth = false`禁用匿名身份验证。
+像kops这样的一些安装程序会为集群使用`AlwaysAllow`授权模式。这将授予任何经过身份验证的实体拥有完全访问集群的权限。应该使用RBAC基于角色的访问控制。检查您的kube-apiserver进程的`--authorization-mode`参数。有关该主题的更多信息，请访问<https://kubernetes.io/docs/admin/authorization/>。要强制进行身份验证，请确保通过设置`--anonymous-auth = false`禁用匿名身份验证。

 注意这不影响Kubelet授权模式。kubelet本身公开了一个API来执行命令，通过它可以完全绕过Kubernetes API。

--- a/guide/managing-tls-in-a-cluster.md
+++ b/guide/managing-tls-in-a-cluster.md
@ -72,7 +72,7 @@ spec:
 EOF
 ```

-请注意，在步骤1中创建的`server.csr`文件是base64编码并存储在`.spec.request`字段中。 我们还要求提供“数字签名”，“密钥加密”和“服务器身份验证”密钥用途的证书。 我们[这里](https://godoc.org/k8s.io/client-go/pkg/apis/certificates/v1beta1#KeyUsage)支持列出的所有关键用途和扩展的关键用途，以便您可以使用相同的API请求客户端证书和其他证书。
+请注意，在步骤1中创建的`server.csr`文件是base64编码并存储在`.spec.request`字段中。 我们还要求提供“数字签名”，“密钥加密”和“服务器身份验证”密钥用途的证书。

 在API server中可以看到这些CSR处于pending状态。执行下面的命令你将可以看到：

--- a/guide/secret-configuration.md
+++ b/guide/secret-configuration.md
@ -1,6 +1,6 @@
 # Secret 配置

-`Secret` 对象类型用来保存敏感信息，例如密码、OAuth 令牌和 ssh key。将这些信息放在 `secret` 中比放在 `pod` 的定义中或者 docker 镜像中来说更加安全和灵活。参阅 [Secret 设计文档](https://git.k8s.io/community/contributors/design-proposals/secrets.md) 获取更多详细信息。
+`Secret` 对象类型用来保存敏感信息，例如密码、OAuth 令牌和 ssh key。将这些信息放在 `secret` 中比放在 `pod` 的定义中或者 docker 镜像中来说更加安全和灵活。

 ## Secret 概览

@ -62,7 +62,7 @@ username.txt:    5 bytes

 请注意，默认情况下，`get` 和 `describe` 命令都不会显示文件的内容。这是为了防止将 secret 中的内容被意外暴露给从终端日志记录中刻意寻找它们的人。

-请参阅 [解码 secret](https://kubernetes.io/docs/concepts/configuration/secret.md#decoding-a-secret) 了解如何查看它们的内容。
+请参阅 [解码 secret](https://kubernetes.io/docs/concepts/configuration/secret#decoding-a-secret) 了解如何查看它们的内容。

 #### 手动创建 Secret

@ -90,9 +90,9 @@ data:
  password: MWYyZDFlMmU2N2Rm
 ```

-数据字段是一个映射。它的键必须匹配 [DNS_SUBDOMAIN](https://git.k8s.io/community/contributors/design-proposals/identifiers.md)，前导点也是可以的。这些值可以是任意数据，使用 base64 进行编码。
+数据字段是一个映射。它的键必须匹配 DNS_SUBDOMAIN，前导点也是可以的。这些值可以是任意数据，使用 base64 进行编码。

-使用 [`kubectl create`](https://kubernetes.io/docs/user-guide/kubectl/v1.7/#create) 创建 secret：
+使用 `kubectl create`创建 secret：

 ```bash
 $ kubectl create -f ./secret.yaml
@ -549,7 +549,7 @@ Secret 的重要性通常不尽相同，其中许多可能只对 Kubernetes 集

 需要访问 secrets API 的应用程序应该根据他们需要的 secret 执行 `get` 请求。这允许管理员限制对所有 secret 的访问，同时设置 [白名单访问](https://kubernetes.io/docs/admin/authorization/rbac/#referring-to-resources) 应用程序需要的各个实例。

-为了提高循环获取的性能，客户端可以设计引用 secret 的资源，然后 `watch` 资源，在引用更改时重新请求 secret。此外，还提出了一种 [”批量监控“ API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/bulk_watch.md) 来让客户端 `watch` 每个资源，该功能可能会在将来的 Kubernetes 版本中提供。
+为了提高循环获取的性能，客户端可以设计引用 secret 的资源，然后 `watch` 资源，在引用更改时重新请求 secret。

 ## 安全属性

@ -565,7 +565,7 @@ Secret 的重要性通常不尽相同，其中许多可能只对 Kubernetes 集

 同一节点上的很多个 pod 可能拥有多个 secret。但是，只有 pod 请求的 secret 在其容器中才是可见的。因此，一个 pod 不能访问另一个 Pod 的 secret。

-Pod 中有多个容器。但是，pod 中的每个容器必须请求其挂载卷中的 secret 卷才能在容器内可见。这可以用于 [在 Pod 级别构建安全分区](https://kubernetes.io/docs/concepts/configuration/secret.md#use-case-secret-visible-to-one-container-in-a-pod)。
+Pod 中有多个容器。但是，pod 中的每个容器必须请求其挂载卷中的 secret 卷才能在容器内可见。这可以用于 [在 Pod 级别构建安全分区](https://kubernetes.io/docs/concepts/configuration/secret#use-case-secret-visible-to-one-container-in-a-pod)。

 ### 风险

--- a/guide/service-access-application-cluster.md
+++ b/guide/service-access-application-cluster.md
@ -16,7 +16,7 @@
   kubectl run hello-world --replicas=2 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0  --port=8080
   ```

-   上述命令创建一个 [Deployment](https://github.com/rootsongjc/kubernetes.github.io/blob/0d907997e57e046bda9c4f5b5d615619181d571f/docs/concepts/workloads/controllers/deployment) 对象和一个相关联的 [ReplicaSet](https://github.com/rootsongjc/kubernetes.github.io/blob/0d907997e57e046bda9c4f5b5d615619181d571f/docs/concepts/workloads/controllers/replicaset) 对象。该 ReplicaSet 有两个 [Pod](https://github.com/rootsongjc/kubernetes.github.io/blob/0d907997e57e046bda9c4f5b5d615619181d571f/docs/concepts/workloads/pods/pod)，每个 Pod 中都运行一个 Hello World 应用程序。
+   上述命令创建一个 [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) 对象和一个相关联的 [ReplicaSet](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset) 对象。该 ReplicaSet 有两个 [Pod](https://kubernetes.io/docs/concepts/workloads/pods/pod)，每个 Pod 中都运行一个 Hello World 应用程序。

 2. 显示关于该 Deployment 的信息：

@ -97,7 +97,7 @@

 ## 使用 Service 配置文件

-作为使用 `kubectl expose` 的替代方法，您可以使用 [service 配置文件](https://github.com/rootsongjc/kubernetes.github.io/blob/0d907997e57e046bda9c4f5b5d615619181d571f/docs/user-guide/services/operations) 来创建 Service。
+作为使用 `kubectl expose` 的替代方法，您可以使用 [service 配置文件](https://kubernetes.io/docs/user-guide/services/operations) 来创建 Service。

 要删除 Service，输入以下命令：

@ -111,5 +111,5 @@ kubectl delete services example-service
 kubectl delete deployment hello-world
 ```

-了解更多关于 [使用 service 连接应用程序](https://github.com/rootsongjc/kubernetes.github.io/blob/0d907997e57e046bda9c4f5b5d615619181d571f/docs/concepts/services-networking/connect-applications-service)。
+了解更多关于 [使用 service 连接应用程序](https://kubernetes.io/docs/concepts/services-networking/connect-applications-service)。

--- a/practice/app-log-collection.md
+++ b/practice/app-log-collection.md
@ -108,7 +108,7 @@ data:

 **说明**

-该文件中包含了配置文件filebeat的配置文件的[ConfigMap](http://rootsongjc.github.io/blogs/kubernetes-configmap-introduction/)，因此不需要再定义环境变量。
+该文件中包含了配置文件filebeat的配置文件的[ConfigMap](https://jimmysong.io/posts/kubernetes-configmap-introduction/)，因此不需要再定义环境变量。

 当然你也可以不同ConfigMap，通过传统的传递环境变量的方式来配置filebeat。

--- a/practice/ceph.md
+++ b/practice/ceph.md
@ -40,25 +40,25 @@ Kubernetes支持Ceph的块存储（Ceph RBD）和文件存储（CephFS）作为K

 | Volume Plugin        | Internal Provisioner| Config Example                       |
 | :---                 |     :---:           |    :---:                             |
-| AWSElasticBlockStore | &#x2713;            | [AWS](#aws)                          |
-| AzureFile            | &#x2713;            | [Azure File](#azure-file)            |
-| AzureDisk            | &#x2713;            | [Azure Disk](#azure-disk)            |
+| AWSElasticBlockStore | &#x2713;            | AWS                      |
+| AzureFile            | &#x2713;            | Azure File            |
+| AzureDisk            | &#x2713;            | Azure Disk            |
 | CephFS               | -                   | -                                    |
-| Cinder               | &#x2713;            | [OpenStack Cinder](#openstack-cinder)|
+| Cinder               | &#x2713;            | OpenStack Cinder |
 | FC                   | -                   | -                                    |
 | FlexVolume           | -                   | -                                    |
 | Flocker              | &#x2713;            | -                                    |
-| GCEPersistentDisk    | &#x2713;            | [GCE](#gce)                          |
-| Glusterfs            | &#x2713;            | [Glusterfs](#glusterfs)              |
+| GCEPersistentDisk    | &#x2713;            | GCE                          |
+| Glusterfs            | &#x2713;            | Glusterfs              |
 | iSCSI                | -                   | -                                    |
 | PhotonPersistentDisk | &#x2713;            | -                                    |
-| Quobyte              | &#x2713;            | [Quobyte](#quobyte)                  |
+| Quobyte              | &#x2713;            | Quobyte                  |
 | NFS                  | -                   | -                                    |
-| RBD                  | &#x2713;            | [Ceph RBD](#ceph-rbd)                |
-| VsphereVolume        | &#x2713;            | [vSphere](#vsphere)                  |
-| PortworxVolume       | &#x2713;            | [Portworx Volume](#portworx-volume)  |
-| ScaleIO              | &#x2713;            | [ScaleIO](#scaleio)                  |
-| StorageOS            | &#x2713;            | [StorageOS](#storageos)              |
-| Local                | -                   | [Local](#local)              |
+| RBD                  | &#x2713;            | Ceph RBD                |
+| VsphereVolume        | &#x2713;            | vSphere                  |
+| PortworxVolume       | &#x2713;            | Portworx Volume  |
+| ScaleIO              | &#x2713;            | ScaleIO                  |
+| StorageOS            | &#x2713;            | StorageOS              |
+| Local                | -                   | Local     |

 后续文档将介绍Kubernetes如何与Ceph RDB 和 CephFS集成。
--- a/practice/ci-cd.md
+++ b/practice/ci-cd.md
@ -32,7 +32,7 @@ Kubernetes细化的应用程序的分解粒度，同时将服务发现、配置

 ![Kubernetes中的CI/CD](https://ws1.sinaimg.cn/large/00704eQkgy1fsayfzk3ezj31bu0tkdky.jpg)

-有了基于Kubernetes的CI/CD流程后，又诞生了GitOps（<http://weave.works>的博客中有很多相关文章）和SecOps（Security Operation）。
+有了基于Kubernetes的CI/CD流程后，又诞生了GitOps（<https://www.weave.works>的博客中有很多相关文章）和SecOps（Security Operation）。

 ### 云原生应用模式

--- a/practice/configuration-best-practice.md
+++ b/practice/configuration-best-practice.md
@ -7,8 +7,8 @@
 - 定义配置文件的时候，指定最新的稳定API版本（目前是V1）。
 - 在配置文件push到集群之前应该保存在版本控制系统中。这样当需要的时候能够快速回滚，必要的时候也可以快速的创建集群。
 - 使用YAML格式而不是JSON格式的配置文件。在大多数场景下它们都可以作为数据交换格式，但是YAML格式比起JSON更易读和配置。
- 尽量将相关的对象放在同一个配置文件里。这样比分成多个文件更容易管理。参考[guestbook-all-in-one.yaml](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook/all-in-one/guestbook-all-in-one.yaml)文件中的配置（注意，尽管你可以在使用`kubectl`命令时指定配置文件目录，你也可以在配置文件目录下执行`kubectl create`——查看下面的详细信息）。
- 为了简化和最小化配置，也为了防止错误发生，不要指定不必要的默认配置。例如，省略掉`ReplicationController`的selector和label，如果你希望它们跟`podTemplate`中的label一样的话，因为那些配置默认是`podTemplate`的label产生的。更多信息请查看 [guestbook app](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook/) 的yaml文件和 [examples](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook/frontend-deployment.yaml) 。
+- 尽量将相关的对象放在同一个配置文件里。这样比分成多个文件更容易管理。
+- 为了简化和最小化配置，也为了防止错误发生，不要指定不必要的默认配置。例如，省略掉`ReplicationController`的selector和label，如果你希望它们跟`podTemplate`中的label一样的话，因为那些配置默认是`podTemplate`的label产生的。
 - 将资源对象的描述放在一个annotation中可以更好的内省。


@ -26,7 +26,7 @@

 ## 使用Label

- 定义 [labels](https://kubernetes.io/docs/user-guide/labels/) 来指定应用或Deployment的 **semantic attributes** 。例如，不是将label附加到一组pod来显式表示某些服务（例如，`service:myservice`），或者显式地表示管理pod的replication controller（例如，`controller:mycontroller`），附加label应该是标示语义属性的标签， 例如`{app:myapp,tier:frontend,phase:test,deployment:v3}`。 这将允许您选择适合上下文的对象组——例如，所有的”tier:frontend“pod的服务或app是“myapp”的所有“测试”阶段组件。 有关此方法的示例，请参阅[guestbook](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook/)应用程序。
+- 定义 [labels](https://kubernetes.io/docs/user-guide/labels/) 来指定应用或Deployment的 **semantic attributes** 。例如，不是将label附加到一组pod来显式表示某些服务（例如，`service:myservice`），或者显式地表示管理pod的replication controller（例如，`controller:mycontroller`），附加label应该是标示语义属性的标签， 例如`{app:myapp,tier:frontend,phase:test,deployment:v3}`。 这将允许您选择适合上下文的对象组——例如，所有的”tier:frontend“pod的服务或app是“myapp”的所有“测试”阶段组件。 

  可以通过简单地从其service的选择器中省略特定于发行版本的标签，而不是更新服务的选择器来完全匹配replication controller的选择器，来实现跨越多个部署的服务，例如滚动更新。

--- a/practice/configuring-dns.md
+++ b/practice/configuring-dns.md
@ -12,7 +12,7 @@ kubeadm init --feature-gates=CoreDNS=true

 ## kube-dns

-kube-dns是Kubernetes中的一个内置插件，目前作为一个独立的开源项目维护，见https://github.com/kubernetes/dns。
+kube-dns是Kubernetes中的一个内置插件，目前作为一个独立的开源项目维护，见<https://github.com/kubernetes/dns>。

 下文中给出了配置 DNS Pod 的提示和定义 DNS 解析过程以及诊断 DNS 问题的指南。

@ -78,7 +78,7 @@ spec:

 ## 继承节点的 DNS

-运行 Pod 时，kubelet 将预先配置集群 DNS 服务器到 Pod 中，并搜索节点自己的 DNS 设置路径。如果节点能够解析特定于较大环境的 DNS 名称，那么 Pod 应该也能够解析。请参阅下面的[已知问题](#known-issues)以了解警告。
+运行 Pod 时，kubelet 将预先配置集群 DNS 服务器到 Pod 中，并搜索节点自己的 DNS 设置路径。如果节点能够解析特定于较大环境的 DNS 名称，那么 Pod 应该也能够解析。请参阅下面的已知问题以了解警告。

 如果您不想要这个，或者您想要为 Pod 设置不同的 DNS 配置，您可以给 kubelet 指定 `--resolv-conf` 标志。将该值设置为 "" 意味着 Pod 不继承 DNS。将其设置为有效的文件路径意味着 kubelet 将使用此文件而不是 `/etc/resolv.conf` 用于 DNS 继承。

@ -111,7 +111,7 @@ data:
 | foo.acme.local                       | 自定义 DNS (1.2.3.4)          |
 | widget.com                           | 上游 DNS (8.8.8.8 或 8.8.4.4) |

-查看 [ConfigMap 选项](#configmap-options) 获取更多关于配置选项格式的详细信息。
+查看 ConfigMap 选项获取更多关于配置选项格式的详细信息。

 ### 对 Pod 的影响

@ -121,7 +121,7 @@ data:

 **未进行自定义配置**：没有匹配上配置的集群域名后缀的任何请求，例如 “www.kubernetes.io”，将会被转发到继承自节点的上游 nameserver。

-**进行自定义配置**：如果配置了存根域和上游 DNS 服务器（和在 [前面例子](#configuring-stub-domain-and-upstream-dns-servers) 配置的一样），DNS 查询将根据下面的流程进行路由：
+**进行自定义配置**：如果配置了存根域和上游 DNS 服务器（和在前面例子配置的一样），DNS 查询将根据下面的流程进行路由：

 1. 查询首先被发送到 kube-dns 中的 DNS 缓存层。

@ -224,7 +224,7 @@ Address 1: 10.0.0.1

 ### 首先检查本地 DNS 配置

-查看下 resolv.conf 文件。（参考[集成节点的 DNS](inheriting-dns-from-the-node)和 下面的[已知问题](#known-issues)获取更多信息）
+查看下 resolv.conf 文件。

 ```bash
 $ kubectl exec busybox cat /etc/resolv.conf
@ -327,6 +327,6 @@ Kubernetes 1.3 版本起引入了支持多站点 Kubernetes 安装的集群联
 ## 参考

 - [Configure DNS Service](https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/)
- [Service 和 Pod 的 DNS](/docs/concepts/services-networking/dns-pod-service/)
- [自动扩容集群中的 DNS 服务](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)
+- [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/)
--- a/practice/coredns.md
+++ b/practice/coredns.md
@ -5,7 +5,7 @@ Kubernetes集群中读取区（zone）数据。它实现了为Kubernetes的DNS

 ## 部署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](/manifests/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。重用已有的服务并不会在服务的请求中发生冲突。
--- a/practice/create-kubeconfig.md
+++ b/practice/create-kubeconfig.md
@ -4,7 +4,7 @@

 `kubelet`、`kube-proxy` 等 Node 机器上的进程与 Master 机器的 `kube-apiserver` 进程通信时需要认证和授权；

-kubernetes 1.4 开始支持由 `kube-apiserver` 为客户端生成 TLS 证书的 [TLS Bootstrapping](https://kubernetes.io/docs/admin/kubelet-tls-bootstrapping/) 功能，这样就不需要为每个客户端生成证书了；该功能**当前仅支持为 `kubelet`** 生成证书；
+kubernetes 1.4 开始支持由 `kube-apiserver` 为客户端生成 TLS 证书的 TLS Bootstrapping 功能，这样就不需要为每个客户端生成证书了；该功能**当前仅支持为 `kubelet`** 生成证书；

 因为我的master节点和node节点复用，所有在这一步其实已经安装了kubectl。参考[安装kubectl命令行工具](kubectl-installation.md)。

--- a/practice/create-private-charts-repo.md
+++ b/practice/create-private-charts-repo.md
@ -73,8 +73,6 @@ Chart 仓库（repository）是一个用来托管`index.yaml`文件和打包好

 ## 构建Monocular UI

-参考 [Monocular UI](Monocular UI) 构建UI。
-
 克隆项目到本地

 ```bash
--- a/practice/create-tls-and-secret-key.md
+++ b/practice/create-tls-and-secret-key.md
@ -405,7 +405,6 @@ cp *.pem /etc/kubernetes/ssl
 ## 参考

 + [Generate self-signed certificates](https://coreos.com/os/docs/latest/generate-self-signed-certificates.html)
-+ [Setting up a Certificate Authority and Creating TLS Certificates](https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/master/docs/02-certificate-authority.md)
 + [Client Certificates V/s Server Certificates](https://blogs.msdn.microsoft.com/kaushal/2012/02/17/client-certificates-vs-server-certificates/)
 + [数字证书及 CA 的扫盲介绍](http://blog.jobbole.com/104919/)
 + [TLS bootstrap 引导程序](../guide/tls-bootstrapping.md)
--- a/practice/distributed-load-test.md
+++ b/practice/distributed-load-test.md
@ -67,7 +67,7 @@ $ kubectl scale --replicas=20 replicationcontrollers locust-worker

 ### 配置Traefik

-参考[kubernetes的traefik ingress安装](http://rootsongjc.github.io/blogs/traefik-ingress-installation/)，在`ingress.yaml`中加入如下配置：
+参考[kubernetes的traefik ingress安装](https://jimmysong.io/posts/traefik-ingress-installation/)，在`ingress.yaml`中加入如下配置：

 ```yaml
  - host: traefik.locust.io
--- a/practice/federation.md
+++ b/practice/federation.md
@ -19,7 +19,7 @@ Federation 对于单个集群没有用处。基于下面这些原因您可能会
 - 低延迟：通过在多个区域部署集群可以最大限度减少区域近端用户的延迟。
 - 故障隔离：拥有多个小集群可能比单个大集群更利于故障隔离（例如：在云服务提供商的不同可用区中的多个集群）。详情请参考 [多集群指南](https://kubernetes.io/docs/concepts/cluster-administration/federation)。
 - 可伸缩性：单个集群有可伸缩性限制（对于大多数用户这不是典型场景。更多细节请参考 [Kubernetes 弹性伸缩与性能目标](https://git.k8s.io/community/sig-scalability/goals.md)）。
- [混合云](https://kubernetes.io/docs/concepts/cluster-administration/federation.md#%E6%B7%B7%E5%90%88%E4%BA%91%E8%83%BD%E5%8A%9B)：您可以在不同的云服务提供商或本地数据中心中拥有多个集群。
+- [混合云](https://kubernetes.io/docs/concepts/cluster-administration/federation/)：您可以在不同的云服务提供商或本地数据中心中拥有多个集群。

 ### 警告

@ -31,9 +31,9 @@ Federation 对于单个集群没有用处。基于下面这些原因您可能会

 ### 混合云能力

-Kubernetes 集群 federation 可以包含运行在不同云服务提供商（例如 Google Cloud、AWS）及本地（例如在 OpenStack 上）的集群。您只需要按需在适合的云服务提供商和/或地点上简单的创建集群，然后向 Federation API Server 注册每个集群的 API endpoint 和凭据即可。（详细信息请参阅 [federation 管理指南](https://kubernetes.io/docs/admin/federation)）。
+Kubernetes 集群 federation 可以包含运行在不同云服务提供商（例如 Google Cloud、AWS）及本地（例如在 OpenStack 上）的集群。您只需要按需在适合的云服务提供商和/或地点上简单的创建集群，然后向 Federation API Server 注册每个集群的 API endpoint 和凭据即可。

-此后，您的 [API 资源](https://kubernetes.io/docs/concepts/cluster-administration/federation.md#API-%E8%B5%84%E6%BA%90) 就可以跨越不同的集群和云服务提供商。
+此后，您的 [API 资源](https://kubernetes.io/docs/concepts/cluster-administration/federation/) 就可以跨越不同的集群和云服务提供商。

 ## 设置 federation

@ -95,7 +95,7 @@ Kubernetes 集群数量的选择可能是一个相对静态的选择，只是偶

 如果在集群故障的情形下允许负载均衡将流量引导到任何区域，则至少需要有比 `R` 或 `U + 1` 数量更大的集群。如果不行的话（例如希望在集群发生故障时对所有用户确保低延迟），那么您需要有数量为 `R * (U + 1)` 的集群（`R` 个区域，每个中有 `U + 1` 个集群）。无论如何，请尝试将每个集群放在不同的区域中。

-最后，如果您的任何集群需要比 Kubernetes 集群最大建议节点数更多的节点，那么您可能需要更多的集群。 Kubernetes v1.3 支持最多 1000 个节点的集群。 Kubernetes v1.8 支持最多 5000 个节点的集群。更多的指导请参见 [构建大型集群](https://kubernetes.io/docs/admin/cluster-large)。
+最后，如果您的任何集群需要比 Kubernetes 集群最大建议节点数更多的节点，那么您可能需要更多的集群。 Kubernetes v1.3 支持最多 1000 个节点的集群。 Kubernetes v1.8 支持最多 5000 个节点的集群。

 ---

--- a/practice/heapster-addon-installation.md
+++ b/practice/heapster-addon-installation.md
@ -66,7 +66,7 @@ influxdb 官方建议使用命令行或 HTTP API 接口来查询数据库，从

 开启镜像中 admin UI的办法如下：先导出镜像中的 influxdb 配置文件，开启 admin 插件后，再将配置文件内容写入 ConfigMap，最后挂载到镜像中，达到覆盖原始配置的目的：

-注意：manifests 目录已经提供了 [修改后的 ConfigMap 定义文件](https://github.com/opsnull/follow-me-install-kubernetes-cluster/blob/master/manifests/heapster/influxdb-cm.yaml)
+注意：manifests 目录已经提供了修改后的 ConfigMap 定义文件。

 ``` bash
 $ # 导出镜像中的 influxdb 配置文件
--- a/practice/heapster.md
+++ b/practice/heapster.md
@ -1,6 +1,6 @@
 # Heapster

-Heapster作为kubernetes安装过程中默认安装的一个插件，见[安装heapster插件](practice/heapster-addon-installation.md)。这对于集群监控十分有用，同时在[Horizontal Pod Autoscaling](../concepts/horizontal-pod-autoscaling.md)中也用到了，HPA将Heapster作为`Resource Metrics API`，向其获取metric，做法是在`kube-controller-manager` 中配置`--api-server`指向[kube-aggregator](https://github.com/kubernetes/kube-aggregator)，也可以使用heapster来实现，通过在启动heapster的时候指定`--api-server=true`。
+Heapster作为kubernetes安装过程中默认安装的一个插件，见[安装heapster插件](heapster-addon-installation.md)。这对于集群监控十分有用，同时在[Horizontal Pod Autoscaling](../concepts/horizontal-pod-autoscaling.md)中也用到了，HPA将Heapster作为`Resource Metrics API`，向其获取metric，做法是在`kube-controller-manager` 中配置`--api-server`指向[kube-aggregator](https://github.com/kubernetes/kube-aggregator)，也可以使用heapster来实现，通过在启动heapster的时候指定`--api-server=true`。

 Heapster可以收集Node节点上的cAdvisor数据，还可以按照kubernetes的资源类型来集合资源，比如Pod、Namespace域，可以分别获取它们的CPU、内存、网络和磁盘的metric。默认的metric数据聚合时间间隔是1分钟。

--- a/practice/helm.md
+++ b/practice/helm.md
@ -43,8 +43,8 @@ kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admi
 ```bash
 helm init -i jimmysong/kubernetes-helm-tiller:v2.8.1 
 ```
-(目前最新版v2.8.2，可以使用阿里云镜像，如：
-helm init --upgrade -i registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.8.2 --stable-repo-url https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts）
+（目前最新版v2.8.2，可以使用阿里云镜像，如：
+`helm init --upgrade -i registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.8.2 --stable-repo-url https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts`）

 我们使用`-i`指定自己的镜像，因为官方的镜像因为某些原因无法拉取，官方镜像地址是：`gcr.io/kubernetes-helm/tiller:v2.8.1`，我在DockerHub上放了一个备份`jimmysong/kubernetes-helm-tiller:v2.8.1`，该镜像的版本与helm客户端的版本相同，使用`helm version`可查看helm客户端版本。

@ -332,19 +332,19 @@ dependencies:

 ### 安装源

-#####################################################################
-
 使用第三方chat库

-。添加fabric8库
+- 添加fabric8库

-    $helm repo add fabric8 https://fabric8.io/helm
+```bash
+$ helm repo add fabric8 https://fabric8.io/helm
+```

-。搜索fabric8提供的工具（主要就是fabric8-platform工具包，包含了CI,CD的全套工具）
+- 搜索fabric8提供的工具（主要就是fabric8-platform工具包，包含了CI、CD的全套工具）

-    $helm search fabric8
-
-#####################################################################
+```bash
+$ helm search fabric8
+```

 我们在前面安装chart可以通过HTTP server的方式提供。

@ -710,6 +710,5 @@ helm package .
 - [Deploy, Scale And Upgrade An Application On Kubernetes With Helm](https://docs.bitnami.com/kubernetes/how-to/deploy-application-kubernetes-helm/)
 - [Helm charts](https://github.com/kubernetes/helm/blob/master/docs/charts.md)
 - [Go template](https://golang.org/pkg/text/template/)
- [Helm docs](https://github.com/kubernetes/helm/blob/master/docs/index.md)
 - [How To Create Your First Helm Chart](https://docs.bitnami.com/kubernetes/how-to/create-your-first-helm-chart/)
 - [Speed deployment on Kubernetes with Helm Chart – Quick yaml example from scratch](https://www.ibm.com/blogs/bluemix/2017/10/quick-example-helm-chart-for-kubernetes/)
--- a/practice/install-kubernetes-with-kubeadm.md
+++ b/practice/install-kubernetes-with-kubeadm.md
@ -1,6 +1,6 @@
 # kubeadm
 ## 基本介绍
-**kubeadm** 是一个工具包，可帮助您以简单，合理安全和可扩展的方式引导最佳实践Kubernetes群集。它还支持为您管理[Bootstrap Tokens](/docs/admin/bootstrap-tokens/)并升级/降级群集。
+**kubeadm** 是一个工具包，可帮助您以简单，合理安全和可扩展的方式引导最佳实践Kubernetes群集。它还支持为您管理[Bootstrap Tokens](https://kubernetes.io/docs/reference/access-authn-authz/bootstrap-tokens/)并升级/降级群集。

 kubeadm的目标是建立一个通过Kubernetes一致性测试[Kubernetes Conformance tests](http://blog.kubernetes.io/2017/10/software-conformance-certification)的最小可行集群 ，但不会安装其他功能插件。

--- a/practice/manage-compute-resources-container.md
+++ b/practice/manage-compute-resources-container.md
@ -1,12 +1,12 @@
 # 管理容器的计算资源

-当您定义 [Pod](http://kubernetes.io/docks/user-guide/pods) 的时候可以选择为每个容器指定需要的 CPU 和内存（RAM）大小。当为容器指定了资源请求后，调度器就能够更好的判断出将容器调度到哪个节点上。如果您还为容器指定了资源限制，节点上的资源就可以按照指定的方式做竞争。关于资源请求和限制的不同点和更多资料请参考 [Resource QoS](https://git.k8s.io/community/contributors/design-proposals/resource-qos.md)。
+当您定义 [Pod](http://kubernetes.io/docs/user-guide/pods) 的时候可以选择为每个容器指定需要的 CPU 和内存（RAM）大小。当为容器指定了资源请求后，调度器就能够更好的判断出将容器调度到哪个节点上。如果您还为容器指定了资源限制，节点上的资源就可以按照指定的方式做竞争。

 ## 资源类型

 *CPU* 和 *memory* 都是 *资源类型*。资源类型具有基本单位。CPU 的单位是 core，memory 的单位是 byte。

-CPU和内存统称为*计算资源*，也可以称为*资源*。计算资源的数量是可以被请求、分配和消耗的可测量的。它们与 [API 资源](https://kubernetes.io/docks/api/) 不同。 API 资源（如 Pod 和 [Service](https://kubernetes.io/docks/user-guide/services)）是可通过 Kubernetes API server 读取和修改的对象。
+CPU和内存统称为*计算资源*，也可以称为*资源*。计算资源的数量是可以被请求、分配和消耗的可测量的。它们与 [API 资源](https://kubernetes.io/docs/api/) 不同。 API 资源（如 Pod 和 [Service](https://kubernetes.io/docs/user-guide/services)）是可通过 Kubernetes API server 读取和修改的对象。

 ## Pod 和 容器的资源请求和限制

@ -93,13 +93,13 @@ spec:

 容器可能被允许也可能不被允许超过其 CPU 限制时间。但是，由于 CPU 使用率过高，不会被杀死。

-要确定容器是否由于资源限制而无法安排或被杀死，请参阅 [疑难解答](#troubleshooting) 部分。
+要确定容器是否由于资源限制而无法安排或被杀死，请参阅疑难解答]部分。

 ## 监控计算资源使用

 Pod 的资源使用情况被报告为 Pod 状态的一部分。

-如果为集群配置了 [可选监控](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/cluster-monitoring/README.md)，则可以从监控系统检索 Pod 资源的使用情况。
+如果为集群配置了可选监控，则可以从监控系统检索 Pod 资源的使用情况。

 ## 疑难解答

@ -261,7 +261,7 @@ spec:

 在 kubernetes 1.5 版本中仅允许在容器上指定资源量。计划改进对所有容器在 Pod 中共享资源的计量，如 [emptyDir volume](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir)。

-在 kubernetes 1.5 版本中仅支持容器对 CPU 和内存的申请和限制。计划增加新的资源类型，包括节点磁盘空间资源和一个可支持自定义 [资源类型](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/resources.md) 的框架。
+在 kubernetes 1.5 版本中仅支持容器对 CPU 和内存的申请和限制。计划增加新的资源类型，包括节点磁盘空间资源和一个可支持自定义资源类型的框架。

 Kubernetes 通过支持通过多级别的 [服务质量](http://issue.k8s.io/168) 来支持资源的过度使用。

--- a/practice/manually-upgrade.md
+++ b/practice/manually-upgrade.md
@ -10,7 +10,6 @@
 目前kubernetes的官方文档上并没有详细的手动安装的集群如何升级的参考资料，只有两篇关于kubernetes集群升级的文档。

 - 在ubuntu上如何使用juju升级：https://kubernetes.io/docs/getting-started-guides/ubuntu/upgrades/
- 使用kubeadm升级：https://kubernetes.io/docs/tasks/administer-cluster/kubeadm-upgrade-1-7/

 手动升级的还没有详细的方案，大多是基于管理工具部署和升级，比如juju、kubeadm、kops、kubespray等。

@ -123,7 +122,6 @@ NAME           STATUS    ROLES     AGE       VERSION
 - [Cluster Upgrade #2524](https://github.com/kubernetes/kubernetes/issues/2524)
 - [Upgrading self-hosted Kubernetes](https://coreos.com/matchbox/docs/latest/bootkube-upgrades.html)
 - [Upgrading Kubernetes - kops](https://github.com/kubernetes/kops/blob/master/docs/upgrade.md)
- [Upgrading kubeadm clusters from 1.6 to 1.7](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm-upgrade-1-7/)
 - [How to Upgrade a Kubernetes Cluster With No Downtime](https://medium.com/retailmenot-engineering/zero-downtime-kubernetes-cluster-upgrades-aab4cac943d2)
 - [manual upgrade/downgrade testing for Kubernetes 1.6 - google group](https://groups.google.com/forum/#!topic/kubernetes-dev/jDbGKAsfo4Q)
 - [Notes/Instructions for Manual Upgrade Testing1.5 -> 1.6](https://docs.google.com/document/d/1DtQFhxmKSZJJ_yv8ttweqotburHHZWxaCYnFbjLDA5g/edit)
--- a/practice/network-and-cluster-perfermance-test.md
+++ b/practice/network-and-cluster-perfermance-test.md
@ -394,10 +394,8 @@ Locust模拟10万用户，每秒增长100个。

 - [基于 Python 的性能测试工具 locust (与 LR 的简单对比)](https://testerhome.com/topics/4839)
 - [Locust docs](http://docs.locust.io/en/latest/what-is-locust.html)
- [python用户负载测试工具：locust](http://timd.cn/2015/09/17/locust/)
 - [Kubernetes集群性能测试](https://supereagle.github.io/2017/03/09/kubemark/)
 - [CoreOS是如何将Kubernetes的性能提高10倍的](http://dockone.io/article/1050)
- [Kubernetes 1.3 的性能和弹性 —— 2000 节点，60,0000 Pod 的集群](http://blog.fleeto.us/translation/updates-performance-and-scalability-kubernetes-13-2000-node-60000-pod-clusters)
 - [运用Kubernetes进行分布式负载测试](http://www.csdn.net/article/2015-07-07/2825155)
 - [Kubemark User Guide](https://github.com/kubernetes/community/blob/master/contributors/devel/kubemark-guide.md)
 - [Flannel host-gw architecture](https://docs.openshift.com/container-platform/3.4/architecture/additional_concepts/flannel.html)
--- a/practice/service-rolling-update.md
+++ b/practice/service-rolling-update.md
@ -177,7 +177,7 @@ kubectl create -f rolling-update-test.yaml

 注意：172.20.0.119是我们之前使用keepalived创建的VIP。

-打开浏览器访问http://rolling-update-test.traefik.io将会看到以下输出：
+打开浏览器访问 `http://rolling-update-test.traefik.io` 将会看到以下输出：

 ```
 This is version 1.
@ -205,7 +205,7 @@ kubectl set image deployment/rolling-update-test rolling-update-test=harbor-001.
 kubectl rollout status deployment/rolling-update-test
 ```

-升级完成后在浏览器中刷新http://rolling-update-test.traefik.io将会看到以下输出：
+升级完成后在浏览器中刷新`http://rolling-update-test.traefik.io`将会看到以下输出：

 ```
 This is version 2.
@ -236,5 +236,4 @@ replicationcontroller "zeppelin-controller" rolling updated

 - [Rolling update机制解析](http://dockone.io/article/328)
 - [Running a Stateless Application Using a Deployment](https://kubernetes.io/docs/tasks/run-application/run-stateless-application-deployment/)
- [Simple Rolling Update](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/simple-rolling-update.md)
 - [使用kubernetes的deployment进行RollingUpdate](https://segmentfault.com/a/1190000008232770)
--- a/practice/traefik-ingress-installation.md
+++ b/practice/traefik-ingress-installation.md
@ -2,7 +2,7 @@

 ## Ingress简介

-如果你还不了解，ingress是什么，可以先看下我翻译的Kubernetes官网上ingress的介绍[Kubernetes Ingress解析](http://rootsongjc.github.io/blogs/kubernetes-ingress-resource/)。
+如果你还不了解，ingress是什么，可以先看下我翻译的Kubernetes官网上ingress的介绍[Kubernetes Ingress解析](https://jimmysong.io/posts/kubernetes-ingress-resource/)。

 **理解Ingress**

@ -244,6 +244,4 @@ Traefik会解析http请求header里的Host参数将流量转发给Ingress配置

 ## 参考

- [Traefik-kubernetes 初试](http://www.colabug.com/thread-1703745-1-1.html)
 - [Traefik简介](http://www.tuicool.com/articles/ZnuEfay)
- [Guestbook example](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook)
--- a/practice/using-ceph-for-persistent-storage.md
+++ b/practice/using-ceph-for-persistent-storage.md
@ -401,12 +401,10 @@ func (util *RBDUtil) CreateImage(p *rbdVolumeProvisioner) (r *v1.RBDVolumeSource

 ## 参考

-https://github.com/kubernetes/examples/blob/master/staging/volumes/cephfs/README.md
+- https://github.com/kubernetes/examples/blob/master/staging/volumes/cephfs/README.md

-[k8s-ceph-statefulsets-storageclass-nfs 动态卷有状态应用实践](http://blog.csdn.net/idea77/article/details/72842723)
+- [k8s-ceph-statefulsets-storageclass-nfs 动态卷有状态应用实践](http://blog.csdn.net/idea77/article/details/72842723)

-[Kubernetes persistent storage with Ceph](https://crondev.com/kubernetes-persistent-storage-ceph/)
+- https://kubernetes.io/docs/concepts/storage/persistent-volumes/#ceph-rbd

-https://kubernetes.io/docs/concepts/storage/persistent-volumes/#ceph-rbd
-
-[Error creating rbd image: executable file not found in $PATH#38923](https://github.com/kubernetes/kubernetes/issues/38923)
+- [Error creating rbd image: executable file not found in $PATH#38923](https://github.com/kubernetes/kubernetes/issues/38923)
--- a/practice/using-glusterfs-for-persistent-storage.md
+++ b/practice/using-glusterfs-for-persistent-storage.md
@ -2,7 +2,7 @@

 我们复用kubernetes的三台主机做glusterfs存储。

-以下步骤参考自：https://www.xf80.com/2017/04/21/kubernetes-glusterfs/（该网站已无法访问）
+以下步骤参考自：`https://www.xf80.com/2017/04/21/kubernetes-glusterfs/`（该网站已无法访问）

 ## 安装glusterfs

@ -135,8 +135,6 @@ $ gluster volume set k8s-volume performance.write-behind-window-size 1024MB

 ## Kubernetes中配置glusterfs

-官方的文档见：https://github.com/kubernetes/kubernetes/tree/master/examples/volumes/glusterfs
-
 以下用到的所有yaml和json配置文件可以在[../manifests/glusterfs](https://github.com/rootsongjc/kubernetes-handbook/blob/master/manifests/glusterfs)中找到。注意替换其中私有镜像地址为你自己的镜像地址。


@ -351,5 +349,3 @@ index.html
 ## 参考

 - [CentOS 7 安装 GlusterFS](http://www.cnblogs.com/jicki/p/5801712.html)
- [GlusterFS with kubernetes](https://github.com/kubernetes/kubernetes/tree/master/examples/volumes/glusterfs)
-
--- a/practice/using-heapster-to-get-object-metrics.md
+++ b/practice/using-heapster-to-get-object-metrics.md
@ -20,52 +20,52 @@ Heapster使用起来很简单，本身就是二进制文件，直接使用命令

 下面是heapster的启动参数：

-| **Flag**                                 | **Description**                          |
-| ---------------------------------------- | ---------------------------------------- |
-| --allowed-users string                   | comma-separated list of allowed users    |
-| --alsologtostderr                        | log to standard error as well as files   |
-| --api-server                             | Enable API server for the Metrics API. If set, the Metrics API will be served on --insecure-port (internally) and --secure-port (externally). |
-| --authentication-kubeconfig string       | kubeconfig file pointing at the 'core' kubernetes server with enough rights to create [tokenaccessreviews.authentication.k8s.io](http://tokenaccessreviews.authentication.k8s.io). |
-| --authentication-token-webhook-cache-ttl duration | The duration to cache responses from the webhook token authenticator. (default 10s) |
-| --authorization-kubeconfig string        | kubeconfig file pointing at the 'core' kubernetes server with enough rights to create  [subjectaccessreviews.authorization.k8s.io](http://subjectaccessreviews.authorization.k8s.io). |
-| --authorization-webhook-cache-authorized-ttl duration | The duration to cache 'authorized' responses from the webhook authorizer. (default 10s) |
+| **Flag**                                                | **Description**                                              |
+| ------------------------------------------------------- | ------------------------------------------------------------ |
+| --allowed-users string                                  | comma-separated list of allowed users                        |
+| --alsologtostderr                                       | log to standard error as well as files                       |
+| --api-server                                            | Enable API server for the Metrics API. If set, the Metrics API will be served on --insecure-port (internally) and --secure-port (externally). |
+| --authentication-kubeconfig string                      | kubeconfig file pointing at the 'core' kubernetes server with enough rights to create tokenaccessreviews.authentication.k8s.io. |
+| --authentication-token-webhook-cache-ttl duration       | The duration to cache responses from the webhook token authenticator. (default 10s) |
+| --authorization-kubeconfig string                       | kubeconfig file pointing at the ‘core' kubernetes server with enough rights to create  subjectaccessreviews.authorization.k8s.io |
+| --authorization-webhook-cache-authorized-ttl duration   | The duration to cache 'authorized' responses from the webhook authorizer. (default 10s) |
 | --authorization-webhook-cache-unauthorized-ttl duration | The duration to cache 'unauthorized' responses from the webhook authorizer. (default 10s) |
-| --bind-address ip                        | The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank, all interfaces will be used (0.0.0.0). (default 0.0.0.0) |
-| --cert-dir string                        | The directory where the TLS certs are located (by default /var/run/kubernetes). If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. (default "/var/run/kubernetes") |
-| --client-ca-file string                  | If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate. |
-| --contention-profiling                   | Enable contention profiling. Requires --profiling to be set to work. |
-| --disable-export                         | Disable exporting metrics in api/v1/metric-export |
-| --enable-swagger-ui                      | Enables swagger ui on the apiserver at /swagger-ui |
-| --heapster-port int                      | port used by the Heapster-specific APIs (default 8082) |
-| --historical-source string               | which source type to use for the historical API (should be exactly the same as one of the sink URIs), or empty to disable the historical API |
-| --label-seperator string                 | seperator used for joining labels (default ",") |
-| --listen-ip string                       | IP to listen on, defaults to all IPs     |
-| --log-backtrace-at traceLocation         | when logging hits line file:N, emit a stack trace (default :0) |
-| --log-dir string                         | If non-empty, write log files in this directory |
-| --log-flush-frequency duration           | Maximum number of seconds between log flushes (default 5s) |
-| --logtostderr                            | log to standard error instead of files (default true) |
-| --max-procs int                          | max number of CPUs that can be used simultaneously. Less than 1 for default (number of cores) |
-| --metric-resolution duration             | The resolution at which heapster will retain metrics. (default 1m0s) |
-| --profiling                              | Enable profiling via web interface host:port/debug/pprof/ (default true) |
-| --requestheader-allowed-names stringSlice | List of client certificate common names to allow to provide usernames in headers specified by --requestheader-username-headers. If empty, any client certificate validated by the authorities in --requestheader-client-ca-file is allowed. |
-| --requestheader-client-ca-file string    | Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers |
-| --requestheader-extra-headers-prefix stringSlice | List of request header prefixes to inspect. X-Remote-Extra- is suggested. (default [x-remote-extra-]) |
-| --requestheader-group-headers stringSlice | List of request headers to inspect for groups. X-Remote-Group is suggested. (default [x-remote-group]) |
-| --requestheader-username-headers stringSlice | List of request headers to inspect for usernames. X-Remote-User is common. (default [x-remote-user]) |
-| --secure-port int                        | The port on which to serve HTTPS with authentication and authorization. If 0, don't serve HTTPS at all. (default 6443) |
-| --sink *flags.Uris                       | external sink(s) that receive data (default []) |
-| --source *flags.Uris                     | source(s) to watch (default [])          |
-| --stderrthreshold severity               | logs at or above this threshold go to stderr (default 2) |
-| --tls-ca-file string                     | If set, this certificate authority will used for secure access from Admission Controllers. This must be a valid PEM-encoded CA bundle. Altneratively, the certificate authority can be appended to the certificate provided by --tls-cert-file. |
-| --tls-cert string                        | file containing TLS certificate          |
-| --tls-cert-file string                   | File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to /var/run/kubernetes. |
-| --tls-client-ca string                   | file containing TLS client CA for client cert validation |
-| --tls-key string                         | file containing TLS key                  |
-| --tls-private-key-file string            | File containing the default x509 private key matching --tls-cert-file. |
-| --tls-sni-cert-key namedCertKey          | A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.key,example.crt" or "*.foo.com,foo.com:foo.key,foo.crt". (default []) |
-| --v Level                                | log level for V logs                     |
-| --version                                | print version info and exit              |
-| --vmodule moduleSpec                     | comma-separated list of pattern=N settings for file-filtered logging |
+| --bind-address ip                                       | The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank, all interfaces will be used (0.0.0.0). (default 0.0.0.0) |
+| --cert-dir string                                       | The directory where the TLS certs are located (by default /var/run/kubernetes). If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. (default "/var/run/kubernetes") |
+| --client-ca-file string                                 | If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate. |
+| --contention-profiling                                  | Enable contention profiling. Requires --profiling to be set to work. |
+| --disable-export                                        | Disable exporting metrics in api/v1/metric-export            |
+| --enable-swagger-ui                                     | Enables swagger ui on the apiserver at /swagger-ui           |
+| --heapster-port int                                     | port used by the Heapster-specific APIs (default 8082)       |
+| --historical-source string                              | which source type to use for the historical API (should be exactly the same as one of the sink URIs), or empty to disable the historical API |
+| --label-seperator string                                | seperator used for joining labels (default ",")              |
+| --listen-ip string                                      | IP to listen on, defaults to all IPs                         |
+| --log-backtrace-at traceLocation                        | when logging hits line file:N, emit a stack trace (default :0) |
+| --log-dir string                                        | If non-empty, write log files in this directory              |
+| --log-flush-frequency duration                          | Maximum number of seconds between log flushes (default 5s)   |
+| --logtostderr                                           | log to standard error instead of files (default true)        |
+| --max-procs int                                         | max number of CPUs that can be used simultaneously. Less than 1 for default (number of cores) |
+| --metric-resolution duration                            | The resolution at which heapster will retain metrics. (default 1m0s) |
+| --profiling                                             | Enable profiling via web interface host:port/debug/pprof/ (default true) |
+| --requestheader-allowed-names stringSlice               | List of client certificate common names to allow to provide usernames in headers specified by --requestheader-username-headers. If empty, any client certificate validated by the authorities in --requestheader-client-ca-file is allowed. |
+| --requestheader-client-ca-file string                   | Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers |
+| --requestheader-extra-headers-prefix stringSlice        | List of request header prefixes to inspect. X-Remote-Extra- is suggested. (default [x-remote-extra-]) |
+| --requestheader-group-headers stringSlice               | List of request headers to inspect for groups. X-Remote-Group is suggested. (default [x-remote-group]) |
+| --requestheader-username-headers stringSlice            | List of request headers to inspect for usernames. X-Remote-User is common. (default [x-remote-user]) |
+| --secure-port int                                       | The port on which to serve HTTPS with authentication and authorization. If 0, don't serve HTTPS at all. (default 6443) |
+| --sink *flags.Uris                                      | external sink(s) that receive data (default [])              |
+| --source *flags.Uris                                    | source(s) to watch (default [])                              |
+| --stderrthreshold severity                              | logs at or above this threshold go to stderr (default 2)     |
+| --tls-ca-file string                                    | If set, this certificate authority will used for secure access from Admission Controllers. This must be a valid PEM-encoded CA bundle. Altneratively, the certificate authority can be appended to the certificate provided by --tls-cert-file. |
+| --tls-cert string                                       | file containing TLS certificate                              |
+| --tls-cert-file string                                  | File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to /var/run/kubernetes. |
+| --tls-client-ca string                                  | file containing TLS client CA for client cert validation     |
+| --tls-key string                                        | file containing TLS key                                      |
+| --tls-private-key-file string                           | File containing the default x509 private key matching --tls-cert-file. |
+| --tls-sni-cert-key namedCertKey                         | A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.key,example.crt" or "*.foo.com,foo.com:foo.key,foo.crt". (default []) |
+| --v Level                                               | log level for V logs                                         |
+| --version                                               | print version info and exit                                  |
+| --vmodule moduleSpec                                    | comma-separated list of pattern=N settings for file-filtered logging |

 **Version**

--- a/practice/using-openebs-for-persistent-storage.md
+++ b/practice/using-openebs-for-persistent-storage.md
@ -19,7 +19,7 @@ iSCSI中包括两种类型的角色：
 - **target**：用来提供存储（server）
 - **initiator**：使用存储的客户端（client）

-下图在Kubernetes中使用iSCSI的架构图（图片来源：http://rootfs.github.io/iSCSI-Kubernetes/）。
+下图在Kubernetes中使用iSCSI的架构图（图片来源：`http://rootfs.github.io/iSCSI-Kubernetes/`）。

 ![Kubernetes iSCSI架构](../images/iscsi-on-kubernetes.png)

@ -58,7 +58,7 @@ kubectl apply -f openebs-storageclasses.yaml

 ## 测试

-下面使用OpenEBS官方文档中的[示例]()，安装Jenkins测试
+下面使用OpenEBS官方文档中的示例，安装Jenkins测试

 ```bash
 wget https://raw.githubusercontent.com/openebs/openebs/master/k8s/demo/jenkins/jenkins.yml
@ -113,11 +113,8 @@ OpenEBS的存储策略使用StorageClaass实现，包括如下的StorageClass：
 - openebs-standard
 - openebs-zk

-每个[Storage Class](../concepts/storageclass.md)都对应与某种应用的存储模式，使用方式请参考[OpenEBS Storage Policies](http://openebs.readthedocs.io/en/latest/Policies/storage_policy.html)。
-
 ## 参考

- [OpenEBS Documentation](http://openebs.readthedocs.io/)
 - [CentOS 7.x 下配置iSCSI网络存储](http://blog.csdn.net/wh211212/article/details/52981305)
 - [Configure iSCSI Initiator](https://www.server-world.info/en/note?os=CentOS_7&p=iscsi&f=2)
 - [RHEL7: Configure a system as either an iSCSI target or initiator that persistently mounts an iSCSI target.](https://www.certdepot.net/rhel7-configure-iscsi-target-initiator-persistently/)
--- a/practice/vistio-visualize-your-istio-mesh.md
+++ b/practice/vistio-visualize-your-istio-mesh.md
@ -21,7 +21,7 @@ Vizceral有两个可视化级别，全局可视化和集群级别可视化。在

 以下Demo使得这些假设更容易部署。如果您的环境设置不同，则可能需要将代码下载到本地并编辑一些文件。

- Prometheus部署在`istio-system` namespace下，可以通过[http://prometheus.istio-system:9090](http://prometheus.istio-system:9090/)地址访问
+- Prometheus部署在`istio-system` namespace下，可以通过`http://prometheus.istio-system:9090`地址访问
 - Istio mixer启用了`istio_request_count` metric
 - Kubernetes集群包含有`standard` StorageClass
 - 为了便于部署已安装了Helm（可选）
--- a/usecases/ai.md
+++ b/usecases/ai.md
@ -4,4 +4,4 @@ Kubernetes 在人工智能领域的应用。

 ## TBD

- [kubeflow](Machine Learning Toolkit for Kubernetes) - Kubernetes 机器学习工具箱
+- [kubeflow](https://github.com/kubeflow/kubeflow) - Kubernetes 机器学习工具箱
--- a/usecases/big-data.md
+++ b/usecases/big-data.md
@ -28,7 +28,7 @@ Spark原生支持standalone、mesos和YARN的调度方式，当前kubernetes社

 ### Spark on Kubernetes

-Spark on kubernetes，使用kubernetes作为调度引擎，spark的任务直接调度到node节点上。参考：[运行支持kubernetes原生调度的Spark程序](usecases/running-spark-with-kubernetes-native-scheduler.md)
+Spark on kubernetes，使用kubernetes作为调度引擎，spark的任务直接调度到node节点上。参考：[运行支持kubernetes原生调度的Spark程序](running-spark-with-kubernetes-native-scheduler.md)。

 ### 调度方式总结

--- a/usecases/conduit-installation.md
+++ b/usecases/conduit-installation.md
@ -32,8 +32,6 @@ conduit install>conduit-0.1.0.yaml
 kubectl apply -f conduit-0.1.0.yaml
 ```

-修改后的yaml文件见：[conduit-0.1.0.yaml](https://github.com/rootsongjc/kubernetes-handbook/tree/master/manifests/conduit-0.1.0.yaml)。
-
 **注意：**Conduit官方给出的yaml文件中不包括RBAC授权，我重新修改了，增加了RBAC和ServiceAccount。

 使用`kubectl proxy`来开放外网访问conduit dashboard：
--- a/usecases/configuring-request-routing.md
+++ b/usecases/configuring-request-routing.md
@ -69,7 +69,7 @@

 由于对代理的规则传播是异步的，因此在尝试访问应用程序之前，需要等待几秒钟才能将规则传播到所有pod。

-2. 在浏览器中打开BookInfo URL（http://$GATEWAY_URL/productpage ，我们在上一节中使用的是 http://ingress.istio.io/productpage ）您应该会看到BookInfo应用程序的产品页面显示。 注意，产品页面上没有评分星，因为`reviews:v1`不访问评级服务。
+2. 在浏览器中打开BookInfo URL（`http://$GATEWAY_URL/productpage` ，我们在上一节中使用的是 `http://ingress.istio.io/productpage`）您应该会看到BookInfo应用程序的产品页面显示。 注意，产品页面上没有评分星，因为`reviews:v1`不访问评级服务。

 3. 将特定用户路由到`reviews:v2`。

--- a/usecases/faas.md
+++ b/usecases/faas.md
@ -14,6 +14,6 @@ FaaS（Functions as a Service）函数即服务，FaaS是无服务器计算的
 - [kubeless](https://github.com/kubeless/kubeless) - Kubernetes Native Serverless Framework [http://kubeless.io](http://kubeless.io/)
 - [nuclio](https://github.com/nuclio/nuclio) - High-Performance Serverless event and data processing platform
 - [OpenFaaS](https://github.com/openfaas/faas) - OpenFaaS - Serverless Functions Made Simple for Docker & Kubernetes [https://blog.alexellis.io/introducing-functions-as-a-service/](https://blog.alexellis.io/introducing-functions-as-a-service/) 
- [OpenWhisk](http://openwhisk.incubator.apache.org/) - Apache OpenWhisk (Incubating) is a [serverless](http://openwhisk.incubator.apache.org/serverless), open source cloud platform that executes functions in response to events at any scale.
+- [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.

 关于整个Cloud Native开源生态，请参考[awesome-cloud-native](https://jimmysong.io/awesome-cloud-native)。
--- a/usecases/install-and-expand-istio-mesh.md
+++ b/usecases/install-and-expand-istio-mesh.md
@ -1,10 +1,12 @@
 # 安装和拓展 Istio mesh

+**注意：本文档已失效，请浏览 [Istio 官方文档](https://istio.io/zh)**。
+
 ## 前置条件

-下面的操作说明需要您可以访问 kubernetes **1.7.3 后更高版本** 的集群，并且启用了 [RBAC (基于角色的访问控制)](https://kubernetes.io/docs/admin/authorization/rbac/)。您需要安装了 **1.7.3 或更高版本** 的 `kubectl` 命令。如果您希望启用 [自动注入 sidecar](http://istio.doczh.cn/docs/setup/kubernetes/sidecar-injection.html#自动注入-sidecar)，您需要启用 kubernetes 集群的 alpha 功能。
+下面的操作说明需要您可以访问 kubernetes **1.7.3 后更高版本** 的集群，并且启用了 [RBAC (基于角色的访问控制)](https://kubernetes.io/docs/admin/authorization/rbac/)。您需要安装了 **1.7.3 或更高版本** 的 `kubectl` 命令。如果您希望启用自动注入 sidecar，您需要启用 kubernetes 集群的 alpha 功能。

-> 注意：如果您安装了 Istio 0.1.x，在安装新版本前请先 [卸载](http://istio.doczh.cn/docs/setup/kubernetes/quick-start.html#卸载) 它们（包括已启用 Istio 应用程序 Pod 中的 sidecar）。
+> 注意：如果您安装了 Istio 0.1.x，在安装新版本前请先卸载它们（包括已启用 Istio 应用程序 Pod 中的 sidecar）。

 - 取决于您的 kubernetes 提供商：

@ -87,7 +89,7 @@

 5. 安装 Istio 的核心部分。选择面两个 **互斥** 选项中的之一：

-   a) 安装 Istio 的时候不启用 sidecar 之间的 [TLS 双向认证](http://istio.doczh.cn/docs/concepts/security/mutual-tls.html)：
+   a) 安装 Istio 的时候不启用 sidecar 之间的 TLS 双向认证：

   为具有现在应用程序的集群选择该选项，使用 Istio sidecar 的服务需要能够与非 Istio Kubernetes 服务以及使用 [liveliness 和 readiness 探针](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)、headless service 和 StatefulSet 的应用程序通信。

@ -97,7 +99,7 @@

   **或者**

-   b) 安装 Istio 的时候启用 sidecar 之间的 [TLS 双向认证](http://istio.doczh.cn/docs/concepts/security/mutual-tls.html)：
+   b) 安装 Istio 的时候启用 sidecar 之间的 TLS 双向认证：

   ```bash
   kubectl apply -f install/kubernetes/istio-auth.yaml
@ -105,7 +107,7 @@

   这两个选项都会创建 `istio-system` 命名空间以及所需的 RBAC 权限，并部署 Istio-Pilot、Istio-Mixer、Istio-Ingress、Istio-Egress 和 Istio-CA（证书颁发机构）。

-6. *可选的*：如果您的 kubernetes 集群开启了 alpha 功能，并想要启用 [自动注入 sidecar](http://istio.doczh.cn/docs/setup/kubernetes/sidecar-injection.html#automatic-sidecar-injection)，需要安装 Istio-Initializer：
+6. *可选的*：如果您的 kubernetes 集群开启了 alpha 功能，并想要启用自动注入 sidecar，需要安装 Istio-Initializer：

   ```bash
   kubectl apply -f install/kubernetes/istio-initializer.yaml
@ -146,15 +148,15 @@

 ## 部署应用

-您可以部署自己的应用或者示例应用程序如 [BookInfo](http://istio.doczh.cn/docs/guides/bookinfo.html)。 注意：应用程序必须使用 HTTP/1.1 或 HTTP/2.0 协议来传输 HTTP 流量，因为 HTTP/1.0 已经不再支持。
+您可以部署自己的应用或者示例应用程序如 BookInfo。 注意：应用程序必须使用 HTTP/1.1 或 HTTP/2.0 协议来传输 HTTP 流量，因为 HTTP/1.0 已经不再支持。

-如果您启动了 [Istio-Initializer](http://istio.doczh.cn/docs/setup/kubernetes/sidecar-injection.html)，如上所示，您可以使用 `kubectl create` 直接部署应用。Istio-Initializer 会向应用程序的 pod 中自动注入 Envoy 容器：
+如果您启动了 Istio-Initializer，如上所示，您可以使用 `kubectl create` 直接部署应用。Istio-Initializer 会向应用程序的 pod 中自动注入 Envoy 容器：

 ```bash
 kubectl create -f <your-app-spec>.yaml
 ```

-如果您没有安装 Istio-initializer 的话，您必须使用 [istioctl kube-inject](http://istio.doczh.cn/docs/reference/commands/istioctl.html#istioctl-kube-inject) 命令在部署应用之前向应用程序的 pod 中手动注入 Envoy 容器：
+如果您没有安装 Istio-initializer 的话，您必须使用 istioctl kube-inject 命令在部署应用之前向应用程序的 pod 中手动注入 Envoy 容器：

 ```bash
 kubectl create -f <(istioctl kube-inject -f <your-app-spec>.yaml)
@ -201,7 +203,7 @@ kubectl create -f <(istioctl kube-inject -f <your-app-spec>.yaml)

 ## 手动注入 sidecar

-`istioctl` 命令行中有一个称为 [kube-inject](http://istio.doczh.cn/docs/reference/commands/istioctl.html#istioctl-kube-inject) 的便利工具，使用它可以将 Istio 的 sidecar 规范添加到 kubernetes 工作负载的规范配置中。与 Initializer 程序不同，`kube-inject` 只是将 YAML 规范转换成包含 Istio sidecar 的规范。您需要使用标准的工具如 `kubectl` 来部署修改后的 YAML。例如，以下命令将 sidecar 添加到 sleep.yaml 文件中指定的 pod 中，并将修改后的规范提交给 kubernetes：
+`istioctl` 命令行中有一个称为 kube-inject 的便利工具，使用它可以将 Istio 的 sidecar 规范添加到 kubernetes 工作负载的规范配置中。与 Initializer 程序不同，`kube-inject` 只是将 YAML 规范转换成包含 Istio sidecar 的规范。您需要使用标准的工具如 `kubectl` 来部署修改后的 YAML。例如，以下命令将 sidecar 添加到 sleep.yaml 文件中指定的 pod 中，并将修改后的规范提交给 kubernetes：

 ```bash
 kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml)
@ -316,7 +318,7 @@ kubectl apply -f install/kubernetes/istio-initializer.yaml
 将会创建下列资源：

 1. `istio-sidecar` InitializerConfiguration 资源，指定 Istio sidecar 注入的资源。默认情况下  Istio sidecar 将被注入到 `deployment`、 `statefulset`、 `job` 和 `daemonset`中。
-2. `istio-inject` ConfigMap，initializer 的默认注入策略，一组初始化 namespace，以及注入时使用的模版参数。这些配置的详细说明请参考 [配置选项](#configuration-options)。
+2. `istio-inject` ConfigMap，initializer 的默认注入策略，一组初始化 namespace，以及注入时使用的模版参数。这些配置的详细说明请参考配置选项。
 3. `istio-initializer` Deployment，运行 initializer 控制器。
 4. `istio-initializer-service-account` ServiceAccount，用于 `istio-initializer` deployment。`ClusterRole` 和 `ClusterRoleBinding` 在 `install/kubernetes/istio.yaml` 中定义。注意所有的资源类型都需要有 `initialize` 和 `patch` 。正式处于这个原因，initializer 要作为 deployment 的一部分来运行而不是嵌入到其它控制器中，例如 istio-pilot。

@ -352,7 +354,7 @@ kubectl get deployment sleep -o yaml

 2) istio-initializer 控制器观察到有一个新的未初始化的工作负载被创建了。pending initializer 列表中的第一个个将作为 `sidecar.initializer.istio.io` 的名称。

-3) istio-initializer 检查它是否负责初始化 namespace 中的工作负载。如果没有为该 namespace 配置 initializer，则不需要做进一步的工作，而且 initializer 会忽略工作负载。默认情况下，initializer 负责所有的 namespace（参考 [配置选项](#配置选项)）。
+3) istio-initializer 检查它是否负责初始化 namespace 中的工作负载。如果没有为该 namespace 配置 initializer，则不需要做进一步的工作，而且 initializer 会忽略工作负载。默认情况下，initializer 负责所有的 namespace。

 4) istio-initializer 将自己从  pending initializer 中移除。如果 pending initializer 列表非空，则 Kubernetes 不回结束工作负载的创建。错误配置的 initializer 意味着破损的集群。

@ -469,7 +471,7 @@ kubectl delete -f install/kubernetes/istio-initializer.yaml

 ## 前置条件

- 按照 [安装指南](http://istio.doczh.cn/docs/setup/kubernetes/quick-start.html) 在 kubernetes 集群上安装 Istio service mesh。
+- 按照安装指南在 kubernetes 集群上安装 Istio service mesh。

 - 机器必须具有到 mesh 端点的 IP 地址连接。这通常需要一个 VPC 或者 VPN，以及一个向端点提供直接路由（没有 NAT 或者防火墙拒绝）的容器网络。及其不需要访问有 Kubernetes 分配的 cluster IP。

@ -729,7 +731,7 @@ Oct 13 21:32:29 demo-vm-1 node_agent[6941]: I1013 21:32:29.862575    6941 nodeag

 ## 整合到一起

-请参阅 [拓展 BookInfo Mesh](http://istio.doczh.cn/docs/guides/integrating-vms.html) 指南。
+请参阅拓展 BookInfo Mesh 指南。

 ------

@ -762,7 +764,7 @@ BookInfo 应用程序包括四个独立的微服务：

 ## 开始之前

-如果您还没有这样做，请按照与您的平台 [安装指南](http://istio.doczh.cn/docs/setup/index.html) 对应的说明安装Istio。
+如果您还没有这样做，请按照与您的平台安装指南对应的说明安装Istio。

 ## 部署应用程序

@ -902,9 +904,7 @@ BookInfo 应用程序包括四个独立的微服务：

 3. 确认所有容器都在运行：

-   ```bash
   docker ps -a
-   ```

   > 如果 Istio Pilot 容器终止了，重新执行上面的命令重新运行。

@ -928,7 +928,7 @@ curl -o /dev/null -s -w "%{http_code}\n" http://${GATEWAY_URL}/productpage

 你也可以通过在浏览器中打开 `http://$GATEWAY_URL/productpage` 页面访问 Bookinfo 网页。如果您多次刷新浏览器将在 productpage 中看到评论的不同的版本，它们会按照 round robin（红星、黑星、没有星星）的方式展现，因为我们还没有使用 Istio 来控制版本的路由。

-现在，您可以使用此示例来尝试 Istio 的流量路由、故障注入、速率限制等功能。要继续的话，请参阅 [Istio 指南](http://istio.doczh.cn/docs/guides/index.html)，具体取决于您的兴趣。[智能路由](http://istio.doczh.cn/docs/guides/intelligent-routing.html) 是初学者入门的好方式。
+现在，您可以使用此示例来尝试 Istio 的流量路由、故障注入、速率限制等功能。要继续的话，请参阅 Istio 指南，具体取决于您的兴趣。智能路由 是初学者入门的好方式。

 ## 清理

--- a/usecases/istio-installation.md
+++ b/usecases/istio-installation.md
@ -1,5 +1,7 @@
 # 安装并试用Istio service mesh

+**注意：本文档已失效，请浏览 [Istio 官方文档](https://istio.io/zh)**。
+
 官方文档地址 [快速开始](https://istio.io/docs/setup/kubernetes/)

 本文根据官网的文档整理而成，步骤包括安装**istio 0.5.1**并创建一个bookinfo的微服务来测试istio的功能。
@ -289,11 +291,11 @@ istio/examples-bookinfo-productpage-v1
 kubectl create -f <(istioctl kube-inject -f samples/apps/bookinfo/bookinfo.yaml)
 ```

-`Istio kube-inject`命令会在`bookinfo.yaml`文件中增加Envoy sidecar信息。参考：https://istio.io/docs/reference/commands/istioctl.html#istioctl-kube-inject
+`Istio kube-inject`命令会在`bookinfo.yaml`文件中增加Envoy sidecar信息。参考 https://istio.io/docs/reference/commands/istioctl/#istioctl-kube-inject

 在本机的`/etc/hosts`下增加VIP节点和`ingress.istio.io`的对应信息，具体步骤参考：[边缘节点配置](../practice/edge-node-configuration.md)，或者使用gateway ingress来访问服务，

-如果将`productpage`配置在了ingress里了，那么在浏览器中访问<http://ingress.istio.io/productpage>，如果使用了istio默认的`gateway` ingress配置的话，ingress service使用`nodePort`方式暴露的默认使用32000端口，那么可以使用<http://任意节点的IP:32000/productpage>来访问。
+如果将`productpage`配置在了ingress里了，那么在浏览器中访问`http://ingress.istio.io/productpage`，如果使用了istio默认的`gateway` ingress配置的话，ingress service使用`nodePort`方式暴露的默认使用32000端口，那么可以使用 `http://任意节点的IP:32000/productpage` 来访问。

 ![BookInfo Sample页面](../images/bookinfo-sample.jpg)

@ -371,29 +373,29 @@ $ kubectl get pod productpage-v1-944450470-bd530 -o json

 **Grafana页面**

-http://grafana.istio.io
+`http://grafana.istio.io`

 ![Istio Grafana界面](../images/istio-grafana.jpg)

 **Prometheus页面**

-http://prometheus.istio.io
+`http://prometheus.istio.io`

 ![Prometheus页面](../images/istio-prometheus.jpg)

 **Zipkin页面**

-http://zipkin.istio.io
+`http://zipkin.istio.io`

 ![Zipkin页面](../images/istio-zipkin.jpg)

 **ServiceGraph页面**

-http://servicegraph.istio.io/dotviz
+`http://servicegraph.istio.io/dotviz`

 可以用来查看服务间的依赖关系。

-访问 http://servicegraph.istio.io/graph 可以获得json格式的返回结果。
+访问` http://servicegraph.istio.io/graph` 可以获得json格式的返回结果。

 ![ServiceGraph页面](../images/istio-servicegraph.jpg)

@ -405,5 +407,5 @@ BookInfo示例中有三个版本的`reviews`，可以使用istio来配置路由

 ## 参考

- [Installing Istio](https://istio.io/docs/tasks/installing-istio.html)
- [BookInfo sample](https://istio.io/docs/guides/bookinfo.html)
+- [安装 Istio](https://istio.io/zh/docs/setup/kubernetes/)
+- [BookInfo 应用](https://istio.io/zh/docs/examples/bookinfo/)
--- a/usecases/istio-tutorial.md
+++ b/usecases/istio-tutorial.md
@ -899,7 +899,7 @@ istioctl delete -f istiofiles/recommendation_cb_policy_pool_ejection.yml -n isti

 Egress 是用来配置 Istio serivce mesh 中的服务对外部服务的访问策略。

-具体配置请参考 [控制 Egress 流量](http://istio.doczh.cn/docs/tasks/traffic-management/egress.html)。
+具体配置请参考控制 Egress 流量。

 以下示例还有问题，无法正常工作。

--- a/usecases/istio-tutorials-collection.md
+++ b/usecases/istio-tutorials-collection.md
@ -1,6 +1,6 @@
 # Istio 免费学习资源汇总

-8月1日0点，[Istio 1.0发布，已生产就绪！](/blog/announcing-istio-1.0/)大家都已经跃跃欲试了，几天前我发布了[一键在本地搭建运行Istio 1.0的分布式Kubernetes集群](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster)教程，在本地搭建起来还是有些门槛，稍显复杂，现在我推荐几个可以在线上学习的地方。这是目前搜集的比较完整的Isito学习环境和包含代码的示例教程有如下几个：
+8月1日0点，[Istio 1.0发布，已生产就绪！](http://www.servicemesher.com/blog/announcing-istio-1.0/)大家都已经跃跃欲试了，几天前我发布了[一键在本地搭建运行Istio 1.0的分布式Kubernetes集群](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster)教程，在本地搭建起来还是有些门槛，稍显复杂，现在我推荐几个可以在线上学习的地方。这是目前搜集的比较完整的Isito学习环境和包含代码的示例教程有如下几个：

 目前搜集的比较完整的Isito学习环境和包含代码的示例教程有如下几个：

@ -19,13 +19,13 @@ Katacoda已支持Istio 1.0的学习环境。

 地址：https://www.katacoda.com/courses/istio/deploy-istio-on-kubernetes

-![](https://ws4.sinaimg.cn/large/006tNc79gy1ftwe77v4u5j31kw0ziwtw.jpg)
+![katacoda](https://ws4.sinaimg.cn/large/006tNc79gy1ftwe77v4u5j31kw0ziwtw.jpg)

-![](https://ws3.sinaimg.cn/large/006tNc79gy1ftwhtmzhfej31kw0ziww1.jpg)
+![weavescope](https://ws3.sinaimg.cn/large/006tNc79gy1ftwhtmzhfej31kw0ziww1.jpg)

 只要傻瓜式操作就可以部署一个Istio出来，同时还提供了Weave scope可以对service mesh的中的服务关系做可视化呈现。

-![](https://ws2.sinaimg.cn/large/006tNc79gy1ftwhvtu1vxj31kw0zitvc.jpg)
+![weavescope](https://ws2.sinaimg.cn/large/006tNc79gy1ftwhvtu1vxj31kw0zitvc.jpg)

 同时还能提供部分监控功能，比如服务状态，CPU和内存使用情况。

@ -35,9 +35,9 @@ Katacoda已支持Istio 1.0的学习环境。

 推荐原因：教程topic划分简洁得当，RedHat大力加持，未来的频繁更新可以预期。

-![](https://ws2.sinaimg.cn/large/006tNc79gy1ftwiolw1tyj31kw0zib29.jpg)
+![Red Hat](https://ws2.sinaimg.cn/large/006tNc79gy1ftwiolw1tyj31kw0zib29.jpg)

-![](https://ws2.sinaimg.cn/large/006tNc79gy1ftwjyxiw1pj31kw0zi4qp.jpg)
+![Red Hat developers](https://ws2.sinaimg.cn/large/006tNc79gy1ftwjyxiw1pj31kw0zi4qp.jpg)

 ## IBM的Istio示例教程

@ -47,9 +47,9 @@ Katacoda已支持Istio 1.0的学习环境。

 https://developer.ibm.com/code/patterns/manage-microservices-traffic-using-istio

-![](https://ws3.sinaimg.cn/large/006tNc79gy1ftweryj0zrj31kw0zix6q.jpg)
+![IBM developerWorks](https://ws3.sinaimg.cn/large/006tNc79gy1ftweryj0zrj31kw0zix6q.jpg)

-![](https://ws2.sinaimg.cn/large/006tNc79gy1ftwesjg1e2j31kw0s8woq.jpg)
+![IBM developers](https://ws2.sinaimg.cn/large/006tNc79gy1ftwesjg1e2j31kw0s8woq.jpg)

 最后更新于2018年5月10号，是基于Istio 0.8的。

--- a/usecases/istio.md
+++ b/usecases/istio.md
@ -1,6 +1,6 @@
 # Istio简介

-> **注意**：Istio 1.10于2018年8月1日发布1.0，关于Istio的更多信息请见Istio官方文档:<https://istio.io>，中文版：<https://istio.io/zh>。
+**注意：Istio 1.10于2018年8月1日发布1.0，关于Istio的更多信息请见Istio官方文档:<https://istio.io>，中文版：<https://istio.io/zh>**。

 [Istio](https://istio.io)是由Google、IBM和Lyft开源的微服务管理、保护和监控框架。Istio为希腊语，意思是”起航“。

@ -72,6 +72,5 @@ Istio-Auth提供强大的服务间和最终用户认证，使用相互TLS，内

 ## 参考

- [Istio开源平台发布，Google、IBM和Lyft分别承担什么角色？](http://www.leiphone.com/news/201705/RwRlyAs7Mi8pqhSb.html)
 - [Istio：用于微服务的服务啮合层](http://www.infoq.com/cn/news/2017/05/istio?utm_source=news_about_opensource&utm_medium=link&utm_campaign=opensource)
- [Istio Overview](https://istio.io/docs/concepts/what-is-istio/overview.html)
+- [Istio 是什么？](https://istio.io/zh/docs/concepts/what-is-istio/)
--- a/usecases/linkerd-user-guide.md
+++ b/usecases/linkerd-user-guide.md
@ -33,7 +33,7 @@ openzipkin/zipkin:1.20
 tutum/dnsutils:latest
 ```

-这些镜像可以直接通过 Docker Hub 获取，我将它们下载下来并上传到了自己的私有镜像仓库 `harbor-001.jimmysong.io` 中，下文中用到的镜像皆来自我的私有镜像仓库，yaml 配置见 [linkerd](../manifests/linkerd) 目录，并在使用时将配置中的镜像地址修改为你自己的。
+这些镜像可以直接通过 Docker Hub 获取，我将它们下载下来并上传到了自己的私有镜像仓库 `harbor-001.jimmysong.io` 中，下文中用到的镜像皆来自我的私有镜像仓库，yaml 配置见 linkerd目录，并在使用时将配置中的镜像地址修改为你自己的。

 ## 部署

@ -82,7 +82,7 @@ Error signal	dtab is already marked as being deployed!

 因为该 dtab entry 已经存在，需要删除后再运行。

-访问 http://namerd.jimmysong.io
+访问 `http://namerd.jimmysong.io`

 ![namerd](../images/namerd-internal.jpg)

@ -113,7 +113,7 @@ $ kubectl create -f api.yml
 $ kubectl create -f world-v2.yml
 ```

-为了在本地调试 linkerd，我们将 linkerd 的 service 加入到 ingress 中，详见 [边缘节点配置](practice/edge-node-configuration.md)。
+为了在本地调试 linkerd，我们将 linkerd 的 service 加入到 ingress 中，详见 [边缘节点配置](../practice/edge-node-configuration.md)。

 在 Ingress 中增加如下内容：

@ -234,7 +234,7 @@ Percentage of the requests served within a certain time (ms)

 ## 监控 kubernets 中的服务与实例

-访问 http://linkerd.jimmysong.io 查看流量情况
+访问 `http://linkerd.jimmysong.io` 查看流量情况

 Outcoming 

@ -244,7 +244,7 @@ Incoming

 ![linkerd监控](../images/linkerd-helloworld-incoming.jpg)

-访问 http://linkerd-viz.jimmysong.io 查看应用 metric 监控
+访问 `http://linkerd-viz.jimmysong.io` 查看应用 metric 监控

 ![linkerd性能监控](../images/linkerd-grafana.png)

--- a/usecases/running-spark-with-kubernetes-native-scheduler.md
+++ b/usecases/running-spark-with-kubernetes-native-scheduler.md
@ -470,7 +470,6 @@ CMD SPARK_CLASSPATH="${SPARK_HOME}/jars/*" && \
 - [Running Spark on Kubernetes](https://apache-spark-on-k8s.github.io/userdocs/running-on-kubernetes.html)
 - [Apache Spark Jira Issue - 18278 - SPIP: Support native submission of spark jobs to a kubernetes cluster](https://issues.apache.org/jira/browse/SPARK-18278)
 - [Kubernetes Github Issue - 34377 Support Spark natively in Kubernetes](https://github.com/kubernetes/kubernetes/issues/34377)
- [Kubernetes example spark](https://github.com/kubernetes/kubernetes/tree/master/examples/spark)
 - https://github.com/rootsongjc/spark-on-kubernetes
 - [Scheduler backend](https://github.com/apache-spark-on-k8s/spark/blob/branch-2.2-kubernetes/resource-managers/kubernetes/architecture-docs/scheduler-backend.md)
 - [Introduction to Spark on Kubernetes - banzaicloud.com](https://banzaicloud.github.io/blog/spark-k8s/)
--- a/usecases/serverless.md
+++ b/usecases/serverless.md
@ -44,13 +44,13 @@ Serverless架构明显比其他架构更简单。更少的组件，就意味着
 - [IronFunctions](https://github.com/iron-io/functions) - IronFunctions - the serverless microservices platform. [http://iron.io](http://iron.io/)
 - [knative](https://github.com/knative) - Kubernetes-based platform to build, deploy, and manage modern serverless workloads
 - [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](http://openwhisk.incubator.apache.org/serverless), open source cloud platform that executes functions in response to events at any scale.
+- [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)。

 ## FaaS

-Function-as-a-Service景观图（图片来自<https://github.com/amyers1793/FunctionasaServiceLandscape>)
+Function-as-a-Service景观图（图片来自`https://github.com/amyers1793/FunctionasaServiceLandscape`)

 ![FaaS Landscape](../images/redpoint-faas-landscape.jpg)

--- a/usecases/spark-standalone-on-kubernetes.md
+++ b/usecases/spark-standalone-on-kubernetes.md
@ -11,7 +11,7 @@ index.tenxcloud.com/jimmy/zeppelin:0.7.1

 代码和使用文档见Github地址：https://github.com/rootsongjc/spark-on-kubernetes

-本文中用到的 yaml 文件可以在 [../manifests/spark-standalone](../manifests/spark-standalone) 目录下找到，也可以在上面的 https://github.com/rootsongjc/spark-on-kubernetes/ 项目的 manifests 目录下找到。
+本文中用到的 yaml 文件可以在 `manifests/spark-standalone` 目录下找到，也可以在上面的 https://github.com/rootsongjc/spark-on-kubernetes/ 项目的 manifests 目录下找到。

 **注意**：时速云上本来已经提供的镜像 `index.tenxcloud.com/google_containers/spark:1.5.2_v1` ，但是该镜像似乎有问题，下载总是失败。

@ -44,12 +44,12 @@ $ kubectl create -f manifests/

 **spark ui**

-访问http://spark.traefik.io
+访问 `http://spark.traefik.io`

 ![spark master ui](../images/spark-ui.jpg)

 **zeppelin ui**

-访问http://zepellin.treafik.io
+访问 `http://zepellin.treafik.io`

 ![zeppelin ui](../images/zeppelin-ui.jpg)