Sync 6 files under configure-pod-container/ with 1.22 version

content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md

@@ -217,14 +217,14 @@ Any code greater than or equal to 200 and less than 400 indicates success. Any
 other code indicates failure.
 
 You can see the source code for the server in
-[server.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/test/images/agnhost/liveness/server.go).
+[server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go).
 
 For the first 10 seconds that the container is alive, the `/healthz` handler
 returns a status of 200. After that, the handler returns a status of 500.
 -->
 任何大于或等于 200 并且小于 400 的返回代码标示成功，其它返回代码都标示失败。
 
-可以在这里看服务的源码 [server.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/test/images/agnhost/liveness/server.go)。
+可以在这里看服务的源码 [server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go)。
 
 容器存活的最开始 10 秒中，`/healthz` 处理程序返回一个 200 的状态码。之后处理程序返回 500 的状态码。
 
@@ -672,35 +672,52 @@ to resolve it.
 -->
 ### 探测器级别 `terminationGracePeriodSeconds`
 
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
 
 <!--
-Prior to release 1.21, the pod-level `terminationGracePeriodSeconds` was used
+In 1.21 and beyond, when the feature gate `ProbeTerminationGracePeriod` is
-for terminating a container that failed its liveness or startup probe. This
+enabled, users can specify a probe-level `terminationGracePeriodSeconds` as
-coupling was unintended and may have resulted in failed containers taking an
+part of the probe specification. When the feature gate is enabled, and both a
-unusually long time to restart when a pod-level `terminationGracePeriodSeconds`
+pod- and probe-level `terminationGracePeriodSeconds` are set, the kubelet will
-was set.
+use the probe-level value.
 -->
-在 1.21 版之前，pod 级别的 `terminationGracePeriodSeconds` 被用来终止
+在 1.21 及更高版本中，当特性门控 `ProbeTerminationGracePeriod` 为
-未能成功处理活跃性探测或启动探测的容器。
+启用状态时，用户可以指定一个探测级别的 `terminationGracePeriodSeconds` 作为
-这种耦合是意料之外的，可能会导致在设置了 pod 级别的 `terminationGracePeriodSeconds` 后，
+探针规格的一部分。当特性门控被启用时，并且
-需要很长的时间来重新启动失败的容器。
+Pod 级和探针级的 `terminationGracePeriodSeconds` 都已设置，kubelet 将
+使用探针级设置的值。
+
+{{< note >}}
+<!--
+As of Kubernetes 1.22, the `ProbeTerminationGracePeriod` feature gate is only
+available on the API Server. The kubelet always honors the probe-level
+`terminationGracePeriodSeconds` field if it is present on a Pod.
+-->
+从 Kubernetes 1.22 开始，`ProbeTerminationGracePeriod` 特性门控只
+在 API 服务器上可用。 kubelet 始终遵守探针级别
+`terminationGracePeriodSeconds` 字段（如果它存在于 Pod 上）。
 
 <!--
-In 1.21, when the feature flag `ProbeTerminationGracePeriod` is enabled, users
+If you have existing Pods where the `terminationGracePeriodSeconds` field is set and
-can specify a probe-level `terminationGracePeriodSeconds` as part of the probe
+you no longer wish to use per-probe termination grace periods, you must delete
-specification. When the feature flag is enabled, and both a pod- and
+those existing Pods.
-probe-level `terminationGracePeriodSeconds` are set, the kubelet will use the
-probe-level value.
-
-For example,
 -->
-在1.21中，启用特性标志 `ProbeTerminationGracePeriod` 后，
+如果你已经为现有 Pod 设置了 “terminationGracePeriodSeconds” 字段并且
-用户可以指定一个探测器级别的 `terminationGracePeriodSeconds` 作为探测器规格的一部分。
+不再希望使用针对每个探针的终止宽限期，则必须删除那些现有的 Pod。
-当该特性标志被启用时，若同时设置了 Pod 级别和探测器级别的 `terminationGracePeriodSeconds`，
-kubelet 将使用探测器级的值。
 
-例如，
+<!--
+When you (or the control plane, or some other component) create replacement
+Pods, and the feature gate `ProbeTerminationGracePeriod` is disabled, then the
+API server ignores the Pod-level `terminationGracePeriodSeconds` field, even if
+a Pod or pod template specifies it.
+-->
+当你（或控制平面或某些其他组件）创建替换
+Pods，并且特性门控 “ProbeTerminationGracePeriod” 被禁用，那么
+API 服务器会忽略 Pod 级别的 `terminationGracePeriodSeconds` 字段，即使
+Pod 或 Pod 模板指定了它。
+{{< /note >}}
+
+例如:
 
 ```yaml
 spec:

content/zh/docs/tasks/configure-pod-container/configure-runasusername.md

@@ -31,14 +31,17 @@ You need to have a Kubernetes cluster and the kubectl command-line tool must be
 <!--
 ## Set the Username for a Pod
 
-To specify the username with which to execute the Pod's container processes, include the `securityContext` field ([PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core) in the Pod specification, and within it, the `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core) field containing the `runAsUserName` field.
+To specify the username with which to execute the Pod's container processes, include the
+`securityContext` field ([PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)) 
+in the Pod specification, and within it, the `windowsOptions` 
+([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core)) field containing the `runAsUserName` field.
 -->
 ## 为 Pod 设置 Username
 
 要指定运行 Pod 容器时所使用的用户名，请在 Pod 声明中包含 `securityContext`
-（[PodSecurityContext](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)）字段，
+([PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)) 字段，
 并在其内部包含 `windowsOptions`
-（[WindowsSecurityContextOptions](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core)）
+([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core))
 字段的 `runAsUserName` 字段。
 
 <!--
@@ -106,13 +109,17 @@ ContainerUser
 <!--
 ## Set the Username for a Container
 
-To specify the username with which to execute a Container's processes, include the `securityContext` field ([SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)) in the Container manifest, and within it, the `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core) field containing the `runAsUserName` field.
+To specify the username with which to execute a Container's processes, include the `securityContext` field 
+([SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)) 
+in the Container manifest, and within it, the 
+`windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param 
+"version" >}}/#windowssecuritycontextoptions-v1-core)) field containing the `runAsUserName` field.
 -->
 
 ## 为容器设置 Username
 
 要指定运行容器时所使用的用户名，请在容器清单中包含 `securityContext`
-（[SecurityContext](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)）
+([SecurityContext](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core))
 字段，并在其内部包含 `windowsOptions`
 （[WindowsSecurityContextOptions](/zh/docs/reference/generated/kubernetes-api/{{< param
 "version" >}}/#windowssecuritycontextoptions-v1-core)）

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

@@ -262,8 +262,8 @@ The output is similar to this:
 Name:           build-robot-secret
 Namespace:      default
 Labels:         <none>
-Annotations:    kubernetes.io/service-account.name=build-robot
+Annotations:    kubernetes.io/service-account.name: build-robot
-                kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da
+                kubernetes.io/service-account.uid: da68f9c6-9d26-11e7-b84e-002dc52800da
 
 Type:   kubernetes.io/service-account-token
 
@@ -540,15 +540,18 @@ JSON Web Key Set（JWKS）。
 
 <!--
 Clusters include a default RBAC ClusterRole called
-`system:service-account-issuer-discovery`. No role bindings are provided
+`system:service-account-issuer-discovery`. A default RBAC ClusterRoleBinding
-by default. Administrators may, for example, choose whether to bind the role to
+assigns this role to the `system:serviceaccounts` group, which all service
+accounts implicitly belong to. This allows pods running on the cluster to access
+the service account discovery document via their mounted service account token.
+Administrators may, additionally, choose to bind the role to
 `system:authenticated` or `system:unauthenticated` depending on their security
 requirements and which external systems they intend to federate with.
 -->
-集群包括一个默认的 RBAC ClusterRole，
+集群包括一个的默认 RBAC ClusterRole, 名为 `system:service-account-issuer-discovery`。 
-名为 `system:service-account-issuer-discovery`。
+默认的 RBAC ClusterRoleBinding 将此角色分配给 `system:serviceaccounts` 组，
-默认情况下不提供角色绑定对象。
+所有服务帐户隐式属于该组。这使得集群上运行的 Pod 能够通过它们所挂载的服务帐户令牌访问服务帐户发现文档。
-举例而言，管理员可以根据其安全性需要以及期望集成的外部系统选择是否将该角色绑定到
+此外，管理员可以根据其安全性需要以及期望集成的外部系统选择是否将该角色绑定到
 `system:authenticated` 或 `system:unauthenticated`。
 
 <!--
@@ -596,11 +599,11 @@ JWKS URI is required to use the `https` scheme.
 See also:
 
 - [Cluster Admin Guide to Service Accounts](/docs/reference/access-authn-authz/service-accounts-admin/)
-- [Service Account Signing Key Retrieval KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190730-oidc-discovery.md)
+- [Service Account Signing Key Retrieval KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1393-oidc-discovery)
 - [OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html)
 -->
 另请参见：
 
 - [服务账号的集群管理员指南](/zh/docs/reference/access-authn-authz/service-accounts-admin/)
-- [服务账号签署密钥检索 KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190730-oidc-discovery.md)
+- [服务账号签署密钥检索 KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1393-oidc-discovery)
 - [OIDC 发现规范](https://openid.net/specs/openid-connect-discovery-1_0.html)

content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md

@@ -110,7 +110,7 @@ kubectl create secret docker-registry regcred \
 where:
 
 * `<your-registry-server>` is your Private Docker Registry FQDN.
-  Use `https://index.docker.io/v2/` for DockerHub.
+  Use `https://index.docker.io/v1/` for DockerHub.
 * `<your-name>` is your Docker username.
 * `<your-pword>` is your Docker password.
 * `<your-email>` is your Docker email.
@@ -120,7 +120,7 @@ You have successfully set your Docker credentials in the cluster as a Secret cal
 在这里：
 
 * `<your-registry-server>` 是你的私有 Docker 仓库全限定域名（FQDN）。
-  DockerHub 使用 `https://index.docker.io/v2/`。
+  DockerHub 使用 `https://index.docker.io/v1/`。
 * `<your-name>` 是你的 Docker 用户名。
 * `<your-pword>` 是你的 Docker 密码。
 * `<your-email>` 是你的 Docker 邮箱。

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

@@ -59,8 +59,12 @@ kubectl create namespace qos-example
 
 For a Pod to be given a QoS class of Guaranteed:
 
-* Every Container, including init containers, in the Pod must have a memory limit and a memory request, and they must be the same.
+* Every Container in the Pod must have a memory limit and a memory request.
-* Every Container, including init containers, in the Pod must have a CPU limit and a CPU request, and they must be the same.
+* For every Container in the Pod, the memory limit must equal the memory request.
+* Every Container in the Pod must have a CPU limit and a CPU request.
+* For every Container in the Pod, the CPU limit must equal the CPU request.
+
+These restrictions apply to init containers and app containers equally.
 
 Here is the configuration file for a Pod that has one Container. The Container has a memory limit and a
 memory request, both equal to 200 MiB. The Container has a CPU limit and a CPU request, both equal to 700 milliCPU:
@@ -69,8 +73,12 @@ memory request, both equal to 200 MiB. The Container has a CPU limit and a CPU r
 
 对于 QoS 类为 Guaranteed 的 Pod：
 
-* Pod 中的每个容器，包含初始化容器，必须指定内存请求和内存限制，并且两者要相等。
+* Pod 中的每个容器都必须指定内存限制和内存请求。
-* Pod 中的每个容器，包含初始化容器，必须指定 CPU 请求和 CPU 限制，并且两者要相等。
+* 对于 Pod 中的每个容器，内存限制必须等于内存请求。
+* Pod 中的每个容器都必须指定 CPU 限制和 CPU 请求。
+* 对于 Pod 中的每个容器，CPU 限制必须等于 CPU 请求。
+
+这些限制同样适用于初始化容器和应用程序容器。
 
 下面是包含一个容器的 Pod 配置文件。
 容器设置了内存请求和内存限制，值都是 200 MiB。

content/zh/docs/tasks/configure-pod-container/security-context.md

@@ -39,7 +39,7 @@ a Pod or Container. Security context settings include, but are not limited to:
   为进程赋予 root 用户的部分特权而非全部特权。
 <!--
 * [AppArmor](/docs/tutorials/clusters/apparmor/): Use program profiles to restrict the capabilities of individual programs.
-* [Seccomp](https://en.wikipedia.org/wiki/Seccomp): Filter a process's system calls.
+* [Seccomp](/docs/tutorials/clusters/seccomp/): Filter a process's system calls.
 * AllowPrivilegeEscalation: Controls whether a process can gain more
   privileges than its parent process. This bool directly controls whether the
   [`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt)
@@ -48,7 +48,7 @@ a Pod or Container. Security context settings include, but are not limited to:
 * readOnlyRootFilesystem: Mounts the container's root filesystem as read-only.
 -->
 * [AppArmor](/zh/docs/tutorials/clusters/apparmor/)：使用程序框架来限制个别程序的权能。
-* [Seccomp](https://en.wikipedia.org/wiki/Seccomp)：过滤进程的系统调用。
+* [Seccomp](/zh/docs/tutorials/clusters/seccomp/)：过滤进程的系统调用。
 * AllowPrivilegeEscalation：控制进程是否可以获得超出其父进程的特权。
   此布尔值直接控制是否为容器进程设置
   [`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt)标志。
@@ -299,6 +299,41 @@ and [`emptydir`](/docs/concepts/storage/volumes/#emptydir).
 这类临时性存储无效。
 {{< /note >}}
 
+<!--
+## Delegating volume permission and ownership change to CSI driver
+-->
+## 将卷权限和所有权更改委派给 CSI 驱动程序
+{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+
+<!--
+If you deploy a [Container Storage Interface (CSI)](https://github.com/container-storage-interface/spec/blob/master/spec.md)
+driver which supports the `VOLUME_MOUNT_GROUP` `NodeServiceCapability`, the
+process of setting file ownership and permissions based on the
+`fsGroup` specified in the `securityContext` will be performed by the CSI driver
+instead of Kubernetes, provided that the `DelegateFSGroupToCSIDriver` Kubernetes
+feature gate is enabled. In this case, since Kubernetes doesn't perform any
+ownership and permission change, `fsGroupChangePolicy` does not take effect, and
+as specified by CSI, the driver is expected to mount the volume with the
+provided `fsGroup`, resulting in a volume that is readable/writable by the
+`fsGroup`.
+
+Please refer to the [KEP](https://github.com/gnufied/enhancements/blob/master/keps/sig-storage/2317-fsgroup-on-mount/README.md)
+and the description of the `VolumeCapability.MountVolume.volume_mount_group`
+field in the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume)
+for more information.
+-->
+如果你部署了一个[容器存储接口 (CSI)](https://github.com/container-storage-interface/spec/blob/master/spec.md)
+驱动支持 `VOLUME_MOUNT_GROUP` `NodeServiceCapability`，
+在 `securityContext` 中指定 `fsGroup` 来设置文件所有权和权限的过程将由 CSI 驱动
+而不是 Kubernetes 来执行，前提是 Kubernetes 的 `DelegateFSGroupToCSIDriver` 
+特性门控已启用。在这种情况下，由于 Kubernetes 不执行任何
+所有权和权限更改，`fsGroupChangePolicy` 不会生效，并且
+按照 CSI 的规定，CSI 驱动应该使用所指定的 `fsGroup` 来挂载卷，从而生成了一个对 `fsGroup` 可读/可写的卷.
+
+更多的信息请参考 [KEP](https://github.com/gnufied/enhancements/blob/master/keps/sig-storage/2317-fsgroup-on-mount/README.md)
+和 [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume) 中的字
+段 `VolumeCapability.MountVolume.volume_mount_group` 的描述 。
+
 <!--
 ## Set the security context for a Container