Merge pull request #34238 from tengqm/zh-34221-concepts-1

[zh] Resync concepts page (concepts-1)

Author: k8s-ci-robot

content/zh-cn/docs/concepts/configuration/secret.md

@@ -447,11 +447,15 @@ You can still [manually create](/docs/tasks/configure-pod-container/configure-se
 a service account token Secret; for example, if you need a token that never expires.
 However, using the [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
 subresource to obtain a token to access the API is recommended instead.
+You can use the [`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-)
+command to obtain a token from the `TokenRequest` API.
 -->
 你仍然可以[手动创建](/zh/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token)
 服务账号令牌。例如，当你需要一个永远都不过期的令牌时。
 不过，仍然建议使用 [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
 子资源来获得访问 API 服务器的令牌。
+你可以使用 [`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-)
+命令调用 `TokenRequest` API 获得令牌。
 {{< /note >}}
 
 <!--
@@ -1446,26 +1450,61 @@ In this case, `0` means you have created an empty Secret.
 ### Service account token Secrets
 
 A `kubernetes.io/service-account-token` type of Secret is used to store a
-token that identifies a
+token credential that identifies a
 {{< glossary_tooltip text="service account" term_id="service-account" >}}.
+-->
+### 服务账号令牌 Secret  {#service-account-token-secrets}
+
+类型为 `kubernetes.io/service-account-token` 的 Secret
+用来存放标识某{{< glossary_tooltip text="服务账号" term_id="service-account" >}}的令牌凭据。
+
+<!--
+Since 1.22, this type of Secret is no longer used to mount credentials into Pods,
+and obtaining tokens via the [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
+API is recommended instead of using service account token Secret objects.
+Tokens obtained from the `TokenRequest` API are more secure than ones stored in Secret objects,
+because they have a bounded lifetime and are not readable by other API clients.
+You can use the [`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-)
+command to obtain a token from the `TokenRequest` API.
+-->
+从 v1.22 开始，这种类型的 Secret 不再被用来向 Pod 中加载凭据数据，
+建议通过 [TokenRequest](/zh-cn/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
+API 来获得令牌，而不是使用服务账号令牌 Secret 对象。
+通过 `TokenRequest` API 获得的令牌比保存在 Secret 对象中的令牌更加安全，
+因为这些令牌有着被限定的生命期，并且不会被其他 API 客户端读取。
+你可以使用 [`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-)
+命令调用 `TokenRequest` API 获得令牌。
+
+<!--
+You should only create a service account token Secret object
+if you can't use the `TokenRequest` API to obtain a token,
+and the security exposure of persisting a non-expiring token credential
+in a readable API object is acceptable to you.
+-->
+只有在你无法使用 `TokenRequest` API 来获取令牌，
+并且你能够接受因为将永不过期的令牌凭据写入到可读取的 API 对象而带来的安全风险时，
+才应该创建服务账号令牌 Secret 对象。
+
+<!--
 When using this Secret type, you need to ensure that the
 `kubernetes.io/service-account.name` annotation is set to an existing
-service account name. A Kubernetes
-{{< glossary_tooltip text="controller" term_id="controller" >}} fills in some
-other fields such as the `kubernetes.io/service-account.uid` annotation, and the
-`token` key in the `data` field, which is set to contain an authentication
-token.
+service account name. If you are creating both the ServiceAccount and
+the Secret objects, you should create the ServiceAccount object first.
+-->
+使用这种 Secret 类型时，你需要确保对象的注解 `kubernetes.io/service-account-name`
+被设置为某个已有的服务账号名称。
+如果你同时负责 ServiceAccount 和 Secret 对象的创建，应该先创建 ServiceAccount 对象。
+
+<!--
+
+After the Secret is created, a Kubernetes {{< glossary_tooltip text="controller" term_id="controller" >}}
+fills in some other fields such as the `kubernetes.io/service-account.uid` annotation, and the
+`token` key in the `data` field, which is set to contain an authentication token.
 
 The following example configuration declares a service account token Secret:
 -->
-### 服务账号令牌 Secret  {#service-account-token-secrets}
-
-类型为 `kubernetes.io/service-account-token` 的 Secret 用来存放标识某
-{{< glossary_tooltip text="服务账号" term_id="service-account" >}}的令牌。
-使用这种 Secret 类型时，你需要确保对象的注解 `kubernetes.io/service-account-name`
-被设置为某个已有的服务账号名称。某个 Kubernetes
-{{< glossary_tooltip text="控制器" term_id="controller" >}}会填写 Secret
-的其它字段，例如 `kubernetes.io/service-account.uid` 注解以及 `data` 字段中的
+当 Secret 对象被创建之后，某个 Kubernetes{{< glossary_tooltip text="控制器" term_id="controller" >}}会填写
+Secret 的其它字段，例如 `kubernetes.io/service-account.uid` 注解以及 `data` 字段中的
 `token` 键值，使之包含实际的令牌内容。
 
 下面的配置实例声明了一个服务账号令牌 Secret：
@@ -1498,34 +1537,23 @@ data:
 ```
 
 <!--
-When creating a `Pod`, Kubernetes automatically finds or creates a service account
-Secret and then automatically modifies your Pod to use this Secret. The service account
-token Secret contains credentials for accessing the Kubernetes API.
-
-The automatic creation and use of API credentials can be disabled or
-overridden if desired. However, if all you need to do is securely access the
-API server, this is the recommended workflow.
+After creating the Secret, wait for Kubernetes to populate the `token` key in the `data` field.
 -->
-Kubernetes 在创建 Pod 时会自动寻找或创建一个服务账号 Secret 并自动修改你的 Pod
-以使用该 Secret。该服务账号令牌 Secret 中包含了访问 Kubernetes API
-所需要的凭据。
-
-如果需要，可以禁止或者重载这种自动创建并使用 API 凭据的操作。
-不过，如果你仅仅是希望能够安全地访问 API 服务器，这是建议的工作方式。
+创建了 Secret 之后，等待 Kubernetes 在 `data` 字段中填充 `token` 主键。
 
 <!--
 See the [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/)
 documentation for more information on how service accounts work.  
 You can also check the `automountServiceAccountToken` field and the
 `serviceAccountName` field of the
 [`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
-for information on referencing service account from Pods.
+for information on referencing service account credentials from within Pods.
 -->
 参考 [ServiceAccount](/zh/docs/tasks/configure-pod-container/configure-service-account/)
 文档了解服务账号的工作原理。你也可以查看
 [`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
 资源中的 `automountServiceAccountToken` 和 `serviceAccountName` 字段文档，
-进一步了解从 Pod 中引用服务账号。
+进一步了解从 Pod 中引用服务账号凭据。
 
 <!--
 ### Docker config Secrets

content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -551,12 +551,11 @@ same zone currently running Pods with the `Security=S2` Pod label.
 并且节点具有标签 `topology.kubernetes.io/zone=R`，Pod 不能被调度到该节点上。
 
 <!--
-See the
-[design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
-for many more examples of Pod affinity and anti-affinity.
+To get yourself more familiar with the examples of Pod affinity and anti-affinity,
+refer to the [design proposal](https://github.com/kubernetes/design-proposals-archive/blob/main/scheduling/podaffinity.md).
 -->
-查阅[设计文档](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
-以了解 Pod 亲和性与反亲和性的更多示例。
+查阅[设计文档](https://github.com/kubernetes/design-proposals-archive/blob/main/scheduling/podaffinity.md)
+以进一步熟悉 Pod 亲和性与反亲和性的示例。
 
 <!--
 You can use the `In`, `NotIn`, `Exists` and `DoesNotExist` values in the

content/zh-cn/docs/concepts/scheduling-eviction/pod-overhead.md

@@ -151,10 +151,11 @@ map[cpu:250m memory:120Mi]
 ```
 
 <!--
-If a ResourceQuota is defined, the sum of container requests as well as the
+If a [ResourceQuota](/docs/concepts/policy/resource-quotas/) is defined, the sum of container requests as well as the
 `overhead` field are counted.
  -->
-如果定义了 ResourceQuata, 则容器请求的总量以及 `overhead` 字段都将计算在内。
+如果定义了 [ResourceQuata](/zh/docs/concepts/policy/resource-quotas/), 
+则容器请求的总量以及 `overhead` 字段都将计算在内。
 
 <!--
 When the kube-scheduler is deciding which node should run a new Pod, the scheduler considers that Pod's

content/zh-cn/docs/concepts/security/pod-security-standards.md

@@ -1,12 +1,16 @@
 ---
 title: Pod 安全性标准
+description: >
+  详细了解 Pod 安全性标准（Pod Security Standards）中所定义的不同策略级别。
 content_type: concept
 weight: 10
 ---
 <!--
 reviewers:
 - tallclair
 title: Pod Security Standards
+description: >
+  A detailed look at the different policy levels defined in the Pod Security Standards.
 content_type: concept
 weight: 10
 -->
@@ -49,18 +53,17 @@ Pod 安全性标准定义了三种不同的 _策略（Policy）_，以广泛覆
 **The _Privileged_ policy is purposely-open, and entirely unrestricted.** This type of policy is
 typically aimed at system- and infrastructure-level workloads managed by privileged, trusted users.
 
-The privileged policy is defined by an absence of restrictions. For allow-by-default enforcement
-mechanisms (such as gatekeeper), the privileged profile may be an absence of applied constraints
-rather than an instantiated policy. In contrast, for a deny-by-default mechanism (such as Pod
-Security Policy) the privileged policy should enable all controls (disable all restrictions).
+The Privileged policy is defined by an absence of restrictions. Allow-by-default
+mechanisms (such as gatekeeper) may be Privileged by default. In contrast, for a deny-by-default mechanism (such as Pod
+Security Policy) the Privileged policy should disable all restrictions.
 -->
 **_Privileged_ 策略是有目的地开放且完全无限制的策略。**
 此类策略通常针对由特权较高、受信任的用户所管理的系统级或基础设施级负载。
 
-Privileged 策略定义中限制较少。对于默认允许（Allow-by-default）实施机制（例如 gatekeeper），
-Privileged 框架可能意味着不应用任何约束而不是实施某策略实例。
-与此不同，对于默认拒绝（Deny-by-default）实施机制（如 Pod 安全策略）而言，
-Privileged 策略应该默认允许所有控制（即，禁止所有限制）。
+Privileged 策略定义中限制较少。默认允许的（Allow-by-default）实施机制（例如 gatekeeper）
+可以缺省设置为 Privileged。
+与此不同，对于默认拒绝（Deny-by-default）的实施机制（如 Pod 安全策略）而言，
+Privileged 策略应该禁止所有限制。
 
 ### Baseline
 
@@ -842,6 +845,22 @@ of individual policies are not defined here.
 - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
 - {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}}
 
+<!--
+### Alternatives
+-->
+### 替代方案   {#alternatives}
+
+{{% thirdparty-content %}}
+
+<!--
+Other alternatives for enforcing policies are being developed in the Kubernetes ecosystem, such as: 
+-->
+在 Kubernetes 生态系统中还在开发一些其他的替代方案，例如：
+
+- [Kubewarden](https://github.com/kubewarden)
+- [Kyverno](https://kyverno.io/policies/pod-security/)
+- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper)
+
 <!--
 ## FAQ
 
@@ -863,8 +882,8 @@ SIG Auth may reconsider this position in the future, should a clear need for oth
 这里定义的三种策略框架有一个明晰的线性递进关系，从最安全（Restricted）到最不安全，
 并且覆盖了很大范围的工作负载。特权要求超出 Baseline 策略者通常是特定于应用的需求，
 所以我们没有在这个范围内提供标准框架。
-这并不意味着在这样的情形下仍然只能使用 Privileged 框架，只是说处于这个范围的
-策略需要因地制宜地定义。
+这并不意味着在这样的情形下仍然只能使用 Privileged 框架，
+只是说处于这个范围的策略需要因地制宜地定义。
 
 SIG Auth 可能会在将来考虑这个范围的框架，前提是有对其他框架的需求。
 
@@ -878,31 +897,20 @@ in the Pod manifest, and represent parameters to the container runtime.
 ### 安全策略与安全上下文的区别是什么？
 
 [安全上下文](/zh/docs/tasks/configure-pod-container/security-context/)在运行时配置 Pod
-和容器。安全上下文是在 Pod 清单中作为 Pod 和容器规约的一部分来定义的，所代表的是
-传递给容器运行时的参数。
+和容器。安全上下文是在 Pod 清单中作为 Pod 和容器规约的一部分来定义的，
+所代表的是传递给容器运行时的参数。
 
 <!--
 Security profiles are control plane mechanisms to enforce specific settings in the Security Context,
 as well as other related parameters outside the Security Context. As of July 2021, 
 [Pod Security Policies](/docs/concepts/security/pod-security-policy/) are deprecated in favor of the
 built-in [Pod Security Admission Controller](/docs/concepts/security/pod-security-admission/). 
-
-Other alternatives for enforcing security profiles are being developed in the Kubernetes
-ecosystem, such as: 
-- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper).
-- [Kubewarden](https://github.com/kubewarden).
-- [Kyverno](https://kyverno.io/policies/pod-security/).
 -->
 安全策略则是控制面用来对安全上下文以及安全性上下文之外的参数实施某种设置的机制。
 在 2020 年 7 月，
 [Pod 安全性策略](/zh/docs/concepts/security/pod-security-policy/)已被废弃，
 取而代之的是内置的 [Pod 安全性准入控制器](/zh/docs/concepts/security/pod-security-admission/)。
 
-Kubernetes 生态系统中还在开发一些其他的替代方案，例如
-- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper)。
-- [Kubewarden](https://github.com/kubewarden)。
-- [Kyverno](https://kyverno.io/policies/pod-security/)。
-
 <!--
 ### What profiles should I apply to my Windows Pods?
 
@@ -914,27 +922,26 @@ such, no standardized Pod Security profiles currently exists.
 ### 我应该为我的 Windows Pod 实施哪种框架？
 
 Kubernetes 中的 Windows 负载与标准的基于 Linux 的负载相比有一些局限性和区别。
-尤其是 Pod SecurityContext 字段
-[对 Windows 不起作用](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。
+尤其是 Pod SecurityContext
+字段[对 Windows 不起作用](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。
 因此，目前没有对应的标准 Pod 安全性框架。
 
-
 <!-- 
 If you apply the restricted profile for a Windows pod, this **may** have an impact on the pod
 at runtime. The restricted profile requires enforcing Linux-specific restrictions (such as seccomp
 profile, and disallowing privilege escalation). If the kubelet and / or its container runtime ignore
 these Linux-specific values, then the Windows pod should still work normally within the restricted
 profile. However, the lack of enforcement means that there is no additional restriction, for Pods
 that use Windows containers, compared to the baseline profile.
-
-The use of the HostProcess flag to create a HostProcess pod should only be done in alignment with the privileged policy. Creation of a Windows HostProcess pod is blocked under the baseline and restricted policies, so any HostProcess pod should be considered privileged.
 -->
-
 如果你为一个 Windows Pod 应用了 Restricted 策略，**可能会** 对该 Pod 的运行时产生影响。
 Restricted 策略需要强制执行 Linux 特有的限制（如 seccomp Profile，并且禁止特权提升）。
 如果 kubelet 和/或其容器运行时忽略了 Linux 特有的值，那么应该不影响 Windows Pod 正常工作。
 然而，对于使用 Windows 容器的 Pod 来说，缺乏强制执行意味着相比于 Restricted 策略，没有任何额外的限制。
 
+<!--
+The use of the HostProcess flag to create a HostProcess pod should only be done in alignment with the privileged policy. Creation of a Windows HostProcess pod is blocked under the baseline and restricted policies, so any HostProcess pod should be considered privileged.
+-->
 你应该只在 Privileged 策略下使用 HostProcess 标志来创建 HostProcess Pod。
 在 Baseline 和 Restricted 策略下，创建 Windows HostProcess Pod 是被禁止的，
 因此任何 HostProcess Pod 都应该被认为是有特权的。
@@ -945,22 +952,24 @@ Restricted 策略需要强制执行 Linux 特有的限制（如 seccomp Profile
 There is not currently an API standard that controls whether a Pod is considered sandboxed or
 not. Sandbox Pods may be identified by the use of a sandboxed runtime (such as gVisor or Kata
 Containers), but there is no standard definition of what a sandboxed runtime is.
+-->
+### 沙箱（Sandboxed） Pod 怎么处理？
+
+现在还没有 API 标准来控制 Pod 是否被视作沙箱化 Pod。
+沙箱 Pod 可以通过其是否使用沙箱化运行时（如 gVisor 或 Kata Container）来辨别，
+不过目前还没有关于什么是沙箱化运行时的标准定义。
 
+<!--
 The protections necessary for sandboxed workloads can differ from others. For example, the need to
 restrict privileged permissions is lessened when the workload is isolated from the underlying
 kernel. This allows for workloads requiring heightened permissions to still be isolated.
 
 Additionally, the protection of sandboxed workloads is highly dependent on the method of
 sandboxing. As such, no single recommended policy is recommended for all sandboxed workloads.
 -->
-### 沙箱（Sandboxed） Pod 怎么处理？
-
-现在还没有 API 标准来控制 Pod 是否被视作沙箱化 Pod。
-沙箱 Pod 可以通过其是否使用沙箱化运行时（如 gVisor 或 Kata Container）来辨别，不过
-目前还没有关于什么是沙箱化运行时的标准定义。
-
 沙箱化负载所需要的保护可能彼此各不相同。例如，当负载与下层内核直接隔离开来时，
 限制特权化操作的许可就不那么重要。这使得那些需要更多许可权限的负载仍能被有效隔离。
 
 此外，沙箱化负载的保护高度依赖于沙箱化的实现方法。
 因此，现在还没有针对所有沙箱化负载的建议策略。
+