Delete the English content and fix translations

concepts/init-containers.md

@@ -2,7 +2,7 @@
 
 该特性在自 Kubernetes 1.6 版本推出 beta 版本。Init 容器可以在 PodSpec 中同应用程序的 `containers` 数组一起来指定。此前 beta 注解的值仍将保留，并覆盖 PodSpec 字段值。
 
-本文讲解 Init 容器的基本概念，这是一种专用的容器，在应用程序容器启动之前运行，用来包含一些应用镜像中不存在的实用工具和安装脚本。
+本文讲解 Init 容器的基本概念，这是一种专用的容器，在应用程序容器启动之前运行，用来包含一些应用镜像中不存在的实用工具或安装脚本。
 
 ## 理解 Init 容器
 
@@ -21,7 +21,7 @@ Init 容器与普通的容器非常像，除了如下两点：
 
 Init 容器支持应用容器的全部字段和特性，包括资源限制、数据卷和安全设置。 然而，Init 容器对资源请求和限制的处理稍有不同，在下面 [资源](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#resources) 处有说明。 而且 Init 容器不支持 Readiness Probe，因为它们必须在 Pod 就绪之前运行完成。
 
-如果为一个 Pod 指定了多个 Init 容器，那些容器会按顺序一次运行一个。 每个 Init 容器必须运行成功，下一个才能够运行。 当所有的 Init 容器运行完成时，Kubernetes 初始化 Pod 并像平常一样运行应用容器。
+如果为一个 Pod 指定了多个 Init 容器，那些容器会按顺序一次运行一个。只有当前面的 Init 容器必须运行成功后，才可以运行下一个 Init 容器。当所有的 Init 容器运行完成后，Kubernetes 才初始化 Pod 和运行应用容器。
 
 ## Init 容器能做什么？
 
@@ -205,9 +205,9 @@ myapp-pod   1/1       Running   0          9m
 
 如果 Pod [重启](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#pod-restart-reasons)，所有 Init 容器必须重新执行。
 
-对 Init 容器 spec 的修改，被限制在容器 image 字段中。 更改 Init 容器的 image 字段，等价于重启该 Pod。
+对 Init 容器 spec 的修改被限制在容器 image 字段，修改其他字段都不会生效。更改 Init 容器的 image 字段，等价于重启该 Pod。
 
-因为 Init 容器可能会被重启、重试或者重新执行，所以 Init 容器的代码应该是幂等的。特别地，被写到 `EmptyDirs` 中文件的代码，应该对输出文件可能已经存在做好准备。
+因为 Init 容器可能会被重启、重试或者重新执行，所以 Init 容器的代码应该是幂等的。特别地当写到 `EmptyDirs` 文件中的代码，应该对输出文件可能已经存在做好准备。
 
 Init 容器具有应用容器的所有字段。除了 `readinessProbe`，因为 Init 容器无法定义不同于完成（completion）的就绪（readiness）之外的其他状态。这会在验证过程中强制执行。
 

concepts/pod.md

@@ -26,7 +26,7 @@ Volume跟pod有相同的生命周期（当其UID存在的时候）。当Pod因
 
 ![Pod示意图](../images/pod-overview.png)
 
-*A multi-container pod that contains a file puller and a web server that uses a persistent volume for shared storage between the containers.*
+*一个多容器Pod，包含文件提取程序和Web服务器，该服务器使用持久卷在容器之间共享存储。*
 
 ## Pod的动机
 
@@ -46,11 +46,11 @@ Pod中的应用容器可以共享volume。Volume能够保证pod重启时使用
 
 Pod也可以用于垂直应用栈（例如LAMP），这样使用的主要动机是为了支持共同调度和协调管理应用程序，例如：
 
-- content management systems, file and data loaders, local cache managers, etc.
-- log and checkpoint backup, compression, rotation, snapshotting, etc.
-- data change watchers, log tailers, logging and monitoring adapters, event publishers, etc.
-- proxies, bridges, and adapters
-- controllers, managers, configurators, and updaters
+- 内容管理系统、文件和数据加载器、本地换群管理器等。
+- 日志和检查点备份、压缩、旋转、快照等。
+- 数据变更观察者、日志和监控适配器、活动发布者等。
+- 代理、桥接和适配器等。
+- 控制器、管理器、配置器、更新器等。
 
 通常单个pod中不会同时运行一个应用的多个实例。
 
@@ -75,18 +75,18 @@ Pod在设计支持就不是作为持久化实体的。在调度失败、节点
 
 通常，用户不需要手动直接创建Pod，而是应该使用controller（例如[Deployments](./deployment.md)），即使是在创建单个Pod的情况下。Controller可以提供集群级别的自愈功能、复制和升级管理。
 
-The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [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), and [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](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)。
 
-Pod is exposed as a primitive in order to facilitate:
+Pod 原语有利于：
 
-- scheduler and controller pluggability
-- support for pod-level operations without the need to "proxy" them via controller APIs
-- decoupling of pod lifetime from controller lifetime, such as for bootstrapping
-- decoupling of controllers and services — the endpoint controller just watches pods
-- clean composition of Kubelet-level functionality with cluster-level functionality — Kubelet is effectively the "pod controller"
-- high-availability applications, which will expect pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions, image prefetching, or live pod migration [#3949](http://issue.k8s.io/3949)
+- 调度程序和控制器可插拔性
+- 支持pod级操作，无需通过控制器API“代理”它们
+- 将pod生命周期与控制器生命周期分离，例如用于自举（bootstrap）
+- 控制器和服务的分离——端点控制器只是监视pod
+- 将集群级功能与Kubelet级功能的清晰组合——Kubelet实际上是“pod控制器”
+- 高可用性应用程序，它们可以在终止之前及在删除之前更换pod，例如在计划驱逐、镜像预拉取或实时pod迁移的情况下[#3949](https://github.com/kubernetes/kubernetes/issues/3949)
 
-[StatefulSet](statefulset.md) controller（目前还是beta状态）支持有状态的Pod。在1.4版本中被称为PetSet。在kubernetes之前的版本中创建有状态pod的最佳方式是创建一个replica为1的replication controller。
+[StatefulSet](statefulset.md) 控制器支持有状态的Pod。在1.4版本中被称为PetSet。在kubernetes之前的版本中创建有状态pod的最佳方式是创建一个replica为1的replication controller。
 
 ## Pod的终止