Merge pull request #41815 from windsonsea/admiss

[zh] sync admission-controllers.md and configure-liveness-readiness-startup-probes.md

Author: k8s-ci-robot

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

@@ -4,7 +4,6 @@ linkTitle: 准入控制器
 content_type: concept
 weight: 30
 ---
-
 <!--
 reviewers:
 - lavalamp
@@ -342,7 +341,8 @@ This admission controller ignores any `PersistentVolumeClaim` updates; it acts o
 See [persistent volume](/docs/concepts/storage/persistent-volumes/) documentation about persistent volume claims and
 storage classes and how to mark a storage class as default.
 -->
-关于持久卷申领和存储类，以及如何将存储类标记为默认，请参见[持久卷](/zh-cn/docs/concepts/storage/persistent-volumes/)页面。
+关于持久卷申领和存储类，以及如何将存储类标记为默认，
+请参见[持久卷](/zh-cn/docs/concepts/storage/persistent-volumes/)页面。
 
 ### DefaultTolerationSeconds {#defaulttolerationseconds}
 
@@ -505,6 +505,20 @@ This file may be json or yaml and has the following format:
 ImagePolicyWebhook 使用配置文件来为后端行为设置选项。该文件可以是 JSON 或 YAML，
 并具有以下格式:
 
+<!--
+```yaml
+imagePolicy:
+  kubeConfigFile: /path/to/kubeconfig/for/backend
+  # time in s to cache approval
+  allowTTL: 50
+  # time in s to cache denial
+  denyTTL: 50
+  # time in ms to wait between retries
+  retryBackoff: 500
+  # determines behavior if the webhook backend fails
+  defaultAllow: true
+```
+-->
 ```yaml
 imagePolicy:
   kubeConfigFile: /path/to/kubeconfig/for/backend
@@ -635,15 +649,14 @@ group (`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`).
 -->
 注意，Webhook API 对象与其他 Kubernetes API 对象一样受制于相同的版本控制兼容性规则。
 实现者应该知道对 alpha 对象兼容性是相对宽松的，并检查请求的 "apiVersion" 字段，
-以确保正确的反序列化。
-此外，API 服务器必须启用 `imagepolicy.k8s.io/v1alpha1` API 扩展组
+以确保正确的反序列化。此外，API 服务器必须启用 `imagepolicy.k8s.io/v1alpha1` API 扩展组
 （`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`）。
 {{< /note >}}
 
 <!--
 An example request body:
 -->
-请求载荷示例：
+请求体示例：
 
 ```json
 {
@@ -808,7 +821,7 @@ group/version via the `--runtime-config` flag, both are on by default.
 <!--
 #### Use caution when authoring and installing mutating webhooks
 -->
-#### 谨慎编写和安装变更 webhook  {#use-caution-when-authoring-and-installing-mutating-webhooks}
+#### 谨慎编写和安装变更 Webhook  {#use-caution-when-authoring-and-installing-mutating-webhooks}
 
 <!--
 * Users may be confused when the objects they try to create are different from
@@ -860,8 +873,7 @@ This admission controller also prevents deletion of three system reserved namesp
 `kube-system`, `kube-public`.
 -->
 该准入控制器禁止在一个正在被终止的 `Namespace` 中创建新对象，并确保针对不存在的
-`Namespace` 的请求被拒绝。
-该准入控制器还会禁止删除三个系统保留的名字空间，即 `default`、
+`Namespace` 的请求被拒绝。该准入控制器还会禁止删除三个系统保留的名字空间，即 `default`、
 `kube-system` 和 `kube-public`。
 
 <!--
@@ -1006,8 +1018,7 @@ This admission controller is disabled by default.
 此准入控制器会自动将由云提供商（如 Azure 或 GCP）定义的区（region）或区域（zone）
 标签附加到 PersistentVolume 上。这有助于确保 Pod 和 PersistentVolume 位于相同的区或区域。
 如果准入控制器不支持为 PersistentVolumes 自动添加标签，那你可能需要手动添加标签，
-以防止 Pod 挂载其他区域的卷。
-PersistentVolumeLabel **已被弃用**，
+以防止 Pod 挂载其他区域的卷。PersistentVolumeLabel **已被弃用**，
 为持久卷添加标签的操作已由{{< glossary_tooltip text="云管理控制器" term_id="cloud-controller-manager" >}}接管。
 
 此准入控制器默认被禁用。
@@ -1129,7 +1140,7 @@ admitted, determines if it should be admitted based on the requested security co
 for the namespace that the Pod would be in.
 -->
 PodSecurity 准入控制器在新 Pod 被准入之前对其进行检查，
-根据请求的安全上下文和 Pod 所在命名空间允许的
+根据请求的安全上下文和 Pod 所在名字空间允许的
 [Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards/)的限制来确定新 Pod
 是否应该被准入。
 
@@ -1253,21 +1264,34 @@ for more information.
 
 ### SecurityContextDeny {#securitycontextdeny}
 
-{{< feature-state for_k8s_version="v1.0" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.27" state="deprecated" >}}
 
 {{< caution >}}
 <!--
-This admission controller plugin is **outdated** and **incomplete**, it may be
-unusable or not do what you would expect. It was originally designed to prevent
-the use of some, but not all, security-sensitive fields. Indeed, fields like
-`privileged`, were not filtered at creation and the plugin was not updated with
-the most recent fields, and new APIs like the `ephemeralContainers` field for a
-Pod.
+The Kubernetes project recommends that you **do not use** the
+`SecurityContextDeny` admission controller.
+
+The `SecurityContextDeny` admission controller plugin is deprecated and disabled
+by default. It will be removed in a future version. If you choose to enable the
+`SecurityContextDeny` admission controller plugin, you must enable the
+`SecurityContextDeny` feature gate as well.
+-->
+Kubernetes 项目建议你**不要使用** `SecurityContextDeny` 准入控制器。
+
+`SecurityContextDeny` 准入控制器插件已被弃用，并且默认处于禁用状态。
+此插件将在后续的版本中被移除。如果你选择启用 `SecurityContextDeny` 准入控制器插件，
+也必须同时启用 `SecurityContextDeny` 特性门控。
+
+<!--
+The `SecurityContextDeny` admission plugin is deprecated because it is outdated
+and incomplete; it may be unusable or not do what you would expect. As
+implemented, this plugin is unable to restrict all security-sensitive attributes
+of the Pod API. For example, the `privileged` and `ephemeralContainers` fields
+were never restricted by this plugin.
 -->
-这个准入控制器插件是**过时的**且**不完整的**，它可能无法使用或无法达到你的预期。
-它最初旨在防止使用某些（但不是全部）安全敏感字段。
-事实上，像 `privileged` 这样的字段在创建时并没有被过滤，
-而且该插件没有根据最新的字段和新的 API（例如 Pod 的 `ephemeralContainers` 字段）来更新。
+`SecurityContextDeny` 准入插件已被弃用，因为它已经过时且不完整；
+它可能无法使用或无法达到你的预期。该插件实现之时，就无法限制 Pod API 的所有与安全相关的属性。
+例如，`privileged` 和 `ephemeralContainers` 字段就从未受过此插件的限制。
 
 <!--
 The [Pod Security Admission](/docs/concepts/security/pod-security-admission/)
@@ -1333,8 +1357,8 @@ Refer to the
 for more detailed information.
 -->
 `StorageObjectInUseProtection` 插件将 `kubernetes.io/pvc-protection` 或
-`kubernetes.io/pv-protection` finalizers 添加到新创建的持久卷申领（PVC）
-或持久卷（PV）中。如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除终结器（finalizers），
+`kubernetes.io/pv-protection` 终结器（finalizers）添加到新创建的持久卷申领（PVC）
+或持久卷（PV）中。如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除终结器，
 否则 PVC/PV 不会被删除。有关更多详细信息，
 请参考[保护使用中的存储对象](/zh-cn/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)。
 
@@ -1406,4 +1430,3 @@ You can enable additional admission controllers beyond the default set using the
 （请查看[这里](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/#options)）。
 因此，你无需显式指定它们。
 你可以使用 `--enable-admission-plugins` 标志（ **顺序不重要** ）来启用默认设置以外的其他准入控制器。
-

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

@@ -13,17 +13,17 @@ weight: 140
 <!--
 This page shows how to configure liveness, readiness and startup probes for containers.
 
-The [kubelet](/docs/reference/command-line-tools-reference/kubelet/) uses liveness probes to know when to
-restart a container. For example, liveness probes could catch a deadlock,
-where an application is running, but unable to make progress. Restarting a
-container in such a state can help to make the application more available
-despite bugs.
+The [kubelet](/docs/reference/command-line-tools-reference/kubelet/) uses
+liveness probes to know when to restart a container. For example, liveness
+probes could catch a deadlock, where an application is running, but unable to
+make progress. Restarting a container in such a state can help to make the
+application more available despite bugs.
 -->
 这篇文章介绍如何给容器配置存活（Liveness）、就绪（Readiness）和启动（Startup）探针。
 
 [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/)
 使用存活探针来确定什么时候要重启容器。
-例如，存活探针可以探测到应用死锁（应用程序在运行，但是无法继续执行后面的步骤）情况。
+例如，存活探针可以探测到应用死锁（应用在运行，但是无法继续执行后面的步骤）情况。
 重启这种状态下的容器有助于提高应用的可用性，即使其中存在缺陷。
 
 <!--
@@ -41,7 +41,7 @@ One use of this signal is to control which Pods are used as backends for Service
 When a Pod is not ready, it is removed from Service load balancers.
 
 The kubelet uses startup probes to know when a container application has started.
-If such a probe is configured, it disables liveness and readiness checks until
+If such a probe is configured, liveness and readiness probes do not start until
 it succeeds, making sure those probes don't interfere with the application startup.
 This can be used to adopt liveness checks on slow starting containers, avoiding them
 getting killed by the kubelet before they are up and running.
@@ -52,8 +52,7 @@ kubelet 使用就绪探针可以知道容器何时准备好接受请求流量，
 若 Pod 尚未就绪，会被从 Service 的负载均衡器中剔除。
 
 kubelet 使用启动探针来了解应用容器何时启动。
-如果配置了这类探针，你就可以控制容器在启动成功后再进行存活性和就绪态检查，
-确保这些存活、就绪探针不会影响应用的启动。
+如果配置了这类探针，存活探针和就绪探针成功之前不会重启，确保这些探针不会影响应用的启动。
 启动探针可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。
 
 {{< caution >}}
@@ -74,9 +73,9 @@ scalable; and increased workload on remaining pods due to some failed pods.
 Understand the difference between readiness and liveness probes and when to apply them for your app.
 -->
 错误的存活探针可能会导致级联故障。
-这会导致在高负载下容器重启；例如由于应用程序无法扩展，导致客户端请求失败；以及由于某些
+这会导致在高负载下容器重启；例如由于应用无法扩展，导致客户端请求失败；以及由于某些
 Pod 失败而导致剩余 Pod 的工作负载增加。了解就绪探针和存活探针之间的区别，
-以及何时为应用程序配置使用它们非常重要。
+以及何时为应用配置使用它们非常重要。
 {{< /note >}}
 
 ## {{% heading "prerequisites" %}}
@@ -389,7 +388,7 @@ kubelet 可以配置为使用该协议来执行应用存活性检查。
 [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
 才能配置依赖于 gRPC 的检查机制。
 
-这个例子展示了如何配置 Kubernetes 以将其用于应用程序的存活性检查。
+这个例子展示了如何配置 Kubernetes 以将其用于应用的存活性检查。
 类似地，你可以配置就绪探针和启动探针。
 
 下面是一个示例清单：
@@ -557,7 +556,7 @@ provide a fast response to container deadlocks.
 If the startup probe never succeeds, the container is killed after 300s and
 subject to the pod's `restartPolicy`.
 -->
-幸亏有启动探测，应用程序将会有最多 5 分钟（30 * 10 = 300s）的时间来完成其启动过程。
+幸亏有启动探测，应用将会有最多 5 分钟（30 * 10 = 300s）的时间来完成其启动过程。
 一旦启动探测成功一次，存活探测任务就会接管对容器的探测，对容器死锁作出快速响应。
 如果启动探测一直没有成功，容器会在 300 秒后被杀死，并且根据 `restartPolicy`
 来执行进一步处置。
@@ -646,7 +645,9 @@ liveness and readiness checks:
 
 <!--
 * `initialDelaySeconds`: Number of seconds after the container has started before startup,
-  liveness or readiness probes are initiated. Defaults to 0 seconds. Minimum value is 0.
+  liveness or readiness probes are initiated. If a startup  probe is defined, liveness and
+  readiness probe delays do not begin until the startup probe has succeeded.
+  Defaults to 0 seconds. Minimum value is 0.
 * `periodSeconds`: How often (in seconds) to perform the probe. Default to 10 seconds.
   The minimum value is 1.
 * `timeoutSeconds`: Number of seconds after which the probe times out.
@@ -655,7 +656,8 @@ liveness and readiness checks:
   after having failed. Defaults to 1. Must be 1 for liveness and startup Probes.
   Minimum value is 1.
 -->
-* `initialDelaySeconds`：容器启动后要等待多少秒后才启动启动、存活和就绪探针，
+* `initialDelaySeconds`：容器启动后要等待多少秒后才启动启动、存活和就绪探针。
+  如果定义了启动探针，则存活探针和就绪探针的延迟将在启动探针已成功之后才开始计算。
   默认是 0 秒，最小值是 0。
 * `periodSeconds`：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。
 * `timeoutSeconds`：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。