Add spaces to properly render bold text in Chinese

content/zh-cn/blog/_posts/2019-04-24-Hardware-Accelerated-SSLTLS-Termination-in-Ingress-Controllers-using-Kubernetes-Device-Plugins-and-RuntimeClass.md

@@ -171,12 +171,12 @@ underlying host devices.
 基于 PCIe 的加密加速设备功能
 可以受益于 IO 硬件虚拟化，通过 I/O 内存管理单元（IOMMU），提供隔离：IOMMU 将设备分组，为工作负载提供隔离的资源
 （假设加密卡不与其他设备共享 **IOMMU 组**）。如果PCIe设备支持单根 I/O 虚拟化（SR-IOV）规范，则可以进一步增加隔离资源的数量。
-SR-IOV 允许将 PCIe 设备将**物理功能项（Physical Functions，PF）**设备进一步拆分为
+SR-IOV 允许将 PCIe 设备将 **物理功能项（Physical Functions，PF）** 设备进一步拆分为
 **虚拟功能项（Virtual Functions, VF）**，并且每个设备都属于自己的 IOMMU 组。
 要将这些借助 IOMMU 完成隔离的设备功能项暴露给用户空间和容器，主机内核应该将它们绑定到特定的设备驱动程序。
 在 Linux 中，这个驱动程序是 vfio-pci，
 它通过字符设备将设备提供给用户空间。内核 vfio-pci 驱动程序使用一种称为
-**PCI 透传（PCI Passthrough）**的机制，
+**PCI 透传（PCI Passthrough）** 的机制，
 为用户空间应用程序提供了对 PCIe 设备与功能项的直接的、IOMMU 支持的访问。
 用户空间框架，如数据平面开发工具包（Data Plane Development Kit，DPDK）可以利用该接口。
 此外，虚拟机（VM）管理程序可以向 VM 提供这些用户空间设备节点，并将它们作为 PCI 设备暴露给寄宿内核。

content/zh-cn/docs/concepts/configuration/manage-resources-containers.md

@@ -37,12 +37,12 @@ that system resource specifically for that container to use.
 {{< glossary_tooltip text="容器" term_id="container" >}}设定所需要的资源数量。
 最常见的可设定资源是 CPU 和内存（RAM）大小；此外还有其他类型的资源。
 
-当你为 Pod 中的 Container 指定了资源 **request（请求）**时，
+当你为 Pod 中的 Container 指定了资源 **request（请求）** 时，
 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}
 就利用该信息决定将 Pod 调度到哪个节点上。
-当你为 Container 指定了资源 **limit（限制）**时，{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}
+当你为 Container 指定了资源 **limit（限制）** 时，{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}
 就可以确保运行的容器不会使用超出所设限制的资源。
-kubelet 还会为容器预留所 **request（请求）**数量的系统资源，供其使用。
+kubelet 还会为容器预留所 **request（请求）** 数量的系统资源，供其使用。
 
 <!-- body -->
 

content/zh-cn/docs/reference/access-authn-authz/rbac.md

@@ -960,7 +960,7 @@ so that authentication produces usernames in the format you want.
 -->
 ### 对主体的引用   {#referring-to-subjects}
 
-RoleBinding 或者 ClusterRoleBinding 可绑定角色到某**主体（Subject）**上。
+RoleBinding 或者 ClusterRoleBinding 可绑定角色到某**主体（Subject）** 上。
 主体可以是组，用户或者{{< glossary_tooltip text="服务账户" term_id="service-account" >}}。
 
 Kubernetes 用字符串来表示用户名。

content/zh-cn/docs/reference/glossary/downstream.md

@@ -34,5 +34,5 @@ tags:
 * In the **Kubernetes Community**: Conversations often use *downstream* to mean the ecosystem, code, or third-party tools that rely on the core Kubernetes codebase. For example, a new feature in Kubernetes may be adopted by applications *downstream* to improve their functionality.
 * In **GitHub** or **git**: The convention is to refer to a forked repo as *downstream*, whereas the source repo is considered *upstream*.
 -->
-* 在 **Kubernetes 社区**中：**下游(downstream)**在人们交流中常用来表示那些依赖核心 Kubernetes 代码库的生态系统、代码或者第三方工具。例如，Kubernetes 的一个新特性可以被**下游(downstream)**应用采用，以提升它们的功能性。
-* 在 **GitHub** 或 **git** 中：约定用**下游(downstream)**表示分支代码库，源代码库被认为是**上游(upstream)**。
+* 在 **Kubernetes 社区**中：**下游(downstream)** 在人们交流中常用来表示那些依赖核心 Kubernetes 代码库的生态系统、代码或者第三方工具。例如，Kubernetes 的一个新特性可以被**下游(downstream)** 应用采用，以提升它们的功能性。
+* 在 **GitHub** 或 **git** 中：约定用**下游(downstream)** 表示分支代码库，源代码库被认为是**上游(upstream)**。

content/zh-cn/docs/tasks/configure-pod-container/configure-service-account.md

@@ -33,7 +33,7 @@ server, you identify yourself as a particular _user_. Kubernetes recognises
 the concept of a user, however, Kubernetes itself does **not** have a User
 API.
 -->
-**服务账号（Service Account）**为 Pod 中运行的进程提供身份标识，
+**服务账号（Service Account）** 为 Pod 中运行的进程提供身份标识，
 并映射到 ServiceAccount 对象。当你向 API 服务器执行身份认证时，
 你会将自己标识为某个**用户（User）**。Kubernetes 能够识别用户的概念，
 但是 Kubernetes 自身**并不**提供 User API。