[zh-cn] Resync apparmor.md

content/zh-cn/docs/tutorials/security/apparmor.md

@@ -4,6 +4,8 @@ content_type: tutorial
 weight: 10
 ---
 <!--
+reviewers:
+- stclair
 title: Restrict a Container's Access to Resources with AppArmor
 content_type: tutorial
 weight: 10
@@ -61,7 +63,9 @@ AppArmor 可以通过限制允许容器执行的操作，
 
 ## {{% heading "prerequisites" %}}
 
-<!-- Make sure: -->
+<!--
+Make sure:
+-->
 确保：
 
 <!--
@@ -201,7 +205,9 @@ gke-test-default-pool-239f5d02-xwux: kubelet is posting ready status. AppArmor e
 
 <!-- lessoncontent -->
 
-<!-- ## Securing a Pod -->
+<!--
+## Securing a Pod
+-->
 ## 保护 Pod {#securing-a-pod}
 
 {{< note >}}
@@ -245,7 +251,7 @@ specifies the profile to apply. The `profile_ref` can be one of:
 <!--
 See the [API Reference](#api-reference) for the full details on the annotation and profile name formats.
 -->
-有关注解和配置文件名称格式的详细信息，请参阅[API 参考](#api-reference)。
+有关注解和配置文件名称格式的详细信息，请参阅 [API 参考](#api-reference)。
 
 <!--
 Kubernetes AppArmor enforcement works by first checking that all the prerequisites have been
@@ -280,11 +286,15 @@ kubectl exec <pod_name> cat /proc/1/attr/current
 k8s-apparmor-example-deny-write (enforce)
 ```
 
-<!-- ## Example -->
+<!--
+## Example
+-->
 ## 举例 {#example}
 
-<!-- *This example assumes you have already set up a cluster with AppArmor support.* -->
+<!--
-*本例假设你已经设置了一个集群使用 AppArmor 支持。*
+*This example assumes you have already set up a cluster with AppArmor support.*
+-->
+**本例假设你已经设置了一个集群使用 AppArmor 支持。**
 
 <!--
 First, we need to load the profile we want to use onto our nodes. This profile denies all file writes:
@@ -334,7 +344,9 @@ EOF'
 done
 ```
 
-<!-- Next, we'll run a simple "Hello AppArmor" pod with the deny-write profile: -->
+<!--
+Next, we'll run a simple "Hello AppArmor" pod with the deny-write profile:
+-->
 接下来，我们将运行一个带有拒绝写入配置文件的简单 “Hello AppArmor” Pod：
 
 {{< codenew file="pods/security/hello-apparmor.yaml" >}}
@@ -361,7 +373,9 @@ kubectl get events | grep hello-apparmor
 13s        13s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Started     {kubelet gke-test-default-pool-239f5d02-gyn2}   Started container with docker id 06b6cd1c0989
 ```
 
-<!-- We can verify that the container is actually running with that profile by checking its proc attr: -->
+<!--
+We can verify that the container is actually running with that profile by checking its proc attr:
+-->
 我们可以通过检查该配置文件的 proc attr 来验证容器是否实际使用该配置文件运行：
 
 ```shell
@@ -371,7 +385,9 @@ kubectl exec hello-apparmor -- cat /proc/1/attr/current
 k8s-apparmor-example-deny-write (enforce)
 ```
 
-<!-- Finally, we can see what happens if we try to violate the profile by writing to a file: -->
+<!--
+Finally, we can see what happens if we try to violate the profile by writing to a file:
+-->
 最后，我们可以看到，如果我们尝试通过写入文件来违反配置文件会发生什么：
 
 ```shell
@@ -382,7 +398,9 @@ touch: /tmp/test: Permission denied
 error: error executing remote command: command terminated with non-zero exit code: Error executing in Docker Container: 1
 ```
 
-<!-- To wrap up, let's look at what happens if we try to specify a profile that hasn't been loaded: -->
+<!--
+To wrap up, let's look at what happens if we try to specify a profile that hasn't been loaded:
+-->
 最后，让我们看看如果我们试图指定一个尚未加载的配置文件会发生什么：
 
 ```shell
@@ -464,10 +482,14 @@ Note the pod status is Pending, with a helpful error message: `Pod Cannot enforc
 `Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded`。
 还用相同的消息记录了一个事件。
 
-<!-- ## Administration -->
+<!--
+## Administration
+-->
 ## 管理 {#administration}
 
-<!-- ### Setting up nodes with profiles -->
+<!--
+### Setting up nodes with profiles
+-->
 ### 使用配置文件设置节点 {#setting-up-nodes-with-profiles}
 
 <!--
@@ -496,15 +518,17 @@ Kubernetes 目前不提供任何本地机制来将 AppArmor 配置文件加载
 The scheduler is not aware of which profiles are loaded onto which node, so the full set of profiles
 must be loaded onto every node.  An alternative approach is to add a node label for each profile (or
 class of profiles) on the node, and use a
-[node selector](/docs/concepts/configuration/assign-pod-node/) to ensure the Pod is run on a
+[node selector](/docs/concepts/scheduling-eviction/assign-pod-node/) to ensure the Pod is run on a
 node with the required profile.
 -->
 调度程序不知道哪些配置文件加载到哪个节点上，因此必须将全套配置文件加载到每个节点上。
 另一种方法是为节点上的每个配置文件（或配置文件类）添加节点标签，
-并使用[节点选择器](/zh-cn/docs/concepts/configuration/assign-pod-node/)确保
+并使用[节点选择器](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/)确保
 Pod 在具有所需配置文件的节点上运行。
 
-<!-- ### Restricting profiles with the PodSecurityPolicy -->
+<!--
+### Restricting profiles with the PodSecurityPolicy
+-->
 ### 使用 PodSecurityPolicy 限制配置文件 {#restricting-profiles-with-the-podsecuritypolicy}
 
 {{< note >}}
@@ -527,7 +551,9 @@ enable the PodSecurityPolicy, the following flag must be set on the `apiserver`:
 --enable-admission-plugins=PodSecurityPolicy[,others...]
 ```
 
-<!-- The AppArmor options can be specified as annotations on the PodSecurityPolicy: -->
+<!--
+The AppArmor options can be specified as annotations on the PodSecurityPolicy:
+-->
 AppArmor 选项可以指定为 PodSecurityPolicy 上的注解：
 
 ```yaml
@@ -547,10 +573,14 @@ specification.
 如果同时提供了这两个选项，则必须允许默认值。
 配置文件的指定格式与容器上的相同。有关完整规范，请参阅 [API 参考](#api-reference)。
 
-<!-- ### Disabling AppArmor -->
+<!--
+### Disabling AppArmor
+-->
 ### 禁用 AppArmor {#disabling-apparmor}
 
-<!-- If you do not want AppArmor to be available on your cluster, it can be disabled by a command-line flag: -->
+<!--
+If you do not want AppArmor to be available on your cluster, it can be disabled by a command-line flag:
+-->
 如果你不希望 AppArmor 在集群上可用，可以通过命令行标志禁用它：
 
 ```
@@ -575,7 +605,9 @@ availability (GA).
 {{</note>}}
 
 
-<!-- ## Authoring Profiles -->
+<!--
+## Authoring Profiles
+-->
 ## 编写配置文件 {#authoring-profiles}
 
 <!--
@@ -608,13 +640,19 @@ AppArmor 将详细消息记录到 `dmesg`，
 错误通常可以在系统日志中或通过 `journalctl` 找到。
 更多详细信息见 [AppArmor 失败](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures)。
 
-<!-- ## API Reference -->
+<!--
+## API Reference
+-->
 ## API 参考 {#api-reference}
 
-<!-- ### Pod Annotation -->
+<!--
+### Pod Annotation
+-->
 ### Pod 注解 {#pod-annotation}
 
-<!-- Specifying the profile a container will run with: -->
+<!--
+Specifying the profile a container will run with:
+-->
 指定容器将使用的配置文件：
 
 <!--
@@ -628,7 +666,9 @@ AppArmor 将详细消息记录到 `dmesg`，
   可以为 Pod 中的每个容器指定单独的配置文件。
 - **键值**: 对配置文件的引用，如下所述
 
-<!-- ### Profile Reference -->
+<!--
+### Profile Reference
+-->
 ### 配置文件引用 {#profile-reference}
 
 <!--
@@ -650,13 +690,19 @@ AppArmor 将详细消息记录到 `dmesg`，
   - 可能的配置文件名在[核心策略参考](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications)。
 - `unconfined`: 这相当于为容器禁用 AppArmor。
 
-<!-- Any other profile reference format is invalid. -->
+<!--
+Any other profile reference format is invalid.
+-->
 任何其他配置文件引用格式无效。
 
-<!-- ### PodSecurityPolicy Annotations -->
+<!--
+### PodSecurityPolicy Annotations
+-->
 ### PodSecurityPolicy 注解 {#podsecuritypolicy-annotations}
 
-<!-- Specifying the default profile to apply to containers when none is provided: -->
+<!--
+Specifying the default profile to apply to containers when none is provided:
+-->
 指定在未提供容器时应用于容器的默认配置文件：
 
 <!--
@@ -666,7 +712,9 @@ AppArmor 将详细消息记录到 `dmesg`，
 * **键名**: `apparmor.security.beta.kubernetes.io/defaultProfileName`
 * **键值**: 如上述文件参考所述
 
-<!-- Specifying the list of profiles Pod containers is allowed to specify: -->
+<!--
+Specifying the list of profiles Pod containers is allowed to specify:
+-->
 上面描述的指定配置文件，Pod 容器列表的配置文件引用允许指定：
 
 <!--
@@ -681,7 +729,9 @@ AppArmor 将详细消息记录到 `dmesg`，
 
 ## {{% heading "whatsnext" %}}
 
-<!-- Additional resources: -->
+<!--
+Additional resources:
+-->
 其他资源：
 
 <!--