fix typos: a blank should be put after * to show italic (#13301)

content/zh/docs/concepts/_index.md

@@ -28,7 +28,7 @@ weight: 40
 
 <!-- To work with Kubernetes, you use *Kubernetes API objects* to describe your cluster's *desired state*: what applications or other workloads you want to run, what container images they use, the number of replicas, what network and disk resources you want to make available, and more. You set your desired state by creating objects using the Kubernetes API, typically via the command-line interface, `kubectl`. You can also use the Kubernetes API directly to interact with the cluster and set or modify your desired state. -->
 
-要使用 Kubernetes，你需要用 *Kubernetes API 对象*来描述集群的*预期状态（desired state）*：包括你需要运行的应用或者负载，它们使用的镜像、副本数，以及所需网络和磁盘资源等等。你可以使用命令行工具 `kubectl`  来调用 Kubernetes API 创建对象，通过所创建的这些对象来配置预期状态。你也可以直接调用 Kubernetes API 和集群进行交互，设置或者修改预期状态。
+要使用 Kubernetes，你需要用 *Kubernetes API 对象* 来描述集群的*预期状态（desired state）* ：包括你需要运行的应用或者负载，它们使用的镜像、副本数，以及所需网络和磁盘资源等等。你可以使用命令行工具 `kubectl`  来调用 Kubernetes API 创建对象，通过所创建的这些对象来配置预期状态。你也可以直接调用 Kubernetes API 和集群进行交互，设置或者修改预期状态。
 
 <!-- Once you've set your desired state, the *Kubernetes Control Plane* works to make the cluster's current state match the desired state. To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster:  -->
 
@@ -63,7 +63,7 @@ Kubernetes 包含若干抽象用来表示系统状态，包括：已部署的容
 
 <!-- In addition, Kubernetes contains a number of higher-level abstractions called Controllers. Controllers build upon the basic objects, and provide additional functionality and convenience features. They include: -->
 
-另外，Kubernetes 包含大量的被称作*控制器（controllers）*的高级抽象。控制器基于基本对象构建并提供额外的功能和方便使用的特性。具体包括：
+另外，Kubernetes 包含大量的被称作*控制器（controllers）* 的高级抽象。控制器基于基本对象构建并提供额外的功能和方便使用的特性。具体包括：
 
 * [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
 * [Deployment](/docs/concepts/workloads/controllers/deployment/)

content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md

@@ -17,7 +17,7 @@ content_template: templates/concept
 ## 规划集群
 
 
-查阅 [选择正确解决方案](/docs/setup/pick-right-solution/) 中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版*。
+查阅 [选择正确解决方案](/docs/setup/pick-right-solution/) 中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版* 。
 
 
 在选择一个指南前，有一些因素需要考虑：

content/zh/docs/concepts/configuration/manage-compute-resources-container.md

@@ -14,9 +14,9 @@ content_template: templates/concept
 
 ## 资源类型
 
-*CPU* 和 *内存* 都是 *资源类型*。资源类型具有基本单位。CPU 的单位是 core，内存的单位是 byte。
+*CPU* 和 *内存* 都是 *资源类型* 。资源类型具有基本单位。CPU 的单位是 core，内存的单位是 byte。
 
-CPU和内存统称为*计算资源*，也可以称为*资源*。计算资源的数量是可以被请求、分配、消耗和可测量的。它们与 [API 资源](/docs/api/) 不同。 API 资源（如 Pod 和 [Service](/docs/user-guide/services)）是可通过 Kubernetes API server 读取和修改的对象。
+CPU和内存统称为*计算资源* ，也可以称为*资源* 。计算资源的数量是可以被请求、分配、消耗和可测量的。它们与 [API 资源](/docs/api/) 不同。 API 资源（如 Pod 和 [Service](/docs/user-guide/services)）是可通过 Kubernetes API server 读取和修改的对象。
 
 ## Pod 和 容器的资源请求和限制
 
@@ -226,7 +226,7 @@ Kubernetes 1.5 版本中引入不透明整型资源。不透明的整数资源
 
 **注意：** 不透明整型资源在 kubernetes 1.5 中还是 Alpha 版本。只实现了资源计量，节点级别的隔离还处于积极的开发阶段。
 
-不透明整型资源是以 `pod.alpha.kubernetes.io/opaque-int-resource-` 为前缀的资源。API server 将限制这些资源的数量为整数。*有效* 数量的例子有 `3`、`3000m` 和 `3Ki`。*无效*数量的例子有 `0.5` 和 `1500m`。
+不透明整型资源是以 `pod.alpha.kubernetes.io/opaque-int-resource-` 为前缀的资源。API server 将限制这些资源的数量为整数。*有效* 数量的例子有 `3`、`3000m` 和 `3Ki`。*无效* 数量的例子有 `0.5` 和 `1500m`。
 
 申请使用不透明整型资源需要两步。首先，集群运维人员必须在一个或多个节点上通告每个节点不透明的资源。然后，用户必须在 Pod 中请求不透明资源。
 

content/zh/docs/concepts/containers/container-environment-variables.md

@@ -40,7 +40,7 @@ Pod 名称和名字空间可以通过
 容器创建时运行的所有服务的列表都会作为环境变量提供给容器。
 这些环境变量与 Docker 链接语法相匹配。
 
-对一个名为 *foo*，映射到名为 *bar* 的容器端口的服务，
+对一个名为 *foo* ，映射到名为 *bar* 的容器端口的服务，
 会定义如下变量：
 
 ```shell

content/zh/docs/concepts/overview/what-is-kubernetes.md

@@ -107,7 +107,7 @@ Kubernetes 不是一个传统意义上，包罗万象的 PaaS (平台即服务)
 * Kubernetes 不提供或授权一个全面的应用程序配置语言/系统 (例如 [jsonnet](https://github.com/google/jsonnet)).
 * Kubernetes 不提供也不采用任何全面机器配置、保养、管理或自我修复系统
 
-另一方面，许多 PaaS 系统*运行*在 Kubernetes 上面，例如  [Openshift](https://github.com/openshift/origin), [Deis](http://deis.io/), and [Eldarion](http://eldarion.cloud/)。 您也可以自定义您自己的 PaaS, 与您选择的 CI 系统集成，或与 Kubernetes 一起使用: 将您的容器镜像部署到 Kubernetes。
+另一方面，许多 PaaS 系统*运行* 在 Kubernetes 上面，例如  [Openshift](https://github.com/openshift/origin), [Deis](http://deis.io/), and [Eldarion](http://eldarion.cloud/)。 您也可以自定义您自己的 PaaS, 与您选择的 CI 系统集成，或与 Kubernetes 一起使用: 将您的容器镜像部署到 Kubernetes。
 
 由于 Kubernetes 在应用级别而不仅仅在硬件级别上运行，因此它提供 PaaS 产品通用的一些功能，例如部署、扩展、负载均衡、日志记录、监控等。但是，Kubernetes 不是单一的，默认解决方案是可选和可插拔的。
 

content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md

@@ -36,9 +36,9 @@ Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernete
 
 ### 对象规约（Spec）与状态（Status）
 
-每个 Kubernetes 对象包含两个嵌套的对象字段，它们负责管理对象的配置：对象 *spec* 和 对象 *status*。
+每个 Kubernetes 对象包含两个嵌套的对象字段，它们负责管理对象的配置：对象 *spec* 和 对象 *status* 。
 *spec* 是必需的，它描述了对象的 *期望状态（Desired State）* —— 希望对象所具有的特征。
-*status* 描述了对象的 *实际状态（Actual State）*，它是由 Kubernetes 系统提供和更新的。在任何时刻，Kubernetes 控制面一直努力地管理着对象的实际状态以与期望状态相匹配。
+*status* 描述了对象的 *实际状态（Actual State）* ，它是由 Kubernetes 系统提供和更新的。在任何时刻，Kubernetes 控制面一直努力地管理着对象的实际状态以与期望状态相匹配。
 
 
 

content/zh/docs/concepts/policy/pod-security-policy.md

@@ -46,9 +46,9 @@ _Pod 安全策略_ 是集群级别的资源，它能够控制 Pod 运行的行
 
 _Pod 安全策略_ 由设置和策略组成，它们能够控制 Pod 访问的安全特征。这些设置分为如下三类：
 
-- *基于布尔值控制*：这种类型的字段默认为最严格限制的值。
-- *基于被允许的值集合控制*：这种类型的字段会与这组值进行对比，以确认值被允许。
-- *基于策略控制*：设置项通过一种策略提供的机制来生成该值，这种机制能够确保指定的值落在被允许的这组值中。
+- *基于布尔值控制* ：这种类型的字段默认为最严格限制的值。
+- *基于被允许的值集合控制* ：这种类型的字段会与这组值进行对比，以确认值被允许。
+- *基于策略控制* ：设置项通过一种策略提供的机制来生成该值，这种机制能够确保指定的值落在被允许的这组值中。
 
 
 
@@ -122,7 +122,7 @@ _Pod 安全策略_ 由设置和策略组成，它们能够控制 Pod 访问的
 
 
 ### 主机网络
- - *HostPorts*， 默认为 `empty`。`HostPortRange` 列表通过 `min`(包含) and `max`(包含) 来定义，指定了被允许的主机端口。
+ - *HostPorts* ， 默认为 `empty`。`HostPortRange` 列表通过 `min`(包含) and `max`(包含) 来定义，指定了被允许的主机端口。
 
 ### 允许的主机路径
  - *AllowedHostPaths* 是一个被允许的主机路径前缀的白名单。空值表示所有的主机路径都可以使用。

content/zh/docs/concepts/workloads/controllers/garbage-collection.md

@@ -26,7 +26,7 @@ Kubernetes 垃圾收集器的角色是删除指定的对象，这些对象曾经
 ## Owner 和 Dependent
 
 某些 Kubernetes 对象是其它一些对象的 Owner。例如，一个 ReplicaSet 是一组 Pod 的 Owner。
-具有 Owner 的对象被称为是 Owner 的 *Dependent*。
+具有 Owner 的对象被称为是 Owner 的 *Dependent* 。
 每个 Dependent 对象具有一个指向其所属对象的 `metadata.ownerReferences` 字段。
 
 有时，Kubernetes 会自动设置 `ownerReference` 的值。
@@ -73,10 +73,10 @@ metadata:
 ## 控制垃圾收集器删除 Dependent
 
 当删除对象时，可以指定是否该对象的 Dependent 也自动删除掉。
-自动删除 Dependent 也称为 *级联删除*。
+自动删除 Dependent 也称为 *级联删除* 。
 Kubernetes 中有两种 *级联删除* 的模式：*background* 模式和 *foreground* 模式。
 
-如果删除对象时，不自动删除它的 Dependent，这些 Dependent 被称作是原对象的 *孤儿*。
+如果删除对象时，不自动删除它的 Dependent，这些 Dependent 被称作是原对象的 *孤儿* 。
 
 
 

content/zh/docs/concepts/workloads/pods/init-containers.md

@@ -18,7 +18,7 @@ content_template: templates/concept
 {{< toc >}}
 
 
-这个特性在 1.6 版本已经退出 beta 版本。Init 容器可以在 PodSpec 中同应用的 `containers` 数组一起来指定。
+这个特性在 1.6 版本已经退出 beta 版本。Init 容器可以在 PodSpec 中有效 QoS 层同应用的 `containers` 数组一起来指定。
 beta 注解的值将仍然需要保留，并覆盖 PodSpec 字段值。
 
 {{% capture body %}}
@@ -291,7 +291,7 @@ Init 容器具有应用容器的所有字段。
   * 所有应用容器对某个资源的请求/限制之和
   * 对某个资源的有效初始请求/限制
 * 基于有效请求/限制完成调度，这意味着 Init 容器能够为初始化预留资源，这些资源在 Pod 生命周期过程中并没有被使用。
-* Pod 的 *有效 QoS 层*，是 Init 容器和应用容器相同的 QoS 层。
+* Pod 的 *有效 QoS 层* ，是 Init 容器和应用容器相同的 QoS 层。