Remove trailing spaces from zh documents(#16742) (#16794)

2019-10-15 18:23:51 +09:00
parent 0268ed0c18
commit b05129acc3
106 changed files with 648 additions and 648 deletions
@@ -313,7 +313,7 @@ such as your desktop machine.
 -->
 ## 访问集群中正在运行的服务

-上一节介绍了如何连接 Kubernetes API 服务。本节介绍如何连接到 Kubernetes 集群上运行的其他服务。 
+上一节介绍了如何连接 Kubernetes API 服务。本节介绍如何连接到 Kubernetes 集群上运行的其他服务。
 在 Kubernetes 中，[节点](/docs/admin/node)，[pods](/docs/user-guide/pods) 和 [服务](/docs/user-guide/services) 都有自己的 IP。
 在许多情况下，集群上的节点 IP，pod IP 和某些服务 IP 将无法路由，因此无法从集群外部的计算机（例如桌面计算机）访问它们。

@@ -499,14 +499,14 @@ The redirect capabilities have been deprecated and removed.  Please use a proxy
 There are several different proxies you may encounter when using Kubernetes:

 1.  The [kubectl proxy](#directly-accessing-the-rest-api):
-  
+
    - runs on a user's desktop or in a pod
    - proxies from a localhost address to the Kubernetes apiserver
    - client to proxy uses HTTP
    - proxy to apiserver uses HTTPS
    - locates apiserver
    - adds authentication headers
-    
+
 -->
 ## 多种代理

@@ -520,10 +520,10 @@ There are several different proxies you may encounter when using Kubernetes:
    - 代理到 apiserver 使用 HTTPS
    - 定位 apiserver
    - 添加身份验证 header
-    
+
 <!--
 1.  The [apiserver proxy](#discovering-builtin-services):
-  
+
    - is a bastion built into the apiserver
    - connects a user outside of the cluster to cluster IPs which otherwise might not be reachable
    - runs in the apiserver processes
@@ -541,10 +541,10 @@ There are several different proxies you may encounter when using Kubernetes:
    - 代理将根据可用的信息决定使用 HTTP 或者 HTTPS 代理到目标
    - 可用于访问节点、Pod 或服务
    - 在访问服务时进行负载平衡
-    
+
 <!--
 1.  The [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
-  
+
    - runs on each node
    - proxies UDP and TCP
    - does not understand HTTP
@@ -552,29 +552,29 @@ There are several different proxies you may encounter when using Kubernetes:
    - is just used to reach services
 -->
 1.  [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips)：
-  
+
    - 运行在每个节点上
    - 代理 UDP 和 TCP
    - 不能代理 HTTP
    - 提供负载均衡
    - 只能用来访问服务
-    
+
 <!--
 1.  A Proxy/Load-balancer in front of apiserver(s):
-  
+
    - existence and implementation varies from cluster to cluster (e.g. nginx)
    - sits between all clients and one or more apiservers
    - acts as load balancer if there are several apiservers.
 -->
 1.  位于 apiserver 之前的 Proxy/Load-balancer：
-  
+
    - 存在和实现因集群而异（例如 nginx）
    - 位于所有客户和一个或多个 apiserver 之间
    - 如果有多个 apiserver，则充当负载均衡器
-    
+
 <!--
 1.  Cloud Load Balancers on external services:
-  
+
    - are provided by some cloud providers (e.g. AWS ELB, Google Cloud Load Balancer)
    - are created automatically when the Kubernetes service has type `LoadBalancer`
    - use UDP/TCP only
@@ -584,7 +584,7 @@ Kubernetes users will typically not need to worry about anything other than the
 will typically ensure that the latter types are setup correctly.
 -->
 1.  外部服务上的云负载均衡器：
-  
+
    - 由一些云提供商提供（例如 AWS ELB，Google Cloud Load Balancer）
    - 当 Kubernetes 服务类型为 `LoadBalancer` 时自动创建
    - 只使用 UDP/TCP
@@ -9,7 +9,7 @@ weight: 90

 {{% capture overview %}}

-<!-- 
+<!--
 Many cloud providers (e.g. Google Compute Engine) define firewalls that help prevent inadvertent
 exposure to the internet.  When exposing a service to the external world, you may need to open up
 one or more ports in these firewalls to serve traffic.  This document describes this process, as
@@ -141,15 +141,15 @@ Consider:
 -->
   * 因为在防火墙上为集群的所有节点都打开了 80 端口，所以外部的服务可以向你的
     服务发送数据包。
-   
-<!--  
+
+<!--
   * You start an nginx server, running on port 80 on the host virtual machine
     (IP Address 2.3.4.5).  This nginx is also exposed to the internet on
     the VM's external IP address.
 -->
   * 最后你又虚拟机上的80端口启动 nginx 服务器（ip地址2.3.4.5）。
     这个 nginx 在虚拟机的外部 IP 地址上也被暴露到了互联网上。
-   
+
 <!--
 Consequently, please be careful when opening firewalls in Google Compute Engine
 or Google Kubernetes Engine.  You may accidentally be exposing other services to
@@ -13,7 +13,7 @@ content_template: templates/concept

 {{% capture overview %}}
 <!--
-Kubernetes offers a DNS cluster addon, which most of the supported environments enable by default. 
+Kubernetes offers a DNS cluster addon, which most of the supported environments enable by default.
 -->
 Kubernetes 提供 DNS 集群插件，大多数支持的环境默认情况下都会启用。
 {{% /capture %}}
@@ -57,7 +57,7 @@ load-balanced access to an application running in a cluster.
       ```
       kubectl run hello-world --replicas=2 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0  --port=8080
       ```
-       
+
 <!--
 1. List the pods that are running the Hello World application:
 -->
@@ -99,7 +99,7 @@ load-balanced access to an application running in a cluster.
       ```
       kubectl get services example-service
       ```
-   
+
 <!--
   The output shows the internal IP address and the external IP address of
   your service. If the external IP address shows as `<pending>`, repeat the
@@ -53,24 +53,24 @@ for database debugging.
    查看输出是否成功，以验证是否成功创建 deployment：

        deployment "redis-master" created
- 
+
 <!--
    When the pod is ready, you can get:
 -->
    当 pod 是 ready 时，您将得到：
-       
+
       kubectl get pods

        NAME                            READY     STATUS    RESTARTS   AGE
        redis-master-765d459796-258hz   1/1       Running   0          50s

       kubectl get deployment
-       
+
        NAME         DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
        redis-master 1         1         1            1           55s

       kubectl get rs
-       
+
        NAME                      DESIRED   CURRENT   READY     AGE
        redis-master-765d459796   1         1         1         1m

@@ -104,9 +104,9 @@ for database debugging.
 -->
 3. 验证 Redis 服务是否运行在 pod 中并且监听 6379 端口：

-        
+
       kubectl get pods redis-master-765d459796-258hz --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
-        
+

 <!--
    The output displays the port:
@@ -125,7 +125,7 @@ for database debugging.

 1. 从 Kubernetes v1.10 开始，`kubectl port-forward` 允许使用资源名称（例如服务名称）来选择匹配的 pod 来进行端口转发。

-        kubectl port-forward redis-master-765d459796-258hz 6379:6379 
+        kubectl port-forward redis-master-765d459796-258hz 6379:6379

 <!--
    which is the same as
@@ -135,18 +135,18 @@ for database debugging.
        kubectl port-forward pods/redis-master-765d459796-258hz 6379:6379

 <!--
-    or  
+    or
 -->
    或者

-        kubectl port-forward deployment/redis-master 6379:6379 
+        kubectl port-forward deployment/redis-master 6379:6379

 <!--
    or
 -->
    或者

-        kubectl port-forward rs/redis-master 6379:6379 
+        kubectl port-forward rs/redis-master 6379:6379

 <!--
    or
@@ -56,7 +56,7 @@ provides load balancing for an application that has two running instances.
 1. 在您的集群中运行一个 Hello World 应用：
   ```shell
   kubectl run hello-world --replicas=2 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0  --port=8080
-   ```   
+   ```
 <!--
    The preceding command creates a
    [Deployment](/docs/concepts/workloads/controllers/deployment/)
@@ -22,7 +22,7 @@ weight: 15
 {{% capture overview %}}

 <!--
-Setting up an extension API server to work the aggregation layer allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs. 
+Setting up an extension API server to work the aggregation layer allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
 -->
 设置一个扩展的 API server 来使用聚合层以让 Kubernetes apiserver 使用其它 API 进行扩展，这些 API 不是核心 Kubernetes API 的一部分。

@@ -333,7 +333,7 @@ deployment "not-best-effort-nginx" created
 ```


-虽然没有指定默认的 limits，`best-effort-nginx` deployment 还是会创建 8 个 pods。这是由于它被 `best-effort` 配额追踪，而 `not-best-effort` 配额将忽略它。`not-best-effort` 配额将追踪 `not-best-effort-nginx` deployment，因为它创建的 pods 具有 `Burstable` 服务质量。 
+虽然没有指定默认的 limits，`best-effort-nginx` deployment 还是会创建 8 个 pods。这是由于它被 `best-effort` 配额追踪，而 `not-best-effort` 配额将忽略它。`not-best-effort` 配额将追踪 `not-best-effort-nginx` deployment，因为它创建的 pods 具有 `Burstable` 服务质量。


 让我们列出 namespace 中的 pods：
@@ -384,7 +384,7 @@ requests.memory     512Mi 1Gi
 ```


-如你看到的，`best-effort` 配额追踪了我们在 `best-effort-nginx` deployment 中创建的 8 个 pods 的资源用量，而 `not-best-effort` 配额追踪了我们在 `not-best-effort-nginx` deployment 中创的两个 pods 的用量。 
+如你看到的，`best-effort` 配额追踪了我们在 `best-effort-nginx` deployment 中创建的 8 个 pods 的资源用量，而 `not-best-effort` 配额追踪了我们在 `not-best-effort-nginx` deployment 中创的两个 pods 的用量。


 Scopes 提供了一种来对任何配额文档追踪的资源集合进行细分的机制，给操作人员部署和追踪资源消耗带来更大的灵活性。
@@ -55,7 +55,7 @@ content_template: templates/task
   默认 StorageClass 的注解 `storageclass.kubernetes.io/is-default-class` 设置为 `true`。注解的其它任意值或者缺省值将被解释为 `false`。


-   要标记一个 StorageClass 为非默认的，您需要改变它的值为 `false`： 
+   要标记一个 StorageClass 为非默认的，您需要改变它的值为 `false`：

        kubectl patch storageclass <your-class-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'

@@ -30,7 +30,7 @@ content_template: templates/task
 1. 列出你集群中的 PersistentVolumes

       kubectl get pv
-       
+
    输出类似于这样：

        NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                  REASON    AGE
@@ -47,7 +47,7 @@ content_template: templates/task
    ```shell
    kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
    ```
-       
+
    这里的 `<your-pv-name>` 是你选择的 PersistentVolume 的名字。

 3. 验证你选择的 PersistentVolume 拥有正确的策略：
@@ -15,7 +15,7 @@ title: 集群管理
 ## 创建和配置集群


-要在一组机器上安装 Kubernetes， 请根据您的环境，查阅现有的 [入门指南](/docs/getting-started-guides/) 
+要在一组机器上安装 Kubernetes， 请根据您的环境，查阅现有的 [入门指南](/docs/getting-started-guides/)


 ## 升级集群
@@ -38,7 +38,7 @@ content_template: templates/task
 ```console
 $ kubectl run nginx --image=nginx --replicas=2
 deployment "nginx" created
-$ kubectl expose deployment nginx --port=80 
+$ kubectl expose deployment nginx --port=80
 service "nginx" exposed
 ```

@@ -121,7 +121,7 @@ Waiting for pod default/busybox-472357175-y0m47 to be running, status is Pending

 Hit enter for command prompt

-/ # wget --spider --timeout=1 nginx 
+/ # wget --spider --timeout=1 nginx
 Connecting to nginx (10.100.0.16:80)
 wget: download timed out
 / #
@@ -95,7 +95,7 @@ data:
 1. 查询首先被发送到 kube-dns 中的 DNS 缓存层。

 1. 从缓存层，检查请求的后缀，并根据下面的情况转发到对应的 DNS 上：
- 
+
   * *具有集群后缀的名字*（例如 ".cluster.local"）：请求被发送到 kube-dns。

   * *具有存根域后缀的名字*（例如 ".acme.local"）：请求被发送到配置的自定义 DNS 解析器（例如：监听在 1.2.3.4）。
@@ -4,7 +4,7 @@ reviewers:
 - luxas
 - roberthbailey
 - jbeda
-title: 将 kubeadm 集群在 v1.8 版本到 v1.9 版本之间升级/降级 
+title: 将 kubeadm 集群在 v1.8 版本到 v1.9 版本之间升级/降级
 content_template: templates/task
 ---

@@ -98,9 +98,9 @@ chmod a+rx /usr/bin/kubeadm
 {{< caution >}}
 <!--

-Upgrading the `kubeadm` package on your system prior to upgrading the control plane causes a failed upgrade. 
-Even though `kubeadm` ships in the Kubernetes repositories, it's important to install `kubeadm` manually. The kubeadm 
-team is working on fixing this limitation. 
+Upgrading the `kubeadm` package on your system prior to upgrading the control plane causes a failed upgrade.
+Even though `kubeadm` ships in the Kubernetes repositories, it's important to install `kubeadm` manually. The kubeadm
+team is working on fixing this limitation.

 --->
 **注意:** 在您的系统上升级控制面板之前升级 `kubeadm` 包会导致升级失败。
@@ -189,7 +189,7 @@ You can now apply the upgrade by executing the following command:

 _____________________________________________________________________
 ```
-         
+
 --->

  ```shell
@@ -242,7 +242,7 @@ _____________________________________________________________________
    请注意：在您执行升级之前，您必须升级 kubeadm 到 v1.9.0 版本
 _____________________________________________________________________
 ```
-                 
+
 <!--

 The `kubeadm upgrade plan` checks that your cluster is upgradeable and fetches the versions available to upgrade to in an user-friendly way.
@@ -326,7 +326,7 @@ To upgrade the cluster with CoreDNS as the default internal DNS, invoke `kubeadm
 - Creates new certificate and key files of apiserver and backs up old files if they're about to expire in 180 days.

 --->
-                       
+
 升级具有默认内部的 DNS 的 coreDNS 集群，调用具有 `--feature-gates=CoreDNS=true` 标记的 `kubeadm upgrade apply`。
 `kubeadm upgrade apply`按照如下进行：

@@ -345,14 +345,14 @@ To upgrade the cluster with CoreDNS as the default internal DNS, invoke `kubeadm

   Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow.
   Check the [addons](/docs/concepts/cluster-administration/addons/) page to find your CNI provider and see if there are additional      upgrade steps necessary.
-                                            
+
 --->

 4. 手动升级定义网络（SDN）的软件

   容器网络接口（CNI）提供者具有升级说明指导。
   检查这个[插件](/docs/concepts/cluster-administration/addons/)页面来找到 CNI 提供者和查看是否需要额外的升级步骤。
-                                                     
+
 <!--

 ## Upgrading your master and node packages
@@ -381,7 +381,7 @@ When running this command against the master host, this error is expected and ca
 node "master" already cordoned
 error: pods not managed by ReplicationController, ReplicaSet, Job, DaemonSet or StatefulSet (use --force to override): etcd-kubeadm, kube-apiserver-kubeadm, kube-controller-manager-kubeadm, kube-scheduler-kubeadm
 ```
-<!-- 
+<!--

 2. Upgrade the Kubernetes package versions on the `$HOST` node by using a Linux distribution-specific package manager:

@@ -265,7 +265,7 @@ Here are two of the restrictions that a resource quota imposes on a namespace:
 -->

 * 运行在命名空间中的每个容器必须有自己的内存限制。
-* 命名空间中所有容器的内存使用量之和不能超过声明的限制值。 
+* 命名空间中所有容器的内存使用量之和不能超过声明的限制值。

 <!--
 If a Container does not specify its own memory limit, it is given the default limit, and then
@@ -65,16 +65,16 @@ weight: 10
    ```

    Calico 的 pods 名以 `calico` 打头，检查确认每个 pods 状态为 `Running`。
-<!-- 
+<!--
 ## Creating a local Calico cluster with kubeadm

-To get a local single-host Calico cluster in fifteen minutes using kubeadm, refer to the 
+To get a local single-host Calico cluster in fifteen minutes using kubeadm, refer to the
 [Calico Quickstart](https://docs.projectcalico.org/latest/getting-started/kubernetes/).
 -->

 ## 使用 kubeadm 创建一个本地 Calico 集群

-在15分钟内使用 kubeadm 得到一个本地单主机 Calico 集群，请参考 
+在15分钟内使用 kubeadm 得到一个本地单主机 Calico 集群，请参考
 [Calico 快速入门](https://docs.projectcalico.org/latest/getting-started/kubernetes/)。

 {{% /capture %}}
@@ -24,7 +24,7 @@ For background on Cilium, read the [Introduction to Cilium](https://cilium.readt
 {{% /capture %}}

 {{% capture steps %}}
-<!-- 
+<!--
 ## Deploying Cilium on Minikube for Basic Testing

 To get familiar with Cilium easily you can follow the
@@ -51,14 +51,14 @@ clusterrolebinding "cilium" created
 daemonset "cilium" created
 clusterrole "cilium" created
 ```
-<!-- 
+<!--
 The remainder of the Getting Started Guide explains how to enforce both L3/L4
 (i.e., IP address + port) security policies, as well as L7 (e.g., HTTP) security
 policies using an example application.
 -->
 入门指南其余的部分用一个示例应用说明了如何强制执行L3/L4（即 IP 地址+端口）的安全策略以及L7 （如 HTTP）的安全策略。

-<!-- 
+<!--
 ## Deploying Cilium for Production Use

 For detailed instructions around deploying Cilium for production, see:
@@ -74,7 +74,7 @@ production DaemonSet files.
 {{% /capture %}}

 {{% capture discussion %}}
-<!-- 
+<!--
 ##  Understanding Cilium components

 Deploying a cluster with Cilium adds Pods to the `kube-system` namespace. To see
@@ -96,7 +96,7 @@ NAME            DESIRED   CURRENT   READY     NODE-SELECTOR   AGE
 cilium          1         1         1         <none>          2m
 ...
 ```
-<!-- 
+<!--
 There are two main components to be aware of:

 - One `cilium` Pod runs on each node in your cluster and enforces network policy
@@ -113,7 +113,7 @@ configuration because it automatically connects to the minikube's etcd instance.
 - 在集群中的每个节点上都会运行一个 `cilium` Pod，并利用Linux BPF执行网络策略管理该节点上进出 Pod 的流量。
 - 对于生产部署，Cilium 应该复用 Kubernetes 所使用的键值存储集群（如 etcd），其通常在Kubernetes 的 master 节点上运行。
 [Cilium Kubernetes安装指南](https://cilium.readthedocs.io/en/latest/kubernetes/install/)
-包括了一个示例 DaemonSet，可以自定义指定此键值存储集群。 
+包括了一个示例 DaemonSet，可以自定义指定此键值存储集群。
 简单的 minikube 的“一体化” DaemonSet 不需要这样的配置，因为它会自动连接到 minikube 的 etcd 实例。

 {{% /capture %}}
@@ -21,7 +21,7 @@ weight: 40
 {{% /capture %}}

 {{% capture steps %}}
-<!-- 
+<!--
 ## Installing Romana with kubeadm

 Follow the [containerized installation guide](https://github.com/romana/romana/tree/master/containerize) for kubeadm.
@@ -49,7 +49,7 @@ To apply network policies use one of the following:
 {{% /capture %}}

 {{% capture whatsnext %}}
-<!-- 
+<!--
 Once you have installed Romana, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
 -->
 Romana 安装完成后，您可以按照[声明 Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)去尝试使用 Kubernetes NetworkPolicy。
@@ -15,14 +15,14 @@ weight: 50
 {{% /capture %}}

 {{% capture prerequisites %}}
-<!-- 
+<!--
 You need to have a Kubernetes cluster. Follow the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/) to bootstrap one.
 -->
 您需要拥有一个 Kubernetes 集群。按照[kubeadm 入门指南](/docs/getting-started-guides/kubeadm/)来引导一个。
 {{% /capture %}}

 {{% capture steps %}}
-<!-- 
+<!--
 ## Install the Weave Net addon

 Follow the [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kube-addon/) guide.
@@ -34,7 +34,7 @@ The Weave Net addon for Kubernetes comes with a [Network Policy Controller](http
 按照[通过插件集成Kubernetes](https://www.weave.works/docs/net/latest/kube-addon/)指南。

 Kubernetes 的 Weave Net 插件带有[网络策略控制器](https://www.weave.works/docs/net/latest/kube-addon/#npc)，可自动监控 Kubernetes 所有名称空间中的任何 NetworkPolicy 注释。 配置`iptables`规则以允许或阻止策略指示的流量。
-<!-- 
+<!--
 ## Test the installation

 Verify that the weave works.
@@ -69,7 +69,7 @@ weave-net-pmw8w                         2/2       Running   0          9d
 {{% /capture %}}

 {{% capture whatsnext %}}
-<!-- 
+<!--
 Once you have installed the Weave Net addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. If you have any question, contact us at [#weave-community on Slack or Weave User Group](https://github.com/weaveworks/weave#getting-help).
 -->

@@ -9,8 +9,8 @@ spec:
    resources:
      limits:
        memory: "1Gi"
-        cpu: "800m"      
+        cpu: "800m"
      requests:
        memory: "700Mi"
        cpu: "400m"
-      
+
@@ -9,8 +9,8 @@ spec:
    resources:
      limits:
        memory: "800Mi"
-        cpu: "800m" 
+        cpu: "800m"
      requests:
        memory: "600Mi"
        cpu: "400m"
-      
+
@@ -44,7 +44,7 @@ Kubernetes 将发送一个 preStop 事件。
 In this exercise, you create a Pod that has one Container. The Container has handlers
 for the postStart and preStop events.
 -->
-在本练习中，你将创建一个包含一个容器的 Pod，该容器为 postStart 和 preStop 事件提供对应的处理函数。 
+在本练习中，你将创建一个包含一个容器的 Pod，该容器为 postStart 和 preStop 事件提供对应的处理函数。

 <!--
 Here is the configuration file for the Pod:
@@ -133,7 +133,7 @@ Kubernetes 在容器结束前立即发送 preStop 事件。除非 Pod 宽限期
 <!--
 {{< note >}}
 Kubernetes only sends the preStop event when a Pod is *terminated*.
-This means that the preStop hook is not invoked when the Pod is *completed*. 
+This means that the preStop hook is not invoked when the Pod is *completed*.
 This limitation is tracked in [issue #55087](https://github.com/kubernetes/kubernetes/issues/55807).
 {{< /note >}}
 -->
@@ -6,6 +6,6 @@ spec:
  hard:
    pods: "4"
    requests.cpu: "1"
-    requests.memory: 1Gi 
+    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi
@@ -1,7 +1,7 @@
 apiVersion: v1
 kind: Pod
 metadata:
-  name: security-context-demo-2 
+  name: security-context-demo-2
 spec:
  securityContext:
    runAsUser: 1000
@@ -1,7 +1,7 @@
 apiVersion: v1
 kind: Pod
 metadata:
-  name: security-context-demo  
+  name: security-context-demo
 spec:
  securityContext:
    runAsUser: 1000
@@ -123,7 +123,7 @@ A policy with no (0) rules is treated as illegal.

 Below is an example audit policy file:
 -->
-您可以使用 `--audit-policy-file` 标志将包含策略的文件传递给 [kube-apiserver][kube-apiserver]。如果不设置该标志，则不记录事件。 
+您可以使用 `--audit-policy-file` 标志将包含策略的文件传递给 [kube-apiserver][kube-apiserver]。如果不设置该标志，则不记录事件。
 注意 `rules` 字段 __必须__ 在审计策略文件中提供。没有（0）规则的策略将被视为非法配置。

 以下是一个审计策略文件的示例：
@@ -529,7 +529,7 @@ plugin which supports full-text search and analytics.
 <!--
 ## Legacy Audit

-__Note:__ Legacy Audit is deprecated and is disabled by default since 1.8 and 
+__Note:__ Legacy Audit is deprecated and is disabled by default since 1.8 and
 will be removed in 1.12. To fallback to this legacy audit, disable the advanced
 auditing feature using the `AdvancedAuditing` feature gate in [kube-apiserver][kube-apiserver]:
 -->
@@ -29,24 +29,24 @@ $ kubectl describe pods ${POD_NAME}

 #### pod停留在pending状态

-如果一个pod卡在`Pending`状态，则表示这个pod没有被调度到一个节点上。通常这是因为资源不足引起的。  
-敲一下`kubectl describe ...`这个命令，输出的信息里面应该有显示为什么没被调度的原因。  
+如果一个pod卡在`Pending`状态，则表示这个pod没有被调度到一个节点上。通常这是因为资源不足引起的。
+敲一下`kubectl describe ...`这个命令，输出的信息里面应该有显示为什么没被调度的原因。
 常见原因如下：

-* **资源不足**:  
+* **资源不足**:
 你可能耗尽了集群上所有的CPU和内存，此时，你需要删除pods，调整资源请求，或者增加节点。
 更多信息请参阅[Compute Resources document](/docs/user-guide/compute-resources/#my-pods-are-pending-with-event-message-failedscheduling)

 * **使用了`hostPort`**:
-如果绑定一个pod到`hostPort`，那么能创建的pod个数就有限了。  
-多数情况下，`hostPort`是非必要的，而应该采用服务来暴露pod。  
+如果绑定一个pod到`hostPort`，那么能创建的pod个数就有限了。
+多数情况下，`hostPort`是非必要的，而应该采用服务来暴露pod。
 如果确实需要使用`hostPort`，那么能创建的pod的数量就是节点的个数。


 #### pod停留在waiting状态

-如果一个pod卡在`Waiting`状态，则表示这个pod已经调试到节点上，但是没有运行起来。  
-再次敲一下`kubectl describe ...`这个命令来查看相关信息。  
+如果一个pod卡在`Waiting`状态，则表示这个pod已经调试到节点上，但是没有运行起来。
+再次敲一下`kubectl describe ...`这个命令来查看相关信息。
 最常见的原因是拉取镜像失败。可以通过以下三种方式来检查：

 * 使用的镜像名字正确吗？
@@ -81,20 +81,20 @@ $ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${
 $ kubectl exec cassandra -- cat /var/log/cassandra/system.log
 ```

-如果以上方法都不起作用，找到这个pod所在的节点并用SSH登录进去做进一步的分析。  
-通常情况下，是不需要在Kubernetes API中再给出另外的工具的。  
+如果以上方法都不起作用，找到这个pod所在的节点并用SSH登录进去做进一步的分析。
+通常情况下，是不需要在Kubernetes API中再给出另外的工具的。
 因此，如果你发现需要ssh进一个主机来分析问题时，请在GitHub上提一个特性请求，描述一个你的场景并说明为什么已经提供的工具不能满足需求。


 #### pod处于running态，但是没有正常工作

-如果创建的pod不符合预期，那么创建pod的描述文件应该是存在某种错误的，并且这个错误在创建pod时被忽略掉。  
-通常pod的定义中，章节被错误的嵌套，或者一个字段名字被写错，都可能会引起被忽略掉。  
-例如，希望在pod中用命令行执行某个命令，但是将`command`写成`commnd`，pod虽然可以创建，但命令并没有执行。  
+如果创建的pod不符合预期，那么创建pod的描述文件应该是存在某种错误的，并且这个错误在创建pod时被忽略掉。
+通常pod的定义中，章节被错误的嵌套，或者一个字段名字被写错，都可能会引起被忽略掉。
+例如，希望在pod中用命令行执行某个命令，但是将`command`写成`commnd`，pod虽然可以创建，但命令并没有执行。

-如何查出来哪里出错？  
-首先，删掉这个pod再重新创建一个，重创时，像下面这样带着`--validate`这个参数：  
-`kubectl create --validate -f mypod.yaml`，`command`写成`commnd`的拼写错误就会打印出来了。  
+如何查出来哪里出错？
+首先，删掉这个pod再重新创建一个，重创时，像下面这样带着`--validate`这个参数：
+`kubectl create --validate -f mypod.yaml`，`command`写成`commnd`的拼写错误就会打印出来了。

 ```shell
 I0805 10:43:25.129850   46757 schema.go:126] unknown field: commnd
@@ -104,13 +104,13 @@ pods/mypod

 <!-- TODO: Now that #11914 is merged, this advice may need to be updated -->

-如果上面方法没有看到相关异常的信息，那么接下来就要验证从apiserver获取到的pod是否与期望的一致，比如创建Pod的yaml文件是mypod.yaml。  
+如果上面方法没有看到相关异常的信息，那么接下来就要验证从apiserver获取到的pod是否与期望的一致，比如创建Pod的yaml文件是mypod.yaml。

-运行如下命令来获取apiserver创建的pod信息并保存成一个文件：  
+运行如下命令来获取apiserver创建的pod信息并保存成一个文件：
 `kubectl get pods/mypod -o yaml > mypod-on-apiserver.yaml`。

-然后手动对这两个文件进行比较:  
-apiserver获得的yaml文件中的一些行，不在创建pod的yaml文件内，这是正常的。  
+然后手动对这两个文件进行比较:
+apiserver获得的yaml文件中的一些行，不在创建pod的yaml文件内，这是正常的。
 如果创建Pod的yaml文件内的一些行，在piserver获得的yaml文件中不存在，可以说明创建pod的yaml中的定义有问题。


@@ -122,7 +122,7 @@ RC相当简单。他们要么能创建pod，要么不能。如果不能创建pod

 ### Debugging Services

-服务提供了多个Pod之间的负载均衡功能。  
+服务提供了多个Pod之间的负载均衡功能。
 有一些常见的问题可以造成服务无法正常工作。以下说明将有助于调试服务的问题。

 首先，验证服务是否有端点。对于每一个Service对像，apiserver使`endpoints`资源可用。
@@ -133,12 +133,12 @@ RC相当简单。他们要么能创建pod，要么不能。如果不能创建pod
 $ kubectl get endpoints ${SERVICE_NAME}
 ```

-确保endpoints与服务内容器个数一致。  
+确保endpoints与服务内容器个数一致。
 例如，如果你创建了一个nginx服务，它有3个副本，那么你就会在这个服务的endpoints中看到3个不同的IP地址。

 #### 服务缺少endpoints

-如果缺少endpoints，请尝试使用服务的labels列出所有的pod。  
+如果缺少endpoints，请尝试使用服务的labels列出所有的pod。
 假如有一个服务，有如下的label：

 ```yaml
@@ -155,7 +155,7 @@ spec:
 $ kubectl get pods --selector=name=nginx,type=frontend
 ```

-如果pod列表附合预期，但是endpoints仍然为空，那么可能没有暴露出正确的端口。  
+如果pod列表附合预期，但是endpoints仍然为空，那么可能没有暴露出正确的端口。
 如果服务指定了`containerPort`，但是列表中的Pod没有列出该端口，则不会将其添加到端口列表。

 验证该pod的`containerPort`与服务的`containerPort`是否匹配。
@@ -2,7 +2,7 @@
 title: 集群故障排查
 ---

-本篇文档是介绍集群故障排查的；我们假设对于你碰到的问题，你已经排除了是由应用程序造成的。  
+本篇文档是介绍集群故障排查的；我们假设对于你碰到的问题，你已经排除了是由应用程序造成的。
 对于应用的调试，请参阅[应用故障排查指南](/cn/docs/tasks/debug-application-cluster/debug-application)。
 你也可以访问[troubleshooting document](/docs/troubleshooting/)来获取更多的信息。

@@ -20,7 +20,7 @@ kubectl get nodes

 ## 查看logs

-现在，挖掘出集群更深层的信息就需要登录到相关的机器上。下面是相关log文件所在的位置。  
+现在，挖掘出集群更深层的信息就需要登录到相关的机器上。下面是相关log文件所在的位置。
 (注意，对于基于systemd的系统，你可能需要使用`journalctl`)


@@ -58,7 +58,7 @@ kubectl get nodes
      - apiserver应该不能起来
      - kubelets将不能访问它，但是能够继续运行之前的Pods和提供相同的服务代理
      - 在apiserver重启之前，需要手动恢复或者重创apiserver的状态
-	    
+	
  - Kubernetes服务组件(节点控制器，副本控制器，调度器等等)所在的VM关机或者崩溃
    - 当前，这些控制器是和apiserver共存的，它们不可用的现象是与apiserver类似的
    - 将来，这些控制器也会复制为多份，并且可能为非共存的
@@ -56,7 +56,7 @@ content_template: templates/task
    ```

    日志中显示了HOSTNAME 与KUBERNETES_PORT 这两个环境变量的值：
-    
+
    ```
    command-demo
    tcp://10.3.240.1:443
@@ -81,7 +81,7 @@ args: ["$(MESSAGE)"]
 [Secrets](/docs/concepts/configuration/secret/).

 {{< note >}}
-**注意：** 环境变量需要加上括号，类似于`"$(VAR)"`。这是在`command` 
+**注意：** 环境变量需要加上括号，类似于`"$(VAR)"`。这是在`command`
 或 `args`字段使用变量的格式要求。
 {{< /note >}}

@@ -38,7 +38,7 @@ base-64 形式的密码为 `Mzk1MjgkdmRnN0pi`。

    ```shell
    kubectl create -f https://k8s.io/examples/pods/inject/secret.yaml
-    ```  
+    ```

    {{< note >}}
    **注意：** 如果想要跳过 Base64 编码的步骤，可以使用 `kubectl create secret` 命令来创建 Secret：
@@ -105,7 +105,7 @@ base-64 形式的密码为 `Mzk1MjgkdmRnN0pi`。
    ```
 											
 1. 在 Pod 中运行的容器中获取一个 shell：
-       
+
    ```shell
    kubectl exec -it secret-test-pod -- /bin/bash
    ```
@@ -117,7 +117,7 @@ base-64 形式的密码为 `Mzk1MjgkdmRnN0pi`。
    root@secret-test-pod:/# cd /etc/secret-volume
    ```
 1. 在 shell 中，列出 `/etc/secret-volume` 目录的文件：
- 
+
    ```shell
    root@secret-test-pod:/etc/secret-volume# ls
    ```
@@ -154,26 +154,26 @@ base-64 形式的密码为 `Mzk1MjgkdmRnN0pi`。
    ```

 1. 确认 Pod 正在运行：
- 
+
    ```shell
    kubectl get pod secret-envars-test-pod
    ```

    输出：
-        
+
    ```shell
    NAME                     READY     STATUS    RESTARTS   AGE
    secret-envars-test-pod   1/1       Running   0          4m
    ```

 1. 在 Pod 中运行的容器中获取一个 shell：
-       
+
    ```shell
    kubectl exec -it secret-envars-test-pod -- /bin/bash
    ```

 1. 在 shell 中，显示环境变量：
-        
+
    ```shell
    root@secret-envars-test-pod:/# printenv
    ```
@@ -40,7 +40,7 @@ content_template: templates/task
 第二个元素指示Pod的`annotations`字段的值保存在名为`annotations`的文件中。

 {{< note >}}
-**注意:** 本示例中的字段是Pod字段，不是Pod中容器的字段。 
+**注意:** 本示例中的字段是Pod字段，不是Pod中容器的字段。
 {{< /note >}}

 创建 Pod：
@@ -4,7 +4,7 @@ approvers:
 title: 使用 PodPreset 将信息注入 Pods
 ---

-在 pod 创建时，用户可以使用 `podpreset` 对象将 secrets、卷挂载和环境变量等信息注入其中。 
+在 pod 创建时，用户可以使用 `podpreset` 对象将 secrets、卷挂载和环境变量等信息注入其中。
 本文展示了一些 `PodPreset` 资源使用的示例。
 用户可以从[理解 Pod Presets](/docs/concepts/workloads/pods/podpreset/) 中了解 PodPresets 的整体情况。

@@ -209,9 +209,9 @@ A cron job config also needs a [`.spec` section](https://git.k8s.io/community/co

 CronJob 配置也需要包括[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).

-{{< note >}} 
+{{< note >}}
 <!--
-All modifications to a cron job, especially its `.spec`, are applied only to the following runs. 
+All modifications to a cron job, especially its `.spec`, are applied only to the following runs.
 -->
 对 CronJob 的所有改动，特别是它的 `.spec`，只会影响将来的运行实例。
 {{< /note >}}
@@ -291,7 +291,7 @@ That means 120 schedules were missed, so the cron job is no longer scheduled. If
 field is set (not null), the CronJob controller counts how many missed jobs occurred from the value of
 `.spec.startingDeadlineSeconds` until now. For example, if it is set to `200`, it counts how many missed
 schedules occurred in the last 200 seconds. In that case, if there were more than 100 missed schedules in the
-last 200 seconds, the cron job is no longer scheduled. 
+last 200 seconds, the cron job is no longer scheduled.
 -->

 CronJob 控制器会统计错过了多少次调度。如果错过了100次以上的调度，CronJob 就不再调度了。当没有设置 `.spec.startingDeadlineSeconds` 时，CronJob 控制器统计从`status.lastScheduleTime`到当前的调度错过次数。
@@ -85,7 +85,7 @@ See the [Redis Example](https://github.com/kubernetes/examples/tree/master/guest
 of deploying Redis scalably and redundantly.
 -->
 对于这个例子，为了简单起见，我们将启动一个单实例的 Redis。
-了解如何部署一个可伸缩、高可用的 Redis 例子，请查看 [Redis 样例](https://github.com/kubernetes/examples/tree/master/guestbook) 
+了解如何部署一个可伸缩、高可用的 Redis 例子，请查看 [Redis 样例](https://github.com/kubernetes/examples/tree/master/guestbook)

 <!--
 If you are working from the website source tree, you can go to the following
@@ -44,7 +44,7 @@ REVISION        CHANGE-CAUSE
 ...
 ```

-* 在创建时，DaemonSet 的变化原因从 `kubernetes.io/change-cause` 注解（annotation）复制到其版本中。 用户可以在 `kubectl` 中指定 `--record=true` ，将执行的命令记录在变化原因注解中。 
+* 在创建时，DaemonSet 的变化原因从 `kubernetes.io/change-cause` 注解（annotation）复制到其版本中。 用户可以在 `kubectl` 中指定 `--record=true` ，将执行的命令记录在变化原因注解中。

 执行以下命令，来查看指定版本的详细信息：

@@ -88,8 +88,8 @@ daemonset "<daemonset-name>" rolled back

 执行以下命令，来观察 DaemonSet 回滚进度：

-```shell 
-kubectl rollout status ds/<daemonset-name> 
+```shell
+kubectl rollout status ds/<daemonset-name>
 ```

 回滚完成时，输出形如：
@@ -35,22 +35,22 @@ Kubernetes 提供对分布在节点上的 NVIDIA GPU 进行管理的**实验**

 ```yaml
 apiVersion: v1
-kind: Pod 
+kind: Pod
 metadata:
  name: gpu-pod
-spec: 
-  containers: 
-    - 
+spec:
+  containers:
+    -
      name: gpu-container-1
      image: k8s.gcr.io/pause:2.0
-      resources: 
-        limits: 
+      resources:
+        limits:
          alpha.kubernetes.io/nvidia-gpu: 2 # requesting 2 GPUs
    -
      name: gpu-container-2
      image: k8s.gcr.io/pause:2.0
-      resources: 
-        limits: 
+      resources:
+        limits:
          alpha.kubernetes.io/nvidia-gpu: 3 # requesting 3 GPUs
 ```

@@ -55,7 +55,7 @@ kubectl delete service <service-name>
 ```

 <!--
-Deleting a StatefulSet through kubectl will scale it down to 0, thereby deleting all pods that are a part of it. 
+Deleting a StatefulSet through kubectl will scale it down to 0, thereby deleting all pods that are a part of it.
 If you want to delete just the StatefulSet and not the pods, use `--cascade=false`.
 --->
 通过 kubectl 删除 StatefulSet 会将其缩容为0，因此删除属于它的所有pods。
@@ -141,7 +141,7 @@ my-nginx-o0ef1                                    1/1       Running   0
 my-nginx-q6all                                    1/1       Running   0          8m        2d1d7a8f682934a254002b56404b813e
 ```

-使用`kubectl rolling-update`可以实时看到更新的进度： 
+使用`kubectl rolling-update`可以实时看到更新的进度：

 ```
 Scaling up my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 from 0 to 3, scaling down my-nginx from 3 to 0 (keep 3 pods available, don't exceed 4 pods)
@@ -22,12 +22,12 @@ content_template: templates/task

 ## 概述

-Kubelet 使用证书进行 Kubernetes API 的认证。 
+Kubelet 使用证书进行 Kubernetes API 的认证。
 默认情况下，这些证书的签发期限为一年，所以不需要太频繁地进行更新。

 Kubernetes 1.8 版本中包含 beta 特性 [kubelet 证书轮换](/docs/tasks/administer-cluster/certificate-rotation/)，
 在当前证书即将过期时，
-将自动生成新的秘钥，并从 Kubernetes API 申请新的证书。 一旦新的证书可用，它将被用于与 
+将自动生成新的秘钥，并从 Kubernetes API 申请新的证书。 一旦新的证书可用，它将被用于与
 Kubernetes API 间的连接认证。

 ## 启用客户端证书轮换
@@ -57,7 +57,7 @@ Kubelet 会从 Kubernetes API 取回签署的证书，并将其写入磁盘，

 当签署的证书即将到期时，kubelet 会使用 Kubernetes API，发起新的证书签名请求。
 同样地，控制器管理器会自动批准证书请求，并将签署的证书附加到证书签名请求中。 Kubelet
-会从 Kubernetes API 取回签署的证书，并将其写入磁盘。 然后它会更新与 Kubernetes API 
+会从 Kubernetes API 取回签署的证书，并将其写入磁盘。 然后它会更新与 Kubernetes API
 的连接，使用新的证书重新连接到 Kubernetes API。

 {{% /capture %}}